Re: ACTION-240 :TLS errors...

Johnathan Nightingale wrote:

> That scenario has led us towards considering a harsher attitude towards 
> bad certs in general.  There is discussion going on now (not final, of 
> course) around making SS-certs and other broken-cert conditions into 
> error pages, without a 1-click override.  Users can add certs to a list 
> of overrides for their intranet, etc., but it's a complicated procedure 
> and outside of their immediate task flow.  If we do this, it will make 
> people sad.  But it may also help to clean up some of the ubiquity of 
> self-signed certs out there on the public web, and it's not clear to us 
> how to make the process nicer without making the attack process nicer as 
> well.

But SSC are not "bad certs," are they? Effectively they're trust anchors
and could in principle be handled the same as the SSH leap of faith
which seems generally acceptable in protocol security terms, if not in
terms of usability.

I'd argue strongly that even if the net effect is the same in many
cases that you really should try have a different code path handling SSC
and "bad certs."

To take an extreme example, I'd say its quite fine to toss a cert signed
using a unsupported sig alg and just give a connection error. Forcing
that same outcome for all SSCs does not seem right at all unless at the
same time you setup a free, automated, scaleable, privacy friendly
low-assurance CA to support all those who'd be disenfranchised by such
a change.

Stephen.

Received on Monday, 9 July 2007 22:15:19 UTC