brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Macartney (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (BROOKLYN-456) "SSLException: internal_error" upon trying to connect to site requiring SNI
Date Tue, 28 Mar 2017 09:11:41 GMT

    [ https://issues.apache.org/jira/browse/BROOKLYN-456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15944833#comment-15944833
] 

Geoff Macartney commented on BROOKLYN-456:
------------------------------------------

Looks good [~m4rkmckenna], definitely there's something we are doing in the construction of
the HttpClient down in HttpTool that is causing us to not send the SNI (Compare the results
of [HttpToolSNITest|https://github.com/apache/brooklyn-server/blob/master/core/src/test/java/org/apache/brooklyn/util/core/http/HttpToolSNITest.java#L63]
with your example ( with -Djavax.net.debug=ssl:handshake), where your test has the SNI header
in the ClientHello output:

{code}
Extension server_name, server_name: [type=host_name (0), value=httpbin.org]
{code}

and the Brooklyn code doesn't.  It's probably down to an issue with custom HostNameVerifier
described [here on SO|http://stackoverflow.com/questions/41692736/all-trusting-hostnameverifier-causes-ssl-errors-with-httpurlconnection]
but I haven't worked out yet how to update the Brooklyn code to fix it. I'll try to get another
look at it soon.



> "SSLException: internal_error" upon trying to connect to site requiring SNI
> ---------------------------------------------------------------------------
>
>                 Key: BROOKLYN-456
>                 URL: https://issues.apache.org/jira/browse/BROOKLYN-456
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Geoff Macartney
>            Priority: Minor
>
> On 17th March brooklyn-server builds began failing, such as https://builds.apache.org/view/Brooklyn/job/brooklyn-server-master/492/.

> The errors were failures in tests 
> {quote}
> org.apache.brooklyn.camp.brooklyn.HttpCommandEffectorYamlRebindTest.testRebindWhenHealthy
> org.apache.brooklyn.camp.brooklyn.HttpCommandEffectorYamlTest.testHttpCommandEffectorWithParameters
> org.apache.brooklyn.camp.brooklyn.CompositeEffectorYamlRebindTest.testRebindWhenHealthy
> org.apache.brooklyn.camp.brooklyn.CompositeEffectorYamlTest.testCompositeEffector
> {quote}
> all of which issued requests to "https://httpbin.org" for test purposes.
> There seems to have been a change in configuration on httpbin.org on the 16h of March,
see [here|https://lists.apache.org/thread.html/2d7bfb556b5459590d266d079043861bc34c0b921a2b5346ae9fd8ae@%3Cdev.brooklyn.apache.org%3E].
> However the certificate changes appear not to be the problem, as far as I can tell, as
the certificate chain from the site has root "Let's Encrypt Authority X3" (SHA1 Fingerprint=E6:A3:B4:5B:06:2D:50:9B:33:82:28:2D:19:6E:FE:97:D5:95:6C:CB),
which is signed by CA "DST Root CA X3"  (Certificate fingerprint DA:C9:02:4F:54:D8:F6:DF:94:93:5F:B1:73:26:38:CA:6A:D7:7C:13),
which is in the cacerts file of Java 8 by default.
> I believe the problem lies on the Java SSL client side, specifically that the client
is not including the SNI (Server Naming Indicator) extension in the SSL handshake.  httpbin
requires this, compare 
> {code}
> openssl s_client -showcerts -connect httpbin.org:443  </dev/null
> CONNECTED(00000003)
> 7944:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.1/src/ssl/s23_lib.c:185:
> {code}
> with the output from 
> {code}
> openssl s_client -servername httpbin.org  -showcerts -connect httpbin.org:443  </dev/null
> {code}
> The result is that the connection attempt fails with 
> {code}
> SSLException: Received fatal alert: internal_error
> {code}
> Searching around the web there seem to be a number of other people who have encountered
this problem, e.g. https://forums.aws.amazon.com/message.jspa?messageID=669911.  The issue
seems to be fixed only in Java 9, but there may be workarounds on 7 and 8. I haven't tried
these out yet. 
> I will look at adding a test in Brooklyn to record this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message