harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Qiu" <sean.xx....@gmail.com>
Subject Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message
Date Thu, 04 Sep 2008 10:14:37 GMT
2008/9/4 Tim Ellison <t.p.ellison@gmail.com>:
> Sean Qiu wrote:
>>  I do can't find these cipher suites in our implementation[1].
>
> Those listed in Harmony's JSSE cipher suite are defined by the TLSv1
> spec (RFC2246).
>
>> For RI, I have no idea whether they have supplied these suites.
>> As far as I know, there is no public API to check it, I have concerns
>> to use refection.
>
> But isn't the problem that the negotiation should be robust when offered
> any unknown suites?  People can invent new, possibly private, cipher
> suites and the negotiation algorithm should still work.
>

Yes, it should be fixed  at first.

>> If it do, I guess we can add them as well.
>> I will try to make a patch to add them if possible.
>
> I think the ciphers are there and available.  By default our providers are:
>  DRLCertFactory version 1.0
>  Crypto version 1.0
>  HarmonyJSSE version 1.0
>  BC version 1.39
>
> and the Ciphers available in that lot include:
>  CAMELLIA
>  CAMELLIARFC3211WRAP
>  CAMELLIAWRAP
>
> Which are courtesy of BouncyCastle.
>

Yes, I have found them too.
I guess we  are required to create new CipherSuites  instance refer to
them to support FF3.

So we have two actions to complete:
1. Make our code more robust to handle similar situation when we don't
support the algorithm.
2. Add  CAMELLIA to our CipherSuites if possible.
    Its priority is lower since we are able to work when these
algorithm is disabled.

> Regards,
> Tim
>
>> [1] http://svn.apache.org/viewvc/harmony/enhanced/classlib/trunk/modules/x-net/src/main/java/org/apache/harmony/xnet/provider/jsse/CipherSuite.java?revision=476395&view=markup&pathrev=691931
>>
>> 2008/9/4 Suresh Kumar J <suresh.kumar.j@gmail.com>:
>>> 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/%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
>>>>>>>
>>>>>>>
>>>>>>>
>>
>>
>>
>



-- 
Best Regards
Sean, Xiao Xia Qiu

China Software Development Lab, IBM

Mime
View raw message