

Improving SSL certificate security - yanw
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html

======
CWuestefeld
_One could rightly point out that both of these efforts rely on DNS, which is
not secure. Luckily we’ve been working on that problem for even longer than
this one, and a reasonable answer is DNSSEC, which enables publishing DNS
records that are cryptographically protected against forgery and
modification._

This still wouldn't protect against the US government's recent misbehavior. If
they actually seize the DNS records, then they can put their own certs into
it, too.

I'm not familiar with the details of DNSSEC, so I don't know if it protects
against scenarios like in China, where their government controls the DNS. If
they can intercept the official DNS records and substitute their own, is there
anything preventing them from substituting their own sites, and giving certs
that match them?

~~~
agl
The current certificate infrastructure already sits on top of DNS. If an
attacker can control your DNS then they can get any CA to issue certificates
to them because they can accept emails at that domain.

~~~
tptacek
The current certificate infrastructure does _not_ intrinsically depend on DNS.
No scheme is resilient against bad actors at the top of the hierarchy; yes,
there are (bad) CAs who offer only DNS-equivalent security today. But that's
not an SSL/TLS problem; it's a "we should delete CA certs for those CAs"
problem.

~~~
CWuestefeld
Well, to the extent that a cert enables the browser to compare the site's name
to its IP address, it is dependent on DNS.

------
zwp
Wouldn't it be great if some (smart, enterprising, generous) person could
produce a browser extension to leverage these approaches for those that might
find typing "openssl s_client -connect..." into a UNIX prompt a little bit
much?

Another idea: Schneier writes:
[http://www.schneier.com/blog/archives/2011/03/comodo_group_i...](http://www.schneier.com/blog/archives/2011/03/comodo_group_is.html)

"The safest thing for us users to do would be to remove the Comodo root
certificate from our browsers so that none of their certificates work, but we
don't have the capability to do that."

You certainly can do it manually (as one of the comments explains) but a sweet
program that targets system keystores (Windows, Java, Mozilla, Chrome, Safari,
any more?) might be a nice little project.

List of configurable CA DNs to remove? Regexes? Whitelist? Zap that "unknown
origin" mozilla cert whilst you're there perhaps?

I don't have bandwidth, these thoughts are free to steal :)

------
MichaelGG
Do I understand correctly: With DNSSEC the bar will be raised because the
registrar of a specific domain will need to be compromised to change the DNS
entries? So some misc country's CA that ends up trusted for whatever reason
will not be able to sign records for another TLD?

~~~
EricButler
Yep this is correct. See the note about "exclusion" on
<http://www.imperialviolet.org/2010/08/16/dnssectls.html>

------
y0ghur7_xxx
This can't work. There are pages on the internet that google does not see and
should not see. And the proposed solution (centrally managed TXT records)
would not work for those pages. Also, it only moves the problem from the CAs
to google.

------
mahmud
Off topic: but I have been unable to use my Gmail accounts for the last two
days because Thunderbird warns:

    
    
      You're about to override how Thunderbird identifies this site.
      Legitimate banks, stores and other public sites will not ask you to do this
    
      ..
      Certificate belongs to a different site, which could be ID theft
    

etc, etc.

Has Google changed anything? what could trigger this? I can't find anything in
.. Google.

~~~
agl
Please email me (my username at chromium.org) with the output of `openssl
s_client -tls1 -showcerts -connect imap.googlemail.com:993` as well as any
proxy settings, maybe a packet trace etc.

~~~
mahmud
Sent, from the same email address as the one in my profile.

Thanks :-)

