An initial report of a possible timing side channel was made on 14th July 2020
by Hubert Kario (Red Hat). A refined report identifying a specific timing side
channel was made on 15th July 2022 by Hubert Kario.
The fix was developed by Dmitry Belyavsky (Red Hat) and Hubert Kario.
If so, it's interesting that it took exactly 2 years and 1 day for the refined report.
EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.
Maybe in this case! You can look at P1v15 RSA and assume that there might be some kind of behavior oracle, which is definitely not the same thing as demonstrating that there is a viable oracle. A problem with P1v15 in general is that you have to mitigate these kinds of covert channels directly.
But I assume the comment above was suggesting there was something more interesting than the magnitude of the lag.
Right, especially in this case where you can almost just go from TLS library to TLS library saying "hm, this implements P1v15, probably has a timing channel" to get credit for the eventual finding. :)
Right. In a lot of cases "this implements RSA" and "this wasn't written by Thomas Pornin" is enough to suspect a timing channel. Writing a proof of concept for one is at least an order of magnitude more challenging; at least in my experience. (I am way better at mitigation than exploit development.)
It took 2 years to find out that a potential vulnerability actually exists. There's a lot of potential vulnerabilities that may or may not actually be exploitable.
For a long time it was months. The original BRs say 60 months (ie 5 years) and then moving to 39 months in 2015. That 1185 days you listed wasn't ever actually in a written document, it's how Chromium browsers generously estimate 39 months.
But yes, none of it matters any more. Apple insisted on 398 days, they decided it is a compliance issue, so all legit leaf certificates in the Web PKI that haven't expired have a maximum lifespan of 398 days.
People tend to think about it as a year or two years because the way a for-profit CA used these limits was to sell annual certificates but allow early renewal without losing out. Say you bought a cert on June 10th 2022, this year as the end of May approaches you get an email (In reality use automation, please) saying hey, you should renew soon. You can pay up on 29th of May, you get a new certificate which expires on... June 10th 2024. They couldn't do that if the rules didn't allow enough extra days.
The CA/B forum lost a lot of credibility with me, the vote failed and it took a single member (Apple) to tell everyone else that they were going to ignore the vote and proceed anyways.
No debate, no re-vote, no giving anyone any extra time or warning.
That's how it should work: the major browser vendors and their root programs should be calling the shots. Participation in CA/B is a favor they do the CA industry, nothing more. The rise of activist browser root programs correlates with essentially everything good that has happened in the WebPKI.
Is there a writeup describing the exact timing side channel?
The advisory states that the vulnerability affects all RSA padding modes, which seems to imply non-constant-time BigNum operations. However, OpenSSL implemented RSA blinding even before the fix, which is supposed to prevent those class of problems. So this should be interesting :-)
Not if you have an ASN.1 compiler and library, but otherwise yes.
OpenSSL has hand-coded templates that correspond to ASN.1 modules for PKIX. That hand-coding can have mistakes, but otherwise the OpenSSL template system is pretty solid. Here we had a mistake in that hand-coding. If they had an ASN.1 compiler then that wouldn't have happened because they could have just compiled the modules from RFC 5280.
"""
Case Studies
1. The Python cryptographic authority is one of the most widely used cryptography libraries
in the Python ecosystem. Many of the tools are largely built on OpenSSL. The popular
cryptography library is written in C. About two years ago, the maintainers started the
process of migrating some of their dependence on OpenSSL away from that to their own
Rust code, particularly starting with areas around certificate parsing and parsing of other
structures. These are some of the most classical places to find memory safety
vulnerabilities in C libraries, and they wanted to mitigate the risk that they were having by
relying on OpenSSL.
Another benefit was getting huge performance improvements, because the greater
safety guarantees they were getting from the language allowed them to be more
aggressive in doing things like not copying memory. Specifically, the safety guarantees
of Rust mean that one can easily represent structures like X.509 certificates as an array
of bytes, and then a parsed structure containing pointers into the original array. ...
"""
Ratio of what to what? Do you mean the number of bugs one would expect to find in a modern implementation (the former two) as a ratio to the number of bugs one finds in old C code (all of the above)?
Basically. Microsoft and Google have both analyzed software defects and claimed that memory safety violations account for ~70%. I don't have time to dig up citations atm, but it's not hard to find. I think the Google results are 'security' related defects whereas the Microsoft results are all defects, but look it up yourself.
From Microsoft[0]: "As we’ve seen, roughly 70% of the security issues that the MSRC assigns a CVE to are memory safety issues."
And from Google[1]: "memory safety bugs continue to be a top contributor of stability issues, and consistently represent ~70% of Android’s high severity security vulnerabilities."
No need, I had the same initial reaction as I scrolled through the list, going from "oh that's a lot of security issues... and virtually all C issues, too... ugh why do we still do this"
OpenSSL is not a security product. It's a loss leader for a security company that sells support contracts. There isn't very much incentive for them to turn out a good product.
A few more CVEs and we're at OpenSSL 1.1.1z, followed by v1.1.1.za, and it is going to break some package manager that in a certain locale orders versions as 1.1.1.za > 1.1.1z, and its users will be stuck on a vulnerable version.
I love LibreSSL and what they represent, but neither LibreSSL nor BoringSSL target all platforms or compatibility with OpenSSL, which can be a bit of a challenge ... and I don't think LibreSSL is likely to have FIPS certification.
At the AWS cryptography group, we've open-sourced our libcrypto - https://github.com/awslabs/aws-lc - which essentially tries to use the best from Google's BoringSSL, OpenSSL (from 1.1x , not 3.x) , our own code, and formal verification and does target a broad set of platforms and is our FIPS module.
We're at about 95% OpenSSL compatibility right now, it "just works" for a lot of applications, and I expect we'll get near-full compatibility this year as we switch more and more of our own systems to using it internally.
We don't promote it broadly, and it's not intended to compete with OpenSSL - but it's a may be an interesting option for some to consider.
> "Release date for this was set to be January 31.
Unilaterally pushed back to February 7 by OpenSSL by way of announcement of many completely unrelated embargoed issues, some of which they had been sitting on since July 2020"
This exemplifies one of the key reasons OpenBSD forked OpenSSL. For those who haven't seen it I'd recommend this presentation from Bob Beck[1], around the 10 minute mark he recounts fixing issues in the memory allocator which had been reported 4 years prior. Seems there's still a similar backlog sitting behind embargoes?
Going by the patch, that looks like the same bug as OpenSSL fixed. That's seven of the eight bugs not applicable.
But this is just one round of patches, I have no further information or experience on/with LibreSSL or how the features compare. Just saying that one patch release does not mean either secure or insecure software.
For cryptography it uses the ring-library which still relies on C-Code in many places. Additionally there is no API-stability (still v0.*) and the last official audit was 3 years ago.
The project has potential but isn't quite ready for prime time yet.
Importantly, that C code (and assembly) is in the guts of crypto primitives. Those tend to be a lot easier to test than higher level X.509 parsing code, which I think is all done in safe Rust.
But for sure, taking a dependency on RusTLS from C code isn't a "boring" choice, and I wouldn't pretend to be confident that that would all go smoothly for a big project.
EDIT: By interesting I just mean "an amusing coincidence" or "possibly a typo", nothing weird.