On Tue, Oct 22, 2013 at 4:14 PM, David Miller <[email protected]> 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 industry). 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. Jeff _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
