Industry Concerns about TLS 1.3
ietf.org
ietf.org
Unless you have extensive experience in this area, perhaps you shouldn't be so quick to judge "oh they are just spying on their users".
The simple answer to this question is that if a way is not given for businesses to decrypt their own traffic that they generated and encrypted, they simply won't encrypt it.
Take this example: A regulation says that all incoming traffic into a banking sector company must be scanned for potential vulnerabilities and exploits, and allows for "compensating controls". If the incoming traffic is unable to be decrypted at TLS1.3, it will simply be decrypted at the boarder of the business and routed internally unencrypted. This would be worse than copying the TLS1.2 traffic for out-of-band scanning.
I'm not saying that this guy wasn't a little late by the party, but failing to recognise that big businesses have regulations you don't understand or even care about is a huge mistake that will make us all more insecure. After all, who doesn't have a bank account?
But rules and regulations shield me and give me legal and financial aid for the stupid thing my bank might do.
But those who steal your account information and use it to pose as you don't follow the rules and regulations.
Officer Friendly: His social security card was found at the scene, so Mr.Smith must be guilty!
Sure they might be inside the bank's network in which case being able to more easily decrypt traffic could help in sighting this kind of activity, but there's easier ways of stealing people's data and impersonating them than infiltrating a bank.
Sorry, I don't get it. All encrypted traffic is typically decrypted by the recipient. There's no need to add transport-level vulnerabilities to facilitate virus/exploit checks.
He is right, it will be expensive. And he has a right to complain. Should the working group ignore him? It's a tough call. You risk forking standards when you start to do that.
The enterprise as walled garden approach to security seems quite out of date and is harmful to all parties involved. Like it or not, the Internet at large has made our life one big WAN party, and we need to come to terms with that sooner rather than later.
So how would that new approach look? The de-facto solution today is that security is more and more delegated to device vendors and cloud providers. But that seems worse to me than delegating it to the admins of your organization that you know and trust.
We need machines and global policy to help do this work and we need to stop putting faith in magic black boxes which we know will be thoroughly compromised (e.g.: all enterprise vendor equipment).
More on point, TLS 1.3 seems like a step in the right direction of thought: that you can improve your local security posture by improving the global posture.
The use-cases for inspection at the corporate firewall are often explicitly about catching cases where the recipient isn't policing itself:
- the device is compromised, exfiltrating company secrets, but has been rigged to send false reports to the central antivirus server saying it's clean.
- the device is not something it makes sense to install a host-based IDS/firewall/AV on.
- the device is assigned to a broker-dealer who is using a non-work email account to give fraudulent advice to clients off the record.
In an enterprise IT environment, "the recipient" is the company, and the company has internal controls, often required by law or regulation, that involve i.e. people who are not salesmen or traders (IT, compliance, legal, etc) knowing what information flows into and out of the sales and trading departments.
But I don't want financial institutions to use clients that can't be trusted to police themselves.
So, because banks fail at keeping their devices secure, TLS 1.3 must be weakened? I don't see a convincing case here.
The third point especially seems a bit ridiculous: non-work accounts can probably be used from anywhere, why would said broker-dealer bother using the bank's network for his fraudulent activities? If he controls his device, he can use an LTE USB stick, an external VPN with a cipher of his choice etc. ...
However regulation isn't static. Infact, TLS1.3 is likely to live on longer than any given set of government or industry regulations.
If old regulations have a dependency on TLS1.2, then they'll be stuck on that until they "upgrade"
And MITM is the cornerstone of analysis. It may require spending money, or couple of megabytes more for storage of session keys, but at the end - you have the plaintext on your company devices.
TBH I think the BITS guy is over-egging his case a fair bit.
For all outbound to Internet comms they've got to use an interecepting proxy anyway 'cause they're unlikely to have the relevant private key for the communication. So those systems are in place already.
For inbound comms sure there's a hit, you'd need to decrypt at the time of interception and then re-encrypt with a key you know to avoid storing the data in plaintext, but it's far from impossible. And given that the timeline for deprecation of TLS 1.2 is a loong way off, they've got a load of warning to ensure that they can work around it.
As to your question of whether it's more secure, I'd ask more secure for whom? It's obvious that forward secrecy provides valuable additional protection for ordinary users of TLS. That financial services organisations will need to account for a different method of achieving the same goals they have now at some hypothetical point in the future when TLSv1.2 is deprecated, doesn't seem an unreasonable trade-off to me, but then I don't have to pay for those new systems.
As I said in my original comment I think the BITS guy is over-blowing his arguments to make a point.
The rest of us shouldn't suffer because it might mean slightly reduced profit margins for these bozos.
I get that this would be less secure to use in practice because now anyone who gets control over the server or the middleboxes or who can somehow compromise that secure channel between them can get at the shared secret but still, it would preserve forward secrecy. The only caveat is that the secure channel between the server and the middleboxes would also need forward secrecy but I don't really see how that is a problem.
Am I missing something obvious here?
Surely for the presence of FS to be relevant, they must already have the server's private key, implying they do have control of the server?
Then the regulations are faulty and need updating to be on par with reality.
As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?
In this case, the endpoint by necessity is physically accessible to the possible adversary, which means they have a whole host of methods for disabling monitoring software. It's much harder to interfere with a box which you don't have physical access to that is listening in on your communication, and which simply drops any data it cannot intercept.
For example, I heard exactly the same arguments against forward security. On surface they look reasonable with all the complains how it would be difficult to decrypt and re-encrypt again at end points to forward the traffic for scanning.
But then the same bank uses Akamai to defend against DoS and let Akamai decrypts all the traffic so the bank can use Acamai's infrastructure for caching and minimize load on own systems.
Endpoint security is paramount, and some sort of network MitM system is absolutely not a replacement for endpoint agents. I would highly suggest deploying agents on your endpoints.
If you're relying on MitMing S2S traffic for debugging a payment stack, it sounds like your payment stack is opaque to you, which is not only a concern for security, but the general reliable operation of your payment stack as a whole.
> End point monitoring: This technique does not replace the pervasive network visibility that private enterprises will lose without the RSA key exchange. Ensuring that every endpoint has a monitoring agent installed and functioning at all times is vastly more complex than ensuring that a network traffic inspection appliance is present and functioning. In the case of monitoring of supervised employee communications, moving the monitoring function to the endpoint raises new security concerns focusing on deliberate circumvention - because in the supervision use case the threat vector is the possessor of the endpoint.
In fact, those endpoints themselves might be locked-down environments secured against monitoring... ironically by the same "secure everything against everything else" attitude.
That complexity is a sunk cost. You can't guarantee that the network path through the inspection device is the only one available in a world of cellular data and tethering, twelve different kinds of VPN service some of which can purposely look like HTTP, file-level encryption etc.
> In the case of monitoring of supervised employee communications, moving the monitoring function to the endpoint raises new security concerns focusing on deliberate circumvention - because in the supervision use case the threat vector is the possessor of the endpoint.
If the user is the threat then everything on their endpoint is already compromised. Preventing external communication would then require prohibiting every mobile device capable of tethering, constant body cavity searches for storage devices or wireless hardware, etc. If you need that level of security then your internal network should not be connected to the internet at all.
And if you have internal threats but can't justify those measures then it's all the more important that everything is secured at the endpoints to protect the other endpoints from the adversary on the internal side of the inspection device.
For example, his tone is too formal and sounds bureaucratic. He refuses to state his actual request until the end of a long winded description of his clout and authority.
I think people did listen but were turned off before he even got to the point.
edit: Oh dear. Just noticed he has a degree in political science and no development background. How can this end well for him?
I see that as just being a professional adult. He states who he is, which implies why his opinion matters, then he states his opinion.
'Please don't do this kthxbye!!!1!cos(0)!!' is hardly more persuasive.
I think most in this culture lean toward informal speech, and toward stating your argument first and mentioning your credentials last, if at all.
I wanted to send him a private message with suggestions, but couldn't be sure it would be taken constructively and not be hurtful.
I agree that his message was a rational argument. The dismissive response was disappointing, however.
Ultimately, the conflict of interest here is created by the fact that not everyone wants the same set of security properties. (Rhetorical question: does everyone want DRM? It's "more secure"!) The important thing to keep in mind whenever reading about security is what it secures against. It is not unreasonable that banks want to audit the data that flows through their network, in the same way that I should also have a right to inspect the data my devices are communicating on my network. The example I like to remember is the smart TV that phones home with viewing info --- discovered because it was doing it in plaintext.
Rationale: We're trying to build a more secure internet.
Phrases like this rather bother me because it assumes everyone wants the same security properties, which is clearly not the case given this example. "more secure" against what? "secure everything against everything else" seems like a popular attitude recently, and I think it does more harm than good.
Relatedly, it's already hard enough with many "smart devices" that aren't full PCs to add your own CA and do MITM; I can't imagine logging session keys to be any easier if even feasible.
I'm with the banks on this one.
Standards bodies are trying to improve security for a very wide range of people and the obvious target with this is that they're trying to mitigate the risk that government agencies and others can passively read encrypted traffic and then demand access to the server's keys to decrypt.
This is a very real risk, and one with security benefits to mitigating.
Now obviously banks (and other corps) have a legitimate need to intercept and decrypt comms on their own networks. As long as they have control over one of the two ends of the communication, they can get access to the session key and then, to me, it's an implementation matter with their existing logging solutions to log that.
I'm not trying to trivialise the effort needed, but to suggest that there's no fundamental reason that they can' adapt existing solutions to address it, especially as we're not talking about some kind of near-term problem here. This will only come into focus when/if TLSv1.2 is deprecated and if the amount of places still supporting SSLv3 is anything to go by we're a really long way away from that.
So for me the idea of pushing things forward from a security standpoint at a protocol level somewhat outweighs the impact that organizations will need to modify their solutions over the course of the next say 10 years (that's a ballpark number I don't have a crystal ball that tells me when TLSv1.2 deprecation will occur) to address it.
There are very good reasons why you want to latch your regulations to a common, Internet standards body, especially when it comes to security (open, visible, accessible discussion is the primary reason, for me). But in that case, you don't also get to dictate that the goals of the wider Internet need to align with your industry's (short-term) business objectives, especially if they run counter to the goals of the Internet standards bodies. The Internet will continue on and make standards that are appropriate for itself, no matter what the banks do in this regard. Internet standards bodies are not in the business of securing internal bank networks, but if securing internal bank networks is important to banks, they are welcome to use Internet standards in order to do so.
The banks can just as well go back to having regulations on internal communications like they had before SSL and TLS existed if keeping up with Internet standards is too expensive financially or operationally. Or their regulations can say that TLS1.2 is an acceptable deployment for their internal networks. This, too, has costs, as the rest of the Internet deprecates old, insecure stuff. And one of those costs is that you cease being able to piggybank on the efforts of the wider Internet. That cost, over the long term, needs to be assessed by the banking industry too.
The point of "perfect" forward security is that it's not possible to recover session keys using only the secret key and the (logged) handshake data.
One solution would be to modify the server's stack to use kerberos or some other low-overhead encrypted channel to send the session keys to the logging server so that the session keys can be logged along with the encrypted data. Another, less scalable, solution would be to have a border proxy set up the TLS 1.3 session keys and then set up a connection from the border proxy to the internal server using TLS 1.3 PSK such that the internal and external connections use the same session key. Both of these solutions would allow a border proxy to decrypt and filter traffic without the overhead of having the border proxy decrypt and re-encrypt the traffic. The border proxy could decrypt and process traffic, and if no problems are found, forward the still-encrypted data to the internal server.
Yes, with TLS 1.3 it will be a pain to set up logs that make customer data more vulnerable to theft. It will still be possible, and multiple vendors will gladly implement it for banks and sell to banks.
I'm also hopeful that an increase in price of any MITM solutions that might get develop will put an end to such practices where they are abused for marginal utility: Universities, Hotels, Airports, ad-replacing proxies etc.
If big business needs to secure communications in and out of the enterprise, then they need to stop being lazy about it. Tap the endpoints and use internet proxies, block communications with unapproved websites, and install surveillance gear in the conference rooms. I get these are costly measures, but they are only costly because of input cost to get there, not operating cost.
Want to know how you get a gargantuan database out of any company? Ship it out the firewall through a client PC as a H.323 video stream through your favorite software package. You tell me how to filter that one on a modern, carrier grade Pal-Alto firewall? We have tremendous holes in the existing infrastructure because we don't want to put the work into actual security or into fundamental theory.
The bias here is the market should slow down for big business, the reality is, big business not being on the ball and putting pressure for changes on a protocol like this is a tremendous subsidy to those companies. Frankly, public sediment is right in this case, the big businesses should bare the brunt and cost of their mistakes.
Thank you for the eggcorn.
Sounds good to me.
Where have the banks been?
Why didn't this Andrew Kennedy guy (or any other banks) chime in when this was fresh?
Why did this only become relevant to them at the last minute? Forgive me, but I have no sympathy for these institutions. If they really cared about Security, they would have dealt with this nonsense a long time ago.
You want to excuse the banks because they are "big businesses [that] have regulations you don't understand or even care about", but for institutions where security is of critical importance, why haven't they been following this more closely?
This a case of pure neglect and greed.
One cannot rule out... <whistles with fingers in ears>
Someone's going to get vastly improved security whether they want it or not!
Protocols like TLS protect bank customers from fraud. It is the bank's duty first and foremost to protect their every day customers. If Wall Street always comes first banking's primary product will be despair.
This has already come to be :)
If the banks do this, it's their problem, and I hope the regulators will be very unhappy about it. There is no need to make the defaults less secure for billions of people in order to make it slightly cheaper for a few large corporations to implement an obviously correct alternative.
b) Why should I, as a bank account holder, value a bank that uses TLS 1.2 with decryption devices (after the release of TLS 1.3) more highly than one that uses no encryption at all?
is probably the best response for the request.
On a related note though, it's always amazing how on one hand Big Banking tries to show that it's in touch with the latest tech developments (Bitcoin Consortiums, RFID/NFC payments) etc. but on the other hand display a very shallow understanding of how secure systems should work.
But that's completely orthogonal to the understanding how the secure systems work.
I notice some posts argue that we should aim for a pareto-optimum and accommodate the banks, but really this should require a broad representation for the rest of the subjects of TLS 1.3 to work out exactly what the pareto would look like. Given that they are 15 drafts in, it seems to me that there has been ample opportunity.
So they tick all the boxes and in the end up with a worse off posture than if they just stayed with defaults for example.
A little out of the checkbox thinking goes a long way for attackers. It could for enterprises too if they could overcome their inertia.
Meaning that if something hits the fan and the company has their checklists in order, then they can be exempt from liability.
So maybe their checklist is worth a look.
Unfortunately (most) banks/big enterprise are full of CISSPs which is why they keep getting styled on all the time. If they woke up and hired real hackers, adopted real security practices and knowledge sharing they could drastically reduce risk and probably get better software and systems in the process.
They still ask about mother's maiden name, prevent paste of passwords, took forever to adopt EMV in the US and other idiocies
It's security by cargo-culting
Totally agree with your comment, but I'll go a little bit on a tangent here.
I am an European, all my cards have always had a chip, I have not even seen a card without a chip until I visited the United States. All this reluctance to adopt chips seems so ridiculous to me.
But then I spent more time in the United States and with magnetic stripe cards, and boy do I love the better experience.
Let's see, in the US I can swipe a card at any moment of the transaction, and this physical act takes less than a second.
With chip, in most European countries not only I have to wait for the cashier to scan everything, but I also have to wait for the cashier to press a magic button that says "card payment"; only then does the POS become active.
Then I have to plug the card in, different POS terminals require the card to be put in different orientations, wait 3 seconds for the terminal to do whatever, insert PIN, wait another 5-30 seconds until the transaction runs, and then get my card back.
Or let's look at NFC. I still have to wait for the cashier to scan everything and push the magic button, I have to press the card 3 seconds on the POS until the NFC chip is read. Since there's no feedback, I have no idea if I keep the card in the right place until it beeps. After that, it still takes the same 5-20 seconds until it's done. The only advantage of NFC is that I don't have to plug my card in the terminal, but since the progress feedback is worse, I am not sure how that is any improvement at all.
The user experience is so much worse. Why wouldn't I want a magstripe-only card? Yes, it's (vastly) more insecure, but I am not liable for fraud. I don't have anything to lose.
True, swiping is faster (but you have to scribble something on a paper or an e-screen where the end result usually resembles nothing like your signature) :)
I can agree with the criticism there but the tradeoff doesn't bother me (too much)
We do it for our safety, but chip cards are for bank's safety. Consumers are not liable for fraud anyway, only the bank wins.
Let me put it another way. Americans consumers love their magstripe; they wouldn't if they lost money. At the end of the day, chip or magstripe, the consumer has the same amount of money in his bank account.
Right now the banks bear the cost of fraud. They are moving a small amount of that cost to the consumer through by annoying him with imposing a poor UI upon him. Why should the consumer accept that?
Why do you think US credit card transaction fees to merchants are so damn high?
Because until recently, the law was that merchants were not allowed to charge discriminatively based on cash vs. card. Since americans love their CCs and unlike in Europe, CCs are a massive part of retail sales, it was not too difficult for the credit card mafia to impose whatever fees on merchants.
Here in Europe, fees are capped through regulations, not out of credit card companies good will.
I mention this because chip cards can only protect against using a physical clone of a card, while the vast majority of fraud happens online, where the card is not present and the chip is not used at all.
The fraud profile is the same in Europe and the US, yet the fees are vastly different. That has nothing to do with chip vs. magstripe.
Yes, fees in the EU are capped by law, but to think cards are not used just as much used in places like the UK as they are in the US ... Have you been living under a rock for 30 years?
And no, the chip doesn't protect online, other features do.
One way or another, the US consumer pays for the much higher levels of fraud that the stripe allows.
Swiping the stripe at any point during the transaction is tantamount to handing over your card to the cashier and never looking at the bill.
Here is the thing, the stripe holds nothing more than your card number in machine readable form. On the other hand the chip is doing a full on chain of trust review before giving the final ok to the card issuer.
As for not liable, have fun yakking with their lawyers if you ever need to dispute a transaction...
When I dispute a transaction, I click a button in a web interface, and it's instant, I don't have to talk to anyone, certainly not lawyers.
At another bank I have to call, but when I had to call, it also was instant, no question asked.
VISA/Mastercard have very strict rules about how transaction disputes must happen and how long they can take, rules that are very much in the cardholder's benefit, rather than the banks.
Further, you always had to wait for the cashier to scan everything in the UK. The 'magic button' is an implementation detail and not native to the technology.
But apart from that, sure, you want an easily-cloneable passive technology because it saves you a few seconds under some circumstances.
But not in the US. This is also just an "implementation detail". But implementation details are essential for the user experience.
> you want an easily-cloneable passive technology because it saves you a few seconds under some circumstances.
Exactly, convenience trumps everything.
At the end of the day, I don't lose any money with the less secure technology. The bank does. Why should I care?
Apparently you never had a card skimmed
1 - Your card is cancelled and you have to wait some days for a replacement (requiring also that you update it everywhere)
2 - The money you lost (in case of debit) will get back to you, after an investigation.
I did! Just a few days ago! And it's a chip card, but doesn't matter since the skimmer used the information in the magstripe online.
> Your card is cancelled and you have to wait some days for a replacement (requiring also that you update it everywhere)
The new card arrived minutes ago! And that only because they had to send it to a different country. I would have gotten one the same day if I wouldn't have been abroad.
This is the reason why I have multiple cards, and why I never mix up the cards I use online, with the cards I use physically at the store. Since the card that was skimmed was one that I used physically, I didn't have to change it anywhere. And in the meantime, I had backup cards. Always have backup cards and backup banks.
> The money you lost (in case of debit) will get back to you, after an investigation.
Nope. The money was returned instantly. In fact, the bank realised what was going on and reversed all transaction before even calling me.
If my bank didn't do these basic things I would chose a different bank.
This is more complicated when you're a tourist
You know in Europe people don't have many cards. Some people use a prepaid one for online transactions (not only for fraud but also for "things I suspect I might get overcharged")
(I also don't want to swipe my card before I know how much they're charging for it, so I'll wait for everything to give them my card)
Don't dismiss it as "the bank pays for it", I know banks get big profits, but guess where they money come from.
No, this was a Romanian bank, and a Romanian card, and I am currently in Austria.
> You know in Europe people don't have many cards.
Yes, I know that. It's very annoying because it allows many merchants to not accept cards, or certain types of cards (e.g. VISA/Mastercard).
None of my cards have magstripes, that was phased out years ago, so skimming is only a problem because you still haven't migrated away from those. It's not a problem with the chip cards.
Even if you got all the information on the card, my cards all require a second-factor for all online transactions.
> This is the reason why I have multiple cards, and why I never mix up the cards I use online, with the cards I use physically at the store.
An inconvenience that is only required because the security of your cards is less than optimal.
Good luck using them in the United States.
> that was phased out years ago
Where do you live? There have been chip-only debit cards all around the world, but I am not aware of anywhere in the world where they have chip-only credit cards (except maybe in Korea, not sure).
Good luck showing up at a hotel without a credit card, or good luck trying to rent a car.
> my cards all require a second-factor for all online transactions.
Good God, what annoyance. My banks also tried to offer me this "service". I am sure going to wake up in the middle of the night just to approve Amazon's request to take my money for some product that I ordered during the day.
Not to mention the whole plethora of online services I use that charge me monthly at random times.
Looking at my CC bills, I use CCs online multiple times a day. I'm so happy I don't have to approve each one of those. Good thing I could opt-out of 3DSecure too, which in the case of my bank uses SMS, which never arrives in time (or at all) while I am abroad.
> An inconvenience that is only required because the security of your cards is less than optimal.
There's no inconvenience. Even ignoring security, not having multiple cards and multiple banks is completely unresponsible. It increases availability for so many reasons. The security aspect of it is just bonus.
What is inconvenient is not being able to buy stuff in the US, or rent hotels and cars. Different people have very different definitions of inconvenient, I guess.
I am sure going to wake up in the middle of the night
just to approve Amazon's request to take my money for
some product that I ordered during the day.
In face-to-face retailing the two steps happen within seconds of each other, but they don't /have/ to. They can also charge slightly different amounts - for example if your card is swiped for a restaurant bill before you've chosen what tip you're leaving, or if your order comes in two shipments as it's partly back-ordered.
Any two-factor authentication for online use happens as soon as you give your card details, regardless of whether the retailer waits until the box is shipped before transferring the charge.
Yes, and Amazon does not do the 1st step when you order something. It does it some random time later (usually hours).
You don't lose money with the stripe in the US because the banks eat the (massive) losses. Here they don't, because of the better tech. You can still use the stripe, but the merchant takes the liability. It's up to them. Guess why they don't...
So no, convenience doesn't trump everything.
Oh, and in the US you have to wait and sign a piece of paper, eating into your precious time.
Yeah, like we know that will ever happen.
> economics
Then let the banks allow people to chose what type of card they want, allow merchants to charge different price based on the type of card, allow merchants to implement paying before scanning, etc. Basically, allow the economy to work. The system works the way it works (in any country) because of fixed regulations. There's no economy. Neither consumers not merchants have any say in how anything works.
> Oh, and in the US you have to wait and sign a piece of paper, eating into your precious time.
Usually you "sign" on some electronic POS, but this time is comparable to the time spent entering the PIN, still much less than the extra time required to wait for the chip transaction to go through at the end of shopping session.
You have to wait for the transaction to go through regardless. With a chip you just have to wait before removing the card, as a security feature.
Never had to wait that long (unless there is some issue at the bank but usually it just stops working all together when that happens) here in Finland. Also if you use a credit card instead of debit for payments under X euros it doesn't even call the bank just checks on the machine if the pin matches the chip.
The payment industry in the US did not properly prepare for the EMV transition, and it's pissing everyone off.
In Australia, you can activate the card terminal by inserting it, swiping it or tapping it. There is no difference in liability shifting.
In Europe, if you insert the card you'll be prompted for your PIN. If the transactions succeeds, the liability is shifted to you (the cardholder).
It just happens to be what consumers have become used to in each country.
Madness!
The protocol must be finalized before enterprise-grade products can use it, not the other way around.
socat tcp-listen:8080,reuseaddr,fork 'system:curl $(grep -m 1 GET | cut -d " " -f 2)'
with a little logging to put Nefarious Sites on your Permanent Record.
You answered your own question. They need it in order to spy on YOU!
Their problem isn't the "good" employees who don't do stuff like that, their problem is exactly people like you who try (and succeed) to bypass things.
I think there could be a security gain though in adding support for a better way to actively MITM TLS traffic though - in having a proper mechanism for filtering proxy firewalls. For some applications (say, school networks) it is OK to monitor and filter traffic, but the way it is done now is terrible for security. Usually this is by terminating the TLS at the proxy, scanning it, and then re-encrypting it with an certificate automatically generated and trusted by an internal CA (whose root certificate is installed on the machines).
The huge problem is that now everyone has to trust all the root CAs installed on the firewall, instead of being able to decide which ones to trust themselves. The firewall has to also decide whether or not to trust self-signed certificates.
Much better would be to be able to decrypt, re-encrypt with a certificate issued by a real CA, and then also send the original certificate along with the handshake. Then, the first time you visited a TLS site, it could pop up a big warning saying 'This traffic is intercepted by firewall.institution.edu, do you consent?' and have a little exclamation mark in the toolbar to always indicate that it's being intercepted. The browser would have to trust both the interception certificate (which encrypts between the firewall and the endpoint inside the internal network) as well as getting the original certificate and deciding whether to trust that (which you don't get now).
I predict certain folks would respond to this by trapping themselves in the indefensible position of "but if they know we're intercepting them, how will we catch them being bad?!?!"
Edit: And before anyone starts with the "you shouldn't spy on your users" bullshit: Bollocks. If you want that, welcome to laa laa fantasy land where we all breathe sand.
You will use computers or networks in which the operator is recording everything you do. You can either work within that assumption, or you can stick your fingers in your ears and pretend.
And no, I don't use my employer's[+] computer for anything personally-sensitive and I don't install their shite on mine in order to access their network and when I do use their computer I expect they will watch everything I do even if they don't because I'm using their equipment. I do my real work on my own computer or I don't do my work. The employer is well within its rights to suck on it.
[+] There is no reason why the same should not apply to schools, libraries or any other institution in which people are permitted to use items owned or services controlled by others.
This is talking about providing internet for educational purposes to minors. I don't really think there is any argument to say that they should not be subject to automated filtering of the content that they can use on those computers.
Even at work it's probably fair enough. An employer is well within their rights to filter the internet they provide - if you want to do private personal stuff, bring your own laptop and use an LTE dongle or tether it to your phone's internet...
If they do, I don't see how forward secrecy changes much, and they just have to tap the plain text from the proxy.
If they don't, I'm seriously surprised.
from https://mailarchive.ietf.org/arch/msg/tls/1n1tQSGKMBJKsmuCe-...
"With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment."
As I understand their argument, if you control the server (and hence private key and cipher suite) you can store the traffic without MITM and later decrypt it if needed. With forward secrecy, that isn't possible.
I don't buy it.
You can store entire sessions worth of data, but can't also optionally save metadata?
Yes, I realise you may not want to store it for all connections, but if you don't want to have a "should I store" oracle inline with the connections, then do it async and skip writing it do disk/storage service once the answer comes back.
Was the argument by the bankers basically a complaint that retooling would be very expensive? and/or that employee surveillance would be more difficult? (yeah, I'm sure everyone is a fan of that!)
Security is hard. Hard problems are easier when there are fewer of them. It's easier to build one big wall than lots of little ones.
Surveillance of employees is a cornerstone of enterprise security because humans are inherently untrustworthy. One part of the solution to this problem is to define a distinction (using golf[+] of all things as an analogy) between the rough, the fairway and the green. Because defining a border between the rough and the course is easy, and untrustworthy humans aren't all that bad most of the time, the distinction between the fairway and the green easily becomes blurred.
While employers may polish up the distinction between their workaday desktops and their locked-down servers they will never abandon the difference, and nor should they, between their systems and everyone else's systems.
[+] You have my permission to use this analogy with your manglers.
The reason it's a cornerstone is because your clients, especially laptops, are huge gaping attack vectors. They visit other networks and browse the web. Even if they're browsing the web 100% of the time through a web proxy it's not going to catch everything.
And it's for that same reason Google decided to shrink their perimeter. The distinction between their systems and someone else's is still maintained, but they've accepted and embraced the fact that the laptops used by their employees can and will get owned. So instead of acting as a bridge between the internet and internal squishy networks they sit out there with the internet.
But I'm hardly doing the concept justice. In fact I'm probably hurting it more than helping it. If you haven't read it Google discusses the security concepts in a short paper you can get here: http://research.google.com/pubs/pub43231.html
The problem here is really they were way, way, behind on getting their concerns out there.
Are you a fan of laws like "people who sell you financial products are not permitted to lie" and "financial institutions must make an effort to ensure that their salesmen are not lying to customers" or at least "there need to be records so we can sort it out on the lawsuit after the fact"?
That's one of the main things employee surveillance is for in financial services.
Yes.
Everyone else should be more vulnerable to MitM attacks and insecurities, because it's too expensive for them to fix their endpoints.
I don't care. Security protocols are hard enough to design correctly, without adding crap like that. And, I don't care enough about their crappy business model to support it by giving up some of my security.
It's 2016, people. Grow up, or get out.
https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr...
With TLS 1.3, they would need to MITM, which require infrastructure changes and potentially affects the performance.
They are complaining TLS 1.3 forces them to do work they otherwise wouldn't have to do.
They have full control of the end hosts. That's why the group policy forces you to use Internet Explorer instead of letting you use Firefox.
Also never use the word just outside the context of law.
I'm at lost here. What's the point of having TLS if it can be easily decrypted? Why not to ditch it altogether then? All this argument sounds somewhat fishy, just because your practices rely on insecure behavior, it doesn't mean it shouldn't be fixed for the rest of us.
Basically the model changes from Alice <internet> Bob to Alice, Alice's employer <internet> Bob.
I wonder why SOCKs proxies, which every browser supports, wouldn't work for them.
And exactly as expected, they have a MSFT stack so they're wedged and think changing the spec is the right way to solve it. Sigh.
> With TLS 1.2 we can ask the end user to take a Wireshark trace and then decrypt it with the RSA private key. With TLS 1.3 we will have to rely on the SSLKEYLOGFILE feature in Firefox and Chrome, so we want it to be available. Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment.
The alternative namely monitoring on the end points is hard to implement comprehensively and a lot more expensive.
If (and that is a big iff) the banking use case really justifies a special and weaker transport protocol then maybe it should be upon the banks bear the whole cost of doing that. It would also clearly assign the responsibility when things may fail from a security perspective. Maybe the end point alternative looks then more attractive.
And thus essentially defeating the entire purpose of TLS. Can you please help us continue doing this with the new version of TLS too. Thanks. Love. Big Banks.
The argument here could be whether you, as an individual working for an employer on employer-controlled hardware, have the right to communications that cannot be viewed by the employer at their discretion on those systems.
Having that capability (undecryptable communication) on an exceptional basis (e.g. only a few sites or methods do it) might be grounds for blocking any instances of the protocol that negotiate that level at the border.
Having every secure site do it would result in not being able to passively store and only decode the communications that, say, you have occasion to go inspect later for discovery reasons, and instead would require MITMing and downgrading all connections (and storing the traffic, at best, re-encrypted with a different key).
(Note that I'm not voicing an opinion on the topic, just observing that there are legitimate reasons to desire this functionality from several perspectives, which do not necessarily imply wanting a backdoor in the protocol in the general case.)
From a protocol perspective, you can't distinguish it - any new protocol either makes monitoring harder for everyone or easier for everyone, without checking if your reason is good or bad.
If we choose to make communications more private, then yes, the ability to monitor stuff will suffer even if someone has a legitimate and reasonable reason to need this ability. Too bad, we've made a choice that the security of the masses is more important than this. I acknowledge that this change will hurt the banks for the reasons given above, but in this case hurting them is an unavoidable cost of helping most everyone else.
I hope I'm wrong. I don't want to end up in a world where all enterprises actively MITM and negotiate down to non-PFS protocols to avoid this, or hack up the software stacks on their machines to circumvent this (with all the overhead that implies - echoes of "requires Internet Explorer 5" for how old some of this will probably get between updates).
I just don't think that the people who make use of this functionality are going to let it go, no matter what it takes.
(That's not to say it's not worth trying, to be clear - I just foresee it ending poorly for everyone except for private individuals, and possibly even them if ISPs start requiring you accept their MITM CA.)
https://www.ietf.org/mail-archive/web/tls/current/msg12266.h...
> The consensus in the room at IETF-89 was to remove RSA key transport from TLS 1.3. If you have concerns about this decision please respond on the TLS list by April 11, 2014.
https://threatpost.com/tls-1-3-working-group-has-consensus-t...
https://github.com/tlswg/tls13-spec/commit/5d861d58b8a5ef2e8...
https://news.ycombinator.com/item?id=12560284
> On 22 Sep 2016, at 20:27, BITS Security <BITSSecurity at fsroundtable.org> wrote:
>
> To: IETF TLS 1.3 Working Group Members
>
> My name is Andrew Kennedy and I work at BITS, the technology policy
> division of the Financial Services Roundtable
> (http://www.fsroundtable.org/bits). My organization represents
> approximately 100 of the top 150 US-based financial services
> companies including banks, insurance, consumer finance, and asset
> management firms.
>
> I manage the Technology Cybersecurity Program, a CISO-driven forum
> to investigate emerging technologies; integrate capabilities into
> member operations; and advocate member, sector, cross-sector, and
> private-public collaboration.
>
> While I am aware and on the whole supportive of the significant
> contributions to internet security this important working group has
> made in the last few years I recently learned of a proposed change
> that would affect many of my organization's member institutions: the
> deprecation of RSA key exchange.
>
> Deprecation of the RSA key exchange in TLS 1.3 will cause
> significant problems for financial institutions, almost all of whom
> are running TLS internally and have significant, security-critical
> investments in out-of-band TLS decryption.
>
> Like many enterprises, financial institutions depend upon the
> ability to decrypt TLS traffic to implement data loss protection,
> intrusion detection and prevention, malware detection, packet
> capture and analysis, and DDoS mitigation. Unlike some other
> businesses, financial institutions also rely upon TLS traffic
> decryption to implement fraud monitoring and surveillance of
> supervised employees. The products which support these capabilities
> will need to be replaced or substantially redesigned at significant
> cost and loss of scalability to continue to support the
> functionality financial institutions and their regulators require.
>
> The impact on supervision will be particularly severe. Financial
> institutions are required by law to store communications of certain
> employees (including broker/dealers) in a form that ensures that
> they can be retrieved and read in case an investigation into
> improper behavior is initiated. The regulations which require
> retention of supervised employee communications initially focused on
> physical and electronic mail, but now extend to many other forms of
> communication including instant message, social media, and
> collaboration applications. All of these communications channels
> are protected using TLS.
>
> The impact on network diagnostics and troubleshooting will also be
> serious. TLS decryption of network packet traces is required when
> troubleshooting difficult problems in order to follow a transaction
> through multiple layers of infrastructure and isolate the fault
> domain. The pervasive visibility offered by out-of-band TLS
> decryption can't be replaced by MITM infrastructure or by endpoint
> diagnostics. The result of losing this TLS visibility will be
> unacceptable outage times as support groups resort to guesswork on
> difficult problems.
>
> Although TLS 1.3 has been designed to meet the evolving security
> needs of the Internet, it is vital to recognize that TLS is also
> being run extensively inside the firewall by private enterprises,
> particularly those that are heavily regulated. Furthermore, as more
> applications move off of the desktop and into web browsers and
> mobile applications, dependence on TLS is increasing.
>
> Eventually, either security vulnerabilities in TLS 1.2, deprecation
> of TLS 1.2 by major browser vendors, or changes to regulatory
> standards will force these enterprises - including financial
> institutions - to upgrade to TLS 1.3. It is vital to financial
> institutions and to their customers and regulators that these
> institutions be able to maintain both security and regulatory
> compliance during and after the transition from TLS 1.2 to TLS 1.3.
>
> At the current time viable TLS 1.3-compliant solutions to problems
> like DLP, NIDS/NIPS, PCAP, DDoS mitigation, malware detection, and
> monitoring of regulated employee communications appear to be
> immature or nonexistent. There are serious cost, scalability, and
> security concerns with all of the currently proposed alternatives to
> the existing out-of-band TLS decryption architecture:
>
> - End point monitoring: This technique does not replace the
> pervasive network visibility that private enterprises will lose
> without the RSA key exchange. Ensuring that every endpoint has a
> monitoring agent installed and functioning at all times is vastly
> more complex than ensuring that a network traffic inspection
> appliance is present and functioning. In the case of monitoring
> of supervised employee communications, moving the monitoring
> function to the endpoint raises new security concerns focusing on
> deliberate circumvention - because in the supervision use case
> the threat vector is the possessor of the endpoint.
>
> - Exporting of ephemeral keys: This solution has scalability and
> security problems on large, busy servers where it is not possible
> to know ahead of time which session is going to be the important
> one.
>
> - Man-in-the-middle: This solution adds significant latency, key
> management complexity, and production risk at each of the needed
> monitoring layers.
>
> Until the critical concerns surrounding enterprise security,
> employee supervision, and network troubleshooting are addressed as
> effectively as internet MITM and surveillance threats have been, we,
> on behalf of our members, are asking the TLS 1.3 Working Group to
> delay Last Call until a workable and scalable solution is identified
> and vetted, and ultimately adopted into the standard by the TLS 1.3
> Working Group.
>
> Sincerely,
>
> Andrew Kennedy
> Senior Program Manager, BITS
To: BITS Security <BITSSecurity at fsroundtable.org>
Subject: Re: [TLS] Industry Concerns about TLS 1.3
From: "Paterson, Kenny" <Kenny.Paterson at rhul.ac.uk>
Date: Thu, 22 Sep 2016 19:14:25 +0000
[...]
Hi Andrew,
My view concerning your request: no.
Rationale: We're trying to build a more secure internet.
Meta-level comment:
You're a bit late to the party. We're metaphorically speaking at the
stage of emptying the ash trays and hunting for the not quite empty
beer cans.
More exactly, we are at draft 15 and RSA key transport disappeared
from the spec about a dozen drafts ago. I know the banking industry is
usually a bit slow off the mark, but this takes the biscuit.
Cheers,
KennyThat leaves two cases: internal client <-> internal server and internal client <-> internal MITM. For both of these cases, I see two easy solutions:
1. Log the session key.
2. Define a custom TLS extension that contains the session key encrypted with against a known bank-controlled public key and have the server/MITM send this extension after the handshake. Problem solved.
In any event, the internal client <-> external server case is highly problematic. What's to stop, say, Snapchat from running an extra unauthenticated DH exchange in JavaScript and encrypting all the application layer traffic against the resulting session key? The MITM proxy won't notice unless it's very clever indeed and then all those nice MITM proxy logs are useless.
http://queue.acm.org/detail.cfm?id=2904894
What have we gained in security, if TLS1.3 is basically illegal to use for banks ?
Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ?
In any case, they could have made their concerns available earlier to the standards body. Like, over two and a half years ago (RSA key exchange was removed in early 2014). This is hardly the fault of "cyberlibertarians" or whatever, this is just these people being out of touch. The alternative here would be that these guys get to butt into the standardization process and demand changes at the very last moment, after years of work, with no negative impacts or consequences for them -- for what is ultimately a small portion of the overall internet.
Why would we want that? It completely undermines the authority of the IETF and the entire point of a standards process if "really important" people can just completely railroad it and demand changes on a whim with no consequences to themselves. Frankly, completely ignoring the actual content of the request, this alone is pretty bad behavior on their part.
Why we should worsen the security of billions of people, and introduce complexity into a vital internet protocol, so that those dorks can have slightly higher profit margins -- I dunno. Designing a security protocol is hard enough. If they didn't want to pay attention to the conversation, and now want to cry their pockets will take a hit -- well, maybe they'll learn and be more proactive next time and save themselves some cash.
> Who wins if browsers refuses to connect to web-banking which operates inside the boundaries of the law ?
Nobody ever said TLS 1.3 would be illegal for banks, that browsers are going to immediately drop TLS 1.2 after this (both of these two being a requirement for your prediction to be true -- lol, and also completely asinine) making it refuse to connect to a "law abiding bank", or that moving to TLS 1.3 would be literally impossible for them forever and can't be solved.
This is just complete FUD dude, c'mon. Unless you're actually interested in the answers to completely nonsense hypotheticals made up out of thin air, I guess...
They need to routinely spy on some of their people,amd trace what happens to their money. Not sure why this is a problem. Their use-cases are different to (say) a user of Signal.
Unfortunately this is very far removed from the goals of the IETF, who is striving for a more secure internet.