Improving SSL certificate security

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

by yanw • 15 years ago

42 13 15 years ago

googleonlinesecurity.blogspot.com

mahmud2• 15 years ago

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.

agl2• 15 years ago

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.

mahmud2• 15 years ago

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

Thanks :-)

pasbesoin• 15 years ago

In... fall, a year ago, IIRC, they were periodically using a different certificate / apparently their own certificate authority for Gmail. (I'm not sure I recall the underlying root, but I think it was different from "the usual one".) It looked like it might be part of some testing or since-rescinded initiative.

Separately, for me Gmail continues to periodically include http references in the https-delivered web interface, causing the browser to display its corresponding "insecure" message/chrome. I wish they would just stop that: If nothing else, it's a bad lesson/conditioning for the average user.

zwp• 15 years ago

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

"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 :)

CWuestefeld3• 15 years ago

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?

agl2• 15 years ago

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.

CWuestefeld3• 15 years ago

Yes, of course. What I'm wondering about is if (and how) the proposed DNSSEC infrastructure would be superior in this regard.

tptacek• 15 years ago

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.

MichaelGG• 15 years ago

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• 15 years ago

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

y0ghur7_xxx• 15 years ago

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.

Improving SSL certificate security

Related Stories