GnuTLS patches huge security hole that hung around for two years – worse than Heartbleed, says Google cryptoboffin
GnuTLS, a widely used open source library implementing Transport Layer Security, last week fixed a bug that had been hiding in the code for almost two years that made resumed TLS 1.3 sessions vulnerable to attack.
The TLS handshake requires two round-trips between client and server to establish a secure connection. Session tickets provide a way to resume previously established connections with only one round-trip. But this convenience comes at a cost – it's less secure, as described by Google cryptographer Filippo Valsorda.
The flaw allowed GnuTLS servers to use session tickets issued during a previous secure TLS 1.3 session without accessing the function that generates secret keys, gnutls_session_ticket_key_generate(). An attacker capable of exploiting this vulnerability could bypass authentication under TLS 1.3 and could recover previous conversations under TLS 1.2.
The bug, introduced in GnuTLS 3.6.4 (Sep. 24, 2018), was fixed in GnuTLS 3.6.14 (June 3, 2020). [...]
(Score: 0) by Anonymous Coward on Thursday June 11 2020, @04:03PM (1 child)
An audit will only make you feel secure.
These encryption softwares, they are too important as tactcal and strategic targets, to be allowed to not have a deniable way to pervert them in realtime.
And should audit find bugs, and someone fixes them, next day 20 new similar bugs get introduced by spy asset implanted in the project.
In my experience, audits are a tool that is designed to not be able to win this battle, but to provide deniability and the "come on over y'all, the waters fine 'ere"-factor.
(Score: 0) by Anonymous Coward on Thursday June 11 2020, @07:38PM
You're wrong. An audit providing evidence of more malfeasance is enough to impact Red Hat (or anyone else that gets scooped up). Any contributor who repeatedly does things like this - which are transparently "add a deniable security hole" is either incompetent (I've had co-ops who wrote code like this) or malfeasant. Either way, look for evidence. If there's none, they might get a "well mistakes happen, that intern sucked" on their record in the IT-crowd-mindshare memo pad.