9 ms·
TLS 1.3 in enterprise networks
- fulafel 9y agoCompromising 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.
- nerdponx 9y agoWould it make sense to have two "flavors" of the protocol? One "internal enterprise" flavor supporting this case, and one "external" flavor for everyone else?
- MichaelGG 9y agoThe "internal" flavour needs to be supported on everything. From web servers to databases and so on. And that'd include cases where it needs to be supported on external-facing systems (proxies). It also means pretty much every popular TLS library and tool needs to support the "internal" version. And it also means that any switch to enable the weaker ciphersuites will end up getting turned on most of the time "to make sure it works". The only realistic place you might differentiate between internal and external is popular browsers like Chrome or Firefox. They could only disable PFS in case they're configured to do so via Group Policy or something like it. In the end, this is just a matter of tooling, and hurting the protocol because they want to load keys into monitoring platforms is a bad idea. Instead, they should have host-level hooks that dump out the packets before TLS is applied.
- TazeTSchnitzel 9y agohttps://xkcd.com/927/ https://xkcd.com/927/
- Godel_unicode 9y agoThey address this. Your proposal is virtually identical to the "export grade crypto" proposal which has caused all the recent TLS headache.
- AndyMcConachie 9y agoThere 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 9y agoYou 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.
- martinald 9y agoNot if the website uses CA pinning though?
- detaro 9y agoAdditionally installed CA certificates override key pinning, for exactly this use case (at least in the major browsers, it's possible some niche ones don't do this)
- cesarb 9y agoThe right question would be "Not if the website uses client certificates though?". As far as I know, TLS connections using client certificates can't be proxied, since the MITM proxy would need to have the client certificate's private key.
- AndyMcConachie 9y agoPeople 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.
- 9y ago
- revelation 9y agoOr use one of the bazillion other ways to log the traffic from machines you own and control. The response here can be nothing but a giant "fuck off".
- MichaelGG 9y agoA lot of times there isn't any other way, out of the box. For instance, you might have some sort of network appliance that lets you load certs and keys, but has no way to export session keys (so you can't decrypt offline) and might not have any way to export pre-TLS packet-level data. Or they might have logging but not in a format their expensive monitoring system works with. It's obviously possible to do on-device logging somehow, but it probably isn't feasible for a lot of companies. Think of a lot of software that just calls OpenSSL to get an encrypted connection - they'll have zero support for logging session keys. Such apps need to implement some sort of logging in a way others can understand. Given that there's tons of app vendors and tons of monitoring vendors, this quickly becomes a mess. That's why PCAP-level monitoring is handy - just capture the raw protocol, then the monitoring app can re-parse it all and figure stuff out. But we'll all be better off if TLS1.3 doesn't allow PFS and forces vendors to start supporting a unified monitoring/debugging protocol/system.
- fulafel 9y agoThose boxes are a screening violation of the stated TLS aims and should not be pandered to.
- MichaelGG 9y ago... That's like the entire discussion. I'm just explaining why some folks want to pander to such devices. They've invested millions into such systems and it's entrenched in how they work. Not that it's any excuse.
- deleted 9y ago[deleted]
- amygdyl 9y agoI agree generally with the reactions of disbelief in reply to this article. Its in a company. I know of no hindrance to company policy or ability to make the most rational decisions about networking security, from the starting point of not compromising security, and forcing users or client applications adapt to the needs of compliance with data retention and discovery rules. Security measures must come first. If security is necessarily compromised by the requirements of compliance systems or protocols (policies not network encoding) THEN THE PROBLEM HAS TO BE RAISED WITH HIGHER MANAGEMENT AND WITHOUT ADEQUATE RESPONSE, WITH THE BOARD AND SHAREHOLDERS FINALLY. sorry for my shouting, but the legal risks to the author of this article are extremely real, and he should be immediately taking the problem seriously out of his hands. Unilateral decisions, EVEN IF YOU IMAGINE THE ABSENCE OF LOGICAL ALTERNATIVES ABSOLVED YOU FROM RESPONSIBILITY I ASSURE YOU THAT IT WILL NOT, so please do not ever place yourself into situations like this where you are exposed to a specific liability for any resulting breach of security or loss of compliance with your employers legal regulations. Just don't take the risk. And certainly don't think that receiving moral support from your blog is any kind of indemnity. Instead it's advertising "don't hire me" as many industries will interpret the course of action. Or INACTION since you are throwing your hands up in the air, very publicly. Edit: a word of autocorrelation, and first line for clarity
- tedunangst 9y agoWhat kind of legal risks do think there are for writing a blog post summarizing people's positions?
- jsmthrowaway 9y agoremoved
- MichaelGG 9y agoYou are wrong. PFS does not prevent them from doing the same thing they are doing now, where they install their own CAs and MiTM everything, issuing certs on-the-fly. And PFS or not, without subverting the CA system, they cannot monitor employees.
- jsmthrowaway 9y agoremoved
- MichaelGG 9y agoWhy don't you spell it out? Spying on clients is already done via MITM proxies after installing a CA on the client. That'll still work just fine. I've written network monitoring systems (for voice). Needing to decrypt is a big deal, and the easiest way to do so (apart from just turning off TLS) is just to load your servers' private keys into the monitoring box. Nothing is needed on the client, at all. Nothing is needed on the server, either (not everyone supports the same ways of dumping plaintext traffic).
- jsmthrowaway 9y agoremoved
- openasocket 9y agoIt sounds like you're implying you are aware of a vulnerability in the TLS 1.2 protocol or in a major TLS 1.2 implementation. If you do, please responsibly disclose this to the maintainers immediately so it can be fixed. Moreover, you seem to be implying that major enterprises and/or governments are aware of this vulnerability, and will use/are using it to identify leakers. Generally forward security doesn't give you a lot in a data exfiltration scenario. In this scenario a user is in a hostile network and their machine may be partially compromised and they need to upload data to a friendly server. If the friendly server uses non-PFS cryptography, like static DH, anyone with the server's private key can decrypt the traffic. But if the adversary has the secret keys of your friendly server it's already game over. The advantage forward security gives you is that each individual connection will have a different ephemeral key, so you can't steal the server's keys to decrypt the traffic offline, and if you can break the ciphersuite you have to do so for each and every connection. I personally think we should keep non-PFS ciphersuites out of TLS 1.3, but I don't think it's at all fair to assume malice on the part of those arguing to allow it
- solatic 9y agoThe "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 9y agoI'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 9y agoNot all regulation is done by governments.
- matt4077 9y agoThat has nothing to do with the argument.
- johnchristopher 9y agoOriginal title: TLS 1.3 in enterprise networks Submitted title: There's been some drama in the TLS WG. I wrote it up
- lucideer 9y agoThe editorialising may go slightly too far, but the original title is really not very descriptive.
- dankohn1 9y agoI 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
- michaelt 9y agoI 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 9y agoBeing 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.
- revelation 9y agoYeah it's even easier if we just enable the "none" cipher again. That doesn't make it a sensible choice. What despicable thinking to suggest we should break the protocol so ethically dubious interception companies can reuse their implementation from 1999.
- iancarroll 9y agoYou cannot passively decrypt connections that use PFS, even with the certificate key. And TLS 1.3 mandates PFS.
- eridius 9y agoI would assume that session key logging wouldn't offer real-time analysis of the network traffic, which is what the network operators want.
- danpalmer 9y agoGiven 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.
- johncolanduoni 9y agoIt's also much easier to circumvent than a device (which drops anything it cannot understand) physically locked somewhere where the majority of the users cannot access it. Do you have a client-based solution, hard or easy, with new or old software, that provides similar resistance to tampering?
- danpalmer 9y agoImplementing this server-side would probably be the safest option, and would be very tamper resistant. The main problem is just that implementing it on the many pieces of legacy software with expensive support contracts is difficult.
- sametmax 9y agoWell, unless we reach the limit of physics, "we can't" is always synonymous with "we don't want to". And it's usually a matter of resources, values or skills. But it's bad PR to say "we don't want to spend that much" or "we are not skilled enough to do it". So big entities always say it's against moral/law to do it, or that it can't be done.
- oneplane 9y agoOr they could just use their 'enterprise configuration management' to enforce TLS 1.2 internally... They pretty much have no case whatsoever on making TLS 1.3 weak. If TLS 1.3 were to have no enforced FS, they might as well call it TLS 1.2.. oh wait, we already have that.
- bogomipz 9y agoThe 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?
- kkirsche 9y agoMSSP's are the ones I hear about
- matt4077 9y agoTo save everyone a click: "A managed security service provider (MSSP) provides outsourced monitoring and management of security devices and systems. Common services include managed firewall, intrusion detection, virtual private network, vulnerability scanning and anti-viral services. MSSPs use high-availability security operation centers (either from their own facilities or from other data center providers) to provide 24/7 services designed to reduce the number of operational security personnel an enterprise needs to hire, train and retain to maintain an acceptable security posture."
- wmf 9y agoCorporate IT departments.
- bogomipz 9y agoWhy 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.
- wmf 9y agoAnyone is allowed to participate in the IETF but no one has any formal authority so the analogy of a seat at the table doesn't fit. IMO users of a protocol should have some representation, although regulated enterprise users are a pretty small minority compared to consumers.
- runeks 9y agoWhat 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 9y agoNo one is proposing weak cipher suites (unless you're retroactively defining non-PFS as "weak").
- pdimitar 9y agoHis 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.)
- newman314 9y agoThere 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.
- teddyh 9y agoThe so-called “pragmatic viewpoint” is virtually identical to the reasoning that argues for standardizing DRM in the W3C.
- sitkack 9y agoOn 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?
- eridius 9y agoTerminate the TLS at a load balancer and have the load balancer detect the weak ciphersuite and send the traffic to a separate server? That server can then redirect to legacybrowser.example.com, or just serve up the content that you would get if you went to that domain.
- sitkack 9y agoI'd like it so if any old cipher suite is negotiated, it is then redirected to `legacybrowser.example.com` so that main traffic would ONLY use high quality cipher suites. One might even limit what the user could do using the insecure connection.
- eridius 9y agoAnd that's what my proposal does. All the traffic that goes to your normal servers comes from clients that used high quality cipher suites, and all the clients that negotiated weak cipher suites end up talking to a separate server entirely.
- bcoates 9y agoI 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.
- deleted 9y ago[deleted]
- ajnin 9y agoThis 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...
- pdimitar 9y agoI 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.