Re: Proposal: Marking HTTP As Non-Secure

On 12/18/2014 7:02 PM, Matthew Dempsky wrote:
> On Thu, Dec 18, 2014 at 3:46 PM, Michael Martinez 
> <michael.martinez@xenite.org <mailto:michael.martinez@xenite.org>> 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.
>
>
> Citation needed.
>
> Earlier this year, you made these two G+ posts suggesting HTTPS is broken:
>
> https://plus.google.com/102255413942524311706/posts/bBMdzq8Z3vF
>
>     Google, the great champion of HTTPS/SSL, cannot prevent yet more
>     man-in-the-middle attacks against its users:
>     http://www.theregister.co.uk/2014/11/21/hackers_snaffling_smartphone_secrets_with_redirection_attack/
>
>
> https://plus.google.com/102255413942524311706/posts/LjKu1UfraXR
>
>     If your company is serious about using HTTPS it has to do it right
>     (not that it will matter, but don't throw your money away on bad
>     implementation).
>     http://www.darkreading.com/endpoint/the-week-when-attackers-started-winning-the-war-on-trust-/a/d-id/1317657
>
>
> The first link is about an ARP-poisoning man-in-the-middle attack that 
> has nothing to do with HTTPS/SSL, the article doesn't mention "HTTPS" 
> or "SSL", and in fact the attack would have been *prevented* by HTTPS/SSL.
The first article describes a Double Direct attack, which is an 
alternative to ARP poisoning.  HTTPS won't defend against the Double 
Direct method.

>
> The second link is about how mismanaging your web server can 
> compromise HTTPS's added security benefits (e.g., using 
> long-unsupported MD5 certificates or revealing your SSL secret key).  
> That's true, but misleading: the risks are no more severe than if you 
> mismanage an HTTP-only server.
The second article covers several issues (not simply "mismanaging your 
web server"):

1) Misused digital certificates
2) All keys and certificates have to be changed to fix Heartbleed issues
3) A malware Trojan for iOS was discovered compromising keys and 
certificates
4) The MD5 attack you mention

The Web runs on the lowest common denominator, not on the expectations 
of people who require that everything be perfectly executed and blame 
others for failure to execute.  The core of Google's proposal is that 
browsers should be modified to (at first) passively tell users that 
Websites are not using HTTPS.  The significance of HTTPS is lost on most 
people but they will certainly become alarmed if the klaxons are 
sounded.  Worse yet, most Websites don't collect user data or exchange 
private information, so why should they be forced to take on the burden 
of adding security that won't even be used?

>
>
> You seem to be arguing that people shouldn't be encouraged to lock 
> their doors when leaving because sometimes they forget to lock their 
> windows.  But actually we need to encourage people to do *both*.

No, we need to encourage the people building the tools we use to browse 
the Web to think about the implications of their assumptions.  You're 
going to ostracize innocent Websites for doing nothing to harm users' 
privacy and security because Google said JUMP! and you jumped.


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

YOU CAN HELP OUR WOUNDED WARRIORS
http://www.woundedwarriorproject.org/