Message-ID: <141e9146168.2795.8638d110b878e192e265aab66f50a68b@daloo.de>
Date: Thu, 24 Oct 2013 08:08:53 +0200
From: Alex <fd@...oo.de>
To: Fabian Wenk <fabian@...ks.ch>, <full-disclosure@...ts.grok.org.uk>
Subject: Re: Slightly OT: What SSL cert do you consider
	strongest?

Maybe adding the key or at least hash of it to DNS would help against mitm 
attacks. Has anyone thought of it before? Google doesn't give me useful 
hits. The same system is used in SSH. Even governments would have problems 
if the NS are for different TLD ...


Am 23. Oktober 2013 17:59:49 schrieb Fabian Wenk <fabian@...ks.ch>:
> 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/


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

Powered by blists - more mailing lists