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.

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.

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.

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.

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.

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. ...

But I don't want financial institutions to use clients that can't be trusted to police themselves.

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.

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.

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.

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 :)

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.

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"

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.

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?

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 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?

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.

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.

Officer Friendly: His social security card was found at the scene, so Mr.Smith must be guilty!

The rest of us shouldn't suffer because it might mean slightly reduced profit margins for these bozos.

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.