Re: HTTP is just fine

I think I hear Ben saying "whether it's secure depends on your threat
model", and everyone else saying "my threat models always demand secrecy
and integrity".

I have some sympathy for Ben's point of view because "secure connection"
really is a sloppy term.  People are using it as a shorthand for
"connection with secrecy and integrity", and it would be more accurate to
describe HTTP as "lacking secrecy and integrity" than "insecure".  If I
were to show a message to the user, "Information you submit and receive can
be exposed or altered in transit" is more meaningful than "Insecure" anyway.


—Ping



On Fri, Nov 20, 2015 at 1:43 PM, <[email protected]> wrote:

> 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
>>
> _______________________________________________
> dev-security mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security
>
>
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security