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]
