java ssl：chrome / firefox 发送“G”在 http 标头中而不是“GET / HTTP/1.1”
您好，我正在尝试一个简单的 java http 服务器 NanoHTTPD： http://elonen.iki.fi/code/ nanohttpd/
今天我尝试用 HTTPS 支持它，因此我在其 NanoHTTPD 构造函数中创建了 SSLServerSocket：
// myServerSocket = new ServerSocket(myTcpPort);
myServerSocket = SSLServerSocketFactory.getDefault().createServerSocket(myTcpPort);
并且还提供了javax.net.ssl.keyStore 具有 2048 位 RSA 密钥
结果是 https 连接在 MSIE6.0、MSIE8.0、Firefox 9.0.1 上成功 然而，在 Google Chrome 17.0.963.56 m 和 Firefox 10.0.1 上失败：
通过调试，NanoHTTPD.HTTPSession.decodeHeader 方法仅获取 String inLine = "G" 几乎没有一个字符，而通常在这里您会期望标准的 http 标头“GET / HTTP/1.1”。
那么任何熟悉 Firefox 的人都可以看出 9.0.1 和 10.0.1 中关于 https / ssl 的不同之处吗？浏览器制作的东西可能才是重点。 （当然我是java ssl编程的新手，请告诉我我在SSLServerSocket方面是否错误）。
我已经交叉发布了这个问题： https://support.mozilla.org/en-US/questions/920116
谢谢大家。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
缺点是您的 SSL 实施已损坏。 SSL 记录可以以任意方式分割，Google 和 Mozilla 改变了分割方式，以解决 SSL 上的一些 MITM 攻击。具体来说，在发送带有其余数据的第二个 SSL 记录之前先发送 1 字节 SSL 记录。听起来您的 SSL 实现只读取第一条记录，而不是读取所有数据。
请参阅 http://rt.openssl.org/ Ticket/Display.html?id=2635&user=guest&pass=guest 和 https://bugzilla.mozilla.org/show_bug.cgi?id=665814 和文章就像http://www.livehacking.com/2011/10/27/chrome-15-broke-the-wall-street-journal-while-trying-to-beat-the-beast/
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/
我可以确认 java 的 SSLEngine 默认情况下似乎已损坏。我可以解决这个问题的方法是：
关闭奇怪的 TLS 模式。
如果您继续按照它提供的说明读取分段数据包，最新的 SSLEngine 似乎会正常运行。您必须循环多次读取（中间有一些间歇状态），最终您将获得完整的块。
I can confirm the SSLEngine from java appears broken by default. The way I can get around it is:
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.