using nginx to reverse proxy to neo4j webadmin - problem on ubuntu 12.04 (to do with openssl version)

[j2d3]

So, in order to secure access to the webadmin area running on port 7473, I reverse proxy with nginx. This worked fine until I upgraded from an ubuntu 10.04 to 12.04 image.

At that point, I started getting bad gateway, and in the nginx error log something like this:

SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

I figured the problem had to do with the self signed certificates, so I tried reverse proxying to the non-ssl version of the webadmin control panel like this:

https / 443 / nginx --> http / 7474 / neo4j

This unfortunately doesn't work because of mixed content, some calls in javascript that go to http instead of https, etc. Generally, it just doesn't work.

Then I thought I'd use my own certs, but it seems the one I have is not of an acceptable format to neo4j.

I would like to just get https / 443 / nginx --> https /7473 / neo4j - the setup that was working before, to work again.

I found this (among several other sites) that explain some about the nature of this particular problem, and this approach interests me the most (easiest seeming fix):

http://georgik.sinusgear.com/2012/02/19/tomcat-7-and-curl-ssl23_get_server_hellotlsv1-alert-internal-error/

This is about how to restrict the cypher used in a tomcat server that exhibits this error when trying to access it with curl... 

so finally, my question:

Is there an equivalent way to restrict the cyphers used by neo4j's https connection?

[John Durkin]

Additional notes:

This page also has a lot of info on the problem:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/861137

It mentions the strategy of forcing the sending/requesting client to use SSLv3 and telling it to use a particular (set of) ciphers rather than trying to restrict the ciphers on the receiving/target server (in most users' cases, they are experiencing problems when proxying or requesting over https to a tomcat server). I tried this in my nginx configuration, setting the proxy_protocol to SSLv3, and setting proxy_ciphers, but none of this seems to work for me. Interestingly adding -sslv3 to curl *does* fix the problem (you can see the problem if you try doing curl https://127.0.0.1:7473 locally on a machine running neo4j with https enabled on 7473 - it generates the same error message i see in my nginx error logs)

[Javier de la Rosa]

Hi John,

Did you get this error fixed? I'd really appreciate if you explain how you fixed it.

Regards.

--
 
 

--
Javier de la Rosa
http://versae.es

[John Durkin]

unfortunately, no, I have not fixed the problem, but i did come across this, https://github.com/neo4j/authentication-extension - which seems like it might be a good fix since it looks like i wouldn't need to proxy with nginx or apache to get basic auth, but I have not tried it yet.

If I get to it soon I'll let you know if that works for me, or if you try it out first let me know if it works for you!

--
 
 

[Dave Stern (FiftyThree)]

I'm not sure if this will help, but I use the authentication extension with high availability on EC2 instances. These are behind an AWS ELB load balancer. Unfortunately, you cannot add username and password to the PING PATH for ELB health checks. So I use apache2 on ubuntu 12.04 with mod_proxy to proxy requests internally from an arbitrary port, sending the base64 encoded username:password to neo4j on the same instance. Because we set the firewall to only allow requests on this port internally, there is no security issue. 

It looks conceptually something like this (assuming the port we ping with the ELB is 8000 for this example):

ELB ---> neo4j instance: 8000 --- proxy w/password --> same neo4j instance: 7474

Here's what the relevant part of the apache config file looks like:

<VirtualHost *:8000>

    ProxyPass           / http://127.0.0.1:7474/ha-info/masterinfo/isMaster
    ProxyPassReverse    / http://127.0.0.1:7474/ha-info/masterinfo/isMaster
    RequestHeader set Authorization "Basic [base 64 encoded username:password]"

</VirtualHost>

[Javier de la Rosa]

On Thu, Dec 6, 2012 at 9:53 AM, Dave Stern (FiftyThree) <da...@fiftythree.com> wrote:

ELB

Thanks guys, I definitively have to try ELB, my entire ecosystem run on AWS. What I was able to get was:

    Nginx (SSL with PEM certs) → Neo4j:8000 (not open to Internet) → authentication-extension [1] → Neo4j:7474.

However, the webadmin interface didn't work as expected and I was getting that weird error http://host:port/db/data/?_=1354833348195

I think that finally, even if I don't like so much, I will use authentication-extension over the port 7474.

Best regards.

[1] https://github.com/neo4j/authentication-extension

[Michael Hunger]

Che,

Thanks a lot for the pointer !

Neo4j is right now only supported for oracle/sun-jdk6. So probably that's why it wasn't resolved earlier?

I would love if you could write up this email as a quick blog post, so that the information is out there for others to find too?

Thanks,

Michael

Am 12.01.2013 um 01:57 schrieb Che Ruisi-Besares:

Hey guys I was working on this last night when I stumbled on this thread. I don't know if you care about which jdk your using but I found this bug report https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1006776 and figured I would try a different jdk. Long story short I uninstalled openjdk -6 ( Im not sure if your using that ) and installed from oracles repo like this:

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java6-installer

The following nginx config got me the rest of the way ( I have some extras in the proxy settings but you can strip them out.. if you even need the config file at all.

server {

listen 443 default ssl;

        root /path/to/site;

        access_log /path/to/log/access.log;

        error_log /path/to/log/error.log;

        server_name yourdomain.com;

      

ssl on;

ssl_certificate /path/to/ssl/something.pem;

ssl_certificate_key /path/to/ssl/something.key;

        location / {

                auth_basic "Restriced";

                auth_basic_user_file  /path/to/auth/pass;

                proxy_set_header X-Real-IP $remote_addr;

                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

                proxy_set_header Host $http_host;

                proxy_redirect off;

                proxy_buffering off;

proxy_set_header X_FORWARDED_PROTO https;

                proxy_pass https://localhost:7473/;

        }

}

Anyway don't know if that will help you out. I wound up going with java-7 in the end even though it throws a warning. If there are other ways you found I would be intrested.

Che

--