Re: HTTP is just fine

What does security of HTTPS have to do with security of HTTP?

Question: Is HTTPS secure?

Answer: It depends on implementation (HTTPS enforcement, key/cert 
pinning, TLS version, cipher choice, etc.)

Question: Is HTTP secure?

Answer: No. End of story.


It's about connection security, not web site security.

If on a given day a plain HTTP connection doesn't suffer a 
privacy/security breach, then lucky you, but that doesn't mean that that 
connection is secure. And if a breach occurs, would you like to complain 
to every ISP of every WiFi hotspot you use while traveling abroad? Are 
you sure about the necessary procedures and lawfulness of the said 
breach? Do you expect every user to be sure about that in their home 
country? Or even to be aware of a breach?

Whether one is willing to accept such a breach is a different question 
and doesn't make the insecurity of HTTP a "lie".

HTTPS has its issues, but they are being worked on. (Introduction of 
more secure features, deprecation of less secure ones.) It will possibly 
never be completely secure for every user, but it will definitely be 
much more secure than plain HTTP.

And if one wants to warn a user about less secure HTTPS implementations, 
then it seems logical to also warn them about plain HTTP, which is 
entirely insecure. Since many users don't even know the difference 
between HTTP and HTTPS and just follow what their browser says.

The warnings will force web site owners to move to more secure HTTPS 
implementations, but that seems to be a step in the right direction, 
IMHO. Plain HTTP and less secure HTTPS implementations are in the same 
camp here. I.e., it's not "HTTP" vs "HTTPS", but rather "less secure 
HTTP(S)" vs "more secure HTTPS".

<A "let's encrypt" cry follows> :)))) I'm just a user, btw.

Joe




On 20/11/15 19:33, Ben Bucksch wrote:
> Boris Zbarsky wrote on 20.11.2015 14:57:
>> lying to people is not a great way to convince them to do something.
>
> Exactly.
>
> The statement "HTTP is insecure" is wrong and a lie. That's my problem.
>
> HTTP is insecure for *some* uses, but it's fine for others. For example:
> * Sending a password in a login form or HTTP Auth via HTTP or from a
> form in an HTTP page is insecure, in most circumstances, but not all -
> e.g. I chose to protect the connection to my servers via a direct
> OpenVPN connection and HTTP rather than HTTPS, because TLS is not secure
> enough for me.
> * Reading lolcats.com via HTTP is just fine. If your ISP inserts ads
> there, go complain to your ISP. No harm done either way.
> * Downloading executables via HTTP is highly insecure, if and only if
> nobody/nothing checks the checksum. If my downloader checks the checksum
> (and gathered it securely), then HTTP is totally secure. As tech lead
> for software used by millions of users, I repeatedly had the discussion
> with my product manager and follow developers whether just HTTPS is
> sufficient. They just thought "it's encrypted and the connection with
> the server is secure, so where's the problem, why do we need to write a
> checksum verifier?" Because a) servers can be hacked and b) the CA's
> disclaimer of liability says that any damage over 1 million US$ is no
> longer their problem. What's the damage when 5 million machines have
> been hacked and the information on them exploited? Most private photos
> been made public, business plans sold to competitors? All multipled by 5
> million? You're at billions of damages. The CA that sold the faulty
> intermediate will just shrug "Not our problem" or at best point to their
> "1 million USD per incident" insurance. Now, I've had that argument with
> my product manager several times that HTTPS is *not* secure enough. We
> need checksums. And with checksums, binary downloads via HTTP are
> secure. And the statement "HTTP is insecure" is wrong, just as the
> statement "HTTPS is secure" is wrong in this case. This is a case where
> HTTP + checksum is more secure than HTTPS.
> * I could go on endlessly. These are just some examples.
>
> So, generic statements as "HTTP is insecure" and "HTTPS is secure" are
> just plain wrong. It depends on the data you're trying to protect.
>
> If the browser says that every HTTP website is "insecure", then it's
> lying. That's what I oppose.
>
> I support efforts to make HTTPS easier to deploy. That solves the actual
> problem, without force.
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security