On 08/15/17 09:54, Andreas Thulin wrote:
Hi!
I run httpd on 6.1-stable (thanks to all of you who make that possible!),
with a pretty vanilla tls setup. When testing the server on ssllabs.com,
results say that
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
is considered weak. How should I interpret that information, as you see it?
And shouldn't default cipher strengths be >= 128? I have probably
misunderstood something, so any pointers in the right direction would be
lovely.
Link to my test result:
https://www.ssllabs.com/ssltest/analyze.html?d=esoteric.andreasthulin.se
at least httpd on current doesn't include any 3DES cipher suites by
default. I am also not aware of any TLS clients which are TLS 1.2-only
and would prefer any 3DES cipher suite at the same time. In case your
server is not required to be interoperable with some very old TLS
1.0-based legacy clients, you should simply exclude 3DES cipher suites.
From a security perspective, although probably still sufficient for the
foreseeable future, the 112-bit security level of 3DES looks like the
weakest link in your specific setup. However, the much bigger problem is
3DES's 64-bit block length which is inherently prone to collisions
(so-called SWEET32 attack). In order to mitigate this problem, the
upcoming recommendation from NIST is to frequently change the key (every
2^20 64-bit data blocks -- see
http://csrc.nist.gov/publications/drafts/800-67r2/sp800-67r2-draft.pdf
). In the context of libssl, BIO_set_ssl_renegotiate_bytes() (see
BIO_f_ssl(3)) seems to be intended for this purpose. However, it doesn't
seem to be called anywhere in OpenBSD's src repository. In case any
developer is reading this -- does libssl/libtls/httpd somehow ensure
that session keys will be refreshed after a cipher suite's maximum key
lifetime (or, alternatively, the session gets terminated)? Although the
recommended limit on the number of TLS records, which could be handled
with the same session key, is much higher for AES-GCM (i.e., 2^32
records), there still is a limit.
Best regards
Andreas
