How secure is HTTPS today? How often is it attacked? (2011) | Hacker News Reader

How secure is HTTPS today? How often is it attacked? (2011)

eff.org

127 pointsMikeCapone20 comments

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.

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?

I would like to reply to myself:

They all are "trusted" by the DNF which is the German Research Network.

https://www.dfn.de/en/

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

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

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.

It looks like ChannelID has been enabled since Chrome 24[1].

[1] https://code.google.com/p/chromium/issues/detail?id=136462#c...

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 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.

(Disclosure: I wrote that section of the draft.)

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.

So what alternatives are there to protecting HTTP? Is something like CurveCP feasible?

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.

Some concerns about CurveCP's performance. Development seems slow from what I've been able to glean from the site and list:

http://comments.gmane.org/gmane.network.curvecp/65

http://i.imgur.com/VMDdTQ3.png

The EFF's answer to this seems to be: HTTPS Everywhere + SSL Observatory + Sovereign Keys:

https://www.eff.org/encrypt-the-web

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?

Reply on news.ycombinator.com