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 Fri, 05 Sep 2008 03:23:41 GMT
I'v tried to create a SSLServerSocket from RI.
Witt following sinppet, I can get the CipherSuites[1] from RI.

        String[] supported = sss.getSupportedCipherSuites();
        for (int i=0; i<supported.length; i++) {
            System.out.println(supported[i]);
        }

There are no CAMELLIA relative CipherSuite as well.
In a conclusion,  it is optional to implement this suites.

So I will focus on defect fixing when the client desired cipher
algorithm isn't supported by server.

[1] CipherSuite from RI

SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_DHE_RSA_WITH_DES_CBC_SHA
SSL_DHE_DSS_WITH_DES_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_WITH_AES_128_CBC_SHA
SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
SSL_DH_anon_WITH_DES_CBC_SHA
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_KRB5_WITH_RC4_128_SHA
TLS_KRB5_WITH_RC4_128_MD5
TLS_KRB5_WITH_3DES_EDE_CBC_SHA
TLS_KRB5_WITH_3DES_EDE_CBC_MD5
TLS_KRB5_WITH_DES_CBC_SHA
TLS_KRB5_WITH_DES_CBC_MD5
TLS_KRB5_EXPORT_WITH_RC4_40_SHA
TLS_KRB5_EXPORT_WITH_RC4_40_MD5
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5

2008/9/4 Sean Qiu <sean.xx.qiu@gmail.com>:
> 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
>



-- 
Best Regards
Sean, Xiao Xia Qiu

China Software Development Lab, IBM

Mime
View raw message