[Ach] Logjam: Missing Debian Stable "Features"
hanno at hboeck.de
Thu May 21 12:43:46 CEST 2015
On Thu, 21 May 2015 12:11:27 +0200
Axel Hübl <axel.huebl at web.de> wrote:
> Should we actually discourage using Debian stable? ;)
> I mean: not backporting such "new features" is actually a security
> risk in that context.
I think this is an underapprechiated problem and I think it's
one that should be pushed forward. We have a problem here and nobody
really has a good solution I think. There is a fundamental clash with
the idea of long term support solutions and complex security fixes.
But I can just quote myself here :-)
"There are also bugs that require changes so big that backporting them
is essentially impossible. In the TLS world a lot of protocol bugs have
been highlighted in recent years. Take Lucky Thirteen for example. It
is a timing sidechannel in the way the TLS protocol combines the CBC
encryption, padding and authentication. I like to mention this bug
because I like to quote it as the TLS bug that was already mentioned in
the specification (RFC 5246, page 23: "This leaves a small timing
channel"). The real fix for Lucky Thirteen is not to use the erratic
CBC mode any more and switch to authenticated encryption modes which
are part of TLS 1.2. (There's another possible fix which is using
Encrypt-then-MAC, but it is hardly deployed.) Up until recently most
encryption libraries didn't support TLS 1.2. Debian Squeeze and Red Hat
Enterprise 5 ship OpenSSL versions that only support TLS 1.0. There is
no trivial patch that could be backported, because this is a huge
change. What they likely backported are workarounds that avoid the
timing channel. This will stop the attack, but it is not a very good
fix, because it keeps the problematic old protocol and will force
others to stay compatible with it.
mail/jabber: hanno at hboeck.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the Ach