Re: Proposal: Marking HTTP As Non-Secure

On 17/12/2014 07:48 am, tylerl@google.com wrote:
> First of all, some change along these lines is absolutely necessary is it
> closes a huge hole that has been successfully exploited since the Netscape
> days. That is, while browsers indicate positive security for TLS, they make
> no indication at all in the case no security, leaving ample room for
> website content to fill that void. Call this the "Green padlock favicon"
> problem if you like.
>
> Some notable points:
>
> Given these roughly 3 distinct scenarios with respect to connection status:
>
> A: The connection is successfully secured. (HTTPS)
> B: No security was attempted. (HTTP)
> C: Securing the connection has failed. (Certificate validation failure)
>
> A few people have said that B and C are roughly identical from a security
> perspective and could be represented as the same state -- in both cases no
> security is provided. I would disagree here. In the case of the failed
> certificate verification, the client has attempted to secure the connection
> and that attempt has failed. In the case of HTTP, the client made no
> indication of a preference for security. While scenario B represents the
> *absence* of security, scenario C represents the *failure* of security, and
> is therefore more troublesome.


Scenario C may be "more troublesome" but not more informative.  The 
problem is that the software agent is not able to derive any or enough 
useful information to inform *a claim of usefulness to the user*.  There 
are too many innocuous causes and too many false reasons floating 
around.  And every mistake tells the user that the browser is wrong, 
thus training the user for the day the phisher comes along ;)

Hence the occam's razor approach of declaring HTTP to be "insecure" aka 
the absence of security, and the failure to secure is "roughly 
identical" in terms of quality of information available.  Breach this 
and you're in danger of training your user to be phished, which is the 
perverse reverse of the intent.


> While we want to raise the awareness of
> scenario B, we shouldn't promote it to the severity of scenario C. Doing so
> conflates two very different cases and failure modes; while both represent
> the absence of verifiable transport security, the latter indicates that the
> user's expressed expectation of security has not been met, while the former
> simply reflects the absence of any expectation of security.


Well, again, trouble.  You're making a presumption that the user 
expressed an expectation of security.  In theory you might be able to 
divine that from HTTPS but if the user just copied a URL what does that 
tell you?  Nothing about expectations of that user, because she never 
looked at the URL.

Or, if the server simply redirects to HTTPS, what is the expectation 
here?  The website user "expected" some security but the web browsing 
user doesn't care.

Even if we know that a user selected HTTPS, we don't know if the user is 
concerned about case 1 (NSA passive eavesdropping) or case 3 (phishing) 
with somewhat different security profiles.  In short, even if we know 
that the user said "give me security" we do not know what the user meant 
by that statement.


....
> Finally, it's worth noting that reports from the field in response to the
> Chrome SHA-1 sunsetting initiative have shown that even the most minor of
> warnings has a measurable impact on site operators. I've received many
> reports from operators large and small indicating visible losses of revenue


Which brings up another definition of security:  reliability of website 
operator's revenue stream.  For geeks doing security coding this might 
be a strange definition of security, but it is what the user cares about.

It may be the case that some users' security might go down in the short 
term in order to provide a higher security over all to more users over 
time.  Unavoidable, because the former's security (easy web leads to 
easy revenue) comes at the latter's expense (easy web leads to higher 
risks of attack).


> due to the nearly-hidden warning Chrome currently displays for a SHA-1 cert
> with a long expiration. This suggests that the UX changes surrounding
> security needn't initially be intrusive to have a strong impact on site
> operations. An unobtrusive but centrally-located notice to the effect of
> "your connection has not been secured" is indisputably accurate,

<cough> is better than its absence :)


> conveys no
> bias or agenda, and yet can be expected to produce a sea-change of behavior
> for site operators.
>
> It's like bike locks: they're functional and highly visible, but also
> optional. Still, if one day someone started putting up signs saying "this
> bike has no lock", even though it's telling you nothing you couldn't
> already see, behavior would immediately change.


Good analogy.  Certainly, we have to start advertising the absence of 
bike locks.  Users don't notice but attackers surely do.



iang

Received on Monday, 22 December 2014 16:58:46 UTC