You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Mick Russom (JIRA)" <ji...@apache.org> on 2008/10/01 01:53:46 UTC
[jira] Commented: (HARMONY-5969) [classlib][xnet] Internal error
upon seeing the "Camellia" cipher suites in the SSLv2 handshake message
[ https://issues.apache.org/jira/browse/HARMONY-5969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12635909#action_12635909 ]
Mick Russom commented on HARMONY-5969:
--------------------------------------
Where can I try this fix? Is this in a new version of harmony or in a snapshot build ? I checked the subversion commits for this issue and didn't find any. Any help would be greatly appreciated ?
> [classlib][xnet] Internal error upon seeing the "Camellia" cipher suites in the SSLv2 handshake message
> -------------------------------------------------------------------------------------------------------
>
> Key: HARMONY-5969
> URL: https://issues.apache.org/jira/browse/HARMONY-5969
> Project: Harmony
> Issue Type: Bug
> Components: Classlib
> Affects Versions: 5.0M7
> Environment: Server-side:
> CentOS 64-bit version
> Apache-Tomcat 6.0.13
> Harmony JRE
> Client-side:
> Windows XP OS
> FireFox 3.0.1 browser
> Reporter: Suresh Kumar J
> Assignee: Tim Ellison
> Attachments: Harmony_InternalError on Camellia cipher suite.txt
>
>
> You can refer to the post on dev@harmony.apache.org
> http://thread.gmane.org/gmane.comp.java.harmony.devel/34754
> Here is the message:-
> -------- Original Message --------
> Subject: Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message
> Date: Wed, 03 Sep 2008 15:12:42 -0700
> From: Suresh Kumar J
> To: dev@harmony.apache.org
> 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
> >>>>
> >>>>
> >>>>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (HARMONY-5969) [classlib][xnet] Internal error
upon seeing the "Camellia" cipher suites in the SSLv2 handshake message
Posted by Tim Ellison <t....@gmail.com>.
Tim Ellison wrote:
> Not sure why JIRA missed the commit...
mea culpa - I didn't give the issue id in the commit message.
Re: [jira] Commented: (HARMONY-5969) [classlib][xnet] Internal error
upon seeing the "Camellia" cipher suites in the SSLv2 handshake message
Posted by Tim Ellison <t....@gmail.com>.
Mick Russom commented on HARMONY-5969:
> Where can I try this fix? Is this in a new version of harmony or in a
> snapshot build ? I checked the subversion commits for this issue and
> didn't find any. Any help would be greatly appreciated ?
Hi Mick,
Not sure why JIRA missed the commit [1], but it was fixed and is
available in the latest snapshot build [2].
Let us know how you get on.
[1] http://svn.apache.org/viewvc?rev=692675&view=rev
[2] http://people.apache.org/builds/harmony/snapshots/r697069/
Regards,
Tim