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 19:08:36 -0500
Message-ID: <54936C84.30801@xenite.org>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, public-webappsec@w3.org, security-dev@chromium.org, mozilla-dev-security@lists.mozilla.org, blink-dev@chromium.org
On 12/18/2014 6:57 PM, Daniel Kahn Gillmor wrote:
> On 12/18/2014 06:46 PM, Michael Martinez wrote:
>> No, what I am saying is that you can bypass the certificate for a MITM
>> attack via a new technique that was published earlier this year.
> Links, please.
I'm not going to sit here and do the research that you should already be 
doing for yourself, but here is one link that explains how some smart 
phone apps were compromised.  It's disturbing to see that people working 
on security protocols are not aware of articles that have appeared on 
security blogs, in news media, and on university Websites.

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.
>
>> If you
>> compromise someone else's router you can control it from your own nearby
>> router.  The compromised router with the valid certificate sends the
>> user through whatever gateway you specify.
> You seem to be saying now that the attacker does need a valid
> certificate; earlier you claimed no certificate was needed.
If you compromise a legitimate router you just hide behind the 
legitimate router and send people wherever you want.  What's one or two 
more hops even if you're only passing them through a gateway they know 
nothing about?  One recent study followed traffic on compromised routers 
that did nothing.  The researchers suggested that it may have been an 
early stage botnet either in testing or buildout.
> The fact that HTTPS is not 100% perfect does not mean that HTTP is
> somehow secure.
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.

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.

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.

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

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.

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

-- 
Michael Martinez
http://www.michael-martinez.com/

YOU CAN HELP OUR WOUNDED WARRIORS
http://www.woundedwarriorproject.org/
Received on Friday, 19 December 2014 00:09:06 UTC

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