There are a lot of keyboard warriors in this thread. This guy puts forward a rational argument for big business.
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?
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.
The original request (see TFA) already addresses this:
> 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.
Taking this further, let's not forget the fact that some endpoints might not even be capable of hosting a "monitoring agent", or it be unfeasible to develop and install one on every single endpoint. Admittedly not directly related to financial institutions, but all the IoT stuff comes to mind as something even consumers would want visibility into the traffic of...
In fact, those endpoints themselves might be locked-down environments secured against monitoring... ironically by the same "secure everything against everything else" attitude.
> 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.
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.
With regards to your example, in my experience in the banking industry, you just re-encrypt for the internal leg.
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.
Yeah, but this means you end up with all this communication infrastructure with MITM or DMZ termination of ssl. Is that really going to be more secure than just allowing for non forward secrecy? Just because the working group removes non forward secrecy from tls doesn't mean it's going to make things better.
Well part of my point was they already have MITM infrastructure and DMZ termination of SSL is something I've seen many times in banks, so it's not exactly an unknown concept there.
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.
Implementing an official Bump-in-the-wire MITM method for TLS would be the final nail in the coffin of the protocol; nobody would take it seriously and would move onto IPSEC.
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.
I agree, this isn't a low margin business either. We are talking about inferior security for all internet users for the sake of Well Fargo's quarterly report.
> 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.
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.
>All encrypted traffic is typically decrypted by the recipient.
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.
>- 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.
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. ...
The guy is basically complaining that they have to change all their infra over to MITM versus just decrypting traffic with private keys.
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.
I think the working group should ignore him because he ultimately wants to save a buck now and shoot himself in the foot, he just doesn't realize it yet.
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.
That clashes big time with the fact that more users than ever are online today with no clue at all about security. (And it's not practical to change that)
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.
I don't think it's so much about who you delegate responsibiltiy for securing networks to so much as how that security actually works. I believe traditional perimeter security is dead or dying and the idea of incident responders manually pouring over pcap files just doesn't scale much further either.
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.
All encrypted traffic is decrypted by the recipient, sure. Who's "the recipient" though? Do all your services handle tls, or do you terminate tls at an haproxy/Nginx/etc before hitting the actual services? How many hops do the unencrypted payloads take inside your network? Do you agree that it would be best to reduce that number to a minimum? There's ways to work around this, but they have trade offs associated with them, and they do have a reasonable requirement here.
If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...
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 would agree that not everyone wants the same set of security problems and that this causes the conflict evident in the mailing thread, not so sure I'm completely with the banks on this one though.
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.
I view this as the banks want to get the experts who are working on the standard to sign-off on their requirements, so they can continue to say they are secure purely because they do what the standards say, and ignoring if the standard is actually increasing security or not.
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.
> If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...
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.
In my experience the only thing the banking industry cares is convince for themselves.
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.
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?
Do not assume that the people who are responsible for monitoring such things (at the big banks) have only their employer's purse in mind.
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.
No surprise, given the quality of the edge software of most banking systems. With few exceptions, they are howlingly bad. I cannot imagine what the insides of them are like.
I sense the response was somewhat less receptive for subjective reasons.
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?
> 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 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.
Unless the devices that need to be monitored are the endpoints. Do you really oppose the laws requiring banks to record all communication (including non-official channels) that goes in and out of their trader's computers? Or do you have an alternate solution that doesn't make circumventing it dramatically easier?
I'm not sure I follow what you're saying. I'm arguing that the banks should already be in full control of their endpoints, so I don't see why they can't perform the monitoring there. Nor do I think that banks should be facilitating the use of non-official channels for communication.
As for circumvention: are you concerned about ensuring a complete communication paper trail or protection from insider threats?
And if you don't have control of your endpoints, any network monitoring or tls mitm is meaningless anyway, as the contents can always be encrypted again inside of the tls tunnel. Then you're back to square one, the inbound/outbound traffic is inscrutable to monitoring.
It's not meaningless, since for a lot of these laws doing something like that can be evidence of willfully trying to avoid the legally mandated documentation requirements and is illegal even if they can't access your information. As long as there is a paper trail from that, you're already in trouble.
The entire point of much of the legislation requiring monitoring of the communications of bank officials is to combat insider threats (though not to security in the usual sense). They're required to monitor all communication (i.e. not just official e-mail that can be easily monitored another way) so there is documentation if any of their employees does something funky (fraud, etc.).
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.
So my knowledge about how forward secrecy works in TLS is spotty to say the least but the server still has the decryption key in memory AFAIK. Why not sidestep the issue and just create a secure channel between the server and whatever middleboxes there are that need the key and just send the ephemeral key that way?
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.
The person requesting this change controls neither the server nor the client. They control the intermediate network. If they could log the ephemeral keys it would solve the solution, but only the server and client hold that.
As I understand it, if you don't have the server's private key it makes no difference whether a connection uses FS. FS merely means compromise of long-term keys does not compromise past session keys.
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?
It does indeed make sense from his point of view. Unfortunately, there are some actors using the exact same perimeter "defense" who I'd gladly see frustrated, mostly governments east of of Poland.
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.
> it will simply be decrypted at the boarder [sic] of the business and routed internally unencrypted.
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.
The authors last point is strong though, if there is an industry body in an area that is affected by these standards, that body should have been involved in the standard process since (before the) beginning. Showing up late and saying "hey, that won't work for us" is pretty weak.
There should internal standards to always encrypt; even internal traffic. Instead of just drop TLS altogether; they could at least reencrypt to a secure protocol that they still support.
a) He's a troll. Look at his patterns around specific requests: he asks for something (an operator, an example), and when one's shown that doesn't count. His messages aren't signed with his name. It's textbook delay-and-befuddlement, right out of that old OSS field manual.
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?
While I probably (haven't followed the issue closely) agree with him on the issue, the arrogance makes my blood boil. These academics and their dysfunctional standard agencies are the ones that should go down in history for how intelligence agencies could build unprecedented dossiers on civilians and despots could enforce their will by torturing journalists. If he thinks one can make a secure internet, something his organization has repeatedly shown itself incapable of doing, without having major players on board with your decisions he is delusional at best.
And how does that relate to the fact that banks would like to have a weaker version of TLS 1.3? If a nefarious entity is stealing your data they're (probably) MITMing your connection with the bank, in which case TLS 1.3 is likely an improvement for you and the bank and so is the forward secrecy part. If it's more along the lines of social engineering then the whole TLS thing becomes moot.
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.
But the bank follows the regulations that tell it to give me all my money back, if there's some fraud. I don't have any money to lose if the bank does not implement security properly. Only the bank has to lose.
They'll refund you after you've already lost the money, or the attacker might use the bank details as part of larger-scale identity theft that might come to leave you in hot water with law enforcement if he uses your identity to commit a crime. All that inconvenience is your own loss, and the bank paying damages for that doesn't really "fix it"
And like, when you put your box on a VLAN which goes through some DPI boxes which goes through some other stuff which is subject to some firewall policy ... guess what? It's still connected to the Internet.
Keyboard warrior here - almost any security solution I have heard of honors user installed CA above all else. Not sure about iOS. So decrypting traffic and MITM are still trivially possible on any device the admins have access to.
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.
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.
I call it paper security or checklist security. Usually it is about implementing enough to check off a list of requirements from some document. Antivirus installed? Check (Nevermind it is a Linux box and AV loads a dubious proprietary driver in the kernel with a huge attack surface and remote exploit posibility because of how it does updates), such and such EAL-4 operating system intalled? Check, and so on ...
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.
You're right, that's fair. I can't remember a large bank was hacked as to where their customer's money was stolen or anything like that. It is usually retailers and such.
We call them "CISSPs" where I have worked. It's a mostly derogatory term for whiteboard warriors of the security world. They usually have a CISSP but no other valuable security background, most certainly aren't programmers and have never even played with Metasploit let alone understood how you exploit a system.
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.
Right. And at the end of the day, skilled attackers can either: a) not care if you decrypt their traffic as they're already in your network and it's too late by the time you're reviewing the incident or b) take a copy of your checklist and say, "well here's something they'll probably never figure out"
A little out of the checkbox thinking goes a long way for attackers. It could for enterprises too if they could overcome their inertia.
> took forever to adopt EMV in the US and other idiocies
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.
That has less to do with chip vs stripe, and more to do with how those terminals interface with the POS.
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...
> 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.
So much worse with NFC, where I can just tap my card (or my phone) against the reader and be done.
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.
No. Convenience doesn't trump everything, economics does. Banks with better security can offer cheaper services to merchants, and the merchants lower prices to the customer.
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.
> Banks with better security can offer cheaper services to merchants
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.
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.
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.
> 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.
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.
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.
Credit and debit card transactions use a two-step process - first of all the charge is approved (between the customer, bank and retailer) and later the charge is transferred. The latter process requires no customer intervention.
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.
> Credit and debit card transactions use a two-step process - first of all the charge is approved (between the customer, bank and retailer) and later the charge is transferred. The latter process requires no customer intervention.
Yes, and Amazon does not do the 1st step when you order something. It does it some random time later (usually hours).
> insert PIN, wait another 5-30 seconds until the transaction runs, and then get my card back.
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.
Unfortunately EMV here in the states is still in its infancy, and it can and does take that long to process a transaction. What I find extremely frustrating is I can use Apple Pay (which still uses EMV under the hood, just the contactless variant) and be done with my payment in under 2 seconds - meanwhile actually dipping my physical card will take a minimum of 5 seconds and up to 30 depending on the situation.
The payment industry in the US did not properly prepare for the EMV transition, and it's pissing everyone off.
Well, having to wear a safety belt is also an inferior experience but we do it for safety
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)
> having to wear a safety belt is also an inferior experience but we do it for safety
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.
The fraud profile is absolutely not the same in the EU and the US, where cloned cards are frequently used to withdraw cash and make physical purchases.
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.
You do realize that e.g. in Germany you are indeed liable if your account has been used for fraud? If by that process you participate in money laundering you'll get sued by the state. Sure you'll probably go free, but the burden is on you.
nfc: i hold my card up the the screen, a progress bar takes 2 second to light up and i just wait for the transaction to go through. i've had way more issues with failing magnetic strips.
I think that's a very biased way of looking at this request. They don't necessarily have a shallow understanding. They have a set of very strict rules they have to obey. If that means no privacy for the employees, then they have to implement no privacy for the employees. The reasoning of the author has been explained pretty well in my opinion.
But that's completely orthogonal to the understanding how the secure systems work.
Indeed, orthogonal. I think it's a denied attempt to connect cross-purposes. I.e. design for security with practicalities of implementation in a broader context.
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.
Usually Big Banking has a sufficient amount of employees that there can be a group that is very interested in the latest developments and a completely different group that only wants to check off boxes on a compliance sheet and change as little as possible "to avoid risk".
I don't understand why the banks need to change TLS 1.3 to spy on their employees. When I was working at a bank, there were literally no routes from the Intranet to the Internet. Everything went through a proxy that blocked 95% of the Internet. Had to run a proxy server on jrock.us in order to get anything done. (They just bought the list of sites to block, and jrock.us never ended up on it. Blacklisting, very good security technique...)
MITM introduces significant delays, yet another single point of failure, adds significant risk of leakage. Current DPI are passive, so they have no such problems.
Could you elaborate a bit on what kind of passive DPI you can usefully do on an encrypted TLS session? Do you mean something like this? https://arxiv.org/pdf/1607.01639v1.pdf
You're getting mixed up. DPI on TLS sessions requires a MITM. The problem is (apparently) that there are no enterprise-grade MITM solutions that support TLS 1.3
So here's how I'm imagining the current solution, as implemented at the bank I worked at. Remember first off, there is no route to the Internet from workstations. Everything goes through a regular old HTTP proxy running on a server that accesses both the intra and Inter nets. You send it the host you want ("GET https://example.com/"), it fetches it and returns the HTML. It is nothing more complicated than:
> I don't understand why the banks need to change TLS 1.3 to spy on their employees ..... run a proxy server....
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.
To be clear, you did have a route to the internet from the intranet, it was just proxied through your bank's proxy server. Presumably you could run TLS through that Proxy Server?
I think this request is pretty unreasonable, and anything that stops the ability to passively snooping on TLS is a great thing.
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).
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.
Just to note - I'm referring to schools as in K-12 kind of schools, in my country we don't call higher education 'school'.
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...
I like your proposed (user-visible) solution quite a lot, this would be great.
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?!?!"
"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.
That's the whole point of forward secrecy. For the one session you use a temporary key which can't be recovered later. You can only decrypt the stream if you store that key.
well your proxy can just store everything in Plain Text? I mean if you really need to decrypt it later you already saved it somewhere, however you can just store the plain text since your proxy already has that?
You're assuming that IT staff in the banking industry is competent and that they have a good budget to work with, but a lot of evidence suggests that often neither of that is the case.
> 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.
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!)
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.
mitm surveillance of employee traffic is basically a cornerstone of enterprise security since those networks are designed to be very squishy on the inside. Thankfully Google is turning the assumption that the perimeter needs to extend to your rather vulnerable clients on its head but that will be several years before it's productized enough that middle managers will be convinced to buy it by a VAR over a game of golf.
That's basically putting the cart before the horse.
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.
Just to be clear I'm referring to monitoring traffic for security threats. Not for things like stealing source code or applying for jobs or whatever BS some employers are paranoid about.
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
Highly culture and jurisdiction dependent. Many places ban this with some narrow exceptions (defense sector etc) in law and/or binding labour org agreements.
> Was the argument by the bankers basically a complaint that retooling would be very expensive?
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.
I don't quite get what they are currently doing. Is it that they have some kind of Internal mitm proxy that proxies every TLS session with external hosts, recording the conversation for later offline analysis? Why wouldn't they still be able to do that? Or are they just worried about their ability to intercept internal conversations? I'd be really interested to know what a typical bank security architecture looks like, does anyone have a reference for further reading perhaps?
Hmm, but why can't they just then record the session keys as before even for forward secure TLS (presuming we are talking about clients inside the bank initiating TLS sessions to external parties)?
"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."
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.
You still get the verification of the other side and still get the encryption on the wire, preventing external MitM. It's just TLS benefiting the company in general, not users separately. You do not want your outgoing traffic to partners and APIs to go out in plaintext.
Basically the model changes from Alice <internet> Bob to Alice, Alice's employer <internet> Bob.
TLS can be decrypted with private key. Just keep your private key secret. For example, this feature is useful for debugging TLS encrypted communication with server by capturing data and decrypting it using WireShark. Forward secrecy breaks that.
Ok I'm missing something here. If an internal bank employee initiates a TLS session to an external service, the only key the bank could hope to access is the session key if it has control over the end host, in which case it can just store the session key for each connection. What private key are you referring too if not the session key?
rather a regular http proxy that every browser supports
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.
It may well be that from a business perspective a greater threat to banking is coming from insiders, failing systems and incompetence than from outsiders exploiting TLS weaknesses. To those wondering why banks are worried about their employees communication even internally keep in mind that there have been very expensive judgements related to banking employees conspiring to break legal or other regulatory rules.
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.
"...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."
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 technical standpoint, the desire of <bank> to monitor all communications of a stockbroker in an easy and effective manner and being able to decrypt historical captured is identical to the desire of <evil government> to do the same for their civil rights activists.
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.
Sure, from a protocol perspective, arranging it so nobody, even the original owner, can decrypt the communication after the fact is beneficial, except that now, you end up with people downgrading such communications or storing the session secret keys, the latter probably by patching software crypto implementations where possible (since I doubt any of the major crypto implementations would agree to storing those keys even with an --i-am-a-developer-really-stop-bothering-me flag).
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.)
> 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.
Welcome to almost two weeks ago? Given how many people seem to be upvoting and commenting on this link, was everyone else on vacation for some holiday I don't celebrate when this came up multiple times before?
Here's the exchange, I found this hard to read without word-wrapping:
> 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
The reply:
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,
Kenny
I don't get it. This can't be about decrypting traffic between internal clients and external servers, because the bank doesn't have the RSA key in the first place. It also seems unlikely that it's about decrypting traffic between external clients and internal servers, because (a) that's not what the bank rep said and (b) the server would just log the traffic.
That 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.
But they're claiming it will require overhauling their infrastructure and cost money to do -- not that it's impossible to support, or that TLS 1.3 will "be illegal" if their demands are not met (this is just nonsense and 100% FUD on part of your comment, honestly -- and I say that as someone who thinks highly of your work). Furthermore there's no clear evidence TLS 1.2 will be deprecated anytime soon, so these people have years to sort out the details with their vendors to have replacements in-flight. Banks have money and connections. They'll survive this and evolve.
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...
While they were very late to the party, this is important for some sectors. Not the reliance on specific tech (RSA) but being able to go back and decrypt their own traffic later, with appropriate keys.
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.
I never knew that it was an accepted practice to have MITM techniques for monitoring activities in cases like the author notes in that thread. I'm not an expert but is this common? I haven't heard something like this before.
Well, North Korea is not complaining about TLS 1.3, why would banks have to? Their proxy servers are already MITM platforms that meet their needs for security.
Probably because Bank employees/customers use modern browsers/devices which will at some point drop support for anything but TLS 1.3. I don't think this will happen in North Korea.
We asked you to please not comment like this, so we've banned this account. We're happy to unban accounts if you email us at hn@ycombinator.com and we believe you'll comment only civilly and substantively in the future.
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?