Just commenting since I saw and recognized the name next to BearSSL...
Thomas Pornin is an absolute treasure, and anyone interested in entry level crypto and beyond should read through his StackOverflow responses. Many of the answers simplify complex topics into more digestable pieces.
With the amount of TLS vulnerabilities I don't really understand why we're not just replacing it completely. From what I've read a lot of the issues is the complexity of the standard itself that we could do much better now that so much more is known about good crypto practice. Google has already pushed HTTP 2 and now 3 thanks to having very sizeable chunks of both the browser and the sites. Why not also have a much better designed crypto standard in one of those efforts?
> The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL.<p>Some kind of award has to go to this sentence, that has to be the most convoluted way to simply say "aren't vulnerable."<p>In context you can only just barely follow it, and it literally involves counting the vulnerable + un-vulnerable libraries to check they all add up to 9...
> <i>The last 20 years of attacks that have been re-discovering Bleichenbacher's seminal work in 1998 clearly show that it is close to impossible to correclty implement the RSA PKCS#1 v1.5 encryption scheme. While our paper recommends a series of mitigations, it is time for RSA PKCS#1 v1.5 to be deprecated and replaced by more modern schemes like OAEP and ECEIS for asymmetric encryption or Elliptic Curve Diffie-Hellman for key exchanges.</i><p>RSA PKCS#1 v1.5: <a href="https://tools.ietf.org/html/rfc2313" rel="nofollow">https://tools.ietf.org/html/rfc2313</a><p>Title: <i>PKCS #1: RSA Encryption version 1.5</i><p>tl;dr: deprecate RSA encryption as a whole?! Did I read this right?
There's a big disparity between the level of ambition in transport security implementations, and the big recent archievements in getting crypto more widely deployed...<p>I think the current standard should be memory-safe implementations with proven robustness against known classes of attacks, and optional resistance against traffic analysis (at expense of wasted bandwidth).
Why is using RSA for key exchanges acceptable? I thought we had dedicated key exchange algorithms, Diffie–Hellman (DH), the ephemeral variant (DHE), and the elliptic curve variant (ECDHE). So why RSA?<p>Also, what if I disable RSA in my browser and make sure the ClientHello doesn't mention RSA? Will I be secure?
How about the obvious solution to all timing attacks of sending a network response after a timer set to 2^K milliseconds expires rather than when the data is ready? (with K adaptively incremented and decremented only rarely, outliers managed by starting the timer again so that the time is rounded up to 2^K)<p>This way, the only timing signal available would be which requests take an outlier amount of time, and I doubt that's enough to break anything unless you can remotely cause the peer to hit slow disks or make network requests depending on secret data (which is a far more explicit programming choice than CPU timing differences).
Maybe a one size fits all transport security protocol is a bad idea. Simpler and smaller protocols with less features might provider better stable security?
Downgrading to TLS1.2 isn't the end of the world.<p>One of the things you can do to make a significant difference is configure all of your httpd (apache2, nginx, whatever) to specifically disallow SSLv3, TLS1.0 and TLS1.1.<p>There is no longer any relevant population of useragents that don't understand TLS1.2.