HTTP is just fine (was: Marking HTTP As Non-Secure)

classic Classic list List threaded Threaded
54 messages Options
123
Reply | Threaded
Open this post in threaded view
|

HTTP is just fine (was: Marking HTTP As Non-Secure)

Ben Bucksch
Chris Palmer wrote on 05.11.2015 21:05:
> We do still want to try to mark non-secure origins as such soon (early
> next year), but 1 thing we have found is that, although the big sites
> are HTTPS and people spend tons of time on them, there is a huge long
> tail of non-secure sites. Over the Summer and Autumn we measured HTTPS
> adoption, and it hasn't gone up much — so we've been spending effort
> trying to make it easier for site operators to migrate.

No reason to throw out the baby with the bath.

Adding TLS to a site is still major work. Added with the fact that I
can't even get IPv4 addresses for each web *host* (much less each
domain) anymore, it gets far more complicated. "Let's encrypt" is a step
in the right direction, but there are still plenty of problems left that
make it difficult to set up.

Added with the fact that I consider TLS to be not strong security, given
the hundreds of CAs being "trusted", but not being trustworthy. So, I
don't consider it worth the effort.

Last but not least, when you're asking for everything to be encrypted,
you're missing the point of many websites. Not all of them have a login.
Many sites are just simple plain old web pages that give information,
including product information and personal sites, and there's no reason
to encrypt them.

Please note that I'm a very strong privacy advocate. But calling a
normal HTTP "insecure" is just plain wrong. Sending passwords over HTTP
is insecure (typically, not always). Running old browsers and email
programs is insecure. Reading my blog unencrypted is not insecure.

Starting to flag the most common communication protocol in the world
"insecure", while most enterprises are using age-old browser and getting
hacked, is simply barking at the wrong tree.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine (was: Marking HTTP As Non-Secure)

Hanno Böck-4
It's amazing how the same wrong arguments get repeated again and
again...

On Thu, 19 Nov 2015 17:00:31 +0100
Ben Bucksch <[hidden email]> wrote:

> Adding TLS to a site is still major work. Added with the fact that I
> can't even get IPv4 addresses for each web *host* (much less each
> domain) anymore, it gets far more complicated.

You don't need an IP for every Domain. That was true 15 years ago. It
is not any more. The solution is called SNI and it is in every major
browser since many years.


> Added with the fact that I consider TLS to be not strong security,
> given the hundreds of CAs being "trusted", but not being trustworthy.
> So, I don't consider it worth the effort.

Are you aware of the efforts to mitigate these problems, namely CT and
HPKP?

> Last but not least, when you're asking for everything to be
> encrypted, you're missing the point of many websites. Not all of them
> have a login. Many sites are just simple plain old web pages that
> give information, including product information and personal sites,
> and there's no reason to encrypt them.

You're missing the point of HTTPS. It's not just about "encryption".
HTTPS guarantees privacy *AND* integrity. You're arguing as if the
second one wasn't an issue. It is.

If you deliver your "information only" webpage over HTTP you have no
guarantee that the data you send is the data the user gets. This is a
very real issue with intermediates injecting all kinds of things into
content (e.g. adding ads or replacing ads or injecting some kind of
javascript doing whatever).


--
Hanno Böck
http://hboeck.de/

mail/jabber: [hidden email]
GPG: BBB51E42

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Kurt Roeckx
In reply to this post by Ben Bucksch
On 2015-11-19 17:40, Hanno Böck wrote:
> If you deliver your "information only" webpage over HTTP you have no
> guarantee that the data you send is the data the user gets. This is a
> very real issue with intermediates injecting all kinds of things into
> content (e.g. adding ads or replacing ads or injecting some kind of
> javascript doing whatever).

And this is a real issue.  When traveling I've seen javascript being
injected in site that I know don't have javascript or for a domain that
usually doesn't show up.  Https sites were never affected and just worked.


Kurt

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine (was: Marking HTTP As Non-Secure)

Richard Barnes
In reply to this post by Hanno Böck-4
On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <[hidden email]> wrote:

> It's amazing how the same wrong arguments get repeated again and
> again...
>

+1000

All of these points have been raised and rebutted several times.  My
favorite reference is:

https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay



> On Thu, 19 Nov 2015 17:00:31 +0100
> Ben Bucksch <[hidden email]> wrote:
>
> > Adding TLS to a site is still major work. Added with the fact that I
> > can't even get IPv4 addresses for each web *host* (much less each
> > domain) anymore, it gets far more complicated.
>
> You don't need an IP for every Domain. That was true 15 years ago. It
> is not any more. The solution is called SNI and it is in every major
> browser since many years.
>

To be fair, SNI is still not universal.  A single-digit percentage of
clients are still on IE/XP and Android 2.2.  However, at this point, I
think creating web sites that those clients can't access is more of a
feature than a bug.


> Added with the fact that I consider TLS to be not strong security,
> > given the hundreds of CAs being "trusted", but not being trustworthy.
> > So, I don't consider it worth the effort.
>
> Are you aware of the efforts to mitigate these problems, namely CT and
> HPKP?
>
> > Last but not least, when you're asking for everything to be
> > encrypted, you're missing the point of many websites. Not all of them
> > have a login. Many sites are just simple plain old web pages that
> > give information, including product information and personal sites,
> > and there's no reason to encrypt them.
>
> You're missing the point of HTTPS. It's not just about "encryption".
> HTTPS guarantees privacy *AND* integrity. You're arguing as if the
> second one wasn't an issue. It is.
>
> If you deliver your "information only" webpage over HTTP you have no
> guarantee that the data you send is the data the user gets. This is a
> very real issue with intermediates injecting all kinds of things into
> content (e.g. adding ads or replacing ads or injecting some kind of
> javascript doing whatever).
>

Indeed, as Kurt pointed out, if you want your information-only site to
actually provide the real information to your users, you need HTTPS.

If you don't find the injection of ads, control panels, and copyright
warnings compelling, imagine how much grief an ISP could cause you simply
by modifying a few numbers on your site.  "But your web site says it costs
$X!"




>
>
> --
> Hanno Böck
> http://hboeck.de/
>
> mail/jabber: [hidden email]
> GPG: BBB51E42
>
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
>
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Hubert Kario
In reply to this post by Kurt Roeckx
On Friday 20 November 2015 10:05:07 Kurt Roeckx wrote:

> On 2015-11-19 17:40, Hanno Böck wrote:
> > If you deliver your "information only" webpage over HTTP you have no
> > guarantee that the data you send is the data the user gets. This is
> > a
> > very real issue with intermediates injecting all kinds of things
> > into
> > content (e.g. adding ads or replacing ads or injecting some kind of
> > javascript doing whatever).
>
> And this is a real issue.  When traveling I've seen javascript being
> injected in site that I know don't have javascript or for a domain
> that usually doesn't show up.  Https sites were never affected and
> just worked.
not to mention that because middle boxes just love to put their grubby
fingers on HTTP traffic, it actually makes it _slower_ than HTTPS for
the average user

see for yourself:
http://www.httpvshttps.com/

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Boris Zbarsky
In reply to this post by Kurt Roeckx
On 11/20/15 6:49 AM, Hubert Kario wrote:
> see for yourself:
> http://www.httpvshttps.com/

Uh...  That test compares HTTP/1.1 (unencrypted) against HTTP/2.0 over SSL.

What it really shows is that a properly configured HTTP/2.0 server can
be much faster for serving lots of small requests than an HTTP/1.1
server, which is not surprising: that was one of the main design goals
of HTTP/2.0.  But that tells you nothing about "https vs http" per se,
unless you're actually running an http/2.0 server.  And none of this has
anything to do with your claim about "middle boxes".

An apples to apples comparison here would be plain HTTP/1.1 against
HTTP/1.1 over SSL, and I would be quite interested in data that shows a
performance win for SSL there.  That would support your "middle box" claim.

As it is, I'm not sure whether you're being misled or disingenuous.

-Boris

P.S.  I'm all in favor of transitioning everything to SSL, by the way.
I just think lying to people is not a great way to convince them to do
something.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Kurt Roeckx
In reply to this post by Kurt Roeckx
On 2015-11-20 12:49, Hubert Kario wrote:
> see for yourself:
> http://www.httpvshttps.com/

This seems to be the results I get:
http using privoxy: around 4 seconds
http not using privoxy: around 10 seconds
https not using privoxy: around 15 seconds
https using privoxy: around 16 seconds

(I think privoxy supports more parallel connections to the same host.)

The results in firefox aren't always very reproducible, but I think the
above results are correct enough.

Trying it in IE11 on windows 7, it complains that SPDY isn't supported
and the results I get are:
http: 10
https: 11


Kurt

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Ben Bucksch
Hanno Böck wrote on 19.11.2015 17:40:
> On Thu, 19 Nov 2015 17:00:31 +0100
> Ben Bucksch <[hidden email]> wrote:
>
>> Adding TLS to a site is still major work. Added with the fact that I
>> can't even get IPv4 addresses for each web *host* (much less each
>> domain) anymore, it gets far more complicated.
> You don't need an IP for every Domain. That was true 15 years ago. It
> is not any more. The solution is called SNI and it is in every major
> browser since many years.

I *explicitly* did *not* speak of domains, but *hosts*. I can't even get
an IPv4 for my *server* anymore.

> Are you aware of the efforts to mitigate these problems, namely CT and
> HPKP?

And which certs do people pin? Those of the CAs. For 3 months. That's
the recommendations I read.

A "mitigation" is not a solution.

And that destroys the "integrity" element, too.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Kurt Roeckx
Aside from speed:

HTTPS renders privoxy almost useless in terms of its privacy protection
features. It can't remove cookies anymore, it can't remove images, it
can't check the page. All that's left to do is a complete all-on or
all-off (per host).

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Richard Barnes
That seems to miss the point that using HTTP also lets folks like
Verizon *add* cookies.  As they have in the past.

Sent from my iPhone.  Please excuse brevity.

> On Nov 20, 2015, at 12:09, Ben Bucksch <[hidden email]> wrote:
>
> Aside from speed:
>
> HTTPS renders privoxy almost useless in terms of its privacy protection features. It can't remove cookies anymore, it can't remove images, it can't check the page. All that's left to do is a complete all-on or all-off (per host).
>
> Ben
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
That's something easy to defend against by law. This is an interference
in (and alteration of) the communication between 2 parties.

In Germany, that might get you in jail for 2 years (and you can't hide
behind the company).
In the US, when MSIE injected links into webpages, NYTimes sued and won.

Ben

Richard Barnes wrote on 20.11.2015 18:13:

> That seems to miss the point that using HTTP also lets folks like
> Verizon *add* cookies.  As they have in the past.
>
> Sent from my iPhone.  Please excuse brevity.
>
>> On Nov 20, 2015, at 12:09, Ben Bucksch <[hidden email]> wrote:
>>
>> Aside from speed:
>>
>> HTTPS renders privoxy almost useless in terms of its privacy protection features. It can't remove cookies anymore, it can't remove images, it can't check the page. All that's left to do is a complete all-on or all-off (per host).
>>
>> Ben
>> _______________________________________________
>> dev-security mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-security
>

_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Richard Barnes
You have to detect it first.  In the Verizon/UIDH case, the ISP and
the web page were in on it, and there was no way for the user agent to
see it.

Plus, do you really want to make the average user's privacy dependent
on lawyers when there's a straightforward technical solution?  Trading
a little bit of webops time for a lot of lawyer time seems like a
great bargain.

Sent from my iPhone.  Please excuse brevity.

> On Nov 20, 2015, at 12:18, Ben Bucksch <[hidden email]> wrote:
>
> That's something easy to defend against by law. This is an interference in (and alteration of) the communication between 2 parties.
>
> In Germany, that might get you in jail for 2 years (and you can't hide behind the company).
> In the US, when MSIE injected links into webpages, NYTimes sued and won.
>
> Ben
>
> Richard Barnes wrote on 20.11.2015 18:13:
>> That seems to miss the point that using HTTP also lets folks like
>> Verizon *add* cookies.  As they have in the past.
>>
>> Sent from my iPhone.  Please excuse brevity.
>>
>>> On Nov 20, 2015, at 12:09, Ben Bucksch <[hidden email]> wrote:
>>>
>>> Aside from speed:
>>>
>>> HTTPS renders privoxy almost useless in terms of its privacy protection features. It can't remove cookies anymore, it can't remove images, it can't check the page. All that's left to do is a complete all-on or all-off (per host).
>>>
>>> Ben
>>> _______________________________________________
>>> dev-security mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-security
>
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Hanno Böck-4
Richard Barnes wrote on 20.11.2015 12:35:
> https://konklone.com/post/were-deprecating-http-and-its-going-to-be-okay 

He's basically stating:
'OK, so HTTPS takes power away from the little man and centralizes power.
BUT that's OK, because it's always been like that and it's inevitable.
The web isn't what it used to anymore anyways, so who cares. Let's just
accept that we lost control.'

Not a strong argument.


Remember that TLS was designed at a time when all crypto from Netscape
had to be approved - in detail, design and code - by the US government.
TLS is unnecessarily and *deliberately* centralized and puts trust in
the center over mutual trust between parties. Because that's what it was
designed to do. And now it's promoted as solution against government
surveillance. I can see them smile. What an irony.

TLS was designed to protect credit card numbers. Nothing more. It was
*explicitly* stated that it cannot protect anything that cannot be
valued with less than 1 million $ (if you have doubts, check you CA's
contract). It was never designed to protect privacy or other human
rights, just your Amazon book order.

TLS is simply the wrong solution.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Ben Bucksch
Kurt Roeckx wrote on 20.11.2015 10:05:
> I've seen javascript being injected

Me too. A lot. And 99% are *not* on the network level.

Sites carry a ton of JavaScript today. Multiple trackers, multiple ad
servers, third party JS libraries or web services loaded from third
party servers. Most of them are less than trusted. Ad servers have been
hacked or simply paid for malware repeatedly, causing the biggest, most
trusted websites to deliver malware. Repeatedly.

And then there's extensions that inject stuff into every website. They
are often sideloaded without the user's actual awareness. Not only
malware does injection, but at least one huge online retailer (which you
know) does that as well.

If the ISP is really bent on hacking their users, they'll find other
ways. Worst case, they make you install a "dial-in" program on your PC.
If your own ISP has bad intent against you, TLS won't rescue you. There
are too many attack angles.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Julien Vehent-2
On Fri 20.Nov'15 at 18:30:51 +0100, Ben Bucksch wrote:
> Kurt Roeckx wrote on 20.11.2015 10:05:
> >I've seen javascript being injected
>
> Me too. A lot. And 99% are *not* on the network level.

Seems to me that if HTTPS protect you from 1% of unwanted javascript
injections, it is well worth the deployment hassle.

Deployment which, by the way, is getting so much easier nowadays that
it's been a long time since I've heard any sysadmin complain about it.

- Julien
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Ben Bucksch

* If you want to run HTTPS on your website, go for it.
* If you want to encourage HTTPS by making it easier to set up, go for it.
* If you want to *force* *me* to use HTTPS, then you're overstepping
your power.

My problems with HTTPS:
* It uses TLS, which is (deliberately) misdesigned from the start and
puts trust in the wrong place, making it inherently insecure. It was
*explicitly* designed to only protect credit cards during your Amazon
order purchase. (If you have doubts, check your CA's contracts.) That
means you can't even use TLS to protect passwords or token that would -
if stolen - make damages superior to 1 million US$, much less things
without price tag, like privacy, human rights or human life. My problem
is that TLS is offered as solution against government surveillance.
* It's very hard to set up. It's made even more difficult now that I
can't even get an IPv4 address for my each of my servers (not just the
web domain) anymore.
* The primary value of the Internet is that the barrier of entry is very
low. Nobody was there to forbid me my idea. That's what allowed this
strong and fast innovation.
* The DNS is already a big problem, finding a memorable domain and name
for my company has become one of the primary obstacles. And you want to
add another *mandatory* central point, the CAs, which have again and
again violated the security guarantees, e.g. by issuing intermediate "*"
certificates to private companies, allowing them to intercept all TLS
traffic.

HTTP is *the* most common communication protocol. It's used for so many
things that it's hard to list them all, including internal services
within the local network. And you want to kill it. Doesn't look like a
wise move to me.

Instead of *forcing* HTTPS and TLS on everybody, why don't you ask
people why they haven't used it yet, and then solve their problems?

Encouraging HTTPS: Progress.
Mandating it: Destructive.

Ben
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Donald Stufft-2
Nobody is forcing you. The browser is the user's agent not the website owner's agent and has a responsibility to accurately indicate whether they are safe from a variety of possible attacks.

Sent from my iPhone

> On Nov 20, 2015, at 12:55 PM, Ben Bucksch <[hidden email]> wrote:
>
>
> * If you want to run HTTPS on your website, go for it.
> * If you want to encourage HTTPS by making it easier to set up, go for it.
> * If you want to *force* *me* to use HTTPS, then you're overstepping your power.
>
> My problems with HTTPS:
> * It uses TLS, which is (deliberately) misdesigned from the start and puts trust in the wrong place, making it inherently insecure. It was *explicitly* designed to only protect credit cards during your Amazon order purchase. (If you have doubts, check your CA's contracts.) That means you can't even use TLS to protect passwords or token that would - if stolen - make damages superior to 1 million US$, much less things without price tag, like privacy, human rights or human life. My problem is that TLS is offered as solution against government surveillance.
> * It's very hard to set up. It's made even more difficult now that I can't even get an IPv4 address for my each of my servers (not just the web domain) anymore.
> * The primary value of the Internet is that the barrier of entry is very low. Nobody was there to forbid me my idea. That's what allowed this strong and fast innovation.
> * The DNS is already a big problem, finding a memorable domain and name for my company has become one of the primary obstacles. And you want to add another *mandatory* central point, the CAs, which have again and again violated the security guarantees, e.g. by issuing intermediate "*" certificates to private companies, allowing them to intercept all TLS traffic.
>
> HTTP is *the* most common communication protocol. It's used for so many things that it's hard to list them all, including internal services within the local network. And you want to kill it. Doesn't look like a wise move to me.
>
> Instead of *forcing* HTTPS and TLS on everybody, why don't you ask people why they haven't used it yet, and then solve their problems?
>
> Encouraging HTTPS: Progress.
> Mandating it: Destructive.
>
> Ben
> _______________________________________________
> dev-security mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Kurt Roeckx
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

Ben Bucksch
In reply to this post by Ben Bucksch
Donald Stufft wrote on 20.11.2015 18:58:
> Nobody is forcing you. The browser is the user's agent not the website owner's agent and has a responsibility to accurately indicate whether they are safe from a variety of possible attacks.

The statement "HTTP is insecure" is not true and simply a lie. See my
reply to bz.
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
Reply | Threaded
Open this post in threaded view
|

Re: HTTP is just fine

klasse
In reply to this post by Ben Bucksch
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-security
_______________________________________________
dev-security mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-security
123