Re: Marking HTTP As Non-Secure

[Chris Palmer]

On Thu, Nov 5, 2015 at 7:35 AM, Raúl Martínez <r...@rme.li> wrote:

> Latest Forefox nightly build (44) marks HTTP as non secure if the page
> contains a password input.
>
> Today I read again the proposal (
> https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure)
> and I realise that year 2015 is about to end and currently no browsers are
> even marking http as dubious.
>
> What are the plans un Chrome and Firefox for this proposal? What is the
> planned roadmap?
>
You can go to chrome://flags/ and turn on the "Mark non-secure origins as
non-secure" experiment to see what the world will look like. (That's been
in there for ~6 months now.)

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. Toward that end, my colleagues
lgarron and estark developed the Security panel in Chrome Dev Tools (you
can see it in Beta now), and we have simplified the Omnibox security
indicators to try to smooth the path somewhat (and make the UX less
complex):
https://googleonlinesecurity.blogspot.com/2015/10/simplifying-page-security-icon-in-chrome.html
.

We've also done a bit of consulting work with large site operators to find
their pain points and help them with technical concerns. The mixed passive
content warning was one (because it made HTTPS look worse than HTTP), and
another is publishers relying on non-secure ads origins. Google is serving
ads by HTTPS, and the industry is generally moving there (
http://www.iab.com/news/lean/).

So, hopefully sooner rather than later, the pain points will diminish and
more and more publishers will move to HTTPS. Happily, Wikipedia got there,
for example. (Woo hoo!)

We are concerned that if people suddenly start seeing the Bad indicator for
lots of the web/for lots of the time they spend on the web, they could get
warning fatigue. Also, site operators could get upset.

But, we do intend to argue that Chrome should show non-secure origins as
non-secure, regardless of HTTPS adoption. We are also redesigning our
security iconography to make the Neutral state more honest about the
reality.

[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

[Hanno Böck]

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

On Thu, 19 Nov 2015 17:00:31 +0100
Ben Bucksch <ben.buck...@beonex.com> 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: ha...@hboeck.de
GPG: BBB51E42

[Kurt Roeckx]

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

[Richard Barnes]

On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <ha...@hboeck.de> 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 <ben.buck...@beonex.com> 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: ha...@hboeck.de
> GPG: BBB51E42
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
>
>

[Hubert Kario]

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

[Hubert Kario]

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

[Boris Zbarsky]

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.

[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

[Ben Bucksch]

Hanno Böck wrote on 19.11.2015 17:40:
> On Thu, 19 Nov 2015 17:00:31 +0100
> Ben Bucksch <ben.buck...@beonex.com> 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

[Ben Bucksch]

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

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

[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]

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.

[Ben Bucksch]

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

[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

[Julien Vehent]

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

[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

[Donald Stufft]

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

[Ben Bucksch]

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.

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

[kla...@partyheld.de]

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

[Frederik Braun]

I don't know how Privoxy works, but in theory you could make privoxy
play man-in-the-middle using a trusted certificate that is in your own
browsers trust store.

This is how intercepting proxys for (security) testing, like ZAP Proxy,
work with HTTPS.

On 20.11.2015 18:10, Ben Bucksch 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

[Hubert Kario]

On Friday 20 November 2015 08:57:36 Boris Zbarsky wrote:
> 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.

you can't realistically deploy HTTP/2.0 without TLS

[Hubert Kario]

On Friday 20 November 2015 08:57:36 Boris Zbarsky wrote:
> 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.

you can't realistically deploy HTTP/2.0 without TLS

[Hubert Kario]

On Friday 20 November 2015 16:12:56 Kurt Roeckx wrote:
> 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

Then it looks like you have a "clean" connection.

In Czech Republic and Poland (on connections from dozen independent
ISPs) the usual I get is something like

8.5s for HTTP
1s for HTTPS

when using Firefox 42

[Hubert Kario]

On Friday 20 November 2015 16:12:56 Kurt Roeckx wrote:
> 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

Then it looks like you have a "clean" connection.

In Czech Republic and Poland (on connections from dozen independent
ISPs) the usual I get is something like

8.5s for HTTP
1s for HTTPS

when using Firefox 42

[Hubert Kario]

On Friday 20 November 2015 19:33:11 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 and HTTP can't be made secure, it's a fact

existence of extensions like Firesheep prove it

[Hubert Kario]

On Friday 20 November 2015 19:33:11 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.
>

[Boris Zbarsky]

On 11/23/15 7:49 AM, Hubert Kario wrote:
> On Friday 20 November 2015 08:57:36 Boris Zbarsky wrote:
>> 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.
>
> you can't realistically deploy HTTP/2.0 without TLS

You completely missed the point of my post. I suggest you read it
again. The claim made was that this site shows that https gives better
performance than http, whereas that is only true if you're using
http/2.0 and only for certain scenarios (lots of small requests). My
objection was not to the claim that in those scenarios http/2.0 over TLS
is faster than http/1.1 (whether over TLS or not) but to the claim
actually being made, which looked nothing like the claim that's actually
true.

-Boris

[Kevin Chadwick]

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

Hmmm, stop talking shit, Integrity, so it getting there at all is
included in that which is far less likely with a SSL enabled server
which is far easier to amplify DDOS against? On top of that DDOS is far
more likely due to it's constant use in the wild than targetted info
poisoning especially when the user could be at anyone's house!! MITM
(ignoring shitty ISPS) is far less likely than you think too!

--

KISSIS - Keep It Simple So It's Securable

[Joerg Stephan]

Good morning,

sorry for being late to the discussion, so just my 2 cents.

I think HTTP is still okay. It is still in use for a reason.
I also think that we maybe should target more towards the awareness of
people and maybe add the option to set paranoid mode in Firefox for
people who do not want to use HTTP at all. This would make sense. There
are so many nice tools in the world from NoScript to HTTPS tools, which
it is maybe time to bring them into Firefox itself.

Honestly, I would love to have a button in the status row where I can
simply disable all based HTTP traffic. I would tell my parents to press
it as soon as they want to do banking stuff.

Am 19.11.2015 um 17:40 schrieb Hanno Böck:
> It's amazing how the same wrong arguments get repeated again and
> again...

>
> On Thu, 19 Nov 2015 17:00:31 +0100
> Ben Bucksch <ben.buck...@beonex.com> 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).
>
>
>
>

> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security

--
--
Kind regards

Joerg Stephan, SSCP

[Kevin Chadwick]

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

The world is NOT BLACK AND WHITE.

A server that has no need for https is more secure without it because it
is simpler and so inherently less exploitable. https is end-end but it
increases the chance to control an end. arguing this isn't true because
javscript may come from unchecked sources is simply idiotic as it still
can anyway and needs controlling in ANY case. If your ISP/network is
dodgy then change it or use a VPN service don;t substitute one problem
for another as that always leads to making things worse in general.

[Kevin Chadwick]

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

And yet mozilla have reduced the control over javascript in their
browser without about:config!!! which is the real issue and nothing to
do with https. Also, a VPN solution would be the right solution for
insecure networks. That makes it a poor excuse for justifying https
everywhere..

[Kevin Chadwick]

> >
> > The statement "HTTP is insecure" is wrong and a lie. That's my
> > problem.
>
> HTTP is insecure and HTTP can't be made secure, it's a fact
>
> existence of extensions like Firesheep prove it

Nonsense, that is likie saying the existence of a virus/rootkit means
that Operating systems are insecure. P.S. redhat should be doing a
much better security job and has a pretty poor security record even
compared to the Windows KERNEL!!!

[Hubert Kario]

On Tuesday 24 November 2015 14:19:13 Kevin Chadwick wrote:
> > > The statement "HTTP is insecure" is wrong and a lie. That's my
> > > problem.
> >
> > HTTP is insecure and HTTP can't be made secure, it's a fact
> >
> > existence of extensions like Firesheep prove it
>
> Nonsense, that is likie saying the existence of a virus/rootkit means
> that Operating systems are insecure.

yes, certain versions of operating systems are known to be insecure.
Subsequently they got updates released and are no longer vulnerable.

You can't update HTTP to not be insecure. You *can't* fix it.

[Hubert Kario]

the ship called "web without javascript" have sailed long ago, reached
its destination, was decommissioned, turned into tourist attraction,
scrapped, turned into toothpicks and finally thrown into trash

[Kevin Chadwick]

> > > > The statement "HTTP is insecure" is wrong and a lie. That's my
> > > > problem.
> > >
> > > HTTP is insecure and HTTP can't be made secure, it's a fact
> > >
> > > existence of extensions like Firesheep prove it
> >
> > Nonsense, that is likie saying the existence of a virus/rootkit means
> > that Operating systems are insecure.
>
> yes, certain versions of operating systems are known to be insecure.
> Subsequently they got updates released and are no longer vulnerable.
>
> You can't update HTTP to not be insecure. You *can't* fix it.

You completely miss the point, extensions like firesheep need access in
the first place like a trojan or local program. Your original argument
has no bearing on the discussion at all.

p.s. it doesn't need fixing, however https really does from a design
point of view. Thankfully from a technical fix point of view there are a
few forks from openssl too such as libressl as well as googles.

Also http tunnelled over ssh is much more secure than over SSL, so it
would make most sense if you would just retract your statement
entirely.

[Kevin Chadwick]

> > And yet mozilla have reduced the control over javascript in their
> > browser without about:config!!! which is the real issue and nothing to
> > do with https. Also, a VPN solution would be the right solution for
> > insecure networks. That makes it a poor excuse for justifying https
> > everywhere..
>
> the ship called "web without javascript" have sailed long ago, reached
> its destination, was decommissioned, turned into tourist attraction,
> scrapped, turned into toothpicks and finally thrown into trash

right and that's why mozilla advertised the noscript extension along
with dr web recently. PHP with suhosin and cgis but especially CSS
3 and html5 are quite capable these days.

In fact I believe js free may be growing momentum. I certainly see more
high profile sites these days that are very functional and yet can
be javascript free such as tesco.com for accessibility reasons, bank
sites, gov.uk. Amazon My own sites!

I'll grant you that ebay and paypal are going backwards and paypal has
had security issues recently too, coincidence or a sign of struggling
technically?!

[Kevin Chadwick]

> the ship called "web without javascript" have sailed long ago, reached
> its destination, was decommissioned, turned into tourist attraction,
> scrapped, turned into toothpicks and finally thrown into trash

> --

lmfao, thinking about it, there was a SSL browser exploit that required
javascript as the attack vector recently.

> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team

God help your users. If your a user then switch to OpenBSD/LibreSSL if
you can!!

[Hubert Kario]

On Tuesday 24 November 2015 17:31:19 Kevin Chadwick wrote:
> > > > > The statement "HTTP is insecure" is wrong and a lie. That's my
> > > > > problem.
> > > >
> > > > HTTP is insecure and HTTP can't be made secure, it's a fact
> > > >
> > > > existence of extensions like Firesheep prove it
> > >
> > > Nonsense, that is likie saying the existence of a virus/rootkit
> > > means
> > > that Operating systems are insecure.
> >
> > yes, certain versions of operating systems are known to be insecure.
> > Subsequently they got updates released and are no longer vulnerable.
> >
> > You can't update HTTP to not be insecure. You *can't* fix it.
>
> You completely miss the point, extensions like firesheep need access
> in the first place like a trojan or local program. Your original
> argument has no bearing on the discussion at all.

you don't understand what firesheep does - it does not require access to
computer under attack, it requires access to network on which the system
under attack is

and that is not exactly that hard to arrange if you're on a WiFi in a
hotel/coffee house/event or on a network in school/library...

it's not 1970's any more, there is no such thing as a "trusted network"*

> p.s. it doesn't need fixing, however https really does from a design
> point of view. Thankfully from a technical fix point of view there are
> a few forks from openssl too such as libressl as well as googles.

you are mixing up completely different topics while missing the elephant
in the room

just because one implementation has a bug doesn't make the protocol
itself incorrect

> Also http tunnelled over ssh is much more secure than over SSL, so it
> would make most sense if you would just retract your statement
> entirely.

and GPG is better than S/MIME which in turn is better than plain text
email

both (S/MIME and HTTP+SSH) are also unusable by the average person
connecting to average server

HTTPS on the other hand is used by billions


* - yes there are exceptions with air gapped systems, with cables not
leaving a shielded room or virtual networks between virtual hosts on a
single machine. But they are only that - exceptions.
--

Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team

[Kevin Chadwick]

> you don't understand what firesheep does - it does not require access to
> computer under attack, it requires access to network on which the system
> under attack is
>
> and that is not exactly that hard to arrange if you're on a WiFi in a
> hotel/coffee house/event or on a network in school/library...
>
> it's not 1970's any more, there is no such thing as a "trusted network"*

Sorry but that is more bullshit!

"However, using Wi-Fi Protected Access (WPA or WPA2) encryption offers
individual user isolation, preventing the attacker from using Firesheep
from decrypting cookies sent over the network even if the Firesheep
user has logged into the network using the same password.[11] An
attacker would be able to manually retrieve and decrypt another user's
data on a WPA-PSK connection, if the key is known and the attacker was
present at the time of the handshake, or if they send a spoofed
de-authenticate packet to the router, causing the user to
re-authenticate and allow the attacker to capture the handshake. This
attack would not work on WPA-Enterprise networks as there is no single
password (the 'Pre Shared Key' in PSK)."

AND

on top of that any site that is set up half correctly would not be
vulnerable anyway!!

http is not for logins, no-one said it was, what is being argued with is
whether the world is truly more secure with or without http. I
would state that the world is less correct with only https and no http
and also state that some servers are more secure without https.

[Hubert Kario]

On Tuesday 24 November 2015 17:43:48 Kevin Chadwick wrote:
> > the ship called "web without javascript" have sailed long ago,
> > reached its destination, was decommissioned, turned into tourist
> > attraction, scrapped, turned into toothpicks and finally thrown
> > into trash

> lmfao, thinking about it, there was a SSL browser exploit that
> required javascript as the attack vector recently.
>

> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
>

> God help your users. If your a user then switch to OpenBSD/LibreSSL if
> you can!!

It's rather clear that your threat assessments and the greater security
community threat assessments don't match up. And that's OK. Maybe we are
wrong. Maybe you're wrong. Or maybe the optimal solution lies some place
else.

What I'm sure is that you're not doing a good job at convincing us that
we're wrong, especially with personal attacks.

[Kevin Chadwick]

> and the greater security
> community threat assessments don't match up. And that's OK.

"Greater security community" NO they never have as I have much higher
security standards, that of a more niche security community that is
practical paranoid!!

[Stefan Arentz]

On Tue, Nov 24, 2015 at 3:26 PM, Kevin Chadwick <m8il...@gmail.com> wrote:

> > and the greater security
> > community threat assessments don't match up. And that's OK.
>
> "Greater security community" NO they never have as I have much higher
> security standards, that of a more niche security community that is
> practical paranoid!!
>

Kevin, this is an interesting discussion but I get the idea that you do not
see the bigger picture.

It makes no sense to talk about WPA2 in the context of Firesheep. Firesheep
was a proof of concept. What it proved was that it is extremely simple to
capture data from insecure http traffic anywhere between your browser and
the web site. Yes it did so best on inseure local networks. But reality is
that there can be dozens of different networks, countries, operators and
types of links between you and that web site. And at every point there
could be a 'Firesheep' running.

We live in a world now where traffic interception happens in multiple
places and for multiple reasons. This is reality now. You should assume
that someone is recording and analyzing your plain internet traffic.

Making that impossible is the point of end-to-end encryption.

You say: yes https must be used for logins. But the rest of Amazon can run
on plain http. What if I tell you that your ISP is currently intercepting
plain HTTP Amazon traffic from all its subscribers so that they can build
up an advertisement profile of you. They do that for all their subscribers
and they sell that data to interested parties. Big data, big money. Only
possible with plain HTTP.

I made that up. But it may be true. Who knows. The data is insecure so
simply you do not know who is capturing it and what is happening with it.
Assume the worst.

Maybe you don't care about your blog being secure. What kind of info is on
there anyway, it is all static content. Does not have to be secure right?
Well, maybe I live in china and I am reading an article about TOR proxies
that you wrote. Technically there is no reason the server is secure. But
the content is dangerous for me to read in China! And since it was captured
by the state hosted proxy I can now expect a visit from local police,
asking me why I am reading about TOR.

That is the bigger picture. Look beyond local networks and bugs in OpenSSL.
It is just not about that.

S.

[Kevin Chadwick]

> What if I tell you that your ISP is currently intercepting
> plain HTTP Amazon traffic from all its subscribers so that they can build
> up an advertisement profile of you. They do that for all their subscribers
> and they sell that data to interested parties. Big data, big money. Only
> possible with plain HTTP.
>
> I made that up. But it may be true. Who knows. The data is insecure so
> simply you do not know who is capturing it and what is happening with it.
> Assume the worst.
>
> Maybe you don't care about your blog being secure. What kind of info is on
> there anyway, it is all static content. Does not have to be secure right?
> Well, maybe I live in china and I am reading an article about TOR proxies
> that you wrote. Technically there is no reason the server is secure. But
> the content is dangerous for me to read in China! And since it was captured
> by the state hosted proxy I can now expect a visit from local police,
> asking me why I am reading about TOR.
>
> That is the bigger picture. Look beyond local networks and bugs in OpenSSL.
> It is just not about that.

Thankyou for a well considered email and I know these are just a
couple of reasonable examples, however my ISP is Zen who I trust not to
do so. If you can't trust your ISP then get a VPN service becauses
https everywhere will not work and only accounts for a fraction of the
danger, after all a compromise elsewhere could lead to a compromises
of all https traffic on an end node anyway. Sites that help you to
find a VPN service that hasn't been blocked by China can enforce https
anyway, however that domain is more likely to have been blocked anyway.

I worry a little about competing companies finding out what parts
we use but the site that offers the best price actually displays "others
who bought this also bought" and probably sells it themselves.

going back to the OP's
"HTTP is just fine" email then I think he raises valid points that have
been overly criticised in a terrible manner as there is NOTHING wrong
with http and it should not be called insecure. The application of HTTP
may be insecure but http itself is not AND the application of http may
be more secure than using https.

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

Perhaps non-encrypted or non-private would be a better term than
non-secure?

p.s. Trust in sites is an ongoing thing, and whilst joking a little, a
better in-security indication may be "this site uses an internet based
CMS and so can't be secure" ;)

[Gervase Markham]

On 24/11/15 19:48, Kevin Chadwick wrote:
> Sorry but that is more bullshit!

This kind of language is not acceptable on this list. And it's also
probably not wise for one person's posts to consist of > 50% of the
posts in a multi-person conversation.

Please exercise restraint.

Gerv

[Hubert Kario]

On Wednesday 25 November 2015 12:31:48 Kevin Chadwick wrote:
> > What if I tell you that your ISP is currently intercepting
> > plain HTTP Amazon traffic from all its subscribers so that they can
> > build up an advertisement profile of you. They do that for all
> > their subscribers and they sell that data to interested parties.
> > Big data, big money. Only possible with plain HTTP.
> >
> > I made that up. But it may be true. Who knows. The data is insecure
> > so simply you do not know who is capturing it and what is happening
> > with it. Assume the worst.
> >
> > Maybe you don't care about your blog being secure. What kind of info
> > is on there anyway, it is all static content. Does not have to be
> > secure right? Well, maybe I live in china and I am reading an
> > article about TOR proxies that you wrote. Technically there is no
> > reason the server is secure. But the content is dangerous for me to
> > read in China! And since it was captured by the state hosted proxy
> > I can now expect a visit from local police, asking me why I am
> > reading about TOR.
> >
> > That is the bigger picture. Look beyond local networks and bugs in
> > OpenSSL. It is just not about that.
>

> however my ISP is Zen who I trust not
> to do so.

https://en.wikipedia.org/wiki/IP_hijacking

> after all a compromise elsewhere could lead to a
> compromises of all https traffic on an end node anyway.

you really have no idea how TLS works and what it provides, now do you?

[Anne van Kesteren]

On Wed, Nov 25, 2015 at 2:52 PM, Hubert Kario <hka...@redhat.com> wrote:
> On Wednesday 25 November 2015 12:31:48 Kevin Chadwick wrote:
>> after all a compromise elsewhere could lead to a
>> compromises of all https traffic on an end node anyway.
>
> you really have no idea how TLS works and what it provides, now do you?

Could you please keep the discourse civil? As far as I can tell that
statement is correct. If a client or server is compromised,
connections to and from it are compromised too. Or simpler, if your
computer is compromised, HTTPS is not going to protect you.


--
https://annevankesteren.nl/

[Kevin Chadwick]

> > however my ISP is Zen who I trust not
> > to do so.
>
> https://en.wikipedia.org/wiki/IP_hijacking
>

> > after all a compromise elsewhere could lead to a
> > compromises of all https traffic on an end node anyway.
>
> you really have no idea how TLS works and what it provides, now do you?

Why is that? You obviously miss understand me because I understand
perfectly well??

Like disk encryption only protects a machine when switched off, TLS only
protects the transport and so a compromised Windows box means TLS
counts for nothing, so A VPN could stop udp packet injection on a game
running as an administrator for example etc. etc. which once exploited
could compromise your TLS. TLS would not and so the FIX is in the wrong
place, was the point that I was making???

[Kevin Chadwick]

> > Sorry but that is more bullshit!
>

> This kind of language is not acceptable on this list. And it's also
> probably not wise for one person's posts to consist of > 50% of the
> posts in a multi-person conversation.
>
> Please exercise restraint.

Okies, but it's getting tiresome when the same bull keeps being
repeated on the same topic on the same list without included
justification that has had any consideration or time spent
and at the same time the opposite is stated whimsically and very
strongly yet incorrectly with the intention of stopping responses.

Anyway, I give up, some people obviously have irremovable filters on
their brains, if mozilla say my site is insecure. I shall simply tell
customers that it is more secure than mozilla.com and mozilla are dumb
and believe that they will believe me.

[Hubert Kario]

On Wednesday 25 November 2015 15:40:07 Anne van Kesteren wrote:
> On Wed, Nov 25, 2015 at 2:52 PM, Hubert Kario <hka...@redhat.com>
wrote:
> > On Wednesday 25 November 2015 12:31:48 Kevin Chadwick wrote:

> >> after all a compromise elsewhere could lead to a
> >> compromises of all https traffic on an end node anyway.
> >
> > you really have no idea how TLS works and what it provides, now do
> > you?

> Could you please keep the discourse civil? As far as I can tell that
> statement is correct.
> If a client or server is compromised,
> connections to and from it are compromised too. Or simpler, if your
> computer is compromised, HTTPS is not going to protect you.

yes, TLS does not help against compromise of computer on either end of
connection, so does using unecrypted communication, which makes this
argument moot

in other words, if you imply that TLS does claim to protect you against
the party you're connecting to, you have no idea about TLS provides

[Kevin Chadwick]

https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

>
> Last but not least, when you're asking for everything to be encrypted,
> you're missing the point of many websites.

Are mozilla actually asking for this? I like the letsencrypt.org
accomplishments (whilst wishing they had strayed further from the
traditional CA model) but the mission statement is misguided IMO.

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


Aren't I correct in that normal HTTP will only be called insecure if it
uses features such as htaccess passwords.

Is there a current list of what features will be blocked?

Video Card hardware acceleration being marked as insecure, might be
annoying. Click to play would be the right move.

It's stated that AES accelerated CPUs mean TLS doesn't matter but man
y clients struggle with web content already, especially on Linux/Unix
and many clients don't have intel i5 processors and actually my web
server cpu is a year too old. I know the main reason for video
struggling on Linux is Adobe's poor flash implementation but xombrero
whilst not compatible with some sites is so much quicker at loading
pages than both firefox and chrome. Perhaps the performance hit is
still marginal, but I'm certainly not convinced from my own
observations.

Incidentally, whilst I've been hoping html5 video would improve things,
the recent upgrade to itv.com has made one of my mythtv boxes in browser
video frame rate drop recently, of course TLS was used before also. I
have a windows box I can use in the same room that I use for
silverlight but that's just annoying and isn't always available.

[Kevin Chadwick]

> yes, TLS does not help against compromise of computer on either end of
> connection, so does using unecrypted communication, which makes this
> argument moot
>
> in other words, if you imply that TLS does claim to protect you against
> the party you're connecting to, you have no idea about TLS provides

The point was that a VPN is a more complete and correct protection for
the concerns raised not to mention award winning software having been
specifically developed for the CHINA censorship problem.

p.s. sorry, I will significantly reduce my posts hopefully to nil now.

[Aymeric Vitte]

Le 20/11/2015 12:35, Richard Barnes a écrit :

> On Thu, Nov 19, 2015 at 8:40 AM, Hanno Böck <ha...@hboeck.de> 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
>
>
>

You might not break the current internet but its future.

Example: https://bugzilla.mozilla.org/show_bug.cgi?id=917829

How do you intend to solve this? ie the case of an entity that just
cannot have valid certificates and/or implements a secure protocol on
top of an insecure one (ws here for Peersm project, the other party can
be by design a "MITM" but we completely don't care per the secure
protocol used, the MITM will not know what happens next)?

Like WebRTC too, but there is an exception for that one, self-signed
certificates are (by some luck) accepted.

It's obvious that browsers will be used for new services involving those
mechanisms in the future, like P2P systems as sketched here:
https://mailman.stanford.edu/pipermail/liberationtech/2015-November/015680.html

--
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

[Hubert Kario]

On Wednesday 25 November 2015 16:07:10 Kevin Chadwick wrote:
> it's getting tiresome when the same bull keeps being
> repeated on the same topic on the same list without included
> justification that has had any consideration or time spent
> and at the same time the opposite is stated whimsically and very
> strongly yet incorrectly with the intention of stopping responses.
>
> Anyway, I give up, some people obviously have irremovable filters on
> their brains

"funny" you say that, I have exact same feelings

> if mozilla say my site is insecure.

mozilla doesn't say that your site is insecure

mozilla wants to say that the connection between the computer and your
site is insecure

> I shall simply tell
> customers that it is more secure than mozilla.com and mozilla are dumb
> and believe that they will believe me.

and again with the ad hominems... I seriously wonder why I'm even
bothering at this point


Please, explain why we should not have protections against unlikely, but
conceivable attacks (attacks that are either documented, or have easy to
use tools to facilitate them).

yes, the few times you went to the coffee place and used unsecured WiFi
you may not have gotten your cookies sniffed and didn't get malware
injected into javascript (or jpg files that exploit bugs in renderers, r
different account numbers for wire-transfers... pick your poison)

you may live in a place where your ISP doesn't want to get few extra
pennies by replacing ads on pages you watch, and you may not have
neighbours that try to sniff credit card numbers (or SSNs) from
connections that go through the shared cable TV network

you may even leave your doors unlocked because you live in a house in
the middle of a prairie

or live in a city and forgot to close the doors few times and nothing
bad happened

are you really trying to say that because of that few instances we all
should leave our doors unlocked and boycott insurance companies that
expect you to lock your homes?

that because there are other technologies for securing communications we
shouldn't use the one that is easiest to use by normal users? one that
does not require any additional setup by the users?

[Kevin Chadwick]

> Please, explain why we should not have protections against unlikely, but
> conceivable attacks (attacks that are either documented, or have easy to
> use tools to facilitate them).
>

Please explain what protections I am saying you should not have, do you
mean https everywhere. If that is what you mean then prepare yourself..
if I can be bothered to keep responding to this nonsense.

> yes, the few times you went to the coffee place and used unsecured WiFi
> you may not have gotten your cookies sniffed and didn't get malware
> injected into javascript (or jpg files that exploit bugs in renderers, r
> different account numbers for wire-transfers... pick your poison)

I wouldn't use a device worth hacking on an unsecured wifi. I shall
ignore that being the case though and state that if I was on an
unsecured coffee shop network (which are rare these days) with many
users and I was a black hat then it would not matter if they were using
TLS or not as to whether I could takeover many of their machines and
probably every mobile phone!!

So I'm still struggling to see your value proposition especially when
things that need TLS will use it anyway in a secure manner??

Are you saying people shouldn't need to look for https or a padlock in
which case they still need to check the domain name which is actually
far more important, so again there is no argumwent? Will they only
check the domain name if it says insecure and so possibly making the
situation worse??

[Kevin Chadwick]

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

That seems much more accurate to me :) and also removes ambiguation
about the actual site being insecure for whatever reason like hosting
malware. Past threads suggested/stated but can I confirm that this
message wouldn't be shown in any case for local loopback connections
such as SSH tunnelled connections too?