Re: [TLS] Eleven out of every ten SSL certs aren't valid

[Ivan Ristic <[e-mail]>]

On Tue, Jun 29, 2010 at 8:34 PM, Nicolas Williams
<[e-mail]> wrote:
> On Tue, Jun 29, 2010 at 07:29:45PM +0100, Ivan Ristic wrote:
>> On Tue, Jun 29, 2010 at 5:33 PM, Nicolas Williams
>> > The subject line is very funny, but, seriously, this doesn't bother me
>> > in the least.  Why?  Because anyone can put up a site with an invalid,
>> > self-signed, or might-as-well-be-self-signed-because-no-one-uses-its-
>> > root-CA cert.  Therefore the number of sites with such certs is utterly
>> > and completely _meaningless_ [m _e _a _n _i _n _g _l _e _s _s _].
>>
>> The problem with that view is that, while the users are experiencing
>> all those sites with invalid certificates they are getting used to the
>> idea that nothing bad comes from browser warnings. Then, one day, when
>> they're accessing their bank's web site from an insecure network, they
>> ignore the one warning they shouldn't and get owned by the MITM guy.
>
> You seem to be confused as to what I actually wrote.

No, not at all. I was responding to this sentence in particular:

"What matters is that the sites that ought to be using HTTPS with
valid certs are"


> There is no such "problem with [my] view" because you cannot stop people
> from deploying servers with bad certs.  It's a _fact of life_.

The fact that we cannot stop bad certs is not relevant. Such sites are
still reducing the effectiveness of SSL, even for the "sites that
ought to be using HTTPS". And that was my point.


> Now, what our client applications do about such servers _is_ a problem.
> If that was your point, well, we agree, and there's no need to put words
> in my mouth.  If you want to discuss how to improve the clients (e.g.,
> make it so there is no warning dialog, make it so you cannot connect to
> sites with bad certs period).

I would like to see that very much (and have proposed it in the past).
Unfortunately, browser vendors will never do that for the fear of
losing customers.


> Nico
> --
>

-- 
Ivan Ristic
ModSecurity Handbook [http://www.modsecurityhandbook.com]
SSL Labs [https://www.ssllabs.com/ssldb/]