I completely disagree with this. Public key pinning has some well known problems that make it very dangerous to implement at scale [1].
There are some very large problems that this introduces and does not solve:
- How do kiosk machines now work? How can I trust any website when every use is first use?
- What about https domains for images and scripts? Is the user supposed to trust each domain separately?
- Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?
- Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task.
Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve.
> How do kiosk machines now work? How can I trust any website when every use is first use?
Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.
> What about https domains for images and scripts? Is the user supposed to trust each domain separately?
Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better.
> Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?
AFAIK, revocation isn't very good even with the current CA infrastructure[1][2].
> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.
I should have the choice. This doesn't even give me that.
> Presumably there could be some sort of <meta> header that listed the public key fingerprint/IDs of any subdomains that the page was going to pull in. This would make the UX better.
This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated?
> AFAIK, revocation isn't very good even with the current CA infrastructure[1][2].
I completely agree with you, so lets not make it any worse.
> I should have the choice. This doesn't even give me that.
I don't understand why you say this. Can you explain more?
> This would make the UX barely passable. If any of these domains change the content at all so the hash changes, how does it get updated?
Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.
>> I should have the choice. This doesn't even give me that.
>I don't understand why you say this. Can you explain more?
Not who you replied to, but with this system, I need to trust everything between the kiosk and the website server to not be MitMed. With the certificate system, I only need to trust the kiosk itself. Specifically, I need to trust the browser does TLS right, and I need to trust the installed root certificates are correct.
>> Not a hash of the contents, just the sub/external domains' key-ids. Yes, the main page would have to change if you updated the keys. Doesn't seem too onerous to me.
Then that means each external domain has to tell all its linkers that its key will change whenever it does. Assuming it even has such a list. What if a party doesn't respond? I understand it would be said parties problem, but it sure does make re-keying difficult.
> Should you ever really trust kiosk machines? They could easily be setup with MITM eavesdropping software.
This has already been answered, but I'll offer a different perspective. For a lot of people kiosk machines are the only way they get to use the internet. Not everyone has the privilege of owning their own computer or internet-enabled phone.
Generally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.
I used to think that; but I'm following Dan Boneh's crypto course on Coursera at the moment, and he specifically notes that you should not even try to implement known algorithms yourself (for production; you could do it ofcourse for the learning experience).
The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.
One of the point of the exercise is to provide constant-time implementations that provably do not leak such information. The hash functions, two AES, one DES/3DES, RSA and elliptic curve implementations in BearSSL have been written to be constant-time. I still have to write some document that explains how such things are done.
This thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong.
I'm not advocating everyone and their mother implement their own crypto. But some software diversity is a good thing. These algorithms aren't quite as scary or fickle as the documentation and existing implementations make them seem. Especially if you stick to good software like DJB's stuff.
For instance, using montgomery/edwards curves instead of weierstrass curves eliminates a lot of the difficulty in writing a constant-time implementation of ECC. And the 25519 implementation comes with a fast, constant-time implementation of a prime field type.
Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance. To Google or Facebook, that may be unacceptable. But to me, that's entirely worth it. Now you have a tiny library that is easy to understand, and easy to audit.
I haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation.
Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame.
(Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)
If you're using modern C++ you might consider using SaferCPlusPlus[1] for improved memory safety. Safe, fast compatible direct substitutes for C++'s unsafe elements (pointers, arrays, vectors, even references are technically unsafe). Small, easy to use, no dependency risk, and can be optionally "disabled" with a compile-time directive. It's the best answer to the Rust crowd who (justifiably) point out the inevitability of memory bugs in large enough C++ code bases.
Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.
OpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.
There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)
On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.
Whoah, no. It's about building crypto code at all.
Given a choice between building something with Nacl and a bespoke stream cipher and building something with a bespoke cryptosystem and AES, I would have a hard time picking, but I'd lean towards Nacl.
this might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.
These guys must be joking. Trust has been lost, the roots should be permanently revoked.
If anything, I think Mozilla's actions are not severe enough. How likely is it that Mozilla doesn't know the full story? There may be additional violations that have been missed.
Mozilla has revoked the CA certificate moving forward. Already-issued certificates are unaffected, to allow current customers time to migrate to a more reputable CA. If they were to immediately revoke the current roots, then thousands of sites would suddenly report certificate errors--which would train users to click through them, helping nobody.
The axe Mozilla is holding over WoSign is the threat of immediate full revocation if WoSign is caught doing backdating again. Given that WoSign has been coerced into cooperating with publishing all CSRs via Certificate Transparency, and that there is likely to be a much larger group of people watching carefully for violations, I don't expect it to take very long for future backdated certificates to be caught if WoSign does try it.
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.
There are some very large problems that this introduces and does not solve:
- How do kiosk machines now work? How can I trust any website when every use is first use?
- What about https domains for images and scripts? Is the user supposed to trust each domain separately?
- Assuming trusting a domain trusts all its other domains mentioned in its content-security-policy, how is this trust revoked for misuse?
- Is the author suggesting that we retain all users of browsers everywhere? I believe that to be a herculean task.
Certificates have their problems, but this is not a solution. I will not propose one here, because it is an extremely complicated problem that needs many separate parties working together to solve.
[1] https://blog.qualys.com/ssllabs/2016/09/06/is-http-public-ke...