From dev-return-34965-apmail-harmony-dev-archive=harmony.apache.org@harmony.apache.org Fri Sep 05 03:24:31 2008 Return-Path: Delivered-To: apmail-harmony-dev-archive@www.apache.org Received: (qmail 25064 invoked from network); 5 Sep 2008 03:24:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Sep 2008 03:24:31 -0000 Received: (qmail 51417 invoked by uid 500); 5 Sep 2008 03:24:28 -0000 Delivered-To: apmail-harmony-dev-archive@harmony.apache.org Received: (qmail 51378 invoked by uid 500); 5 Sep 2008 03:24:28 -0000 Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list dev@harmony.apache.org Received: (qmail 51367 invoked by uid 99); 5 Sep 2008 03:24:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Sep 2008 20:24:28 -0700 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sean.xx.qiu@gmail.com designates 209.85.142.185 as permitted sender) Received: from [209.85.142.185] (HELO ti-out-0910.google.com) (209.85.142.185) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Sep 2008 03:23:29 +0000 Received: by ti-out-0910.google.com with SMTP id y6so115364tia.18 for ; Thu, 04 Sep 2008 20:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=cfnFaecRjG1Vgc7icsa42JMxaV39J8Gd8A0S+j5nb9A=; b=meHOdiHHD8YVQJ9DvxI4MRBNrKuVRC0lSb7rux4bmoBLHeQ6B68vPwD4+myDr4Uw72 0tcMGIN8Az5Mpg+ndjr0Si+k/mzpM00d3e/B6Ep2z9fZZwojGA4O1E2Le9oZMFN7vIGr BRgjFsTjdYGNKhji6oco5IRv6du85kSohVLaM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=LFqNTjfEDnUEsO1+rgTm4Glc+/9NYS9JCNs3/Eql8K7M+h1Zx5xGBEibmmNJkjdMeg JS2Jghu9ueU20qSl0rmZQmO6JGsix7CTNv+/+CjpWrQ6wcKtu0J5xZeUCMc9Q+6wNHdU nAHrkJz+JUngJ+cS+uyndWfRvjI2gB2dF7k4s= Received: by 10.110.42.1 with SMTP id p1mr14179306tip.21.1220585022008; Thu, 04 Sep 2008 20:23:42 -0700 (PDT) Received: by 10.110.10.4 with HTTP; Thu, 4 Sep 2008 20:23:41 -0700 (PDT) Message-ID: <94d710af0809042023k5abfffeeve7969071859e636@mail.gmail.com> Date: Fri, 5 Sep 2008 11:23:41 +0800 From: "Sean Qiu" To: dev@harmony.apache.org Subject: Re: Internal error upon seeing the "Camellia" cipher suites in the SSL handshake message In-Reply-To: <94d710af0809040314r248036bfnbbf80b895aaaea68@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48BE2B5F.1050003@gmail.com> <48BEB9B1.6040902@gmail.com> <48BEC4BE.2080401@gmail.com> <48BEF975.90008@gmail.com> <48BF0BDA.70806@gmail.com> <94d710af0809040150yb124d90r3a86c55ae03dd81b@mail.gmail.com> <48BFAC09.6020209@gmail.com> <94d710af0809040314r248036bfnbbf80b895aaaea68@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org 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: > 2008/9/4 Tim Ellison : >> 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 : >>>> 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: >>>>>>>> ---------------------------- >>>>>>>> >>>>>>> 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