CA Security Council – Myths about CA's
casecurity.org
casecurity.org
Is it really the case that anyone can get a CA to issue a certificate for "Wellsfargo.com?" Doesn't the CA provide some level of value to the consumer, that they really are connecting to someone who was able to prove they have control over the "wellsfargo" domain, or at least their DNS server? And, likewise, doesn't the CA provide some level of value to the Bank, who wants the nice "Green Lock" appearing in the URL bar?
Nobody is arguing that the system is bulletproof, that all consumers are educated to watch for a "green" HTTPS connection, and that 100% of certificates have always been assigned to the proper party, and only the proper party - but, by and large, isn't the job of a CA (and the value that they offer), to provide some level of assurance that you really are connecting to the website that you think you are connecting to? And, haven't they provided a lot of that value over the last decade or so?
1. Over the wire encryption - where most of the criticisms in this thread are focused. Which I will also defer to tptacek's knowledge.
2. Site identification as an anti-phishing mechanism. For even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc.
This has even gotten weird as the browser makers have started to really de-emphasize domain certs vs ev certs (cheap vs expensive), to the point where in most cases now having a domain cert does not know green at all.
Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...
We could do a lot cleaner by doing a new protocol from scratch. But that is out of scope for the TLS WG. We'd need a new WG. And if we did, would anyone use it? Could we avoid repeating the mistakes of the past?
We're a lot better nowadays at building cryptographic protocols than when SSL was first developed, and SSL was never a particularly great protocol.
One could also hope - but probably not expect - that we have learned some painful lessons from the security impacts of SSL's complexity.
"Those of us providing x are really doing it well, and have to pass stringent checks, but those are too complex to go in to so please accept my hand-waving in lieu of actual evidence."
"We've been providing x for so long, obviously we're great at it and it's something that needs to keep being provided."
"We have different flavors of x, by the way: choose from vanilla, rainbow, or secure cookies and cream!"
"We go to conferences and sometimes talk to people. This makes us really important and stuff. Are you impressed yet?"
"Despite there nominally being 600 providers of x, in practice only 65 are 'in the club', and 7 of us have formed an international cartel!"
"Some of us somewhat recently twiddled some configuration bits, therefore we are clearly on top of this x-manufacturing technology stuff."
"It's true! Our reputation, as x providers in the lucrative cartel, is of critical importance. We've even paid someone to draft this drivel. Are you convinced yet?"
"It's not true what those people say - 'Once you take x there's no going back' - you can vomit, have your stomach pumped, or induce psychosis or hypnosis for the duration of the undesired effects. Of course, you can't get anything done for that period of time, which may occur at the worst possible moment: when booking a plane ticket, making a critical banking transaction, or communicating about the human rights abuses of your government. But that's OK, because there's clearly a way to turn off our pervasive control of your 'highly secure' communications... right?"
1. When I go to google.com, I want to be sure it's the same google.com everyone else connects to.
2. When I go to google.com many more times, I want to get to the same google.com as I was visiting before.
It's relatively easy to do #2 (SSH was doing it for years), but it's very hard task to do #1 correctly. The first problem is essentially a problem of global consensus. It can only be solved using Bitcoin blockchain, poorly simulated with Certificate Authorities, or left alone as SSH did (which is fine for hackers connecting to their own machines, but not fine for global name system).
If anyone is interested in improving SSL/TLS, the way forward is to use blockchain to associate names and public keys so that users could know for sure that they connect to the same name as anyone else without trusting any CAs. Of course, that'd require development not only of a new DNS-meets-SSL protocol, but also robust lightweight Bitcoin nodes and correct UX conventions. That's hard, time consuming, but the only way forward out of the current mess.
Relevant quote from Nick Szabo ("leaving small holes unplugged"): http://blog.oleganza.com/post/69174500046/leaving-small-hole...
Could you please elaborate?
What you want to prove to yourself is that if "google.com" is associated with public key "04cafebabe", that association is also visible to everyone else (provided other people follow the same protocol).
The distributed DNS+SSL protocol could look like this (simplified):
1) To register a name "google.com", check that it's not registered yet (see below). If not, create a special Bitcoin transaction ("registration tx") that encodes both the name and the public key of the SSL certificate used by that server.
2) To check who owns the name "google.com", find the earliest "registration tx" on the blockchain (other people could add more, but only the first one is considered valid). If the name is 100 blocks deep, trust the public key associated with it.
The protocol can (and should be) extended to allow transferring the name to new public keys, you may check how Namecoin does it.
What you get in result is that every single user can be sure that they see the same up-to-date public key identifying "google.com" without any trusted Certificate Authorities who have failed at this promise multiple times already.
As a nice side effect, name allocation and trade is also decentralized. If you own name "google.com" and users respect the protocol, no one can take this name from you or censor your sale of that name to someone else. Also, you are free to register your own name without asking for anyone's permission and paying fees.
It is not correct.
If I monitor DNS changes, and when new host names pop up. If I have the resources I can make a block-chain transaction automatically.
How will my transactions (provided I also create a new walletID) for each transaction be framed as fraudulent? Without community or authoritative over-site?
I was not saying that new system must necessarily map current DNS owners to new DNS 2.0 owners. These could exist in parallel. My point is to have secure "TLS with names" you must have something like what I describe, otherwise it's a waste of time. Social issues of fairness etc are secondary to the security of addressing names and servers. (Although, they could be real obstacles to adoption, I don't deny that.)
But using namecoin with DNS allows for duplicate and erroneous entries in one or the other. (DNS record != Namecoin record).
Currently most namecoin advocates pretend the former is the case. And it isn't, because have DNS currently. Namecoin is a complete re-invention of the system. Not a iterative improvement.
My issue is that in its current state one can make a namecoin entry that is correct as far as namecoin is concerned, and incorrect as far as DNSSEC or standard DNS is concerned. Thus rendering the system in a weird state.
* CAs were implemented to issue and verify digital certificates, not verify a connection. No part of TLS PKI is intended to verify that you are connecting to the same service everyone else is.
PKI (and CAs) are intended to assure identity, as well as providing a secure connection over a public network. When you buy a Papa Johns pizza, we know we're not all buying our pizza from the exact same Papa Johns store. But we do know it's a Papa Johns.
* SSH does do your second example, but TLS PKI does not.
As the above example points out, there is more than one Papa Johns store, just as there is more than one web server or service around the globe providing the same organization's data. SSH assumes there is only one Papa Johns store that serves all Papa Johns pizzas; one host is tied to one host key signature. PKI does not make this assumption.
* Blockchains are a stupid idea because they require access to a global public network. Depending on DNS to issue and verify digital certificates is like using SMTP/POP3 to 'simplify' the authentication of users when distributing web downloads.
TLS PKI does not require access to a network, nor receiving any updates from it, and its software is designed to be secure by default, unlike DNS, which in many operating systems cannot be secure by design (because they don't provide a verifying stub resolver, besides the inherent security problems in the protocol's design).
Honestly, most of the suggestions people have to replace PKI just reduces reliability without providing particularly improved security. The biggest problem with PKI is the uncertainty of ensuring the security of such a high number of CAs. That's easy enough to solve... have less CAs and make them more transparent.
yes. And in cases like DigiNotar and other less famous CA (and intermediate) compromises, we've seen how well that works.
Everything's not fine. We're only just beginning to tackle deep-seated problems in TLS and improve things, but we're probably stuck with some of the most regrettable decisions, like x.509 and the CAs.
We need Certificate Transparency most of all for intermediates. The roots may be small in number, and many of them a little outdated, but the number of still-unaccounted-for intermediates worries me. How many have no path and/or usage restriction? Who has them? Are they all regulated? Because they should be. Some are likely in the hands of attackers. We should be accounting for them all.
The CA model, as it stands today, is inferior to DNSSEC for DV. Yes, under DNSSEC, those above you in the chain of authority can fake DNS responses, but at least no-one else can. If the DNS root is removed from the control of a potential attacker (not that they'd ever get away with it, but still) then I view DANE pinning as strictly superior to DV certificates (although still not perfect, but nor is DNS). The CA model may still have use with EV.
The problem of a transparency equivalent for DNSSEC remains unsolved, and is under tension with it being considered a bad thing to be able to enumerate domains and hosts (although it is in practice very practical to do so anyway).
CT will hopefully become widespread, given Chrome will kill EV indicators without it.
The rest is in the same vein. Sounds good until you know the details. Then it doesnt sound all that safe or great anymore - more of a money making machine.
Turns out this site is made to defend these financial interests.