java ssl: chrome / firefox sends “G” in http header instead of “GET / HTTP/1.1”

Question

Hi I am trying out a simple java http server NanoHTTPD: http://elonen.iki.fi/code/nanohttpd/

Today I try to support it with HTTPS, so I create SSLServerSocket in its NanoHTTPD constructor:

// myServerSocket = new ServerSocket(myTcpPort);
myServerSocket = SSLServerSocketFactory.getDefault().createServerSocket(myTcpPort);

and also supplied javax.net.ssl.keyStore with 2048 bit RSA key

The result is that https connections succeed on MSIE6.0, MSIE8.0, Firefox 9.0.1 However fail on Google Chrome 17.0.963.56 m and Firefox 10.0.1:

from debugging, NanoHTTPD.HTTPSession.decodeHeader method gets only String inLine = "G" barely one single char, while normally here you will expect the standard http header "GET / HTTP/1.1".

So anybody familiar with Firefox could tell what's different in 9.0.1 and 10.0.1 regarding https / ssl? Something made by browsers may be the point. (Of course I am newbie in java ssl programming, please tell me if I am wrong in SSLServerSocket).

I have cross posted this issue: https://support.mozilla.org/en-US/questions/920116

Thank you all.

Answer 1

The short of it is that your SSL implementation is broken. SSL records can be split in arbitrary ways, and Google and Mozilla changed the way they split theirs to work around some MITM attacks on SSL. Specifically, a 1-byte SSL record is sent before sendinga second SSL record with the rest of the data. It sounds like your SSL implementation is only reading the first record instead of reading all the data.

See http://rt.openssl.org/Ticket/Display.html?id=2635&user=guest&pass=guest and https://bugzilla.mozilla.org/show_bug.cgi?id=665814 and articles like http://www.livehacking.com/2011/10/27/chrome-15-broke-the-wall-street-journal-while-trying-to-beat-the-beast/

Answer 2

I can confirm the SSLEngine from java appears broken by default. The way I can get around it is:

^Cpck0:bin vladimirralev$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-ssl-false-start --use-spdy=off --use-system-ssl

That turns off the weird TLS modes.

It looks like recent SSLEngine will behave correctly if you keep following the instructions it gives you to read a segmented packets. You have to loop through multiple reads (with some intermittent states in between) and you will have the complete chunk eventually.