harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message
Date Wed, 03 Sep 2008 20:54:13 GMT
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/%3Ce09a11790610180326i4f466152u7015458d7b0e0062@mail.gmail.com%3E
>>
>>
>> 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
>>>
>>>     
> 

Mime
View raw message