But encryption alone is insufficient for security in financial transactions. You also need to verify that the entity you’re exchanging encrypted traffic with is the one you intended to do business with.
How do you do that part today? Not via Let’s Encrypt.
Making the answer to the second question dependent on also answering the first -- so it was necessary to set up a whole chain of trust via a hierarchy of CAs just to encrypt your connections -- just delayed widespread adoption of HTTPS by decades.
The points that the article is making are the aftermath industry having muddled validation of identity and encryption of traffic up with each other in the first place.
Let's Encrypt finally solved that, but at the same time effectively made SSL certs mostly worthless for identity purposes (as it just means the domain you're talking to is the domain you're talking to).
If you're browsing via HTTP there is no expectation at all that what you are doing is secure.
If you have a problem in HTTPS, you are expecting to be secure, you might not be. Hence, a warning.
A bad certificate is a sign that something's actively wrong while (at least historically) no certificate doesn't really give a strong signal.
A cert that's a day out of its expiration time has zero implications to the confidentiality and identity of the parties to the connection. The same cannot be said about a bad CN or signature.
Most browsers really want to show scary warnings for HTTP connections these days. But there are enough complaints about it as a concept that they have not implemented it yet.
“Zero trust” or “BeyondCorp” security strategies are not widely deployed; a lot of organizations still use browsers over HTTP for internal apps, and don’t have a captive CA or a way to satisfy Let’s Encrypt challenges from outside the firewall. No one wants thousands of companies to train their employees to ignore cert warnings.
And there is a small but vocal set of folks who believe one should not have to satisfy a CA (even Let’s Encrypt) to put up a website.
If you don't manage employee devices AND can't get TLS certificates to internal applications, the employees are right to be scared by the browser's warning. You have failed as a corporate IT department.
* Visiting site with HTTP, there's no expectation of encryption / comms security. So there's no need for warning.
* Visiting site with HTTPS, there's expectation of encryption / comms security, so please let me know if it's not working as intended or there are warning signs.
That being said, I'm at the crossroads of "little knowledge is a dangerous thing". Vast majority of my friends and family would not know HTTP is not encrypted... but they also won't even bother reading an experied cert warning and will just click to proceed.
(on a broader level, working in operations has underlined to me that default user behaviour with any modal dialog, window, warning, error, is to click everything until something works. There is no reason whatsoever to read or understand WHAT was clicked, or pay it any attention later, other than remembering which thing was clicked. It's an entirely binary world of "things that when you click them don't make it work" and "things that when you click them make things work". There is literally no other useful information for most users)
Not to mention that it's never been difficult to get a certificate for a dodgy domain, especially when doing so made a phish more likely to succeed.
Which was and is reasonable, given that encryption mitigates risks that can't be mitigated otherwise, and is therefore a more pressing concern for security -- you can take many other measures to verify who the party on the other end of a connection is, but once unencrypted traffic exits your network, there's not much you can do to prevent snooping.
It again goes back to muddling up these two separate concerns. If we used CA-issued certificates only for identity validation, we could have optimized them for that purpose and not diminished their value because the need for ubiquitous encryption was a higher priority. Meanwhile, we could have just had web servers auto-generating encryption keys (a la SSH, as you point out), without being shackled to the trust hierarchy, and had universal adoption of HTTPS 20 years ago. Instead, we got a single solution to two different problems that is still forcing us to compromise one for the other.
Not even via TLS.
In all seriousness, PKI at web scale is a joke. Nobody knows which CAs are installed in their browser, who these entities are, how trustable they are, etc.
I have long accepted that TLS brought encryption, but certainly not trust.
I suppose Certificate Transparency is the tech working behind the scenes to flag mistaken or malicious certificates should they be issued.
Your reply is missing the point and the difficulty of the topic.
Yes, _you_ know "chase.com.swag.ru" is wrong but the harder computer science question is: "How does a web browser deterministically evaluate if "chase.com.swag.ru" is not the real Chase bank the web surfer intends to reach?"
In other words, the FireFox/Chrome browser doesn't have a function such as:
if (ask_7steps2much_if_domain_is_real_instead_of_fake("chase.com.swag.ru")) then ...
But it looks like EV certificates were not a UI signal used by most web surfers so Chrome/Firefox dropped the visual indicators: https://www.google.com/search?q=chrome+firefox+remove+ev+cer...
This is a major flaw I've seen with a lot of the anti-EV rhetoric that's been espoused in recent years by security experts and browser vendors. They correctly identify that the EV certificate system has major flaws, then incorrectly conclude that rather than fix those flaws, the solution is to get rid of the EV certificate system.
Yes, EV certs are currently insufficient as means of identity verification. How does eliminating EV certificates solve that problem? What alternative is being proposed that would be better than EV certificates at verifying the identity of real-world entities? So far, the plan seems to be to just get rid of EV certificates and replace them with... nothing? That's not exactly helping the situation.
Verification markers are common UI elements used on Instagram, Twitter, Facebook, WhatsApp and many other end user focused apps.
I just need to type in that address by hand and make sure I don't mistype right?
She then proceeded to inform me that her bank person had made sure she knows what an internet address is and that chase.com is in fact not chase.com.scammer.ru
EV certs are not unique. If I were to want a cert saying that it is issued to Chase Inc. then I would just have to found a company called Chase.
Domain names however are unique.
EV certs were always an ugly hack and quite frankly a bad one as well. I think LE handing out certs just for encryption is good. Users should not associated encryption with identity verification.
If you want something like that then the easy way would be to not use CA at all, but banking apps that connect to a server with only certain certs. Or maybe hand out Yubikeys that perform a handshake with the website.
But relying on EV certs is like relying on the fact that a certain envelope has a logo on it.
In the US duplicate business name are indeed an issue. Trademarks are however federally unique and could be used to solve this problem.
> (my grandma) then proceeded to inform me that her bank person had made sure she knows what an internet address is and that chase.com is in fact not chase.com.scammer.ru
Wow. That’s better than most programmers. Did everyone clap?
The thing is, TLS certificates are a "weakest link" system. Even if chase.com is buying EV certificates, a bad actor can still get a DV certificate. You can mitigate that a bit by using a CAA record in DNS, but AFAIK there's no way to specify anything like a policy identifier (which indicates the type of certificate) in a CAA record. The best you get is the ability to limit issuance to a specific issuer.
There could be _some_ value to using a CA like DigiCert if you use a CAA record that limits certificate issuance to them only. Since they don't offer DV certificates you reduce the risk of a MITM using HTTP to get a DV certificate for your domain. You'd also want to reconcile every certificate issued to make sure they're legitimate requests.
For finance transactions there's basically a number of well known entities who should be vouching for the data I'm sending, who have large out of band systems for identity verification.
Sadly none of that has happened.
I understand it’s the larger security problem because there are far more return visits than first visits. But that doesn’t mean it is the only security problem online.
What is the web equivalent of walking into a store for the first time and feeling confident I won’t get assaulted or robbed?
Any purchase is a financial transaction; not sure why you zeroed in on banking. Those happen during first visits offline all the time.
every time i switch computers, reinstall or whatever i get a new first visit. seems to me that first visits are more likely than just the first time when signing up for that account.
If you don’t log in, or don’t have an account, though, it obviously can’t help you.
it happens in the reverse too. google gets very suspicious when i log in from a new device. but this happens more often than you think
Now think about coming back to that site after I've made an account. I may be coming from an email, a push notification, a text message, a targeted ad, etc. The risk is a lot higher because I'm not initiating the flow by using a trusted search engine or typing it myself.
Or like, to be more succinct, it's because MITM rarely happens and phishing happens constantly.
The FCA website can be validated using the UK Government website: https://www.gov.uk/registration-with-the-financial-conduct-a...
And if someone's managed to break gov.uk then I've got bigger problems.
I'll note, though, that most of the time I'm going to be using a credit card and it'll be obvious fairly quickly if whatever goods or services I've ordered don't appear. It's only really if I'm making multi-year investments (or going completely off the correct payment rails) that it's catastrophic if I make a mistake. See also: https://bam.kalzumeus.com/archive/no-payments-are-final/
You check the domain name in the address bar.
Embedded forms aren't safe—one must assume that the surrounding page has access to anything entered into the form, so you're not just giving your CC data to Stripe, you're also giving it to whatever site embedded the form. If you don't trust the merchant with your credit card, the only safe system is the one where you're directed to a top-level page hosted by Stripe to enter the payment details.
In the cryptocurrency world, it's usually a feature to be unable to tell who you're sending money to, or even whether they exist, and this does not seem to have hindered adoption.