Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of suresh.kumar.j@gmail.com
 designates 209.85.198.244 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=wS7AXKYWkX14vGKHTMdPYOcdEXtQXZtclnrq96uX4gSH5jKhH2qTiMax+F69gnpuN0
         v1VYUsdh9a8eWPABL3j+77OBPzZZa3uSTU5AWanG+TtSjgRp0cB+dhNUee1f13YPcCVU
         vG9Z3IW+DX54eTM+BkWUg82+H7pAo5+4bMwWE=
Message-ID: <48BF11C4.4060701@gmail.com>
Date: Wed, 03 Sep 2008 15:37:56 -0700
From: Suresh Kumar J <suresh.kumar.j@gmail.com>
User-Agent: Spicebird 0.4 (Windows/2008011302)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: Internal error upon seeing the "Camellia" cipher suites in the
 SSL handshake message
References: <48BE2B5F.1050003@gmail.com> <48BEB9B1.6040902@gmail.com>
 <48BEC4BE.2080401@gmail.com> <48BEF975.90008@gmail.com>
 <48BF0BDA.70806@gmail.com>
In-Reply-To: <48BF0BDA.70806@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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