You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@harmony.apache.org by Suresh Kumar J <su...@gmail.com> on 2008/09/03 08:14:55 UTC

Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message

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

Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message

Posted by Suresh Kumar J <su...@gmail.com>.

Have logged a bug on this issue:
https://issues.apache.org/jira/browse/HARMONY-5969

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

Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message

Posted by Sean Qiu <se...@gmail.com>.

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 <se...@gmail.com>:
> 2008/9/4 Tim Ellison <t....@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 <su...@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