full-disclosure - Re: Slightly OT: What SSL cert do you consider strongest?

lists.openwall.net		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 linux-hardening linux-cve-announce 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 17:59:49 +0200
From: Fabian Wenk <fabian@...ks.ch>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Slightly OT: What SSL cert do you consider
 strongest?

Hello David

On 22.10.2013 22:14, David Miller wrote:
> After the PRISM and other Snowden leaks, inquiring minds want
> to know: whose SSL certs are to be trusted?

This does not really matter. For best privacy you should create 
the secret key for your certificate on your own trusted system 
with a 2048 bit RSA key. Then give the CSR (Certificate Signing 
Request) to the CSP (Certificate Service Provider, aka CA) of 
your trust. They will sign your certificate with their secret 
key, so that the chain can be verified through the already stored 
public root certificate of this CA chain in the used application 
(e.g. your customers browser) or operating system.

Other security measures you can do is with setting appropriate 
SSL ciphers for your services. Use and prefer / force the PFS 
(Perfect Forward Secrecy) variants. But test with all possible 
client applications, as some of them still do not support the 
stronger ciphers and require some weaker once. Disable the MD5 
and if possible also the RC4 ciphers.

As others already have pointed out, any of the CAs, which are on 
default trusted from most Browsers, other Applications and 
operating systems, could issue (aka sign) a third party 
certificate with your FQDN hostname in it, which then could be 
used in a men-in-the-middle attack.

There are steps you could do to protect your customers in the 
future, as the use of such services from the client side is not 
fully supported yet. Sign your DNS zone with DNSSEC and let add 
the corresponding entries to your upstream TLD. But the clients 
(e.g. customers computers) need also to use and check DNSSEC when 
resolving (this also depends on the upstream name server, e.g. 
from your ISP). And then also add DANE [1] entries into your DNS 
zone for the hostnames which provide SSL or TLS services.

   [1] http://www.rfc-editor.org/rfc/rfc6698.txt

Clients (e.g. end users) could use the "Certificate Patrol" [2] 
add-on in Firefox, so they will be alerted if an already known 
certificate changes. It will be suspicious if the certificate for 
your site is suddenly issued from a little unknown CA (CSP) in a 
foreign country.

   [2] 
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol

> Is a self-signed cert likely to be stronger?

No not really. Self-signed is something you can do when you have 
a small known user group, where you can easily deploy the public 
certificate. But as others have pointed out, when this should be 
an open public service (e.g. like a web shop), then it is much 
easier for the visitors if you have your certificate signed form 
one of the well-known CSP.

bye
Fabian

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