4 ms·
One reason not to trust TLS is that it's one system that you want to be secure for all your users - indefinitely. If in the future there was some method to crac
by bArray 6y ago
One reason not to trust TLS is that it's one system that you want to be secure for all your users - indefinitely. If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked.
Remember also it wasn't so long ago we were talking about things such as POODLE attacks. For all we know, some bad implementation of TLS 1.3 could default to some crappy easy to crack algorithm.
I believe there was a paper (can't find it now) that speculated about the cost to crack a specific TLS setup to be about $10 million USD in processing, going back some years. (I think it was in reference to some half of VPN traffic at the time using the same keys.) If Moore's law still applies in any sense, that cost likely halves every two years and people only really change their passwords if they have to.
Another reason is that it reduces risk server side if you are never handling user passwords - at worst an attacker gets a temporary hash that's valid for a short time, specific to that server. Maybe they can do some harm during that time, but you can ultimately revoke that key and undo the changes to the user's accounts.
- sonotmyname 6y ago> If in the future there was some method to crack the TLS or the appropriate keys/certs were leaked, any recorded traffic could be retroactively cracked. This is incomplete. TLS does allow for ciphers that enable Perfect Forward Secrecy (PFS) to prevent this. Those ciphers are not the most commonly used ones, but to describe TLS the way you do implies it's a flaw in TLS.
- johncolanduoni 6y agoI thought ECDHE or X25519 suites were pretty common these days; I appear to get the latter when connecting to Cloudflare hosts for example.
- bArray 6y ago> This is incomplete. TLS does allow for ciphers that enable > Perfect Forward Secrecy (PFS) to prevent this. Sure, it was simplified. I can't remember exactly what the support was like for PFS? And given it probably requires additional exchange for DH, I imagine it would be disabled due to resources reasons.
- johncolanduoni 6y agoApparently TLS 1.3 only supports cipher suites with ephemeral key exchange: https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/ https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/
- kubanczyk 6y agoThere is this study back from 2013 (claimed by OP early days of da internetz) which says that out of 1M top sites, 74.5% of those that support SSL/TLS also supported DH/DHE (supported the perfect forward secrecy). It was a substantial rise comparing to 2006 survey that got 57.5%. AFAIK the contemporary browser versions preferred DH/EDH as soon as they got them. https://blkcipher.pl/assets/pdfs/ecc-pfs.pdf https://blkcipher.pl/assets/pdfs/ecc-pfs.pdf
- deleted 6y ago[deleted]
- tialaramex 6y agoSo, the paper you're remembering is about conventional DH with short (typically 512 bit or 1024 bit) primes https://weakdh.org/ https://weakdh.org/ The proposition is that the NSA has a large black budget, and it could plausibly have done the math to unwind DH with the most popular 1024-bit DH primes, and certainly would be able to do this for 512-bit DH. Nobody does this in 2021. Your browser is using X25519 which is the same concept but with Elliptic curves instead of modular exponentiation of integers. If Steam were concerned about certain TLS parameters, they could just ensure they never agree the worrying parameters. It wouldn't make any sense to instead bake some other mechanism for login and then trust TLS for everything else.