On the Perceived Value of EV Certs, Commercial CAs, Phishing and Let's Encrypt
troyhunt.com
troyhunt.com
We could've had a mostly encrypted Internet a long time ago if encryption and privacy were not hitched to a commercial identity certificate with crappy maintenance tools.
I hope security architects going forward heed this lesson.
The "identity" in TLS exists principally in order to prevent network adversaries from substituting their own keys for those of your intended peer.
The only website that I regularly have anxiousness about entering my credentials on are Google properties. Since email can be used to reset pretty much anything, Google is one of the most important set of credentials to prevent falling into the wrong hands. Unfortunately they don’t seem to care about EV certs.
Additionally, app-based OAuth screens with web login prompts regularly give me pause. I don’t like not being able to see the URL and certificate information.
A more-SSH-like approach would be for browsers to identify PSL-level domains with simple site names, which can be done by-hand for the Alexa top 500 if nothing else; so "https://docs.google.com/whatever" maps to a green "Google docs> whatever" in your URL bar; click to reveal the full URL. The idea is that a local store for this mapping is distributed across all of the browsers out there, so by default you get a yellow arrow on `-> https://idontknowthisdomain.example/` and perhaps as HTTP goes south we get a red one on `-> http://thisdomainneither.example/`. But you can right click that yellow arrow and it asks "Do you trust the following domain?" with a "Name: ____" box to submit your own name. After that, this domain has been white-listed for you to have the given name, just as in HTTPS. Possibly you can even have the page itself suggest the name via a meta tag. The important point is that the user has to say that they trust this domain to have that common-name, before they see it pop up in green.
From there, the browsers can do what they already do best: phone home. If you get millions of different users suggesting the same official name for a web site, it's more reasonable to automatically add them so that more than just the instantaneous Alexa Top 500 is covered.
You still rely on the core certs to provide privacy, but people who visit a phishing site now see by default either a yellow or red arrow where they are accustomed to seeing a green one that they either set up themselves or someone else set up for them.
What about sybil attacks?
I got some of my CS courses from a man named Kevin Walsh who I think was a Ph.D. candidate at the time; I think he's now teaching at Holy Cross. If my memory serves his group solved (at least for the time being) the Sybil attack problem on the then-active distributed-filesharing-networks at the time, but it never really grew in adoption because the stakes were really low.
Their basic idea was (again if memory serves me right) to let people self-classify into clusters, so your esteem of someone else's ranking of websites would be based on your own ranking of those websites and how they match. In that way, you get a fully distributed web-of-trust system which nevertheless can't be Sybil-poisoned: to inject their own phishing sites, an attacker first needs to inject trustworthy reviews for a bunch of other unclassified sites, which violates the Sybil assumption that your reviewer identity is disposable or forgeable or whatever and demands that you contribute more to the network than you take away.
I'm not sure if this could be quasi-centralized for browser reviews of proposed short-names for domains, since it assumes a big peer-to-peer decentralized system with lots of people reviewing lots of things and lets them sort themselves into their own groups; it gets dodgy if you're retroactively like "okay so here's the main group now". There is a hint of what it would look like if you try to recentralize it and say "this is the consensus for that domain name's shortname" in the form of how blockchain networks look: there you have a similar story of "if you want to break our consensus that your site is a phishing site, you first need to join our network and outperform the rest of it." But yeah, I think that sorting out the data requires some sort of complicated thinking. I'm more dreaming that sorting out the interface and getting approximate correctness for 90% of traffic so that people get accustomed to that little green box being there, is not especially hard.
On the flip-side, this is already a problem in the form that browsers have to detect phishing somehow and there are Sybil attacks on that based on marking other sites as phishing to try to decrease peoples' confidence in these phishing indicators. So even though there is a technical problem here, I'm not sure I see it as novel to this particular approach.
The (great-grand)parent is probably not talking about EV certs, because then they'd be stupid. They say:
> We could've had a mostly encrypted Internet a long time ago if encryption and privacy were not hitched to a commercial identity certificate with crappy maintenance tools.
...which wouldn't make sense if it didn't include the basic DV certificates, because then those DV certs would be exactly the sort of quick&easy encryption-without-identity they're looking for.
They're complaining about encryption requiring a process that used to cost enough to discourage many people, even for DV certs. The situation has only really changed in the last two years or so with LE, and you can quite clearly see the impact of free certificates and a slightly better process on the rate of encryption.
"Unlike most digital signature programs, this one has no concept of "true names". It makes no attempt to determine that the Bob you are talking to is the "real" Bob. It merely ensures that it is the same Bob."
But that implies that some time in the past, you had a "first contact" with the real Paypal. You then need something somewhere that helps validate that initial trust.
And let's say a computer already made first contact with paypal.com and bankofamerica.com, what happens when the user needs to format the harddrive or gets a brand new smartphone? Do they export their previous successful handshakes to a flash card and import them into their new device to maintain key continuity? Or is it easier to use an entity (CAs or something similar) to help establish indentity+trust?
Another interesting option is called triangulation IIRC. The idea is to randomly query some other clients for their key-continuity info on first use.
Right, but it seemed like tedunangst's continuity suggestion was an answer to tptacek's "You cannot have privacy without some form of trust or identity."
Since continuity doesn't work for 1st contact, it still doesn't solve the fundamental trust issue. Based on the thread's context about the value or worthlessness of CAs... If you have to still use CAs for 1% of the key handshakes, "key continuity" seems like a tangent to the topic.
There's ways to do third party validation of a DNS entry.. only so much that it's the correct entry, since that's really all DV gives you anyway with automation. This is really only needed on first contact too.
There's no reason that "Only $KEY can read this" and "$KEY belongs to $READ_WORLD_ENTITY" have to be tightly coupled.
Just because you need [the network operator to think you have] some form of the latter, does not in any way mean that the former is "not valid" unless it has one particular form of it baked in.
Tight coupling is evil (ref. dependency injection), and complaining about it is not in any way not valid.
While there are alternatives to such attacks, active attacks require a greater investment by the attacker, and in some cases aren't practically feasible without being detected by the legitimate network operator.
Ultimately, if your threat model is to protect against the actions of a state actor who likely does not have active control over your network, but might be able to passively listen, then ubiquitous encryption helps a lot with defense in depth.
A more mundane case is free wifi at an airport. Someone can set up a hotspot with the same SSID and act as a MitM, but it's not undetectable. Here, encrypting application traffic is just one solution, and not necessarily the best one, but you shouldn't be relying on only one layer of protection.
Anyone connected to the network you are connected to has the ability to route your traffic through themselves and sniff/manipulate it.
For privacy the only trust you need is into cryptography.
* how many users have been here before
* how 'new' is the site
* how much does it look like other popular sites or sites the user has visited (perceptual hash)
* how close is it's name to a popular site (levenshtein distance)
* how did the user get here (clicked a link vs clicked a bookmark)
* does it have form fields
* does it appear to ask for credentials (OCR rendered page for 'Login', 'Username',or 'Password')
I imagine it's possible to evade some or all of these but it increases the difficulty and cost of shenanigans. We often get tripped up where for security application we like some sort of mathematical certainty we're protected when 'pretty good' is still better than nothing.
As a small fish in the big pond that is the www, I'm also wary of any solution that may end up giving the handful of established behemoths an advantage that smaller competitors cannot at least in theory also get (except by growing to similar size). Right now, there's a process that establishes a "good enough" level: EV certificates are within the reach of even small websites, and with my identity being known and proven, I'd argue that they actually track pretty closely to the actual "truth" of the respective trust-worthiness.
If a site pops into existence maybe it shouldn't be trusted immediately. Trust has to be earned and this is a protocol to 'earn trust'.
The goal is to disambiguate 'trust' with 'encrypted connection'.
"HTTPS & SSL doesn't mean "trust this." It means "this is private." You may be having a private conversation with Satan."
TLS (nee SSL) was conceived a long time ago (it's about a 10th of the age of my house but in internet terms a good while back) and is now ubiquitous. The trouble is that end users int al. do not really understand what it really means.
It really doesn't help that Chrome/Chromium and Firefox at least are making it harder and harder to actually view a SSL cert from a website. The Google mob are making it almost bloody impossible for those not familiar with dev tools - rubbish.
EV certs are more of the same - you still have to look up at that URL bar and see the organization name.
All of us who know how to trust websites, do it by looking at the domain. We don't remember what sites have an EV cert. It doesn't matter, the standard procedure always works: check https, check domain, done.
No other solution works reliably, at the scale of the web. Any other solution ends up adding complication. Doing this the right way really isn't hard, people just need one half-hour class, in their entire life, to enable them to reasonably safely use the web.
dig +multi _25._tcp.mx1.comcast.net TLSA
And I'd also note that mail.sys4.de has a TLSA record for HTTPS.
dig +multi _443._tcp.mail.sys4.de TLSA
HPKP (HTTP Public Key Pinning) is a header you send to browsers telling them "the only certificates / intermediate certificates you should trust for this domain are: ABC, XYZ. that's it. if a non-matching cert gets presented for this domain, go apeshit.".
Using HPKP, you can pin any level of certificate: you can pin your own leaf certificate that you purchase from whomever (or that you get from Lets Encrypt), you can pin that vendor's intermediate cert, you can pin that vendor's root cert, whatever you want. You have to specify at least two pins, and you can mix and match the level of the pins.
This is a key point: a lot of (all?) CAs have different intermediate certificates for DV vs EV certificates.
If MyCompany Inc buys an EV Cert from ReputableCertVendor (and another from IrreproachableCertVendor) and issues HPKP headers pinning to the EV intermediates of those two vendors, then can't I have a reasonable expectation that those two companies will take measures to make sure they don't issue EV certificates for perceptually-similar domain names (and could I win a court case against them if they did)? Is that level of assurance not what the exorbitant fees are supposed to go towards?
[0] a colleague of mine calls it the "HPKP footgun"; if you bought a 1 year cert 10 months ago, start pinning that cert's vendor's intermediate and one other, and _then those two vendors go out of business the next day_, you are going to have a really bad day in a couple months when your existing cert expires (browsers that have visited in the last two months will only honor certs from those two CAs, but you can't get a new one and your old one is expired).
[1] HPKP is TOFU (trust on first use, meaning a user/browser has to reach _your site first_ in order to get the "right" HPKP header. If their first visit to mycompany.com is sslstripped or otherwise MITMed, that MITM can and will strip the HPKP header before proxying the response, and then that user/browser doesn't get the benefit of pinning). AFAIK you can't submit your own pins to the browser preload lists like you can with HSTS: https://security.stackexchange.com/questions/143500/are-ther...
then if the customer is google.com, and they've paid for a moat of width 5, and somebody tries to register these domains:
domain distance
=====================
google.com 0
google.co 1
goegle.com 1
gargle.com 4
gaggle.com 9
example.com 40
OK this is actually not a great idea (too easy to abuse). But what else are all those sweet, sweet EV cert fees going towards?
The option for anyone too close would be to get an EV cert... also requiring EV for any domain within a distance of 4 to alexa top 100, 3 to the alexa top 1000 and 2 to the top 10000 would be a good start.
My question is how would registrars coordinate this?
A few of them get together and make a pact about how to measure similarity, then convince browser vendors to treat their certificates specially (triple padlocks!! 3 > 1, must be safer!!)?
See here for a real-world example of what can go wrong when you pin to intermediates: https://cabforum.org/pipermail/public/2016-November/008989.h... (in this case, things worked out OK for the customer, but only because Symantec was willing to intentionally break the rules)
What is your goal here? Pins are per-domain (optionally including all subdomains). They wont affect similar domain names - browsers would accept a certificate from any trusted CA.
A few years later (upon renewal time), it gets swapped out for a "normal" cert and nobody notices.
Fun fact: it was actually our marketing department that nixed our EV cert, on the grounds that having the company's legal name in the address bar would be "confusing" to customers who expected to only see the domain name.
Do you believe the EV process is easily subverted, and certificates issued without adequate proof of identity?
Or do you believe that doing business with someone whose identity is certain is just as risky as doing business with someone who only proved control of the domain's DNS?
I've personally never (knowingly) seen the EV extended green bar generate any positive change in general end user buying behaviour.
I'll be willing to bet that few of them will be able to usefully debate the merits of EV over DV though 8)
However, it is a start and I'm glad it works for you. It would seem that the message is getting through a bit. I own an IT company with 20 odd employees and I estimate that roughly 50% of those staff would be unable to tell me exactly what an EV cert is for as opposed to a DV but to be fair they are all rather good at looking for the signs that a site is dodgy (or bone fide)
Why ask something as esoteric as the differences between EV and DV certs to end users, instead of the differences (albeit cosmetic) they actually see.
This exact point is discussed and addressed in the article:
> What we're seeing here is that EVs are most frequently used by larger sites and as size declines, so does EV adoption. Now perhaps the commercial CAs are simply seeing this as a large addressable market for their product (which would bring us back to financial motives again), but clearly their view of who actually needs the cert the most is not consistent with those who are actually buying them.
See also the mentions in the article of informal surveys of non-technical users, who show no apparent affinity for EV certs.
I have not seen any A/B studies of the efficacy of EV certificates in driving conversions/sales/etc.
In this case the numbers do not tell the whole story.
Sure, it "could help". But let's say there are 2 identical sites. One site upgrades from DV to EV. The other site takes the same money and invests it in a Graphics Designer to make their home page look nicer.
Which one will sell more product? I'll put my money on the nicer-looking site every time.
Random people don't know an obscure corporation any better than they know an obscure domain name. It's as possible for Foo LLC to be operated by "Satan" as foo.com.
And the people who know what an EV cert is know that. So hardly anyone will even realize that you have one, and the few people who do still won't care.
It would be interesting to see a real study that accounts for confounders like site improvements or new products rolled out at the same time as the new certificate.
If there was actually a large effect it might suggest that browsers UIs need to be adjusted, given how little real assurance of trustworthiness an EV certificate provides.
However, what are the benefits of OV though? From checking Google, they seem to display as regular DV certificates but have additional information in the certificate. I don't think anyone actually looks at the certificate if you have most users not even being aware of how EV SSL is shown.