New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migrate to full HTTPS by default #1123

Closed
fvanderbiest opened this Issue Nov 16, 2015 · 12 comments

Comments

Projects
None yet
4 participants
@fvanderbiest
Member

fvanderbiest commented Nov 16, 2015

With the advent of https://letsencrypt.org/ I see no reason to keep unsecured transfers to the browser by default.
Proposal: migrate everything to https by default, including the documentation.

@fvanderbiest fvanderbiest added this to the 15.12 milestone Nov 16, 2015

@landryb

This comment has been minimized.

Show comment
Hide comment
@landryb

landryb Nov 17, 2015

Member

so much +1, even if i hate the complexity nightmare of TLS :)

Member

landryb commented Nov 17, 2015

so much +1, even if i hate the complexity nightmare of TLS :)

@fphg

This comment has been minimized.

Show comment
Hide comment
@fphg

fphg Nov 17, 2015

Member

You mean : sdi.georchestra.org ? Or geOrchestra instances ?

Member

fphg commented Nov 17, 2015

You mean : sdi.georchestra.org ? Or geOrchestra instances ?

@fvanderbiest

This comment has been minimized.

Show comment
Hide comment
@fvanderbiest

fvanderbiest Nov 19, 2015

Member

I mean: the geOrchestra install documentation + template configuration should target an HTTPS setup by default for 15.12. Having a mixed HTTP/HTTPS setup will still be possible, but will require more changes.

Side-effect: sdi.georchestra.org should also switch to https.

Member

fvanderbiest commented Nov 19, 2015

I mean: the geOrchestra install documentation + template configuration should target an HTTPS setup by default for 15.12. Having a mixed HTTP/HTTPS setup will still be possible, but will require more changes.

Side-effect: sdi.georchestra.org should also switch to https.

@fphg

This comment has been minimized.

Show comment
Hide comment
@fphg

fphg Nov 19, 2015

Member

Le 19/11/2015 09:39, François Van Der Biest a écrit :

I mean: the geOrchestra install documentation + template configuration
should target an HTTPS setup by default for 15.12. Having a mixed
HTTP/HTTPS setup will still be possible, but will require more
changes.

Side-effect: sdi.georchestra.org should also switch to https.

While I'm convinced of https interest, I still find it amazingly
difficult to (correctly) set up. The IDS may move to full encrypted
streams but what about the third party clients ? Do referers have to
switch ?


Reply to this email directly or view it on GitHub:
#1123 (comment)

Fabrice Phung

Member

fphg commented Nov 19, 2015

Le 19/11/2015 09:39, François Van Der Biest a écrit :

I mean: the geOrchestra install documentation + template configuration
should target an HTTPS setup by default for 15.12. Having a mixed
HTTP/HTTPS setup will still be possible, but will require more
changes.

Side-effect: sdi.georchestra.org should also switch to https.

While I'm convinced of https interest, I still find it amazingly
difficult to (correctly) set up. The IDS may move to full encrypted
streams but what about the third party clients ? Do referers have to
switch ?


Reply to this email directly or view it on GitHub:
#1123 (comment)

Fabrice Phung

@fvanderbiest

This comment has been minimized.

Show comment
Hide comment
@fvanderbiest

fvanderbiest Nov 19, 2015

Member

I'd say, it depends on the clients.
Some of them will follow the 302 redirection to https without raising an eyebrow, some probably won't...

Member

fvanderbiest commented Nov 19, 2015

I'd say, it depends on the clients.
Some of them will follow the 302 redirection to https without raising an eyebrow, some probably won't...

@fvanderbiest

This comment has been minimized.

Show comment
Hide comment
@fvanderbiest

This comment has been minimized.

Show comment
Hide comment
@fvanderbiest

fvanderbiest Jan 12, 2016

Member

Done. There are probably minor squirks here and there, but we'll fix them as we go.

Member

fvanderbiest commented Jan 12, 2016

Done. There are probably minor squirks here and there, but we'll fix them as we go.

@landryb

This comment has been minimized.

Show comment
Hide comment
@landryb

landryb Jan 12, 2016

Member

So i'm all for HTTPS & letsencrypt, but if i try to harvest https://sdi.georchestra.org/geonetwork/ from a standalone GN3 instance, when fetching sources it immediately fails with (request from the proxy):

Some unexpected error occurred. Error text was: Received fatal alert: handshake_failure

and the traceback in catalina.out

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1098)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)

Trying to work it around by importing LE's X1 root in the keystore:

wget https://letsencrypt.org/certs/letsencryptauthorityx1.der
keytool -importcert -alias letsencrypt -file letsencryptauthorityx1.der -keystore /path/to/keystore -storepass password -noprompt

But apparently that's not the right root/certificate to add to validate the chain.

Member

landryb commented Jan 12, 2016

So i'm all for HTTPS & letsencrypt, but if i try to harvest https://sdi.georchestra.org/geonetwork/ from a standalone GN3 instance, when fetching sources it immediately fails with (request from the proxy):

Some unexpected error occurred. Error text was: Received fatal alert: handshake_failure

and the traceback in catalina.out

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
        at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
        at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1991)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1098)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1344)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1371)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:275)
        at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:254)

Trying to work it around by importing LE's X1 root in the keystore:

wget https://letsencrypt.org/certs/letsencryptauthorityx1.der
keytool -importcert -alias letsencrypt -file letsencryptauthorityx1.der -keystore /path/to/keystore -storepass password -noprompt

But apparently that's not the right root/certificate to add to validate the chain.

@pmauduit

This comment has been minimized.

Show comment
Hide comment
@pmauduit

pmauduit Jan 12, 2016

Member

FYI on debian distro, the default truststore is here: /etc/ssl/certs/java/cacerts, but you have some hooks that can be used, if you have the following packages installed: ca-certificates and ca-certificates-java.

You should be able to save the certificate under /usr/local/share/ca-certificates/ (with the .crt suffix, not PEM !), then launch the update-ca-certificates command as root.

That's theoric, unfortunately: even with every certificates from https://letsencrypt.org/certificates/ I was not able to have my JVM trust sdi.g.o:443

Member

pmauduit commented Jan 12, 2016

FYI on debian distro, the default truststore is here: /etc/ssl/certs/java/cacerts, but you have some hooks that can be used, if you have the following packages installed: ca-certificates and ca-certificates-java.

You should be able to save the certificate under /usr/local/share/ca-certificates/ (with the .crt suffix, not PEM !), then launch the update-ca-certificates command as root.

That's theoric, unfortunately: even with every certificates from https://letsencrypt.org/certificates/ I was not able to have my JVM trust sdi.g.o:443

@landryb

This comment has been minimized.

Show comment
Hide comment
@landryb

landryb Jan 12, 2016

Member

I also tried with https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.der since that's supposed to be the cert from which LE's certs are signed, but that didnt help with the handshake issue. Same thing if i directly import the certificate from sdi.georchestra.org in the keystore, it still fails. SSHell.....

Member

landryb commented Jan 12, 2016

I also tried with https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.der since that's supposed to be the cert from which LE's certs are signed, but that didnt help with the handshake issue. Same thing if i directly import the certificate from sdi.georchestra.org in the keystore, it still fails. SSHell.....

@pmauduit

This comment has been minimized.

Show comment
Hide comment
@pmauduit

pmauduit Jan 12, 2016

Member

You can use the following Java class to test SSL remote services: https://gist.github.com/pmauduit/2efbb1a374cbbc4327ec

Member

pmauduit commented Jan 12, 2016

You can use the following Java class to test SSL remote services: https://gist.github.com/pmauduit/2efbb1a374cbbc4327ec

@fvanderbiest

This comment has been minimized.

Show comment
Hide comment
@fvanderbiest

fvanderbiest Feb 9, 2016

Member

Related commit: 7d6956a

Member

fvanderbiest commented Feb 9, 2016

Related commit: 7d6956a

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment