11–20 of 22 posts
https://www.eff.org/files/colour_map_of_CAs.pdf
Even the very small university I went to (their organization is terrible by the way) is a certificate authority. How is that even possible?
Surprising to see so many public institutions from Germany are certificate authorities. The linked PDF shows a picture of those 600+ authorities. https://www.eff.org/files/colour_map_of_CAs.pdf Even the very small university I went to (their organization is terrible by the way) is a certificate authority. How is that even possible?
They all are "trusted" by the DNF which is the German Research Network.
"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."
I'm no cryptographer, but doesn't ChannelID (and, to a lesser extent, certificate pinning) mitigate a lot of these concerns? certificate pinning is already in Chrome, and I think ChannelID is coming soon (if not already). ChannelID: http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
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.
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.
I'm no cryptographer, but doesn't ChannelID (and, to a lesser extent, certificate pinning) mitigate a lot of these concerns? certificate pinning is already in Chrome, and I think ChannelID is coming soon (if not already). ChannelID: http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
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.
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.
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.
Earlier quoted context omitted.
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).
It protects against more than that, from the RFC: > 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 eve…
(Disclosure: I wrote that section of the draft.)
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.
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 se…
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.
I'm no cryptographer, but doesn't ChannelID (and, to a lesser extent, certificate pinning) mitigate a lot of these concerns? certificate pinning is already in Chrome, and I think ChannelID is coming soon (if not already). ChannelID: http://tools.ietf.org/html/draft-balfanz-tls-channelid-00
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.