24 ms·
ETS Isn't TLS and You Shouldn't Use It
- Spivak 8y agoSo what's the argument from the other side? Going through all this effort to allow PFS to be disabled seems like a ton of work? What's their use-case?
- bryanlarsen 8y agoBanks are required by regulation to monitor & audit pretty much everything. Previously they did this for internet usage by using MITM proxies. TLS 1.3 makes that approach hard/impossible.
- snek 8y agoWhy can't they just install their own self signed root ca on all their computers and continue MITM it?
- yfiapo 8y agoCertificate pinning is used by some very common applications and can break a MITM that relies on a self-signed certificate.
- goda90 8y agoAre those common applications necessary for their business operations though? They could just blacklist them entirely.
- vetrom 8y agobesides, many of those applications depin when you install custom CAs, don't they?
- Legogris 8y agoDo you have any example of such applications that would be used by a bank?
- yfiapo 8y agoI don't work for a bank so I can't speak definitively to their applications. A few sample applications I see listed as certificate pinned in Netskope (a CASB) though include: Adobe Creative Cloud Amazon Work Spaces Docusign GitHub Google Drive GoToMeeting iCloud Microsoft Office 365 Outlook.com Microsoft Skype for Business Salesforce.com Note this typically refers to native applications and plugins which also connect over TLS and not web applications.
- Legogris 8y agoMy suspicion was that any such applications have a web version. I'm a bit surprised by Skype for Business (horrible product BTW, it's a gamble to even be able to sign in on a fresh install) though, the rest I would expect people to use web versions of. I would think that (perhaps coincidentally), the organizations that require these kinds of insights are not the ones that are relying on services that do cert pinning. And if they do, they can but the marketing department/the server running THAT wonky old software from the 90s in a separate subnet.
- Dylan16807 8y agoIsn't that exactly the same between TLS 1.2 and 1.3? They won't have the private keys for google drive. How are those handled today?
- JoshTriplett 8y agoThen those applications are correctly getting the behavior they desire: either they get a secure connection or they don't connect at all.
- hsk0823 8y agoThere's a whole IT market segment around TLS decryption for corporate LAN. Basically corporate MITM that will decrypt TLS at the gateway / firewall, and with currently used TLS standards, will then re encrypt the traffic back to the client so the browser thinks it has a legit connection. It's used to scan packets for intrusion detection, for malware, to track for data loss like the article talks about.
- throwaway2016a 8y agoAll of those require your computer to trust a new Certificate Authority or you will get warnings all over the place. If there is a company that claims to be able to do it without trusting the CA or producing warnings I would love to see it. (seriously, I actually would love to see that). And if you are in a corporate environment using a company computer you forfeit your privacy anyway. You can always go somewhere else or do your banking and Facebook on a different machine / not on company time.
- tonyarkles 8y agoCorrect re: the root cert in my experience at least. They usually get pushed out as part of a Group Policy in Active Directory.
- KingMachiavelli 8y agoWhy? If you have the private key you can decrypt TLS traffic if forward secrecy is off. Which is why forward secrecy exists, to prevent captured encrypted sessions form being decrypted out-of-band with, presumably, comprimised private keys. The issue is that TLS 1.3 deprecates the key exchange that makes this possible, essentially making (perfect) forward secrecy a requirement since the only inlcuded ciphers do so. The only way to monitor/inspect TLS traffic in this situation is to MITM the traffic rather than simply record encrypted sessions.
- dcbadacd 8y agoIt's deceptive to call out-of-band MITM not MITM, it's still MITM just covert. TLSv1.3 forcing it to become glaringly obvious is exactly what should be happening.
- kevin_b_er 8y agoBreaking the security of HTTPS for surveillance and monitoring purposes. The BITS group is formally opposed to secure communications because they want to make it easier to MITM attack the secure communication. They want to make it easier to decrypt communication.
- cbsmith 8y ago...and they want that for transparency, not for nefarious reasons.
- JoshTriplett 8y agoMITMing TLS outside the endpoints is inherently nefarious, whether they think it is or not. If you want to compromise the endpoint, compromise the endpoint. Install your own MITM certificates and terminate the connection in the middle, or install client-side malware. Either way, there should always be a giant warning sign on the client that end-to-end security is compromised.
- cbsmith 8y agoThey don't want to compromise the endpoint. They want to ensure they have a record of all communications to and from the endpoint.
- funkymike 8y agoIn order to implement ETS they already have to compromise the endpoint to make the TLS 1.3 implementation use static keys, right?
- cbsmith 8y agoYeah, but it's a means to an end, not the end. The assumptions that TLS 1.3 is based around are in direct conflict with the requirements of the secure environment they operate in. This isn't some evil thing... a cryptographic protocol is a part of a trusted system, and whether it is appropriate for a particular context has to do with the design of the trusted system.
- yfiapo 8y agoThe other side of the argument is frequently discounted and as an IT security person myself I understand that. However, there is a real challenge for companies who deal with large amounts of very sensitive data. To be able to effectively monitor for data loss it makes a lot of sense to be able to monitor the connection points between your protected network and outside networks. The move to all traffic being encrypted and uninspectable breaks this paradigm. You can cover some of the same concern by implementing an agent on every connected computing device but this brings much greater complexity as you are monitoring potentially hundreds to thousands more places and still have to worry if you have complete coverage. Consider an analogy of going through international customs. Do you employ customs officials at the border who are allowed to sample and inspect private belongings to verify laws are being followed? Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border? The second example is a bit stretched but hopefully illustrates the scale problem.
- Spivak 8y agoBut since every device needs to trust your CA aren't you forced to pack their belongings in either case?
- yfiapo 8y agoHmm, I'm straining my own analogy already so I won't try to beat that horse any deader. :-) I am mostly trying to argue the positives of centralized inspection at network chokepoints in simplicity and guarantee of coverage.
- dcbadacd 8y ago> Or do you employ an official to help pack the belongings of each individual who you think may eventually cross the border? Without telling the person who's things were packed that they were packed by the official.
- Legogris 8y agoI assume that organizations deploying this make it clear to employees that the network and computer equipment is intended for professional use.
- rocqua 8y agoIf your stance is: No opaque data leaves my network Then this is the only way you can have outbound HTTPS connections. And for e.g. a bank, certain legal firms, or any company that has a lot of sensitive data they either don't want to be leaked, or at least want the option of detecting when it is leaked, that is a somewhat reasonable stance. In the case of banks, this is needed for regulatory compliance regarding insider trading. For legal companies, I imagine this is about ensuring certain confidentiality. I could see the same thing for companies dealing with trade-secrets. The statement 'Just log it on the end-points' presumes complete access to those end-points and all software running on them. This method is considered better than terminating TLS early at a proxy and setting up a separate tunnel to the clients because breaking PFS is passive, rather than active. Thus it is a lot less resource intensive, a lot less vulnerable (no internet facing box that, if broken, has all communication in plaintext), and introduces no extra latency. It is essentially a 'better' way to do an authorized MitM on everything on your network, and some companies want this authorized MitM. Like any authorized MitM, it introduces a third party who can compromise security, which is not generally desirable, but some companies don't mind being that third party to their own employees.
- tinus_hn 8y agoIt’s a pipe dream. The webpage or application can easily include its own encryption that can’t be broken by these proxies. If your stance is ‘no opaque data leaves my network’ your only option is an air gap.
- acdha 8y agoEngineering is all about making trade-offs (“perfect is the enemy of the good and all”) and security engineering is no different. The same logic could be used to say that you don't need an edge firewall because each client should have one but it's much easier to simplify the baseline. If nothing else, it would make the remaining traffic stand out more since you wouldn't be spending time auditing normal apps which decode cleanly and it's highly likely that someone trying to circumvent such a system would be required to do things which stand out more than routine usage. As a simple example, an organization which does that kind of monitoring is unlikely to allow users to install arbitrary applications or visit any site on the web. With a standard setup, someone trying to exfiltrate data could just hit a popular site like Github, Gmail, Dropbox, etc. but if they need to use some custom encryption or steganography code they're either forced to install it somewhere far less common (i.e. more likely to stand out) or installing something locally where client monitoring can report an unusual browser extension or application.
- marios 8y agoCorporate environments where "endpoint solutions" snoop through all traffic to detect malware activity. While I understand the use case, I would not support it. What I find unacceptable is, assuming the article is correct, that ETSI is asking NIST to recommend their crippled TLS in their new guidelines rather than TLS1.3. Disabling PFS and thus enabling the decryption of all TLS sessions should be a conscious decision rather than something that was there 'by default' (and could easily be abused).
- propter_hoc 8y agoThis is a remarkable story. Fortunately, this ETSI-backed "ETS" standard appears to have just about zero uptake or internet presence, let alone vendor acceptance. So although this is fairly outrageous based on the EFF article, it doesn't look like something that's a big threat to TLS at this point. PS. I can't even get ETSI's website to load! https://www.etsi.org/ https://www.etsi.org/
- uniformlyrandom 8y agoFunny how word 'Enterprise' picks up more and more negative connotation in modern software world. These days, 'enterprise' means outdated, inflexible and intentionally flawed monster of technology.
- trhway 8y agodont forget the enterprise processes (in software for example it would be Agile/Scrum/Lean/Six Sigma/etc.) and the enterprise people deformed by them. Archaeologically speaking it is a whole culture layer :)
- setquk 8y agoUgh. I’ve been shafted by all of those ideologies. It turned me grey, bald and cynical aka experienced in every possible way to fuck something up. That turned out to be quite valuable!
- bitwize 8y agoI find a useful definition of "enterprise" is this: products or services whose customers are several levels up the org chart from their users.
- dreamcompiler 8y agoIt's even simpler than that: Enterprise just means the people paying for the software are not its users. This is why enterprise software always sucks.
- pjmlp 8y agoDid it ever meant anything else? Many that throw jabs at J2EE (written on purpose), never had the joys of trying out xBaseEE, CEE, C++EE (CORBA, DCOM/MTS),...
- adrianmonk 8y agoSure, ~20 years ago Sun Microsystems used to sell some "Ultra Enterprise" servers which offered nice reliability features like redundant power supplies and a backplane and slot setup where you could install several CPU/memory boards or I/O boards. In comparison to some of their other hardware, these servers were more suited to organizations with more demanding needs like minimizing downtime or having lots of compute power or configuration flexibility. But of course people quickly realized that a key characteristic of actual enterprise computing is large budgets, so it almost immediately turned into a game of labeling things with the word "enterprise" in hopes of vacuuming up as much of that money as possible.
- kevin_thibedeau 8y ago> This would only require changes to servers, not clients, and would look just like the secure version of TLS 1.3. If a TLS 1.3 client will happily connect to an ETS server that isn't playing by the rules, doesn't that indicate a flaw in 1.3?
- tlb 8y agoEither client or server can break secrecy. Server compromise isn't a threat model the client can defend against. For example, the server could simply forward a copy of the whole communication in cleartext to someone, and the client can't know this. In this case, the server is using a predictable number instead of a random one for part of the protocol. Possibly a client could detect this by doing multiple transactions and seeing if a number gets reused, but that seems outside the scope of TLS.
- kevin_thibedeau 8y agoThe expectation is that the encrypted link is not decryptable by a third party. If that isn't always true in the face of an adversary then claims of forward secrecy for TLS 1.3 are false.
- zrm 8y ago
- glitcher 8y ago> Instead of thinking of this as “Enterprise Transport Security,” which the creators say the acronym stands for, you should think of it as “Extra Terrible Security.”
- nneonneo 8y agoIt’s worth reading the mailing list posts by BITS (the main proponent of ETS) here: https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2ScdPZ8E08RE https://mailarchive.ietf.org/arch/msg/tls/KQIyNhPk8K6jOoe2Sc.... The replies are pretty informative. You can see here the message in which BITS starts to consider fixed DH keys, which were implemented in ETS: https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcPn_Xb-ZFjY https://mailarchive.ietf.org/arch/msg/tls/3d7TM0g_EdtMzhgmcP... > Tue, 27 September 2016 18:21 UTC > The various suggestions for creating fixed/static Diffie Hellman keys raise interesting possibilities. We would like to understand these ideas better at a technical level and are initiating research into this potential solution. The core argument made by BITS is that they need a way to log TLS traffic such that it can be decrypted later, in order to provide data retention in line with regulations. While this could be done by logging all ephemeral keys generated by the servers, BITS argues that this isn’t practical due to their use of dedicated packet logging hardware that is key-ignorant. Instead they want to use non-forward-secret TLS so they can decrypt past messages easily. Their beef with TLS 1.3 is that it removes all non-FS key exchange methods, and further that by explicitly obsoleting TLS 1.2 as a standard pushes them to have to adopt 1.3 in an enterprise environment (or risk current/future regulatory scrutiny over their use of an obsoleted standard). Hence why they want to develop a competing, active standard with non-FS key exchange.
- cbsmith 8y agoIf you think about it, given the retention requirements they have, it's not clear that forward secrecy is useful in that context.
- jaas 8y agoForward secrecy is always useful for two endpoints that want to have a secure exchange of messages. It's a core component of secure transport these days. It's not "useful" if your goal is to intercept and decrypt messages that are supposed to be secure, which is what both regulated entities and baddies want to do. If you don't require forward secrecy you introduce a weakness. The protocol won't distinguish between whether that weakness is being exploited by regulated entities or baddies. You don't need to weaken TLS in order to do what the regulated entities want to do - you just need to do the retention on the endpoints. The issue isn't that they can't do that, it's that they don't want to do that, probably for cost or convenience reasons. Those aren't reasons to weaken TLS for everyone who actually wants secure comms.
- peterwwillis 8y agoYeah, let's just make it harder for banks to protect your money so that nobody can figure out your Facebook password in 10 years. EFF: "Everything sent over the network should be a secret! Nobody has a good reason to inspect traffic, it puts users' privacy at risk!" Bank: "We keep trillions of your dollars. Inspecting our own traffic is how we make sure nobody is stealing it. We're a pretty big organization, so this stuff costs a lot of money, and is complex and takes a long time to get right. Can you give us a way to do that in this new TLS standard?" EFF: "No!! Privacy!!!" Bank: "Ok... I guess we'll have to make our own standard, then...?" EFF: "Don't ANYONE use that standard, it will cause REAL HARM!!!!" Bank: "..... Nobody else was going to... except us....."
- wolrah 8y agoPFS doesn't prevent inspection of traffic, it just makes passive capture more complicated since you now need to log the ephemeral keys for each connection rather than just using the private key to decode the whole package. Not necessarily trivial but not exactly impossible for someone who controls one of the endpoints. Active interception with a middlebox still works exactly the same as it always has.
- Dylan16807 8y ago> Nobody else was going to I doubt this pretty strongly. And if they can put in enough effort to implement a new protocol, they can put in enough effort to log some keys. They could do it in a much safer manner, too. They could have a TLS extension that appends the session key to the start of every connection, encrypted so that only the inspection device can use it. Then it would be transparent, connections not using it could be easily blocked, and you would still have forward secrecy in case the private key leaked.
- rocky1138 8y agoSeeing articles like this remind me why I donate to EFF on the regular and recommend others to do so, too. They're on our side.
- unethical_ban 8y agoHow does ETS break MITM for corporate LANs that are trusted CAs on work devices? Why can't a proxy still MITM a connection by terminating the client side, establishing the server side, and that be that? Also, banks seeing their own corporate traffic is ethical and moral. Whether they need to simply find another way to read all data leaving their network is another piece of the story.
- Animats 8y agoWe need a big budget cut in the "homeland security" area. All this interception is not paying off. The biggest "terrorist event" in the US since 2001 was the guy who shot up a gay nightclub in Orlando FL in 2017. That was a solo nutcase; there was no planning chatter to intercept. The Boston Marathon bombing was two brothers. The San Bernardino shooting was a husband and wife. What's discouraging terrorism is the US's overreaction outside the US. It's become very clear to terrorist organizations that if they attack the US, the US is going to hit back, even if it's insanely expensive and causes collateral damage. The people in charge, and many people around them, end up dead. Remember ISIS, the Islamic State? ISIS is down to 1.5 square miles, surrounded, and everybody but the most fanatical fighters is surrendering. The holdouts have days to live. We don't need more Big Brother.
- influx 8y agoI completely agree with you, but the counter argument is the only incidents that are getting through are the ones that are solo because the more complicated plots are getting intercepted and disrupted.
- 51lver 8y agoThat's because people have hands and throats, weapons and weaknesses. You simply can't stop a killer operating at an animal level unless it's stopped while in progress. Stopping organized killing beforehand is however quite feasible, and society does have some responsibilities there.
- AnthonyMouse 8y ago> I completely agree with you, but the counter argument is the only incidents that are getting through are the ones that are solo because the more complicated plots are getting intercepted and disrupted. The problem with this argument is that it can't justify continued spending because that would make it unfalsifiable. We need to spend $450B/year on a bear-repelling rocks because we currently pay for the rocks and there are no bears. And if any bears do appear then we obviously didn't have enough bear-repelling rocks and we need to start spending $900B/year. If there is a real question as to whether the ~0 bears is a result of the rocks, it's time to cut the bear-repelling rock budget in half and see how many bears there are next year. If it's still ~0 then it didn't need to be as high as it was and it may still be too high.
- dreamcompiler 8y agoAs long as browser makers don't support it, this is a non-issue. Correct?
- jeffrallen 8y agoChrist, what assholes.
- forty 8y agoI'm not sure I understand: why can't they record the decrypted traffic instead? (I assume they have it plain text at some point). Of course they could encrypt it again before sending it to their audit server
- flanfly 8y agoI wonder how they plan to get this into Chrome.