Thanks for this helpful reply. This problem is mentioned in
the java-security archives, along with the claim that jsse
is correctly implemented:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0004&L=java-security&D=0&H=0&O=D&T=1&P=234
Where shall I start digging in the openssl source to build
your 'broken' s_client? I would like to reproduce your patch.
Thanks,
--Will Rusch
Dr Stephen Henson wrote:
> Will Rusch wrote:
> >
> > openssl client -> java jsse server problem
> >
> > I'm stuck trying to get the openssl 0.9.5a s_client
> > to talk with a java (jsse) server, using DSA algorithms.
> > I've tried 512-bit and 1024-bit keys.
> >
> > The java server is using a keytool-generated
> > cert/key pair, signed by my CA cert that I created
> > with openssl.
> >
> > The client seems to get past the certificate
> > verification but complains: SSL3_GET_KEY_EXCHANGE:
> > wrong signature length.
> >
> > openssl server <-> openssl client works okay.
> > java server <-> java client works okay.
> > java server <-> openssl is broken.
> >
> > Is this a bug with my certs, or elsewhere?
> > Where do I begin digging?
> >
>
> This may well be a problem with JSSE. JSSE used an invalid signature
> format for DSA. I had someone check this out with a patch that makes
> OpenSSL produce a similar invalid format and it then worked. This isn't
> part of OpenSSL because it would break clients expecting the correct
> format.
>
> The problem in more technical detail is that the DSA signature should be
> a variable length vector consisting of the ASN1 Dss-Sig-Value structure.
> JSSE just uses the signature without the initial length.
>
> SSL v3.0 isn't clear about the DSA format and Netscape uses a third
> variant.
>
> TLS however (for which I believe JSSE claims compliance) is quite clear
> about the matter. To quote RFC2246:
>
> > 4.7. Cryptographic attributes
> >
> > The four cryptographic operations digital signing, stream cipher
> > encryption, block cipher encryption, and public key encryption are
> > designated digitally-signed, stream-ciphered, block-ciphered, and
> > public-key-encrypted, respectively. A field's cryptographic
> > processing is specified by prepending an appropriate key word
> > designation before the field's type specification. Cryptographic keys
> > are implied by the current session state (see Section 6.1).
> >
> > In digital signing, one-way hash functions are used as input for a
> > signing algorithm. A digitally-signed element is encoded as an opaque
> > vector <0..2^16-1>, where the length is specified by the signing
> > algorithm and key.
> >
> > In RSA signing, a 36-byte structure of two hashes (one SHA and one
> > MD5) is signed (encrypted with the private key). It is encoded with
> > PKCS #1 block type 0 or type 1 as described in [PKCS1].
> >
> > In DSS, the 20 bytes of the SHA hash are run directly through the
> > Digital Signing Algorithm with no additional hashing. This produces
> > two values, r and s. The DSS signature is an opaque vector, as above,
> > the contents of which are the DER encoding of:
> >
> > Dss-Sig-Value ::= SEQUENCE {
> > r INTEGER,
> > s INTEGER
> > }
> >
>
> What they were doing (assuming this is still the problem) is just plain
> wrong. I suggest you try and get them to fix it.
>
> Steve.
> --
> Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
> Personal Email: [EMAIL PROTECTED]
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the OpenSSL project: http://www.openssl.org/
> Business Email: [EMAIL PROTECTED] PGP key: via homepage.
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
