Bug#481132: [Pkg-gnutls-maint] Bug#481132: libgnutls26: flags key usage error where OpenSSL does not

[Simon Josefsson]

severity 481132 wontfix
notforwarded 481132
thanks

"brian m. carlson" <sandals at crustytoothpaste.ath.cx> writes:

> Apparently OpenSSL doesn't try to use kEDH, and so it doesn't fail.
> GnuTLS should implement the same behavior; if a certificate doesn't
> support digitalSignature, then GnuTLS shouldn't try to use it in that
> way.  RSA key exchange is fine for what I need.

I looked into this further, and we cannot implement this for the reason
Nikos explained -- in TLS, the server chose the ciphersuite to use.  The
client cannot avoid advertising support for DHE ciphers based on the
server certificate, since it hasn't seen the server certificate when
sending the client hello.

We don't want to mimic OpenSSL's behaviour.  The reason OpenSSL works in
this situation is, if I understand correctly, because OpenSSL clients
list non-DHE ciphers as preferred over DHE ciphers.  So your server
would chose the non-DHE cipher by default, and things would work.  I
don't think that is a good idea from a security perspective.  GnuTLS
clients should advertise preference for DHE ciphers.  Finally, servers
shouldn't chose DHE ciphers if they cannot support.

As far as I can tell you have these options:

1) Reconfigure the server to not (incorrectly) announce support for DHE
ciphers.

2) Regenerate certificates with the digitalSignature bit set.

3) Report a bug against the server to make it avoid chose a DHE
ciphersuite when the certificate does not have the digitalSignature bit.

4) Configure the client to not prefer DHE ciphers over non-DHE ciphers.
This would mimic the OpenSSL behaviour, but does not enforce the
sub-optimal configuration on all GnuTLS users.  A GnuTLS priority string
"PERFORMANCE" is sufficient -- it prefers non-DHE ciphers over DHE
because non-DHE is faster.

I could be wrong somewhere, so please let me know if you see a way to
actually make things work better in your case without worsening security
for all users.

/Simon