
ETS protocol does not provide per-session forward secrecy - jfreax
https://nvd.nist.gov/vuln/detail/CVE-2019-9191
======
galadran
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 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.

~~~
rocqua
> 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.

Actually, the boxes can also MitM the entire SSL connection. This just happens
to be a much more efficient system. It can easily be turned off without
affecting the connection, and it doesn't introduce extra latency. Moreover,
this system allows for post-hoc DPI rather than requiring that it happens on-
line.

> But wait, the moment you have to have software running on every endpoint,
> why do you need a special box?

There are reasons beyond 'market dominance' for not wanting to do this on the
end-points. End-points are numerous, heterogeneous, occasionally and
occasionally difficult to access. This makes actually implementing this system
on _all_ endpoints very hard. Let alone keeping all end-points up-to-date.

In general, which sounds like the nicer approach to take: "drop in solution"
or "solution that affects _all_ endpoints and needs to support all endpoints".

The discussion is a lot more about 'Is PFS an acceptable loss for getting DPI'
with a very large side discussion about whether DPI should even be possible.

~~~
Dylan16807
The passive boxes aren't truly drop-in. You need to extract every single
private key that will be used for traffic. This is easier than modifying the
software to add logging, but not _tremendously_ easier. Endpoints being
numerous, heterogeneous, and difficult to access all apply to existing boxes.
And whether the endpoint is up to date doesn't matter to either method.

It's not a big burden to install a MitM box either; most places call it a load
balancer.

~~~
jakobegger
You can make it less of a hassle by just using the same private key on every
endpoint...

------
sschueller
Just remember, if it has the extra word "Enterprise" in it, it's probably an
insecure, convoluted, undocumented, slow, etc. version of the original...

------
leiroigh
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 secrecy: Forward secrecy is obtained in the moment
you erase from memory the internal state of your CSPRNG, and the server can
just not do that, without violating any protocol assumptions.

Specifying how to implement this in practice is worthwhile; it is not a
weakening or violation of TLS, instead it is an interesting description of
inherent properties of TLS.

The naming (eTLS) might be unfortunate. Better to just make it an RFC on
"Cryptographic backdoors for TLS".

------
Nextgrid
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.

~~~
gruez
Afaik the protocol is merely TLS 1.3 with fixed DH parameters. In that case
it's pretty easy to detect: keep a client side list of DH parameters used by
servers (hashed, limited to the last n connections), and terminate any
connections that shows reuse.

~~~
ratling
You're essentially losing PFS if you do this, since those keys are now
available. This would work, though it would probably have to be at the
application level.

~~~
gruez
>(hashed, limited to the last n connections)

------
jaclaz
The EFF article is actually interesting:

[https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-
you-s...](https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-shouldnt-
use-it)

previous discussion:

[https://news.ycombinator.com/item?id=19255227](https://news.ycombinator.com/item?id=19255227)

------
dogma1138
This is hilarious for the sheer irony of a fix to one compliance issue
creating a different compliance issue.

------
ratling
LOL they changed the name again. This is eTLS (aka not actually TLS but lets
jump on the name).

------
chupa-chups
Hilarious :)

------
kabwj
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.

~~~
tastroder
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 don't see why they should be given
an opportunity to hide that fact behind a known bad standard. That'd only lead
others to be forced to use a broken protocol for reasons like compliance.

~~~
dogma1138
Because companies in some sectors are required by law to inspect all traffic,
while TLS 1.3 doesn’t prevent it in principle it makes it unfeasible to do so
in practice given the number of sessions created in a large organization.

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.

~~~
stefan_
This was never about TLS. Only a stupid person would go "right, we have to
decrypt traffic, we control the clients, _lets break the crypto_ ".

Surely your IT department already updates the software on client computers.
Time to put on their big boy tech pants and decrypt data where the secrets
are, _on the clients_. Then your industry can stop harassing everyone else for
bad crypto.

~~~
dogma1138
Decrypting traffic on the client isn’t always possible due to how modern
browsers operate.

Decrypting traffic on clients is also much harder due to the multiple types of
clients you have and the fact that there is no easy way to MITM every
connection the the client.

The security threat model by definition defines clients as untrustworthy hence
relying on them for decryption is a flawed approach.

If you are going to be cocky and disrespectful at least be right.

~~~
stefan_
You control the client. There are companies making many many millions
_patching Excel to do fancier charts_ , I'm sure whatever vendor you got now
desperately trying to steer the consortiums can instead figure out how to hook
the crypto library in the one browser you install on clients.

Yeah, it's a hard problem. If you don't know half the things your clients are
doing, it's much easier to pretend all the security conscious stuff will be
going through TLS and then we break just that. It's also obviously wrong, as
we all learned when they started filling USB ports with glue.

The boxes already rely on the client, unless someone signed another CA=yes
certificate.

~~~
dogma1138
Again you do not trust your clients in this threat model because you can’t.

It’s simple a client makes an external TCP connection if that connection uses
TLS the its MITMed on the network level and captured this happens to all
connections if the client does not accept the handshake because for example
the CA for the MITM box isn’t trusted or the client uses certificate pinning
the client can simply refuse to proceed with the connection.

If the connection cannot be captured and inspected for any reason it’s simply
terminated and the attempt is logged for future investigation.

There is no reason to break TLS on the client or compromise the browser it’s
worse in every way and cannot be trusted.

