Originally published at: https://boingboing.net/2019/02/26/monumental-recklessness.html
…
1 Like
Intentionally introducing weaknesses into it isn’t just nuts, it’s an act of monumental recklessness bordering on criminality.
But how do you really feel?
4 Likes
I would go a step further. Given the NSA’s record of internationally weakening crypto standards, and a number of other cases that have not been conclusively linked to them, but are suspicious (e.g. Intel’s RNG) I would suspect that this is another of their efforts.
1 Like
I’m certainly shocked to hear of a financial industry group engaged in that sort of behavior…
What I find more disconcerting is this bit from TFA:
In response to these objections, some IETF participants produced a modest proposal: By tweaking some parameters, they could make a TLS 1.3 server look like it was providing forward secrecy, but actually not provide it. This proposal, mentioned earlier and called “Static Diffie-Hellman,” would misuse a number in the handshake that is supposed to be random and discarded after each handshake. Instead of randomly generating that number (the Diffie-Hellman private key), a server using this technique would use the same number for all connections, and make sure to share a copy of it with the devices doing decryption. This would only require changes to servers, not clients, and would look just like the secure version of TLS 1.3.
Having a lousy standard trademark-squatting is bad; but if it’s the case that the remote party can unilaterally implement it against you without you noticing that you’ve deviated from TLS 1.3 that’s a great deal worse.
6 Likes
OpenSSL has a debug mode where the library will dump all the master secrets it generates, and Wireshark allows to easily load the secrets file for offline decryption of the capture.
There’s really not much difference between these two mechanisms; or if there was, that would probably imply a break of DH. It just provides better scalability by using a static key instead of having to gather all the master secrets on thousands of servers.
I get why it would feel that the remote party is cheating and betraying you, but plausible denial is not part of the spec, and if the remote party wants to make a cleartext copy of your conversation available to a third party, they can; no crypto protocol can fix that.
1 Like
There’s nothing intrinsically wrong with some organisations wishing to intercept communications between their own systems and the outside world. If my bank were physically unable to screen traffic between their employee and the dodgy foot-porn site she was looking at on her lunch break, I can imagine that becoming a security issue for me.
I assume these organisations’ concern is that, as commodity software like OSes, web browsers and mail clients adopt ever-stronger, mandatory encryption standards, it may become practically impossible to manage security at the network boundary. I can believe that this is a real worry for some admins, and that vendors and standards bodies are not taking it very seriously (because their focus is on maximising protection at the individual-device level, since very few devices have a large, competent 24/7 security team between them and the internet).
However, globally weakening crypto standards is very obviously not the right solution, and trying to force that solution through trickery is just shady. The right solution might involve complicated, expensive proxy arrangements and onerous desktop restrictions, which is very unfortunate for banks but, you know, tough luck.
No call can ever be secure if you don’t trust the person on the other end of the phone. But I don’t see this idea as particularly menacing, because what they’re suggesting is that if vendors won’t adopt a broken standard, then perhaps those same vendors will agree to adopt a better standard and then make it broken. It seems unlikely to gain traction.
1 Like
I don’t object to people who need to monitor traffic between their devices for security or regulatory reasons doing so; they can load their pet root CAs or endpoint monitoring or whatnot as needed; my concern is with their hope to have TLS weakened because it makes their monitoring infrastructure easier(they don’t even have the ‘wouldn’t be possible without it’/‘going dark’ excuse going for them, they own the devices involved and their configurations.)
It’s not like the mere presence(even when mostly unused) of the deliberately-broken version has ever bitten us in the ass unexpectedly before…
Right, but what I meant was, it doesn’t seem like there’s any reason for vendors to implement the broken version at all. Or rather, if they don’t think it’s a good idea to implement ETS, I don’t see why they would deliberately break their TLS 1.3 implementation to serve the same purpose.
Having read some more about it, what banks are concerned about is their ability to investigate their own employees. Currently they rely on network inspection appliances that log traffic and can then retroactively decrypt it, by using the private key from (e.g.) the bank’s own off-the-shelf SMTP server, if an employee falls under investigation. If that stock SMTP server uses (valid) TLS 1.3, with ephemeral keys that are not stored, then even having its private key will not allow that retroactive decryption. You might think – as the IETF clearly does – that since the bank controls the server, they can just spy on it locally, but the banks are saying it’s much easier for them to do all the spying in one specialised appliance, so please could every software vendor in the world support that by default.
I imagine what will happen is that banks will create a forked version of OpenSSL or whatever that does break TLS 1.3, and use this on their servers so they can carry on as before, even after clients drop support for earlier TLS versions. But IETF obviously aren’t going to endorse that, or want to be associated with it in any way.
Windows has a pretty rich crypto library, and very good client + enterprise management via group policy and Active Directory.
Microsoft could implement an enterprise proxy/interception that performs all the strong certificate checking/verification and decryption at the network edge, and communicate the important bits of that transaction to the enterprise-managed client as well as re-encrypted data between the edge proxy and the client, while being able to relay the decrypted plaintext to compliance & monitoring devices.
That’s where this group ought to spend their effort, and they should summarily club snake oil vendors with shitty middleware boxes that put their local client devices at risk, by not using up to date & strong standards to verify the WAN-side of the TLS transaction.
This topic was automatically closed after 5 days. New replies are no longer allowed.
