Re: Proposal: Marking HTTP As Non-Secure

On Dec 18, 2014 2:55 PM, "Michael Martinez" <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>
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.
>
>
>
> --
> Michael Martinez
> http://www.michael-martinez.com/
>
> YOU CAN HELP OUR WOUNDED WARRIORS
> http://www.woundedwarriorproject.org/
>

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).

Of course, everything you said is true for insecure HTTP. Which is why this
proposal is about reflecting that truth to the user.