
TLS 1.3 in enterprise networks - dankohn1
https://www.cs.uic.edu/~s/musings/tls13-enterprises/
======
danpalmer
Given that these companies 'own' the software with which their employees are
communicating, and 'own' the hardware their employees are using, it should be
entirely possible for them to extract key logs from either or both of those
endpoints, which would mean they could happily use TLS 1.3 with no problem.

However, these organisations have a) invest large sums of money in packet-
capture appliances that do all this for them on their network, b) deployment
of endpoint logging to all client machines is 'hard', and c) they usually
don't actually own the software services - they licence ancient things that
won't do key export and still have decades until they are EOL'd.

They claim that weakening TLS 1.3 is the only way, but really it's the
_cheaper_ way, and they just don't want to take the alternative.

~~~
ploxiln
The easier way is to install their own CA in all internal-network devices,
proxy/MitM all TLS traffic, and effectively block TLS traffic that does not
trust/use their internal CA. (Easier way to guarantee all applications are "in
compliance".) They can use TLS 1.3 in this model.

So yes, agreed, enterprises could deal with TLS 1.3, but they'd rather the
rest of the world use worse crypto instead.

They'd always rather do nothing to upgrade/fix their systems. They can't help
it - it seems less risky and costly, and it's their job to make an attempt to
save that risk and cost. So you need to treat them like a natural phenomenon.

~~~
danpalmer
That could be easier, but I wouldn't be certain of it. Between BYOD policies
and apps certificate pinning it could still be difficult or a non-starter for
some applications.

~~~
ploxiln
I think proxy/MitM is _perfect_ when combined with BYOD and app cert pinning.

The user needs to opt-in to the end-to-end-security undermining corporate
network.

An app can opt-out of such networks. In which case you'll just have to use it
at home, or over the cellular data connection. An app that is sympathetic to
or sold for "enterprise" use will allow use of the user-added MitM CA in the
system root CA store.

Finally, a "guest network" could be created if the enterprise wanted to enable
users to use BYOD and any app as they are normally used.

It's just a matter of everyone making an honest choice between end-to-end
security and "enterprise" interception. That was always the choice.

------
fulafel
Compromising the protocol this way on the spec level sounds pretty corrupt.
These people should use something else than TLS. TLS has so far had a headline
objective of end to end confidentiality (as stated by the spec) and this is a
backdoor mechanism. I think the argument for the "pragmatic" compromise is
pretty clearly morally unsustainable.

~~~
AndyMcConachie
There are legitimate reasons to need to snoop on all traffic in an enterprise.
Some orgs are required by law to snoop on all traffic. For example, in the USA
orgs regulated by the Securities and Exchange Commission (SEC) for financial
transactions need to track communications related to their employees' work.

It's not as simple as snooping == bad.

~~~
MichaelGG
You can still track employees' e.g. web traffic by installing a CA and
proxying their connections. That is what is done today and PFS does not change
it.

~~~
AndyMcConachie
People bring their own devices to work these days. And look, this is not
something that I fundamentally agree with or anything. I just want to make
sure we understand the arguments of both sides.

~~~
MichaelGG
BYOD doesn't affect this. If you're on your own device and you connect to
Google.com via the company's network, PFS or not, the workplace can't
intercept. You'll either get blocked (not using their proxy), or get a CA
error (their MITM system can't trick your phone into thinking their self-
issued cert is valid). This is true with or without PFS.

You'll still have to install the workplace's CA, and then they'll continue to
MITM you, like they do today. Or, just use your cell connection and bypass it
all.

It'd only change if you're connecting to sites the workplace controls and has
the private keys for, that you trust (i.e., they get a cert issues by Digicert
then disable PFS on their webserver). This isn't what enterprises are upset
about.

------
ajnin
This illustrates how workgroups and committees are vulnerable to lobbies and
interest groups. Such entities have the resources to relentlessly put forward
their viewpoints and have them considered by the committees, while the
majority standpoint, which I assume would be that people would not want third
parties to be too easily able to snoop on their communications, is not being
represented, or very little comparatively to their share of actual users.

I hope the TLS WG will not bend under pressure, but I'm especially worried
about the "pragmatic viewpoint", which sound awfully close to what the W3C
said to justify themselves when they decided to standardize Encrypted Media
Extensions into HTML5...

------
michaelt
I can certainly understand that someone with a malfunctioning network
component would want to capture and decrypt packets entering and leaving it.

What confuses me is: Surely enterprise users who need that would simply select
equipment offering session key logging?

~~~
MichaelGG
Being able to decrypt just by loading the cert keys is a whole lot easier
(edit: this is what TLS 1.2 allows). It'll work across vendors, products,
it'll work generically, without having to deal with getting session keys out
in whatever format a product supports. It'll work when there is no session-key
support, like everything that just uses a TLS library as an opaque TCP++
channel, i.e., nearly everything made.

Yeah we'd be better off focusing efforts on creating easy, standardized, ways
of doing plaintext logging.

~~~
iancarroll
You cannot passively decrypt connections that use PFS, even with the
certificate key. And TLS 1.3 mandates PFS.

------
solatic
The "enterprise viewpoint" is, in economic terms, nothing less than an attempt
at regulatory capture, damage to the market be damned.

When the market becomes more competitive (i.e. more difficult to continue to
operate in for reasons beyond the principal's control), the principal may shut
down (not going to happen), appeal to authority for protection (i.e. the TLS
WG), or do the hard work and adapt.

Here's hoping that market interests prevail.

~~~
matt4077
I'm quite opposed to these demands to weaken TLS 1.3, but "regulatory capture"
it is not.

These "enterprises" are not the subject of the TLS WG's regulation, they're
simply a group of stakeholders in the process.

More specifically, they are one group of customers in this "market", although
I'm not sure how far the market metaphor gets us here.

~~~
throwaway2048
Not all regulation is done by governments.

~~~
matt4077
That has nothing to do with the argument.

------
bogomipz
The article states:

>"Recently, as the TLS 1.3 standardization effort has begun to draw to a
close, the enterprise network operators have become more vocal."

Who exactly are "enterprise network operators"? That's a rather vague term for
something so central to the drama. Can anyone clarify?

~~~
wmf
Corporate IT departments.

~~~
bogomipz
Why are corporate IT departments part of the working groups for TLS? What size
company do you have to be to have representation? Do you have an example
companies? I guess I'm having trouble imagining the head of IT for a large
insurance company gets a seat at the table.

~~~
detaro
IETF Working Groups are open, you can just sign up and go participate (or task
an employee to do so).

~~~
bogomipz
Interesting, thanks, I did not know this. I somehow thought it was based on
other criteria(academic, hardware vendors, large internet companies etc.

------
runeks
What if all these "enterprise customers" are just black hats/the NSA trying to
get weak cipher suites into TLS 1.3, because it opens up for cipher suite
downgrading attacks?

~~~
wmf
No one is proposing weak cipher suites (unless you're retroactively defining
non-PFS as "weak").

~~~
pdimitar
His question still stands though, and I believe it's well-founded.

There's no better place to weaken security efforts than the official
committees. Enterprise stakeholders can drag a decision indefinitely and can
make a lot of noise and eventually win at weakening the protocols, one way or
another.

(And I am afraid that they might other means to achieve what they want, but
let's not go into the conspiracy theory territory.)

------
johnchristopher
Original title: TLS 1.3 in enterprise networks

Submitted title: There's been some drama in the TLS WG. I wrote it up

~~~
lucideer
The editorialising may go slightly too far, but the original title is really
not very descriptive.

~~~
dankohn1
I submitted the original title because it was the text of a tweet the author
made:
[https://twitter.com/stevecheckoway/status/888802938805792769](https://twitter.com/stevecheckoway/status/888802938805792769)

------
pdimitar
I commend and salute the author for having the courage to express this
internal conflict for the world to see.

That being said, many others here have said that the enterprises have plenty
of alternatives to circumvent TLS 1.3 without it being backdoored in the first
place, but they don't want to expend dollars and man-hours to do so, thus they
exaggerate the issue and try to hijack the discussion to another area.

I am sincerely hopeful it won't work.

------
sitkack
On a side note, why expose ALL users to legacy TLS ciphersuites to support a
small number of users? It would be nice if there was a way to send legacy
browsers and ciphersuites to

legacybrowser.example.com

I don't know of a clean way to do that and not expose all users to the bad
suites. If future versions of HTTP could encode a retry url on connection
negotiation it would definitely help.

Ideas?

~~~
bcoates
I think the only reliable way to prevent downgrade attacks in the face of
potentially arbitrarily broken old versions is to have a field in the server
certificate promising that the server supports particular protocol versions.

If that were in place, if a client that supports TLS 1.3 received a cert that
says "all servers on example.org support TLS 1.3 (and also possibly older or
newer versions)" then the client would refuse to downgrade even if the server
needed to offer old protocols for old clients.

Otherwise whatever mechanism you use to send old clients to
legacybrowser.example.com could (potentially) be corrupted to trick non-legacy
browsers into going there.

~~~
sitkack
I was also thinking that the connection terminator would _only_ let legacy
clients use the legacy endpoint, at at least known-non-legacy clients would be
forced to communicate with the TLS 1.3 endpoint.

------
teddyh
The so-called “pragmatic viewpoint” is virtually identical to the reasoning
that argues for standardizing DRM in the W3C.

------
newman314
There was a proposal on Twitter a while ago (I'll repost if I find it) wherein
snooping in enterprise was permitted but it was done in a fashion where both
endpoints were alerted that the traffic was being sniffed.

Much as I would rather have e2e in general, I thought this might be a possible
compromise.

