10 ms·
Downgrade Attack on TLS 1.3 and Vulnerabilities in Major TLS Libraries
- Someone1234 8y ago> The cat is not dead yet, with two lives remaining thanks to BearSSL (developed by my colleague Thomas Pornin) and Google's BoringSSL. Some kind of award has to go to this sentence, that has to be the most convoluted way to simply say "aren't vulnerable." 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...
- PappaPatat 8y agoI think the audience addressed loved that joke as much as this brilliant attack suite itself.
- pizzazzaro 8y agoYeah... What about LibreSSL?
- george_perez 8y agoLibreSSL has no TLS 1.3 support yet.
- inetknght 8y ago> 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. RSA PKCS#1 v1.5: https://tools.ietf.org/html/rfc2313 https://tools.ietf.org/html/rfc2313 Title: PKCS #1: RSA Encryption version 1.5 tl;dr: deprecate RSA encryption as a whole?! Did I read this right?
- throwawaymath 8y agoThe consensus among cryptographers for quite a while now has been that RSA should be avoided. Implementation vulnerabilities in RSA aren't surprising, and it's a poor choice of algorithm for modern cryptosystems. However, note that much of the problem with implementing RSA correctly is the padding. The specific recommendation here is to only use RSA OAEP, and preferably to abandon RSA altogether for more modern (elliptic curve) constructions. So no, they're not saying to deprecate RSA in its entirety (though I have high confidence all of the authors would strongly suggest that to anyone who asked). Rather, they're saying you should only use RSA with one very specific form of padding, if you absolutely insist on using RSA in 2019 (and you shouldn't unless you know you have to).
- rakoo 8y agoThe Cryptographic Right Answers (https://latacora.micro.blog/2018/04/03/cryptographic-right-answers.html https://latacora.micro.blog/2018/04/03/cryptographic-right-a...) do tell you to ditch RSA if you can. They say the only way to use RSA is in a very very specific way that is probably not the default in many implementations. If you need to be careful when doing crypto you will do something wrong. It's just better for everyone if you just forget about RSA and switch to something that is both highly secure by default and hard to mess up in the implementation.
- baybal2 8y agoRSA is a reliable algo, key exchange protocols are not, and are being broken all the time. Where is exceeds is its original use in PGP/GPG as no complicated key exchanges are taking place
- mwwaters 8y agoI'm a bit late, but this is referring to ditching RSA only for encrypting a symmetric key. The algorithm is vulnerable to side channel attacks since it expects the plaintext to follow a certain padding. The method only has 6% use today and is generally deprecated for DH. For DH, RSA is still used purely for signatures. RSA is not used to hide any data.
- wilsonthewhale 8y agoIs LibreSSL affected?
- adrian_b 8y agoLibreSSL was not among the 9 libraries tested. Nevertheless, it is likely that LibreSSL has not replaced yet this part of complex code inherited from OpenSSL. In that case, LibreSSL would also be vulnerable.
- deleted 8y ago[deleted]
- throwawaymath 8y agoGood question. The paper is here[1] but there is no mention of LibreSSL. 1: https://eprint.iacr.org/2018/1173 https://eprint.iacr.org/2018/1173
- 0xdeadb00f 8y agoStrange. LibreSSL a fairly well-known implementation compared to something like BearSSL (which I had not heard of until today). Does anyone have any ideas on why LibreSSL was not mentioned?
- loeg 8y agoIt's not really independent. It's a major fork of OpenSSL, but at the end of the day, it's a fork of OpenSSL.
- loeg 8y agoProbably. It's basically OpenSSL, with pieces removed. I don't think they've had time to rototill the majority of it.
- pas 8y agoI guess it's not, as it doesn't support TLSv1.3 yet: https://news.ycombinator.com/item?id=19113106 https://news.ycombinator.com/item?id=19113106
- devit 8y agoHow 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) 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).
- tialaramex 8y agoThe article is about cache side channels. They are running on the same CPU as the victim, typically in the Clown. Your "solution" isn't addressing the problem this article is about.
- java-man 8y agoIs BouncyCastle affected?
- hombre_fatal 8y agoJesus. Imagine being enough of a genius to actually write timing-safe code.
- AstralStorm 8y agoWhy? You should be able to mathematically prove lack of timing channels instead over whole negotiation... (For a specific CPU implementation or a set of them at least.) It's just that even encryption library authors are not mathy enough and it takes effort to model CPUs enough. PKCS#1 RSA is likely possible to be proven broken by design...
- hombre_fatal 8y ago> It's just that even encryption library authors are not mathy enough I rest my case.
- AstralStorm 8y agoThey can implement an algorithm. It is not the same as writing tons of pages of a machine code level automated theorem prover. Except someone wrote a library for timing proofs (including cache and memory) in Isabelle/HOL already, but it has to be combined with the recompile prover from SeL4 project. That would take some time and work.
- kccqzy 8y agoAnd with Intel releasing new micro-architectures all the time invalidating your proof?
- AstralStorm 8y agoWhich is why you should use RISC-V Ariane instead which is already being timing modelled by ETH. Or work on the ARM Cortex M5 verification then run it on AMD-SP which is one. Presuming they allow you to run your own code. Likewise Intel ME... But that processor is some weird architecture. Or other external hardware - smart card or the fancy U2F.
- walrus01 8y agoDowngrading to TLS1.2 isn't the end of the world. 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. There is no longer any relevant population of useragents that don't understand TLS1.2.
- arto 8y agoSeconded, and sourced: > Microsoft cited public stats from SSL Labs showing that 94 percent of the Internet's sites have already moved to using TLS 1.2, leaving very few sites on the older standard versions. > "Less than one percent of daily connections in Microsoft Edge are using TLS 1.0 or 1.1," Pflug said, also citing internal stats. https://www.zdnet.com/article/chrome-edge-ie-firefox-and-safari-to-disable-tls-1-0-and-tls-1-1-in-2020/ https://www.zdnet.com/article/chrome-edge-ie-firefox-and-saf...
- rutthenut 8y agoWell given the amount of Internet traffic out there, I'd say that one percent (albeit 'less than' that) could be rather a lot of traffic that would be blocked if TLS 1.0 or 1.1 were totally dropped or blocked.
- pedrocr 8y agoThe suggestion was to block it at the server not the browser. Presumably most of that 1% is because of old sites/servers and not old browsers.
- tialaramex 8y agoThis advice seems nice but I assume you wrote it as a response to the article title. The article itself is actually only doing TLS 1.3 downgrade in passing, and probably only because if they don't some people will say TLS 1.3 fixes this magically (it couldn't). It's a Bleichenbacher Oracle, again. So the effect is you get the server to do RSA operations for you. You don't learn their private key, but the server uses it and you eavesdrop on the process. A TLS 1.3 ONLY server isn't vulnerable (no Oracle) and a client isn't vulnerable even in TLS 1.2 if it refuses to use RSA completely. But unlike your suggestion to disable much older versions, those options aren't very practical today.
- axaxs 8y agoJust 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.
- Flowdalic 8y agoLink to his stackoverflow answers sorted by votes: https://stackoverflow.com/users/254279/thomas-pornin?tab=answers&sort=votes https://stackoverflow.com/users/254279/thomas-pornin?tab=ans...
- esnard 8y agoThomas Pornin actually posted a lot of answers on multiple sites on the StackExchange network, under two different accounts: https://stackexchange.com/users/92852/thomas-pornin https://stackexchange.com/users/92852/thomas-pornin https://stackexchange.com/users/969353/tom-leek https://stackexchange.com/users/969353/tom-leek
- raesene9 8y agoIt's worth noting that on security.stackexchange.com , The Bear and his alter ego are no.1 and 2 by reputation, respectively.
- axaxs 8y agoThanks for this, StackExchange was actually what I was thinking of when I wrote StackOverflow. Luckily, he also posts there a lot as well. I think my favorite answer is as below, as it's the first time I could recall a simplified answer of how TLS works, while retaining technical detail. A gift for sure... https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work/20847#20847 https://security.stackexchange.com/questions/20803/how-does-...
- fulafel 8y agoThere's a big disparity between the level of ambition in transport security implementations, and the big recent archievements in getting crypto more widely deployed... 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).
- merb 8y agoam I vulnerable if I only use TLS 1.2?
- tialaramex 8y agoYes. The only way to be invulnerable to this class of attack is of one of: 1. You never use RSA at all (the attack needs a server to be willing to do RSA decryption, but clients only need to be willing to do RSA for certificate verification) 2. Everything is "on premises". This is a cache timing attack and probably won't be practical even a short distance away over a network. 3. Server doesn't allow any version below TLS 1.3
- AstralStorm 8y ago2. Just like Spectre was not practical over the distance... Until you introduce the fact that browsers run JavaScript. 3. Almost all known servers accept TLS 1.2, and definitely banks.
- merb 8y agoActually what I mean is that my server only responds with TLS 1.2, nothing below or above. So I am still vulnerable to 1. and 2.?
- tialaramex 8y agoYes. Despite the HN title the article topic isn't really "We found a new problem in TLS 1.3" it's closer to "Bleichenbacher Oracles still exist in lots of TLS implementations, although in two of the nine we checked we couldn't find an Oracle". They only mention TLS 1.3 because otherwise uninformed people would say "Just upgrade to TLS 1.3" which won't fix the problem.
- merb 8y agoThanks. Still confusing title, guess best Would be tls 1.2,1.3
- 8y ago
- kccqzy 8y agoWhy 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? Also, what if I disable RSA in my browser and make sure the ClientHello doesn't mention RSA? Will I be secure?
- tialaramex 8y agoYour browser probably doesn't have an option to do this. If it did you'd find out that certain sites just don't work if you forbid RSA key exchange. The type of site that wants SSL Labs A+ scores works fine. But your bank probably doesn't (they actively don't want ephemeral key exchange) and nor does some crumbly older HTTPS site running a stitched together Apache 1.x on an old Debian release. To protect against this attack the server needs to refuse to try RSA key exchange OR you need to refuse RSA altogether including the safe and extremely popular authentication step.
- _null_ 8y agoSerious question: Why does the bank care about the TLS key exchange?
- dharmab 8y agoSome businesses have to run WAF products for regulatory compliance, which is typically implemented via TLS decryption at a WAF. There are ways to do TLS decryption with ephemeral keys but many orgs just use the easy way of just giving the WAF the RSA key.
- bitmadness 8y agoWhat about LibreSSL?
- baybal2 8y agoNow, who was a TLS 1.3 committee member who pushed for removing "hard versioning" from server hello?
- pedrocr 8y agoWith 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?
- koolba 8y agoThat's a long road. Plus, short of cutting off support for legacy versions you would not mitigate downgrade attacks. On the flip side, if we're ever going to go down that road it needs to start somewhere. A middle ground might be a modern stripped down TLS stack and something similar to HSTS to externally flag that a given site does not accept downgrades.
- tialaramex 8y agoSure, this is the standard anti-agility argument. "Oh, we understand yesterday's mistakes now, so, just throw away everything built before today and start fresh, then there will be no mistakes". It's like CADT but with cryptography. If you have the luxury of greenfield development, you are welcome to try this. There's a pretty good chance you'll screw up badly, but regardless when tomorrow more opportunities for mistake are discovered you'll be vulnerable and won't have a greenfield any more. You get to learn basically the same lessons about agility everybody else did, the same way everybody else learned them. Brilliant. The Web is not a greenfield development. Google may have "pushed HTTP 2" but you can still connect to their sites using HTTP 1.1 because _of course you can_. So that first step, where you throw everything that already exists away, is immediately the end of your whole strategy for the Web or more or less any public Internet service. You might be thinking. "OK, old crap stuff would be affected, but my new shiny things would be fine". And you're almost right. But you have to really operate a scorched earth policy, the new shiny things _must not_ interoperate with the old crap at all. And that's a deal breaker in practice on the Internet. If you say "Well, if we can't do shiny I guess we'll do the old thing" then you lose immediately, that's the thrust of their TLS 1.3 example, both client and server want to talk TLS 1.3 which isn't vulnerable - but the attacker abuses the fact that they're willing to talk TLS 1.2 instead. If you don't want to do RSA kex in your own system where you control all servers and clients, don't do RSA kex. I commend this, it's good sense. You can use the exact OpenSSL version described as vulnerable in this article, switch off RSA key exchange entirely at both ends and the vulnerability vanishes. But alas even "almighty" Google does not control all servers and clients on the Web.
- badrabbit 8y agoMaybe a one size fits all transport security protocol is a bad idea. Simpler and smaller protocols with less features might provider better stable security?