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.
"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.
* 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'.