lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Oct 2013 05:37:40 -0400
From: Jeffrey Walton <>
To: David Miller <>
Cc: Full Disclosure <>
Subject: Re: Slightly OT: What SSL cert do you consider

On Tue, Oct 22, 2013 at 4:14 PM, David Miller <> 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
( 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.
Hosted and sponsored by Secunia -

Powered by blists - more mailing lists