|
| From: | chinmaya |
| Subject: | Re: [Jessie-discuss] Running GNU-Classpath-SSL with Sun-JDK1.5 |
| Date: | Fri, 23 Mar 2007 18:20:37 -0600 |
It looks like Sun's RSA requires that the input start with a byte 0,
which the SSL spec doesn't require (the version of RSA in Classpath
doesn't require this, either). I think the patch I've attached may
help; I haven't tried this yet, however.
On Mar 23, 2007, at 4:24 PM, chinmaya wrote:
> (Ignore my previous mail: changing the subject)
> Hi,
>
> I some how managed to extract GNU-SSL (Jessie) and related packages
> and compile it using SUN JDK1.5.
> I changed my existing sample server/client to use GNU-SSL provider,
> during hand shake I am getting following error:
> javax.crypto.BadPaddingException: Data must start with zero.
> Looks like this very basic error, any idea whats causing this.
>
> 23 Mar 2007 16:37:43,238 ERROR [ 10.1.0.18:53695] TLSServer: Error
> while processing data
> gnu.javax.net.ssl.provider
> .AlertException: HANDSHAKE_FAILURE: locally generated; FATAL
> at
> gnu.javax.net.ssl.provider.ServerHandshake.checkKeyExchange
> (Unknown Source)
> at
> gnu.javax.net.ssl.provider.AbstractHandshake.getInputParams(Unknown
> Source)
> at gnu.javax.net.ssl.provider.SSLEngineImpl.unwrap(Unknown
> Source)
> at javax.net.ssl.SSLEngine.unwrap (SSLEngine.java:566)
> at gnu.javax.net.ssl.provider.SSLSocketImpl.doHandshake
> (Unknown Source)
> at gnu.javax.net.ssl.provider.SSLSocketImpl
> $SocketInputStream.read(Unknown Source)
> at sun.nio.cs.StreamDecoder$CharsetSD.readBytes
> (StreamDecoder.java:411)
> at sun.nio.cs.StreamDecoder$CharsetSD.implRead
> (StreamDecoder.java :453)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183)
> at java.io.InputStreamReader.read( InputStreamReader.java :
> 167)
> at java.io.BufferedReader.fill(BufferedReader.java :136)
> at java.io.BufferedReader.read(BufferedReader.java:157)
> at TLSDataListener.processData(TLSDataListener.java:26)
> at TLSServer$2.run( TLSServer.java:197)
> Caused by: javax.crypto.BadPaddingException: Data must start with zero
> at sun.security.rsa.RSAPadding.unpadV15(RSAPadding.java:308)
> at sun.security.rsa.RSAPadding.unpad(RSAPadding.java :255)
> at com.sun.crypto.provider.RSACipher.a(DashoA12275)
> at com.sun.crypto.provider.RSACipher.engineDoFinal
> (DashoA12275)
> at javax.crypto.Cipher.doFinal(DashoA12275)
> at gnu.javax.net.ssl.provider.ServerHandshake
> $RSAKeyExchange.implRun (Unknown Source)
> at gnu.javax.net.ssl.provider.DelegatedTask.run(Unknown
> Source)
> ... 10 more
>
>
> thanks
> chinmaya
>
> On 3/23/07, Casey Marshall <address@hidden> wrote:On Mar 23, 2007, at
> 11:20 AM, chinmaya wrote:
>
> > On 3/19/07, Casey Marshall < address@hidden> wrote:
> > On Mar 19, 2007, at 2:12 PM, chinmaya wrote:
> >
> > > Hi,
> > >
> > > I am trying to use Jessie as a replacement to Sun's SSL provider.
> > > I can't replace Jessie in JDK 1.4 as due to restrictions (read
> this
> > > link http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/
> > > JSSERefGuide.html#PLUG)
> > > -- snippet --
> > > JSSE in J2SE 1.4.x does not allow use of third party JSSE
> providers
> > > due to U.S. government export restrictions. However, with the
> latest
> > > U.S. government export regulations, JSSE in J2SE 5 allows any JSSE
> > > provider be used as long as it supports only the following cipher
> > > suites.
> > > -- snippet --
> > >
> >
> > You can also try replacing the javax.net.ssl classes with a free
> > version. Jessie comes with these, written from scratch.
> >
> > > I don't have any choice but to go for JDK 1.5.
> > > I think following (minimal) changes are required in Jessie,
> > > * Need addition of SSLEngine (but a skeliton code will do as
> its an
> > > alternative IO support.)
> > > * Changes/Addition to APIs in SSLContext implementation class
> > > * Changes/Addition to APIs in SSLSession implementation class
> > >
> > > Has anyone attempted/successfully using Jessie with JDK 1.5.
> > >
> > > Is Jessie project still alive, I do not see much of activity
> > though, I
> > > see no release after Oct 05 !
> > > Are there any development plans for Jessie?
> > >
> >
> > No. We merged Jessie into GNU Classpath, and are maintaining it
> > there. The current CVS code of Jessie should be compatible with Java
> > 1.5, and it includes a real, non-stub implementation of SSLEngine.
> >
> > > Should I use Jessie release or GNU Classpath release if I have to
> > use
> > > latest of Jessie!
> > >
> >
> > You should use the version in GNU Classpath. The SSL provider is
> > reasonably self-contained in the package gnu.javax.net.ssl.
> >
> >
> > gnu.javax.net.ssl package depends on lot of other classpath packages
> > like gnu.java.security.*, gnu.classpath.debug.*,
> gnu.javax.crypto.* .
> > And they in-turn depend on rest of classpath.
> >
>
> Well, gnu.java.security and gnu.javax.crypto are from GNU Crypto,
> which was also merged into Classpath.
>
> > Is there way I could get individual Jars for these?
> >
>
> I think someone had been putting work into Classpath to support
> compiling the JSSE and crypto into separate jars, but I don't recall
> if this work was done or not.
>
> > And I am trying to use this with Sun Java, and is there way I could
> > build it using Sun JDK1.5?
> >
>
> I don't see why not.
>
> _______________________________________________
> Jessie-discuss mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/jessie-discuss
| [Prev in Thread] | Current Thread | [Next in Thread] |