Giving every CA the power to issue certificates for the whole web is insane. And depending on unauthenticated DNS to bootstrap the connection equally bonkers. Shouldn't we just use dnssec to have each domain publish it's own root certificate and be done with CA's for good? It would solve both issues and we wouldn't have to pay a third party just to be able to encrypt HTTP for our own domains.
Having to pay a substantial fee for a certificate that assures you own a domain is insane.
This technology needs to be improved. Encrypted and authenticated HTTP connection should be a default not a premium feature that site owners need to pay for.
Why wild card certs are so much more expensive than single domain certs? From CA's infrastructure and verification point of view there shouldn't be any additional cost associated with issuing a wild card cert.
Doesn't dnssec still rely on a trust authority counter-signing? It may make it easier for browsers to be cautious but is hardly going to stop regimes like China.
A better solution would be to tie all DNS records to a key on a hardware device that can be in the actual hands of the website operator (in a safe). What users want to know is that the website they visited yesterday is the one they visited today. Physical security of a single key that is never allowed to change is a better way to guarantee that than key chains.
A quick read-through of the wikipedia page tells me it works as expected. The chain of trust follows the DNS hierarchy which is much saner than trusting all CAs for all domains. If you have yourdomain.com you're already trusting the .com TLD to not redirect your users somewhere else so you might as well also trust them for this.
What you describe is basically a self-signed certificate which is known to be a poor solution. It easily allows someone to consistently MITM the whole web (think great firewall of china) without the users knowing.
"Science itself organized the German National Research and Education Network, DFN, the communications network for science and research in Germany. It connects universities and research institutions with one another and has become an integral part of the European and worldwide community of research and education networks."
Everyone can be a certificate authorithy. The problem is that browsers only recognize a small number of authorities and display a scary message for others.
According to the article those 600+ authorities are all trusted by the browsers...
Quote:
"Break into any Certificate Authority (or compromise the web applications that feed into it). As we learned from the SSL Observatory project, there are 600+ Certificate Authorities that your browser will trust; the attacker only needs to find one of those 600 that she is capable of breaking into."
TACK (http://tack.io/), if widely implemented, would help a lot. As I understand it, if you visited a website regularly before it was compromised, then any future compromise along the lines described in the article (i.e., without stealing the server's private key) wouldn't affect you. I'm not sure if TACK is still alive or how on-board with it any browser developers are.
The certificate pinning in chrome is not an universal solution to the problem. It just a built-in list from google that hardcode what certificates are "correct" for a short list of domains. The RFC for expanding the concept to a more universal approach is to do as ssh, by remembering certain attributes from the first time a client connect to a server.
ChannelID seems to operate in the same fashion. The first connection from Client->Server is completely without any security, but further connections can be verified.
I hadn't heard of ChannelID before now, but that draft is clearly talking about client, not server authentication; it's a way for you to prove to HN that you're really 'codeka', not a way for HN to prove to you that it's really Hacker News (which is what SSL certs do).
> There are four classes of attackers against which we consider our security guarantees: passive network attackers, active network attackers, active network attackers with misissued certificates and attackers in possession of the legitimate server's private key.
Basically (and this is just my understanding), it should mean a MITM cannot decode the encrypted stream even if he has the legitimate server's private key.
That section is dealing purely with an attacker who wants to impersonate a ChannelID. It's correct that an attacker cannot fool the real server into believing that it is in possession of a ChannelID, even if the attacker has the server's private key (so long as the server is forward secure). However, that doesn't mean that the client isn't fooled.
Perhaps, but I imagine it will easily be a decade before >90% of deployments are on browser versions that support Cert Pinning and ChannelID... think of all those enterprise deployments, universities and banks.
The vulnerabilities mentioned seem to apply to large scale public websites. If a company serves a website for internal use then it unlikely to be a direct target. Could any of the vulnerabilities expose company data to large scale government data collection? It seems unlikely in the US but what about other authoritarian countries who have full control over their networks?
