[Pkg-openssl-devel] Bug#686470: libssl1.0.0: uses SHA256 instead of SHA384 for 384-bit EC key

[Sebastian Andrzej Siewior]

control: tags -1 + patch upstream
control: forwarded -1 https://rt.openssl.org/Ticket/Display.html?id=4496&user=guest&pass=guest

On 2012-09-02 00:46:38 [+0000], brian m. carlson wrote:
> I am running postfix on a sid machine (using OpenSSL) and I have set up
> both RSA and EC keys.  The EC key in question is using a 384-bit curve
> (secp384r1).  Logically, the appropriate algorithm to use in this case
> is SHA-384, and this is what libgnutls28 expects.  However, OpenSSL
> tries to use SHA-256, which GnuTLS doesn't like.  This causes the
> connection to be aborted.
> 
> I've read the relevant specs and they don't absolutely require that
> SHA-384 or SHA-512 be used (there is no MUST), but if a 384-bit key is
> being used for ECDSA, SHA-384 is the logical choice if the client
> supports it.  I noticed this using both gnutls-cli as a client and
> Debian's mutt package (linked against libgnutls28 instead of the
> default).

TLS 1.0 and 1.1 should end up with SHA1. Unless I am wrong it is not
meant to use anything else here.
TLS 1.2 can do better than SHA1.
Default is SHA512, SHA384 and SHA256 (in that order, combined with RSA,
ECDSA and so on). However without "server's preferences" flag it uses
client's preferences of those.
gnutls seems to send SHA256, SHA384 and SHA512 (in that order). So that
is why you end up with SHA256 here.

If you specify "Signature algorithms" something like
"ECDSA+SHA384:ECDSA+SHA512:ECDSA+SHA256" then you should get SHA384 here
(and fallback to 512 and then to 256 based on client's support).
Afterall you know your key. Without "server's prefrence" you could
eliminate the weaker algorithms from the list of supported ones.

And for "I have no idea and I want to have it working according to RFC 5480
section 4" I made a patch which I forwaded upstream.

Sebastian