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

Re: Proposal: Marking HTTP As Non-Secure

From: Michael Martinez <michael.martinez@xenite.org>
Date: Thu, 18 Dec 2014 18:39:08 -0500
Message-ID: <5493659C.4030306@xenite.org>
To: public-webappsec@w3.org, mozilla-dev-security@lists.mozilla.org, security-dev@chromium.org, blink-dev@chromium.org, public-webappsec@w3.org
On 12/18/2014 6:04 PM, Ryan Sleevi wrote:
> On Dec 18, 2014 2:55 PM, "Michael Martinez" 
> <michael.martinez@xenite.org <mailto:michael.martinez@xenite.org>> wrote:
> >
> > On 12/18/2014 5:29 PM, Chris Palmer wrote:
> >>
> >> On Thu, Dec 18, 2014 at 2:22 PM, Jeffrey Walton <noloader@gmail.com 
> <mailto:noloader@gmail.com>> wrote:
> >>
> >>>>   A) i don't think we should remove "This website does not supply
> >>>> identity information" -- but maybe replace it with "The identity 
> of this
> >>>> site is unconfirmed" or "The true identity of this site is unknown"
> >>>
> >>> None of them are correct when an interception proxy is involved. All
> >>> of them lead to a false sense of security.
> >>>
> >>> Given the degree to which standard bodies accommodate (promote?)
> >>> interception, UA's should probably steer clear of making any
> >>> statements like that if accuracy is a goal.
> >>
> >> Are you talking about if an intercepting proxy is intercepting HTTP
> >> traffic, or HTTPS traffic?
> >>
> >> A MITM needs a certificate issued for the proxied hostname, that is
> >> signed by an issuer the client trusts. Some attackers can achieve
> >> that, but it's not trivial.
> >
> >
> > No it doesn't need a certificate.  A MITM can be executed through a 
> compromised or rogue router.  It's simple enough to set up a public 
> network in  well-known wifi hotspots and attract unwitting users. Then 
> the HTTPS doesn't protect anyone's transmission from anything as the 
> router forms the other end of the secure connection and initiates its 
> own secure connection with the user's intended destination (either the 
> site they are trying to get to or whatever site the bad guys want them 
> to visit).
> >
> > Google, Apple, and other large tech companies learned the hard way 
> this year that their use of HTTPS failed to protect users from MITM 
> attacks.
> >
> I'm sorry, this isn't how HTTPS works and isn't accurate, unless you 
> have explicitly installed the routers cert as a CA cert. If you have, 
> then you're not really an unwitting user (and it is quite hard to do 
> this).

You're assuming people don't connect to open wifi hotspots where rogue 
routers can be set up by anyone.  If thieves are willing to build fake 
ATM machines and distribute them to shopping centers across a large 
geographical area then they will certainly go to the same lengths to 
distribute rogue routers.  Furthermore, at least two research teams have 
shown earlier this year that wireless routers can be compromised with 
virus-like software; when these vulnerabilities are exploited it won't 
matter if the router has a valid certificate.

On top of that University of Birmingham researchers also found that 
inappropriately built apps for iOS and Android can leave users' security 
credentials vulnerable to sniffing.

> Of course, everything you said is true for insecure HTTP. Which is why 
> this proposal is about reflecting that truth to the user.
You people are putting your faith in a defense that has already been 
compromised in many ways.  The distributed nature of the network of 
access points virtually assures that MITM attacks will continue to 
bypass HTTPS security.  The manner of warnings you place on Websites 
with apparently invalid certificates is rendered moot.

Michael Martinez

Received on Thursday, 18 December 2014 23:39:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:44 UTC