11–20 of 39 posts
As far as I understand this garbage protocol is designed to be compatible with TLS 1.3 clients. Can clients detect the use of this, and if detected refuse to connect with a scary warning? That should kill this abomination fairly effectively.
I don't get the complaints. As far as I understood (and ietf appears to agree), eTLS is not a protocol, it is a (server-side) implementation variant of TLS. And it is a universal construction: For any cryptographic protocol, one party can replace its random number generator by a deterministic CSPRNG and store or leak seeds. This is undetectable from outside. There you go, backdoor for later reversal of forward secrec…
Earlier quoted context omitted.
From what I can see this protocol is compatible with TLS 1.3 clients. It makes clients believe perfect forward secrecy is in effect while in fact it isn’t. The risk isn’t much about internal networks, it’s when this starts leaking onto the open internet. Also the fact they call themselves “eTLS” to use TLS’ reputation when actually it’s a voluntarily degraded version of TLS.
There’s no way to guarantee forward secrecy to a client. If regular TLS promises that, the committee is lying and they know it.
If the server doesn't faithfully implement the protocol, of course it will not provide the expected security guarantees. But then it isn't the committee who is lying, it's the server by claiming to implement TLS and then not.
Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.
Why wouldn't they? That group is trying to standardize a protocol that effectively negates a whole lot of progress and even tried to piggy back on the TLS name. Their stated requirements boil down to snake oil and laziness. If companies or groups thereof want to use security measures that aren't on par with the state of the art and intentionally ignore recent learnings, they of course still have that capability but I…
I work for such organization which actually took a fairly reasonable stance and told BOA to piss off when they asked us to join them in petitioning the IETF to make exemptions to PFS in TLS 1.3.
Our current stance is that we dissallow it internally until the vendors that provide us with the DPI and web traffic inspection solutions will have full scalable support for TLS 1.3 or until the regulation would change in a way that would no longer require us to capture, store and be able to decrypt all user traffic within the network.
These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this is no longer enough, you have to share a secret for every session.
This necessitates some kind of software running on each endpoint to transmit these secrets. But wait, the moment you have to have software running on every endpoint, why do you need a special box? Why not do it all in software?
This represents a huge threat to the DPI market. No box means no lock in, no mandatory upgrades, no support contracts. Sure, software can have these things too, but it's inherently a more open, competitive market where you are vulnerable to open source invasion. Solutions like eTLS are just a last ditch gnashing of teeth from DPI box sellers, trying to prevent a lucrative market from disappearing.
Once you move everything to software: a) competition in general gets better and b) open source starts to take over, c) security will improve.
Why do people hate eTLS so much? What do you care what enterprises do within their own networks? They have their requirements and they’ll have to implement them one way or the other.
You could try to assure me that it doesn't, but I do not trust uninformed assurances.
The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…
https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...
previous discussion:
The real story here is not about security, it's about markets and profit (as always). Currently, there's a huge market in DPI boxes for inspecting TLS traffic, which are often poorly implemented, tied to expensive support contracts and super flakey. These boxes can only work with a single static secret, which is shared between the DPI boxes and the actual servers. If the servers are using a forward secret mode, this…
If the endpoint in compromised, in the first scenario, the most the attacker can do it not share the session secret. This is easily detectable.
In the second scenario, the attacker can pretend that the endpoint-local DPI software is still being run, while completely going around it.