

How secure is HTTPS today? How often is it attacked? (2011) - MikeCapone
https://www.eff.org/deeplinks/2011/10/how-secure-https-today

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

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

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

------
LinaLauneBaer
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](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?

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

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

------
codeka
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](http://tools.ietf.org/html/draft-balfanz-tls-channelid-00)

~~~
graue
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).

~~~
codeka
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_.

~~~
agl
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.)

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

~~~
graue
TACK ([http://tack.io/](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.

------
jacob019
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?

