On 2/27/2013 3:14 PM, Dr. Stephen Henson wrote:
On Wed, Feb 27, 2013, Nayna Jain wrote:
Thanks Dr. Stephen and Victor for explanation
Some questions further in this :
Is there an API to configure programmatically , what hash algorithm it
can use. My understanding is that final ciphers which are selected are
for encryption and HMAC generation of application data packets. This
might be required to maintain the compatibility issues.
My understanding is that this error happens on client side, when it
tries to sign the CertificateVerify message, where digest output comes
too big for RSA to encrypt. Let me know if this is correct.
Yes that's correct. If the RSA key size is too small the default SHA512
digest and the associated ASN1 and padding overhead exceeds the maximum for
the RSA algorithm. This is only a problem with insecure keys: most standards
now suggest 1024 bits is the bare minimum and 2048 bits recommended.
There is an API to modify the supported digest list but only in the unreleased
OpenSSL 1.0.2 and later. This can be accessed on the command line through the
-client_sigalgs command line switch, via the SSL_CONF API or through some ctrl
operations. There isn't anything in 1.0.1.
These are the digests used to sign handshake messages for TLS version 1.2.
The digests used for HMAC in application data records are determined by the
cipher suite.
I still think this is a real bug in 1.0.1 (not the absence of an API,
but the failure to implement the hash algorithm selection correctly).
*Nothing in the following description requires any changes to the
OpenSSL API, just correct implementation of the protocol handling in
existing APIs*
To understand the problem more fully, imagine the following scenario:
1. Client user has configured 2 or more client certificates, one has
an RSA-768 public key, the other an RSA-16384 key (throw in the
possibility of DSA keys for extra credit).
2. Client connects to server without knowing in advance what
certificates and algorithms the server will ask for (so client
app code cannot reasonably limit its signing hash choices at
this step, so no extra APIs are useful).
3. Server negotiates a connection and presents a list of acceptable
client certificate issuers with an explicit (TLSv1.2) or implicit
(older TLS versions)
CertificateRequest.supported_signature_algorithms list.
4. Based on the usual logic, OpenSSL client code narrows down the
list of available client certificates, mostly based on issuer
and validity periods.
In this stage code is missing to eliminate certificates whose
public key is incompatible with ALL elements of
CertificateRequest.supported_signature_algorithms.
*This code is not minimally required, but really should be
there to reduce user confusion*
For example if the server list contains only SHA-512 + RSA and
SHA-256 + ECDSA, then the users RSA-768 certificate goes away as it
cannot be used with SHA-512+RSA (due to hash length), nor with
SHA-256+ECDSA (due to not being a DSA certificate).
But if the server offered the long list of choices in Viktor
Dukhovni's post from yesterday at 22:21 UTC, then both certificates
remain as possibilities.
5. Using the usual application specific mechanism, the user/app code
chooses one of the remaining client certificates.
6. Now the OpenSSL client code has a chosen certificate with a given
public key, a matching private key and a list of acceptable signing
algorithms from CertificateRequest.supported_signature_algorithms.
THE BUGGY BEHAVIOR is to choose an element of
CertificateRequest.supported_signature_algorithms which is not
compatible with the chosen certificate, and then error out.
THE REQUIRED BEHAVIOR (as stated in RFC5246 sections 7.4.4, 7.4.6
and 7.4.8) is for the OpenSSL client code to choose an element of
CertificateRequest.supported_signature_algorithms which is
compatible with the chosen client certificate.
THE RECOMMENDED BEHAVIOR is to use the strongest such element,
but without choosing something impossible.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
