Thanks Tim for the analysis.
In my case, the FF client didn't send the initial handshake on TLS at
all, instead it started with SSLv2. So there was no TLS handshake
failure. Have confirmed this by analyzing the packet capture(which I
have enclosed in my earlier email). I have raised this issue(using SSLv2
format even though SSLv2 is disabled) with firefox-security-dev
mailing-list, but no reply from them about this behavior.
Just want to reiterate the point that the following cipher suites seems to cause the
server to "Internal error" state.
When I disable these cipher suites in the FF client, then the web communication
on https WORKS WELL even in FF v3.0.1.
dhe_dss_camellia_128_sha (0x000044)
dhe_dss_camellia_256_sha (0x000087)
dhe_rsa_camellia_128_sha (0x000045)
dhe_rsa_camellia_256_sha (0x000088)
rsa_camellia_128_sha (0x000041)
rsa_camellia_256_sha (0x000084)
Thanks,
Suresh
Tim Ellison wrote:
I read the firefox-security-dev thread and see that they use SSLv2 as a
compatibility mode when the TLS handshake has already failed. So I
agree that we need to discover (1) why that initial exchange failed,
then (2) why the subsequent exchange causes an internal error rather
than graceful fallback.
I notice that secure connections work ok with Internet Explorer.
Turning on Harmony trace (-Djsse=record,prf,socket) I get...
On IE:
INFO: Server startup in 1484 ms
socket[http-8443-Acceptor-0] SSLSocketImpl: SERVER
socket[http-8443-Acceptor-0] SSLSocketImpl.startHandshake
socket[http-8443-Acceptor-0] SSLSocketImpl: HS status: NEED_UNWRAP
NEED_UNWRAP
record[http-8443-Acceptor-0] SSLRecordProtocol.unwrap: BEGIN [
record[http-8443-Acceptor-0] Got the message of type: 22
record[http-8443-Acceptor-0] TLSCiphertext.fragment[97]: ...
01 00 00 5D 03 00 48 BE F6 AB 8F B3 68 82 9A 09
8B 90 90 AD 88 A5 C6 57 D7 13 2C 2E DD D5 D7 62
41 23 7C 6D D1 64 20 49 E3 B4 D3 5D A3 89 17 03
AA F9 F1 B7 22 AD 5A 9A 5A A3 2A A6 8F EC D6 F1
88 69 A5 48 BE F6 6D 00 16 00 04 00 05 00 0A 00
09 00 64 00 62 00 03 00 06 00 13 00 12 00 63 01
00
record[http-8443-Acceptor-0] SSLRecordProtocol:unwrap ] END, type: 22
socket[http-8443-Acceptor-0] SSLSocketImpl: HS status: NEED_WRAP NEED_WRAP
record[http-8443-Acceptor-0] SSLRecordProtocol.wrap:
TLSPlaintext.fragment[700]:
02 00 00 46 03 00 48 BE F6 AB FD 54 4A 16 8C 74
88 9A 13 9A A7 5F FD D0 9E EC 71 71 B4 63 6A 57
5A B0 E0 82 F6 F9 20 71 1F C1 49 D6 39 45 F0 90
and on Firefox I get:
INFO: Server startup in 1532 ms
socket[http-8443-Acceptor-0] SSLSocketImpl: SERVER
socket[http-8443-Acceptor-0] SSLSocketImpl.startHandshake
socket[http-8443-Acceptor-0] SSLSocketImpl: HS status: NEED_UNWRAP
NEED_UNWRAP
record[http-8443-Acceptor-0] SSLRecordProtocol.unwrap: BEGIN [
record[http-8443-Acceptor-0] Non v3.1 message type:128
record[http-8443-Acceptor-0] SSLRecordProtocol.wrap:
TLSPlaintext.fragment[2]:
02 50
Sep 3, 2008 9:43:30 PM org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
Throwable occurred: java.net.SocketException: SSL handshake
errorjavax.net.ssl.SSLException: INTERNAL ERROR
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:150)
at
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310)
at java.lang.Thread.run(Thread.java:670)
Hopefully somebody familiar with this area of code will help explain
what's happening -- otherwise I'll try and dive in and figure it out.
Regards,
Tim
Suresh Kumar J wrote:
Hi Tim,
As you mentioned the client uses SSLv2 handshake message for initial
negotiation. But that doesn't seem to be a problem in this case. The
issue seems to be because of couple of unsupported cipher suites. As I
mentioned in the original post, the following cipher suites seems to
cause the server to "Internal error" state.
dhe_dss_camellia_128_sha (0x000044)
dhe_dss_camellia_256_sha (0x000087)
dhe_rsa_camellia_128_sha (0x000045)
dhe_rsa_camellia_256_sha (0x000088)
rsa_camellia_128_sha (0x000041)
rsa_camellia_256_sha (0x000084)
When I disable these cipher suites in the client, then the web
communication on https WORKS WELL. This makes me to strongly thing that
Harmony doesn't seem to handle these cipher suites. Note there are
couple of common ciphers present in the client's set of ciphers suites.
If the client handshake message didn't have the "Camellia" related
ciphers then the client-server communication on SSL succeeds.
If Harmony doesn't understand some of the cipher suites in the handshake
message then it should gracefully handle them by ignore the unrecognized
cipher suites. Should I file a bug for this issue. This issue is easy to
reproduce with the FireFox 3.0.1 browser which recently added support
for "Camellia" cipher suites.
Note:
My setup is Apache-Tomcat 6.0.13, Harmony JRE, FireFox 3.0.1 browser.
Thanks,
Suresh
Tim Ellison wrote:
Hi Suresh,
I'm no expert in this area, but remember this has been raised before.
Looking in the archives, this seems most relevant [1].
In particular,
"Harmony's JSSE provider supports TLS v1 and SSL v3 versions of the
protocol, and if the server uses SSL v2 it simply does not understand
the client."
Your Frame 4 capture shows that the negotiation was attempting to
conduct an SSLv2 handshake.
I don't know what effort is required to also support SSLv2.
[1]
http://mail-archives.apache.org/mod_mbox/harmony-dev/200610.mbox/[EMAIL
PROTECTED]
Regards,
Tim
Suresh Kumar J wrote:
Hi
I have a web-application which runs on Apache-Tomcat v6.0.13. Am using
theApache Harmony JRE(v6). When I try to launch the application on the
latest FireFox v3.0.1 browser, tomcat errors out with the following
message in the catalina.out :
--------------------------------------------------
Aug 29, 2008 2:52:52 PM
org.apache.tomcat.util.net.JIoEndpoint$Acceptor run
SEVERE: Socket accept failed
Throwable occurred: java.net.SocketException: SSL handshake error
javax.net.ssl.SSLException: INTERNAL ERROR
at
org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket(JSSESocketFactory.java:150)
at
org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310)
at java.lang.Thread.run(Thread.java:657)
--------------------------------------------------
After debugging the issue, it turns out to be that the Apache-Tomcat is
not able to handle the full set of cipher suites implemented in the
latest FireFox v3.0.1.
dhe_dss_camellia_128_sha (0x000044)
dhe_dss_camellia_256_sha (0x000087)
dhe_rsa_camellia_128_sha (0x000045)
dhe_rsa_camellia_256_sha (0x000088)
rsa_camellia_128_sha (0x000041)
rsa_camellia_256_sha (0x000084)
In order to make my web application to work with FireFox browser
v3.0.1), the above mentioned cipher suites needs to be "disabled" in the
browser via the "about:config" option.
* Am having the default lib/security/java.security config of the Harmony
JRE.
* Below is the snippet of the server.xml config file of the tomcat
server:
----------------------------
<Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
maxThreads="150" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" keystoreType="PKCS12"
keystoreFile="conf/my-key-store" keystorePass="abcd"/>
----------------------------
* Why does Tomcat(when used with Harmony JRE) errors out if it doesn't
understand the some of the cipher suite. Instead it should gracefully
ignore them.
* Have enclosed the packet capture which shows the SSL handshake message
from the client(frame$4) and the response from the tomcat server which
has the internal error(frame$6).
* Here is the bug filed no apache-tomcat which got rejected saying the
issue was not actually of Tomcat's and of Harmony JRE.
https://issues.apache.org/bugzilla/show_bug.cgi?id=45730
* Here was my posting in the firefox-security-dev mailing list:
http://www.nabble.com/FireFox-v3.0.1-of-Windows-uses-SSLv2-Record-Layer-even-when-SSLv2-is-disabled-td19239646.html
* Here was my posting in the tomcat-user mailing list:
http://www.nabble.com/How-to-make-to-Apache-Tomcat-6.0.13-to-support-all-of-SSLv2-SSLv3-and-TLS-protocols-tt19228675.html
Any inputs on this issue would be appreciated.
Thanks,
Suresh
