Re: ACTION-240 :TLS errors...

Serge sez: 

> compromised or outright fraudulent.  This becomes a value judgment: if 
> we make an effective indicator to warn about sites with expired 
> certificates, the ones that are genuinely fraudulent will shell out the 
> money for a current certificate.  The net result will be that visitors 
> to websites where the webmaster is lazy will encounter this warning when 

> there's probabilistically just as much danger as visiting a site with a 
> valid SSL certificate.

That's why I like the notion of a three tier primary SCI - a tier for ones 
that look really good (pki, sll, browser history, petname), a tier for 
ones that look bad, and a tier for ones where there just isn't enough data 
to say either way. 

Johnathan sez:

> What would your recommendation be for SS certs?  We toyed with the 
> idea of saying that an SS cert connection should be quietly 
> encrypted, but present no security indicators, since we have no 
> reason to trust it.  The problem is that this enables the MitM 
> scenario nicely.  A diligent user is careful never to visit her bank 
> except via her trusted https bookmark, or by typing in the URL 
> manually.  If someone tried to DNS spoof with a straight http 
> connection, the attempt would fail, since the https connection would 
> fall on the floor.  But if SS certs are quietly allowed through, the 
> attacker can spin a SS-cert for bankofamerica.com and the connection 
> would succeed (albeit without the usual context indicators).  This is 
> the kind of thing that can't happen with a cert issued by a trusted 
> CA, even a $20 one.

That's why some amount of user familiarity should be incorporated (or some 
authority; petname or SBM authority; both are good). 


Serge sez:

> But this is all moot anyway.  If a user is intent on submitting 
> information to a website, he or she will rarely look for the presence of 

> an SSL indicator.  Even when they do notice them, most users will submit 

> information anyway.  Hypothetically, if we can create effective warnings 

> for all these scenarios, chances are that fraudulent sites would simply 
> not use SSL.


It's not all moot. It will matter in our recommendations that constrain 
user input actions based on trust (PII and SBM in its full generality). 
And I continue to believe recommendations around primary SCIs are 
important and useful, since security information will be displayed 
(although it would be interesting if a wg member wanted to promote a 
proposal that said "all security information displays in read only tasks 
should be banned").