W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2014

Re: Proposal: Marking HTTP As Non-Secure

From: ianG <iang@iang.org>
Date: Mon, 22 Dec 2014 14:12:16 +0000
Message-ID: <549826C0.7010803@iang.org>
To: Donald Stufft <donald.stufft@gmail.com>, michael.martinez@xenite.org
CC: blink-dev@chromium.org, public-webappsec@w3.org, mozilla-dev-security@lists.mozilla.org, security-dev@chromium.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
On 19/12/2014 00:14 am, Donald Stufft wrote:
>
>> On Dec 18, 2014, at 7:08 PM, Michael Martinez <michael.martinez@xenite.org> wrote:
....
>> A Study of SSL Proxy Attacks on Android and iOS Mobile Applications
>> http://harvey.binghamton.edu/~ychen/CCNC2014_SSL_Attacks.pdf
>>
>> This is only one example.
>
> A skim of this shows that this is about mobile apps not correctly verifying TLS and has nothing to do with whether TLS as a protocol is broken. Probably you should learn how TLS actually works and read the papers you are linking before making extraordinary claims.


Donald, you guys are talking past each other.  It's pretty darn obvious 
that MM is talking about secure browsing.  You are talking about TLS.

MM is approximately right in what he says -- to a user, the "claims" 
made by TLS are vague and uncertain, not reliable enough.  It matters 
not that you might understand how TLS works, or he understands, or he 
precisely pinpoints the breach.  What matters is whether that 
information reaches and leaves the user in a form which is sufficiently 
reliable and secure.

MM believes approximately that it doesn't, and that approximate belief 
no matter how nuanced is actually a better representation of the user's 
beliefs than the PKI industry talk that assumes that if TLS is working 
then browsing is secure.  Studying more TLS won't change that because 
it's already missed the mark;  and continuing to pound the desk about 
"TLS securing the connection" is irrelevant because that is not secure 
browsing, and users can't tell the difference.


....
>> HTTP doesn't need to be secure.  Explain to me why I should have to have connect to an HTTPS server just to read the news or a blog?  If I am not passing any information to the Website, why does it have to be hosted on HTTPS?  That is not trivial for the average Webmaster.


Michael:  The problem can be stated simply.  Secure browsing doesn't 
work well enough if there is both HTTPS and HTTP.  When you are doing 
any form of secure browsing using standard browsers, there is always a 
way to simulate a "secure connection" with HTTP.

The only way to get rid of this is to move all of HTTP to HTTPS.

Makes sense?  It isn't that we care about securing your blog reading, 
it's because in order to secure your online banking, we need to make the 
overall security framework simpler so that more "simulations" can be 
stopped.

Google's proposal is a half way step:  start by making HTTP clearer in 
the context.


>> I'm not just concerned about HTTPS attacks.  I'm also concerned about wasted effort being spent on unnecessary security because of Google's fear-mongering.  I get why they are doing this.  They were hurt in the public image by the Edward Snowden scandal.  But they sure don't mind telling everyone they have no reasonable expectation of privacy when their services are involved.


Yeah, tricky.  It is of course the case that google's privacy 
pronouncements and breaches in other places are unable to be separated 
in the user mind for the next place.

However, public relations disasters are probably out of scope here ;)

>> BTW -- as you do your due diligence in these matters, look also for information on how YouTube videos can be used to compromise users' computers.  Gosh, that's an HTTPS Website, isn't it?  I feel safer already.
>>
>> Complexity that serves no useful purpose represents no improvement on the status quo.  Google and those who stand with it on these "privacy" issues need to make a much better case for coercing millions of Websites into using HTTPS.


You are approximately right in what you say.  The devil in the details 
is however rather nasty.  The problem is that in order to get the 
browsing onto a secure foundation, we have to a lot of small baby steps.

One small step is that the browsers should start giving more accurate 
"absence of TLS" information.

(As some other posters have pointed out, what browsers do say now is 
often as wrong and often deceptive.  But small baby steps....)


>> Browser developers do not need to participate in this public shaming game.


No, they don't and won't.  Someone else will do that.  Unfortunately it 
is necessary to shift some laggards, uncomfortable as it is.

It may be that name and shame is really bad.  It is important to realise 
however that google and the other browsers won't be doing that and 
aren't responsible for the angst here.

And, not putting out proper information is the wrong way to deal with 
the presence of name & shame.


>> I will leave off on this discussion at this point as it is clear to me I am better informed about what is happening than some, and I really am not going to be drawn into to sharing link after link in order to play a stalling game.
>>
>> Some of you guys have already made up your minds on this without doing proper research.  But you clearly haven't stopped to think about what a burden you will create for millions of Website owners who have no idea of how to support this insane initiative.  And that will just make them more dependent on self-serving solution providers like Google.

The problem is that developers tend to conflate the security statement 
of TLS with the security of web browsing.  That's a known flaw, but 
wasn't really recognised by browser vendors until the last 5 years or so 
as attacks made it clear something was broken.  The old habits die hard.

>> Don't do this.  Please do NOT screw up the web with this nonsense.


Ask yourself this:  do you ever want secure browsing to be secure?


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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC