Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Re: Slightly OT: What SSL cert do you consider strongest?
From: Jeffrey Walton <noloader () gmail com>
Date: Wed, 23 Oct 2013 05:37:40 -0400

On Tue, Oct 22, 2013 at 4:14 PM, David Miller <dmiller () metheus org> wrote:
After the PRISM and other Snowden leaks, inquiring minds want to know: whose SSL certs are to be trusted?
There is no short answer because the protocols, models and clients are broken.

Consider Browsers and HTTP/HTTPS: plain HTTP is good (no visual queues
to a user); while opportunistic HTTPS is bad (self signed certificates
invoke the red danger bar). But "trusted" certificate issuers get the
green bar irregardless of anything, even though they have varying
degrees of "quality" (for some definition of what it means). For
example, Trustwave, gets the green HTTPS bar even though its known
they issue MitM certificates to attack users.

But what happens if the adversary circumvents the Mail Server
certificate all together? For example, its easier for a government to
attack a node within its jurisdiction, and the SSL/TLS certificate on
the server just does not matter. So its easier to go to an email or
web provider and say "give me all the information". This happened to
Lavabit, and they closed their doors rather than comply. Silent Circle
dropped their email service due to the concerns. Sometimes, its best
to avoid the protocols all together.

Is a self-signed cert likely to be stronger?
Peter Gutmann goes into this in great detail. Read Chapters 1 and 6
from his Engineering Security book
(http://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf). He's got a
whitty sense of humor, so its not boring reading (its actually quite
hilarious because he has documented so many failures from the PKI

Self signed certificates are OK, but you need a different model to use
them. The new model would employ security diversification techniques.
For example, if there is an 'a priori' or existing relationship (think
enterprise app), then there is no reason to trust any third parties
since the app knows what to expect. In this case, the enterprise app
could pin the server's public key.

If there's no pre-existing relationship, then you need to employ a
Perspectives like system (in addition to other diversification
techniques). This system is basically Trust On First Use (TOFU), and
its used by SSH when StrictHostKeyChecking is enabled.


Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]