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 Thu, 04 Sep 2008 07:54:15 GMT
Suresh Kumar J wrote:
> 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.

Yes, I got it.

> 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)

Understood.  I'm still working my way towards that problem -- its not an
area of Harmony code I wrote or am familiar with (so bear with me).  If
anyone else understands this then feel free to step in!

Regards,
Tim

> 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/%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