Re: Intent to deprecate: Insecure HTTP

[Daniel Veditz]

You're replying to a 4 year old thread. Don't do that: you're jumping over
4 years of other conversations, and tagged on the end of an old thread
whatever arguments you're making will unseen by a lot of people depending
on how their mail readers work.

Your arguments about HTTPS overhead on poor networks make some sense, but
that tiny amount of data is completely swamped by the average size of a
single image these days, let alone an entire page.

> HTTPS should only be used for sensitive data or stateful queries.

What we've learned from "surveillance capitalism" over the past several
years is that it is _all_ sensitive data.

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[bulk88]

On Monday, April 13, 2015 at 10:57:58 AM UTC-4, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:

For Devs who claim to be crusaders of standards, your standards last little 
more than 1 financial cycle until deprecated and 2 years until removed. TLS has 
observable overhead (more round trips) on all 2G-4G connections vs an 
equivalent cleartext HTTP 1.1. For privileged developers who carry venture 
capital funded client test devices and the most expensive dev machines that 
money can buy funded by Wall Street money, it is easy to throw away all users 
who live in developing nations on budget client hardware or lowest tier 3G or 
4G networks. Cleartext has a place, and until HTTP2/QUIC can get round trips 
and packet size to old cleartext ways on high packet loss, 2G or satellite, or 
the worst monopoly "State Post and Telegraph" 3G mobile networks, HTTPS should 
only be used for sensitive data or stateful queries.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Edmund Wong]

Steve Fink wrote:
> On 12/20/2016 06:20 PM, Edmund Wong wrote:
>> Richard Barnes wrote:
>>
>>> Broadly speaking, this plan would entail  limiting new features to
>>> secure
>>> contexts, followed by gradually removing legacy features from insecure
>>> contexts.  Having an overall program for HTTP deprecation makes a clear
>>> statement to the web community that the time for plaintext is over -- it
>> There is nothing wrong with plaintext just as long as it isn't something
>> credential-like.  Also, what you're doing will only make a clear
>> statement to the web community that you are forcing something on them
>> and limiting THEIR choices of broadcasting their information as they
>> see fit.
>>
>> IOW, "deprecating HTTP" is not a good idea.
> 
> If I have a browser exploit that I can embed in a 

Re: Intent to deprecate: Insecure HTTP

[Steve Fink]

On 12/20/2016 06:20 PM, Edmund Wong wrote:

Richard Barnes wrote:


Broadly speaking, this plan would entail  limiting new features to secure
contexts, followed by gradually removing legacy features from insecure
contexts.  Having an overall program for HTTP deprecation makes a clear
statement to the web community that the time for plaintext is over -- it

There is nothing wrong with plaintext just as long as it isn't something
credential-like.  Also, what you're doing will only make a clear
statement to the web community that you are forcing something on them
and limiting THEIR choices of broadcasting their information as they
see fit.

IOW, "deprecating HTTP" is not a good idea.


If I have a browser exploit that I can embed in a 

Re: Intent to deprecate: Insecure HTTP

[Edmund Wong]

Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.

With all due respects, the HTTP->HTTPS *isn't* entirely a web
developer's choice; but the web server administration choice (unless
the person is wearing both hats).

Just because the US Government is calling for encryption (i.e. HTTPS
over HTTP), it doesn't mean people can and/or will do it.  Why?
Why do people need to be forced to use HTTPS when it's overkill for
their website?  I mean.. would a run-of-the-mill-with-no-shopping
require HTTPS?

Like, i.e http://www.ambrosia-oysterbar.com/catalog/index.php

HTTPS is a secured method of transporting information.  For the
above website,  https would mean absolutely no sense and would
be akin to getting BRINKS to transporting a T-bone steak dinner
to you.  Can you do that?  Sure possibly if BRINKS doesn't ignore
you right out.  Why would you do that?

Like everything, HTTPS is a tool and it's a bad idea
to force people to use HTTPS when they don't need it.  When
do they need it?  Who decides when they need it?  Certainly not
you, or anyone else other than themselves.

So like the NetworkInterface issue...  please stop wasting
resources doing these 'busy' things when you can be doing something
else that gives more choice to the user.  I mean.. doing the things
right vs. doing the right things and I believe it was the late Peter
Drucker that wrote that.

> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it

There is nothing wrong with plaintext just as long as it isn't something
credential-like.  Also, what you're doing will only make a clear
statement to the web community that you are forcing something on them
and limiting THEIR choices of broadcasting their information as they
see fit.

IOW, "deprecating HTTP" is not a good idea.

:ewong
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers 
wrote:

> Absolutely!  Let's Encrypt sounds awesome, super-easy, and the price is
> right.
>
> But I'm thinking of cases like Lavabit where a judge forced the site
> operator to release the private key.  Or the opposite - could a government
> restrict access to a site by forcing the CA to revoke certificates?  I
> guess you could just get another certificate from another CA but what if
> they are all ordered to revoke you - like in some future world government
> or something...
>

Certainly a government could do that, but it's easier to just go after the
DNS.


This example is extreme but security is not about the norm, it's about the
> fringe cases.  I just wish we could have an encryption scheme that doesn't
> need any third-party authority, before we start punishing those who don't
> use it.  That's all.
>

As long as sites are identified by domain names and want those names to be
tied to real world identities, I don't see anything like that one the
horizon (i.e., I'm not aware of any technology which would let you do it).

-Ekr



> On Tuesday, 20 December 2016 10:47:33 UTC-7, Jim Blandy  wrote:
> > Can't people use Let's Encrypt to obtain a certificate for free without
> the
> > usual CA run-around?
> >
> > https://letsencrypt.org/getting-started/
> >
> > "Let’s Encrypt is a free, automated, and open certificate authority
> brought
> > to you by the non-profit Internet Security Research Group (ISRG)."
> >
> >
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Cody Wohlers]

Absolutely!  Let's Encrypt sounds awesome, super-easy, and the price is right.  

But I'm thinking of cases like Lavabit where a judge forced the site operator 
to release the private key.  Or the opposite - could a government restrict 
access to a site by forcing the CA to revoke certificates?  I guess you could 
just get another certificate from another CA but what if they are all ordered 
to revoke you - like in some future world government or something...

This example is extreme but security is not about the norm, it's about the 
fringe cases.  I just wish we could have an encryption scheme that doesn't need 
any third-party authority, before we start punishing those who don't use it.  
That's all.

On Tuesday, 20 December 2016 10:47:33 UTC-7, Jim Blandy  wrote:
> Can't people use Let's Encrypt to obtain a certificate for free without the
> usual CA run-around?
> 
> https://letsencrypt.org/getting-started/
> 
> "Let’s Encrypt is a free, automated, and open certificate authority brought
> to you by the non-profit Internet Security Research Group (ISRG)."
> 
> 


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Jim Blandy]

Can't people use Let's Encrypt to obtain a certificate for free without the
usual CA run-around?

https://letsencrypt.org/getting-started/

"Let’s Encrypt is a free, automated, and open certificate authority brought
to you by the non-profit Internet Security Research Group (ISRG)."


On Tue, Dec 20, 2016 at 6:38 AM,  wrote:

> This is a good idea but a terrible implementation.  I already need someone
> else's approval (registrar) to run a website (unless I want visitors to
> remember my IP addresses).  NOW I will need ANOTHER someone to approve it
> as well (the CA authority), (unless I want visitors to click around a bunch
> of security "errors").
>
> We shouldn't be ADDING authorities required to make websites.  The web is
> open and free and this proposal adds authority to a select few who can
> dictate whats a "valid" site and what isn't.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[cody . wohlers]

This is a good idea but a terrible implementation.  I already need someone 
else's approval (registrar) to run a website (unless I want visitors to 
remember my IP addresses).  NOW I will need ANOTHER someone to approve it as 
well (the CA authority), (unless I want visitors to click around a bunch of 
security "errors").

We shouldn't be ADDING authorities required to make websites.  The web is open 
and free and this proposal adds authority to a select few who can dictate whats 
a "valid" site and what isn't.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd (Sheppy)]

On Thu, May 7, 2015 at 12:43 AM, Adam Roach  wrote:

> Which leaves us with a conundrum regarding your plea for more notice:
> it's a bit hard to seriously consider complaints that "at some future
> date yet to be determined" is "too soon."
>

​My apologies. My reading of the announcements indicated that this was
happening in Firefox 40, which is very soon. It was not at all clear that
there was some kind of step by step process (indeed, this message was the
first time I picked up on that, despite reading this thread fairly closely
-- perhaps communications being clearer would have helped).

I suspect a lot of this kerfuffle could have been dodged had the original
posting been a little more thorough and more cautiously worded.​ Trying to
tease these nuances out of a long and emotional thread has been difficult,
unfortunately.

It was not clear until quite a few messages into the thread that this
wasn't all happening at once, and wasn't automatically being applied to all
servers. It sounded very much as if all unencrypted HTTP was going to be
rejected starting in Firefox 40. Now that I know that's not the case, I'm
much less concerned, although not 100% living in happy unicorns and
rainbows land.



-- 

Eric Shepherd
Senior Technical Writer
Mozilla
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Steve Fink]

On 05/01/2015 01:50 PM, oli...@omattos.com wrote:

When plans like this aren't rolled out across all browsers together, users inevitably 
come across a broken site and say "Firefox works with this site, but Safari gives a 
warning.  Safari must be broken".  Better security is punished.

Having this determined by a browser release is also bad.   "My up to date Firefox is 
broken, but my old Safari works.  Updating breaks things and must be bad!".  Secure 
practices are punished.

All browsers could change their behaviour on a specific date and time.   But 
that would lead to stampedes of webmasters having issues all at once.  And if 
theres any unforeseen compatibility issue, you just broke the entire world.  
Not so great.

So might I suggest the best rollout plan is to apply policies based on a hash 
of the origin and a timestamp.   Ie. on a specific date, 1% of sites have the 
new policies enforced, while 99% do not.  Then a month later, it's up to 51%, 
and another month later it's up to 100%.


The proposal I understood from this thread involves breaking precisely 
0% of existing sites. So the flag day would only be relevant to 
in-development sites using new features only available in development 
browser builds.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Adam Roach]

> On May 6, 2015, at 22:51, Eric Shepherd  wrote:
>
> would have been nice to have more notice


The plan that has been outlined involves a staged approach, with new
JavaScript features being withheld after some date, followed by a
period during which select older JavaScript features are gradually
removed. I'll note that actually turning off http isn't part of the
outline.

Most importantly, all of these steps are to be taken at dates that are
still under discussion. You can be part of that discussion.

Which leaves us with a conundrum regarding your plea for more notice:
it's a bit hard to seriously consider complaints that "at some future
date yet to be determined" is "too soon."

/a
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Gervase Markham wrote:

For this edge case, I would say the solution is to use a proxy, run on
one of your other (faster) computers. As noted elsewhere, that's what
jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again.
That's a reasonable solution for one-offs, but not really viable if you 
have a bunch of hobbyists who don't necessarily have the technical 
background to deal with that. Even I don't know how to set up a proxy 
like that. I'm sure it wouldn't take me long to learn, but I certainly 
can't expect all the people who use programs I write to know how to do it.


I get, of course, that this is the way of progress. Just... would have 
been nice to have more notice, since we're going to have to try to find 
someone to build, produce, and market a simple, plug-and-play mechanism 
to handle encryption and decryption of data in order to keep these hobby 
machines online over the long term.


Will make for a fun project for someone, but will take time.

--

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Cameron Kaiser]

On 5/4/15 3:03 AM, Gervase Markham wrote:

On 01/05/15 20:40, Eric Shepherd wrote:

In my case, the situation is that I have classic computers running 1-10
megahertz processors, for which encrypting and decrypting SSL is not a
plausible option.


For this edge case, I would say the solution is to use a proxy, run on
one of your other (faster) computers. As noted elsewhere, that's what
jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again.


That sort of defeats the purpose of the exercise, but since we've 
already been tarred as "not right in the head" ...


So, Gopher then.
Cameron Kaiser

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Anne van Kesteren]

On Wed, May 6, 2015 at 2:04 PM, Matthew Phillips
 wrote:
> It's absolutely true for hosting yourself today. The only thing even
> slightly difficult is setting up dynamic dns.

And in a future where certificates are issued without cost over a
protocol there's no reason setting up a secure server yourself will be
difficult. HTTP will not disappear overnight and we'll have plenty of
times to get all the moving pieces in order to make this great and
overall a better web for end users. (Who will have less impossible
trust decisions to endure.)


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Matthew Phillips]

It's absolutely true for hosting yourself today. The only thing even
slightly difficult is setting up dynamic dns.

On Mon, May 4, 2015, at 06:01 AM, Gervase Markham wrote:
> On 01/05/15 19:02, Matthew Phillips wrote:
> > You must have missed my original email:
> > It's paramount that the web remain a frictionless place where creating a
> > website is dead simple. 
> 
> That is not true today of people who want to run their own hosting. So
> people who want "frictionless" use blogspot.com, or one of the thousands
> of equivalent sites in many different jurisdictions, to say what they
> want to say.
> 
> In an HTTPS future, such sites would simply provide HTTPS for their
> users.
> 
> Gerv
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-05 4:59 AM, sn...@arbor.net wrote:

Encryption should be activated only after BOTH parties have mutually 
authenticated.
Why establish an encrypted transport to an unknown attacker?
A web you have to uniquely identify yourself to participate in is really 
not open or free for an awful lot of people. And if we had a reliable 
way of identifying attacks and attackers at all, much less in some 
actionable way, this would all be a much simpler problem.


It is, just as one example among thousands, impossible to know if your 
wifi is being sniffed or not.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Florian Bösch]

On Tue, May 5, 2015 at 12:03 AM, Daniel Holbert 
wrote:

> Without getting too deep into the exact details about animation /
> notifications / permissions, it sounds like Florian's concern RE
> "browsers want to disable fullscreen if you are not serving the website
> over HTTPS" may be unfounded, then.
>
> (Unless Florian or Martin have some extra information that we're missing.)
>
I responded to OPs comment about restricting features (such as fullscreen),
I have no more information than that.

Yes, if the permission dialog could be done away with altogether and an
appropriate UX could be done to make it difficult to miss the fullscreen
change, and if that made it possible to have fullscreen functionality
regardless of http or https that would make me happy.

It would also take care of another UX concern of mine (permission dialog
creep), particularly in the case of where an iframe with fullscreen
functionality is embedded, and the youtube player for instance is
re-polling permissions to go fullscreen on every domain it's embedded in
(which from a users point of view just doesn't make any sense).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[snash]

The additional expense of HTTPS arises from the significantly higher cost to 
the service owner of protecting it against attack, to maintain service 
Availability (that third side of the security CIA triangle that gets 
forgotten). 

Encryption should be activated only after BOTH parties have mutually 
authenticated.
Why establish an encrypted transport to an unknown attacker?

This might be done with mutual authentication in TLS  (which nobody does) or 
creating a separate connection after identities are authenticated, or use an 
App with embedded identity.

I'll be at RIPE70. Steve

On Monday, April 13, 2015 at 3:57:58 PM UTC+1, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
> 
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
> 
> Some earlier threads on this list [5] and elsewhere [6] have discussed
> deprecating insecure HTTP for "powerful features".  We think it would be a
> simpler and clearer statement to avoid the discussion of which features are
> "powerful" and focus on moving all features to HTTPS, powerful or not.
> 
> The goal of this thread is to determine whether there is support in the
> Mozilla community for a plan of this general form.  Developing a precise
> plan will require coordination with the broader web community (other
> browsers, web sites, etc.), and will probably happen in the W3C.
> 
> Thanks,
> --Richard
> 
> [1] https://tools.ietf.org/html/rfc7258
> [2]
> https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
> [3] https://w3ctag.github.io/web-https/
> [4] https://https.cio.gov/
> [5]
> https://groups.google.com/d/topic/mozilla.dev.platform/vavZdN4tX44/discussion
> [6]
> https://groups.google.com/a/chromium.org/d/topic/blink-dev/2LXKVWYkOus/discussion
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Daniel Holbert]

Great!

Without getting too deep into the exact details about animation /
notifications / permissions, it sounds like Florian's concern RE
"browsers want to disable fullscreen if you are not serving the website
over HTTPS" may be unfounded, then.

(Unless Florian or Martin have some extra information that we're missing.)

~Daniel


On 05/04/2015 02:55 PM, Jet Villegas wrote:
> We're adding UX to clearly indicate http:// or https:// in fullscreen
> while still meeting the user desire for secure one-click-to-fullscreen.
> The latest and greatest proposal posted here:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1129061
> 
> --Jet
> 
> On Mon, May 4, 2015 at 2:04 PM, Eric Rescorla  > wrote:
> 
> On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan  > wrote:
> 
> > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson  > wrote:
> >
> > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert  >
> > > wrote:
> > > > (I think there's a strong case for disabling *persistent* fullscreen
> > > > permission, for the reasons described in ekr's response to you 
> here.  I
> > > > haven't seen any proposal for going beyond that, but I might've 
> missed
> > > it.)
> > >
> > > A little birdy told me that that is planned.
> > >
> >
> > I'm currently working on fullscreen. I believe our current plan is 
> neither
> > disabling fullscreen on HTTP, nor disabling persistent permission of 
> that.
> >
> > Instead, we're going to remove permission bit on fullscreen, which means
> > website can always enter fullscreen as far as that is initiated from a 
> user
> > input. We plan to use some transition animation to make entering 
> fullscreen
> > obvious for users, so that they are free from the burden deciding 
> whether a
> > website is trustworthy.
> 
> 
> This is not what I gathered from the notes Richard Barnes forwarded me.
> Rather, I had the impression that we were going to make the
> animation more
> aggressive *and* require a permissions prompt every time for HTTP.
> 
> Richard?
> 
> -Ekr
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org 
> https://lists.mozilla.org/listinfo/dev-platform
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Jet Villegas]

We're adding UX to clearly indicate http:// or https:// in fullscreen while
still meeting the user desire for secure one-click-to-fullscreen. The
latest and greatest proposal posted here:

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

--Jet

On Mon, May 4, 2015 at 2:04 PM, Eric Rescorla  wrote:

> On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan  wrote:
>
> > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson  wrote:
> >
> > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert 
> > > wrote:
> > > > (I think there's a strong case for disabling *persistent* fullscreen
> > > > permission, for the reasons described in ekr's response to you
> here.  I
> > > > haven't seen any proposal for going beyond that, but I might've
> missed
> > > it.)
> > >
> > > A little birdy told me that that is planned.
> > >
> >
> > I'm currently working on fullscreen. I believe our current plan is
> neither
> > disabling fullscreen on HTTP, nor disabling persistent permission of
> that.
> >
> > Instead, we're going to remove permission bit on fullscreen, which means
> > website can always enter fullscreen as far as that is initiated from a
> user
> > input. We plan to use some transition animation to make entering
> fullscreen
> > obvious for users, so that they are free from the burden deciding
> whether a
> > website is trustworthy.
>
>
> This is not what I gathered from the notes Richard Barnes forwarded me.
> Rather, I had the impression that we were going to make the animation more
> aggressive *and* require a permissions prompt every time for HTTP.
>
> Richard?
>
> -Ekr
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan  wrote:

> On Tue, May 5, 2015 at 6:04 AM, Martin Thomson  wrote:
>
> > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert 
> > wrote:
> > > (I think there's a strong case for disabling *persistent* fullscreen
> > > permission, for the reasons described in ekr's response to you here.  I
> > > haven't seen any proposal for going beyond that, but I might've missed
> > it.)
> >
> > A little birdy told me that that is planned.
> >
>
> I'm currently working on fullscreen. I believe our current plan is neither
> disabling fullscreen on HTTP, nor disabling persistent permission of that.
>
> Instead, we're going to remove permission bit on fullscreen, which means
> website can always enter fullscreen as far as that is initiated from a user
> input. We plan to use some transition animation to make entering fullscreen
> obvious for users, so that they are free from the burden deciding whether a
> website is trustworthy.


This is not what I gathered from the notes Richard Barnes forwarded me.
Rather, I had the impression that we were going to make the animation more
aggressive *and* require a permissions prompt every time for HTTP.

Richard?

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Xidorn Quan]

On Tue, May 5, 2015 at 6:04 AM, Martin Thomson  wrote:

> On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert 
> wrote:
> > (I think there's a strong case for disabling *persistent* fullscreen
> > permission, for the reasons described in ekr's response to you here.  I
> > haven't seen any proposal for going beyond that, but I might've missed
> it.)
>
> A little birdy told me that that is planned.
>

I'm currently working on fullscreen. I believe our current plan is neither
disabling fullscreen on HTTP, nor disabling persistent permission of that.

Instead, we're going to remove permission bit on fullscreen, which means
website can always enter fullscreen as far as that is initiated from a user
input. We plan to use some transition animation to make entering fullscreen
obvious for users, so that they are free from the burden deciding whether a
website is trustworthy.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Mon, May 4, 2015 at 12:59 PM, Florian Bösch  wrote:

> On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla  wrote:
>>
>> I'm going to refer you at this point to the W3C HTML design principles of
>> priority of constituencies
>> (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies
>> ).
>>
>> "In case of conflict, consider users over authors over implementors over
>> specifiers over theoretical purity. In other words costs or difficulties to
>> the user should be given more weight than costs to authors; which in turn
>> should be given more weight than costs to implementors; which should be
>> given more weight than costs to authors of the spec itself, which should be
>> given more weight than those proposing changes for theoretical reasons
>> alone. Of course, it is preferred to make things better for multiple
>> constituencies at once."
>>
>> Again, we're happy to look at ways to ease this transition, but right now
>> you're not offering any.
>>
> You've set out on a course that leaves no room to offer any. You're going
> to break things. You've decided to break things and damn the consequences.
> You've decided to synchronize breaking things so that users have no UA to
> flee to. And you've decided to hide your breaking of things so that the
> shitstorm isn't going to come all at once. You're trying to delegate the
> cost to fix things you broke for users, to authors, which in many cases
> cannot burden that cost, even if they wanted to.
>
> I, as an author, tell you that this isn't going to go over smoothly. In
> fact, it's going to go over pretty terribly badly. Coercing everybody to
> conform with your greater goal (tm) from a situation where many cannot
> comply always does.
>

Thanks for clarifying that you're not interested in engaging at a technical
level.

Feel free to flame on.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Florian Bösch]

On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla  wrote:
>
> I'm going to refer you at this point to the W3C HTML design principles of
> priority of constituencies
> (http://www.w3.org/TR/html-design-principles/#priority-of-constituencies).
>
> "In case of conflict, consider users over authors over implementors over
> specifiers over theoretical purity. In other words costs or difficulties to
> the user should be given more weight than costs to authors; which in turn
> should be given more weight than costs to implementors; which should be
> given more weight than costs to authors of the spec itself, which should be
> given more weight than those proposing changes for theoretical reasons
> alone. Of course, it is preferred to make things better for multiple
> constituencies at once."
>
> Again, we're happy to look at ways to ease this transition, but right now
> you're not offering any.
>
You've set out on a course that leaves no room to offer any. You're going
to break things. You've decided to break things and damn the consequences.
You've decided to synchronize breaking things so that users have no UA to
flee to. And you've decided to hide your breaking of things so that the
shitstorm isn't going to come all at once. You're trying to delegate the
cost to fix things you broke for users, to authors, which in many cases
cannot burden that cost, even if they wanted to.

I, as an author, tell you that this isn't going to go over smoothly. In
fact, it's going to go over pretty terribly badly. Coercing everybody to
conform with your greater goal (tm) from a situation where many cannot
comply always does.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Mon, May 4, 2015 at 10:52 AM, Florian Bösch  wrote:

> On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla  wrote:
>
>> This would be more useful if you explained what they considered the cost
>> of converting to HTTPS so, so we could discuss ways to ameliorate that cost.
>>
> I agree. But I don't get to choose what answers I get. I can press the
> point out of interest. But even if I get to some satisfactory outcome there
> that way, it's still effort/money to expend, there's dozens of clients from
> the past and more in the future that I'll have to have the same conversion
> with. For the ones from the past, in many cases even in an ideal case (not
> much effort and everybody knows what's to do), the budget for those
> deployments is used up. There's no new budget coming. They're not going to
> get fixed no matter the good intentions of everybody. End of the day, work
> is not free.
>

I'm going to refer you at this point to the W3C HTML design principles of
priority of constituencies
(http://www.w3.org/TR/html-design-principles/#priority-of-constituencies).

"In case of conflict, consider users over authors over implementors over
specifiers over theoretical purity. In other words costs or difficulties to
the user should be given more weight than costs to authors; which in turn
should be given more weight than costs to implementors; which should be
given more weight than costs to authors of the spec itself, which should be
given more weight than those proposing changes for theoretical reasons
alone. Of course, it is preferred to make things better for multiple
constituencies at once."

Again, we're happy to look at ways to ease this transition, but right now
you're not offering any.


With that said, fullscreen is actually a good example of a feature which
>> really benefits from being over HTTPS. Consider what happens if the user
>> grants a persistent permission to site X to use fullscreen. At that point,
>> any network attacker can take over the user's entire screen without their
>> consent by pretending to be site X. Note that this is true *even if* the
>> real version of site X doesn't do anything sensitive. So, I think it should
>> be fairly easy to understand why we want to limit access to fullscreen over
>> HTTP.
>>
>
> I don't agree with that reasoning. But my agreeing to it or not doesn't
> change the outcome I have tested in the real world.
>

I don't really understand what you're talking about here. I think this is a
fairly straightforward security analysis here. I appreciate that it makes
people sad that we don't want to let them do unsafe things, but that
doesn't make them safe. If you have a security analysis to offer in this
case about why fullscreen over HTTP is safe, I'd be happy to hear it.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Martin Thomson]

On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert  wrote:
> (I think there's a strong case for disabling *persistent* fullscreen
> permission, for the reasons described in ekr's response to you here.  I
> haven't seen any proposal for going beyond that, but I might've missed it.)

A little birdy told me that that is planned.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Daniel Holbert]

On 05/04/2015 09:39 AM, Florian Bösch wrote:
> Here is what I wrote that client:
> 
> [...] For security reasons browsers want to disable fullscreen if you
>> are not serving the website over HTTPS.

Are you sure this is true?  Where has it been proposed to completely
disable fullscreen for non-HTTPS connections?

(I think there's a strong case for disabling *persistent* fullscreen
permission, for the reasons described in ekr's response to you here.  I
haven't seen any proposal for going beyond that, but I might've missed it.)

~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Mon, May 4, 2015 at 9:39 AM, Florian Bösch  wrote:

> On Mon, May 4, 2015 at 6:33 PM, Adam Roach  wrote:
>
> >  You have made some well-thought-out contributions to conversations at
> > Mozilla in the past. I'm a little sad that you're choosing not to
> > participate in a useful way here.
> >
>
> I think this is a pretty relevant contribution. Obviously it's not the kind
> of story you want to hear. It's also not the story I want to hear. But we
> can't pick and choose what we will get. And that's what you'll get:
>
> I have polled a client of mine which has a small web property that contains
> a WebGL widget which does include a fullscreen button.
>
> Here is what I wrote that client:
>
> I'd like to inform you that it's likely that the fullscreen button will
> > break in google chrome and firefox in the forseeable future (mid
> > 2015-2016). For security reasons browsers want to disable fullscreen if
> you
> > are not serving the website over HTTPS.
> > Starting mid 2015 a new SSL Certificate Authority will offer free
> > certificates (https://letsencrypt.org/)
> > Do you think you could host your site over HTTPS to prevent the
> fullscreen
> > button breaking? If required, I could also remove the fullscreen button.
>
>
> The clients response below:
>
> I appreciate the heads up.
> > Redesigning our site to use HTTPS is probably possible but I currently do
> > not have time and resources to undertake that task.
> > Would it be possible to let me know when you get the information that the
> > first production Chrome or Firefox is released?  At that time I can
> > certainly disable the fullscreen function myself as this is real easy to
> do
> > in your .js file.
>
>
> So yeah, again, Congrats.


This would be more useful if you explained what they considered the cost of
converting to HTTPS so, so we could discuss ways to ameliorate that cost.

With that said, fullscreen is actually a good example of a feature which
really benefits from being over HTTPS. Consider what happens if the user
grants a persistent permission to site X to use fullscreen. At that point,
any network attacker can take over the user's entire screen without their
consent by pretending to be site X. Note that this is true *even if* the
real version of site X doesn't do anything sensitive. So, I think it should
be fairly easy to understand why we want to limit access to fullscreen over
HTTP.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Coughlin, R. Shawn]

I agree HTTPS makes information safer and protects it¹s integrity, making
it (once again) safer.
However;
1) are the benefits worth the millions of man-hours, and countless dollars
this will cost?
2) why is Mozilla suddenly everyone¹s nanny?

- Shawn


On 5/1/15, 2:44 PM, "Joseph Lorenzo Hall"  wrote:

>On Fri, May 1, 2015 at 2:37 PM, Patrick McManus 
>wrote:
>> It is afterall likely stored in cleartext on each computer. This is an
>> important distinction no matter the nature of the content because
>>Firefox,
>> as the User's Agent, has a strong interest in the user seeing the
>>content
>> she asked for and protecting her confidentiality (as best as is
>>possible)
>> while doing the asking.Those are properties transport security gives
>>you.
>> Sadly, both of those fundamental properties of transport are routinely
>> broken to the user's detriment, when http:// is used.
>
>Yes, I'll add something Patrick knows very well, but just to hammer it
>home: HTTPS as transport protection isn't just about confidentiality
>but integrity of the transport.
>
>So, even if those of you out there are saying "The web doesn't have
>much private stuff! jeez!" the web sure has a lot of stuff that is
>highly dynamic with javascript and other active content. That stuff
>needs be protected in transit lest the Great Cannon or any number of
>user-hostile crap on the net start owning your UAs, even if you don't
>think the content need be private.
>
>best, Joe
>
>-- 
>Joseph Lorenzo Hall
>Chief Technologist
>Center for Democracy & Technology
>1634 I ST NW STE 1100
>Washington DC 20006-4011
>(p) 202-407-8825
>(f) 202-637-0968
>j...@cdt.org
>PGP: https://josephhall.org/gpg-key
>fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Florian Bösch]

On Mon, May 4, 2015 at 3:38 PM, Adam Roach  wrote:

>  others who want to work for a better future
>
A client of mine whom I polled if they can move to HTTPs with their server
stated they do not have the time and resources to do so. So the fullscreen
button will just stop working. That's an amazing better future right there.

You didn't get what you want (HTTPS), I didn't get what I want (a cool
feature working) and the client didn't get what he wanted (a feature
working they paid money to integrate).

Loose/Loose/Loose situations are pretty much the best kind of better future
I can think of. Congrats.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Florian Bösch]

On Mon, May 4, 2015 at 6:33 PM, Adam Roach  wrote:

>  You have made some well-thought-out contributions to conversations at
> Mozilla in the past. I'm a little sad that you're choosing not to
> participate in a useful way here.
>

I think this is a pretty relevant contribution. Obviously it's not the kind
of story you want to hear. It's also not the story I want to hear. But we
can't pick and choose what we will get. And that's what you'll get:

I have polled a client of mine which has a small web property that contains
a WebGL widget which does include a fullscreen button.

Here is what I wrote that client:

I'd like to inform you that it's likely that the fullscreen button will
> break in google chrome and firefox in the forseeable future (mid
> 2015-2016). For security reasons browsers want to disable fullscreen if you
> are not serving the website over HTTPS.
> Starting mid 2015 a new SSL Certificate Authority will offer free
> certificates (https://letsencrypt.org/)
> Do you think you could host your site over HTTPS to prevent the fullscreen
> button breaking? If required, I could also remove the fullscreen button.


The clients response below:

I appreciate the heads up.
> Redesigning our site to use HTTPS is probably possible but I currently do
> not have time and resources to undertake that task.
> Would it be possible to let me know when you get the information that the
> first production Chrome or Firefox is released?  At that time I can
> certainly disable the fullscreen function myself as this is real easy to do
> in your .js file.


So yeah, again, Congrats.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Adam Roach]

On 5/4/15 11:24, Florian Bösch wrote:
On Mon, May 4, 2015 at 3:38 PM, Adam Roach > wrote:


others who want to work for a better future

A client of mine whom I polled if they can move to HTTPs with their 
server stated they do not have the time and resources to do so. So the 
fullscreen button will just stop working. That's an amazing better 
future right there.


You have made some well-thought-out contributions to conversations at 
Mozilla in the past. I'm a little sad that you're choosing not to 
participate in a useful way here.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[scoughlin]

On Monday, May 4, 2015 at 9:40:08 AM UTC-4, Adam Roach wrote:
> On 5/2/15 05:25, Florian Bösch wrote:
> > I now mandate that you (and everyone you know) shall only do ethernet 
> > trough pigeon carriers. There are great advantages to doing this, and 
> > I can recommend a number of first rate pigeon breeders which will sell 
> > you pigeons bred for that purpose. I will not discuss with you any 
> > notion that pigeons shit onto everything and that cost might rise 
> > because pigeons are more expensive to keep than a copper line. 
> > Obviously you're a pigeon refusenik and preventer of great progress. 
> > My mandate for pigeons is binding will come into effect because I 
> > happen to have a controlling stake in all utility companies and come 
> > mid 2015 copper lines will be successively cut. Please refrain from 
> > disagreeing my mandate in vulgar terms, also I refuse any notion that 
> > using pigeons for ethernet by mandate is batshit insane (the'yre 
> > pigeons, not bats, please).
> 
> It's clear you didn't see it as such, but Nicholas was trying to do you 
> a favor.
> 
> You obviously have input you'd like to provide on the topic, and the 
> very purpose of this thread is to gather input. If you show up with 
> well-reasoned arguments in a tone that assumes good faith, there's a 
> real chance for a conversation here where people reach a common 
> understanding and potentially change certain aspects of the outcome.
> 
> If all you're willing to do is hurl vitriol from the sidelines, you're 
> not making a difference. Even if you have legitimate and 
> well-thought-out points hidden in the venom, no one is going to hear 
> them. Nicholas, like I, would clearly prefer that the time of people on 
> this mailing list be spent conversing with others who want to work for a 
> better future rather than those who simply want to be creatively 
> abusive. You get to choose which one you are.
> 
> -- 
> Adam Roach
> Principal Platform Engineer
> a...@mozilla.com
> +1 650 903 0800 x863




"Nothing goes over my head! My reflexes are too fast, I would catch it."
 -- Drax the Destroyer
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-04 8:37 AM, Henri Sivonen wrote:


I think without empirical evidence showing the *current* (as opposed
to arguments from 20 years ago) importance of shared caching on the
supposed "constrained networks"--i.e. empirical evidence showing that
the shared cache hit rate is is a make-or-break deal for actual
present-day networks where the bottleneck is between the ISP [the
location of the shared cache] and the backbone and the bottleneck
can't be fixed e.g. by lighting up more fiber--it doesn't make sense
to put effort into building complications that seek to preserve shared
caching in the encrypted future.
As I've understood it, Mozilla has some good relationships with a number 
of telcos who serve sparsely-populated and developing countries. Have we 
considered asking our existing partners for this kind of information?



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Adam Roach]

On 5/2/15 05:25, Florian Bösch wrote:
I now mandate that you (and everyone you know) shall only do ethernet 
trough pigeon carriers. There are great advantages to doing this, and 
I can recommend a number of first rate pigeon breeders which will sell 
you pigeons bred for that purpose. I will not discuss with you any 
notion that pigeons shit onto everything and that cost might rise 
because pigeons are more expensive to keep than a copper line. 
Obviously you're a pigeon refusenik and preventer of great progress. 
My mandate for pigeons is binding will come into effect because I 
happen to have a controlling stake in all utility companies and come 
mid 2015 copper lines will be successively cut. Please refrain from 
disagreeing my mandate in vulgar terms, also I refuse any notion that 
using pigeons for ethernet by mandate is batshit insane (the'yre 
pigeons, not bats, please).


It's clear you didn't see it as such, but Nicholas was trying to do you 
a favor.


You obviously have input you'd like to provide on the topic, and the 
very purpose of this thread is to gather input. If you show up with 
well-reasoned arguments in a tone that assumes good faith, there's a 
real chance for a conversation here where people reach a common 
understanding and potentially change certain aspects of the outcome.


If all you're willing to do is hurl vitriol from the sidelines, you're 
not making a difference. Even if you have legitimate and 
well-thought-out points hidden in the venom, no one is going to hear 
them. Nicholas, like I, would clearly prefer that the time of people on 
this mailing list be spent conversing with others who want to work for a 
better future rather than those who simply want to be creatively 
abusive. You get to choose which one you are.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Florian Bösch]

On Sat, May 2, 2015 at 11:57 AM, Nicholas Nethercote  wrote:

> Please refrain from further discussion until you can avoid making
> crude personal attacks such as these.
>
I now mandate that you (and everyone you know) shall only do ethernet
trough pigeon carriers. There are great advantages to doing this, and I can
recommend a number of first rate pigeon breeders which will sell you
pigeons bred for that purpose. I will not discuss with you any notion that
pigeons shit onto everything and that cost might rise because pigeons are
more expensive to keep than a copper line. Obviously you're a pigeon
refusenik and preventer of great progress. My mandate for pigeons is
binding will come into effect because I happen to have a controlling stake
in all utility companies and come mid 2015 copper lines will be
successively cut. Please refrain from disagreeing my mandate in vulgar
terms, also I refuse any notion that using pigeons for ethernet by mandate
is batshit insane (the'yre pigeons, not bats, please).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Henri Sivonen]

On Fri, May 1, 2015 at 1:25 AM, Richard Barnes  wrote:
> 3. HTTP caching is an important feature for constrained networks.

I think it important to emphasize that the affected case is shared
caching in the form of forward proxies. https doesn't prevent caching
in the browser or caching on site-chosen caching nodes (CDNs). (I know
you know this; this paragraph is for the mailing list.)

Whether shared caching in forward proxies is indeed an important
feature hasn't been properly shown in this thread.

To bring a data point to the thread, data from the network of the
University of Edinburgh (http://www.ltg.ed.ac.uk/~ht/HST_noREST.pdf ;
skip forward to PDF page 14) indicates that even without the action
proposed in this thread to deprecate insecure HTTP, the hit rate in
the university's shared cache is already rather low and getting lower.
Obviously, university networks in Europe don't count as constrained,
but this is likely a best-case scenario of cache hits, since this is a
network whose users one might imagine to have more of a common set of
interests in their use of the network (due to being part of the same
organization) than users who have no organizational commonality and
only have locational commonality.

I think without empirical evidence showing the *current* (as opposed
to arguments from 20 years ago) importance of shared caching on the
supposed "constrained networks"--i.e. empirical evidence showing that
the shared cache hit rate is is a make-or-break deal for actual
present-day networks where the bottleneck is between the ISP [the
location of the shared cache] and the backbone and the bottleneck
can't be fixed e.g. by lighting up more fiber--it doesn't make sense
to put effort into building complications that seek to preserve shared
caching in the encrypted future.

> 5. It may be productive to take some interim steps, such as placing
> limitations on cookies stored by non-HTTPS sites.

Forgetting insecure cookies when quitting Firefox is now
https://bugzilla.mozilla.org/show_bug.cgi?id=1160368

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Robert O'Callahan]

On Mon, May 4, 2015 at 10:04 PM, Gervase Markham  wrote:

> On 03/05/15 03:39, Xidorn Quan wrote:
> > This has been happening in the Internet in China. I would suggest you use
> > "360 Secure Browser", one of the major browsers in China. They completely
> > consider the experience of developers and users. Their browser allows
> user
> > to access a website even if the website provides a broken certificate :)
>
> Translation: their browser makes MITM attacks much easier.
>

I think Xidorn was being sarcastic :-)

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 01/05/15 20:40, Eric Shepherd wrote:
> In my case, the situation is that I have classic computers running 1-10
> megahertz processors, for which encrypting and decrypting SSL is not a
> plausible option.

For this edge case, I would say the solution is to use a proxy, run on
one of your other (faster) computers. As noted elsewhere, that's what
jwz did to get Netscape 1.0 (which only spoke HTTP 1.0) working again.

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 03/05/15 03:39, Xidorn Quan wrote:
> This has been happening in the Internet in China. I would suggest you use
> "360 Secure Browser", one of the major browsers in China. They completely
> consider the experience of developers and users. Their browser allows user
> to access a website even if the website provides a broken certificate :)

Translation: their browser makes MITM attacks much easier.

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 01/05/15 19:02, Matthew Phillips wrote:
> You must have missed my original email:
> It's paramount that the web remain a frictionless place where creating a
> website is dead simple. 

That is not true today of people who want to run their own hosting. So
people who want "frictionless" use blogspot.com, or one of the thousands
of equivalent sites in many different jurisdictions, to say what they
want to say.

In an HTTPS future, such sites would simply provide HTTPS for their users.

Gerv


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Richard Barnes wrote:
Nobody right in the head is going to be plugging an antique with a 
1mhz processor directly into an unfiltered, internet-facing network 
connection, but I guess people who aren't right in the head like that 
are still people whose concerns deserve consideration. 
The SE/30 was 16 MHz, but it was also 32-bit, which makes a lot of 
difference as compared to an 8 or 16 bit machine when trying to do 
modern crypto. And I promise not to talk about retro gadgets anymore, 
since this is way off topic.


FWIW, I concede that I'm among those that misinterpreted the original 
email on this. That it's still going to be possible to do basic things 
is good to know.


I admit I'm a mite sensitive about the issue, because our little 
community of retro hackers has been working for a very long time (over 
twenty years now!) on bringing up TCP/IP stacks, getting newer and 
better network adapters designed and built, drivers written and 
optimized, etc. We finally get to the point where cool stuff is starting 
to really be feasible and this comes along. It was a little like driving 
your sled dog team through the worst blizzard in history to be the first 
person to the North Pole only to have someone steal your sled just 
before you get there. :)


--

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[mofforg]

воскресенье, 3 мая 2015 г., 6:06:08 UTC+3 пользователь Xidorn Quan написал:
> I don't think anyone will ever completely drop support of HTTP. What we
> probably will do, at very most, is to treat HTTP websites just like the
> websites provide a broken certificate.
> 
> - Xidorn
It's the same as drop because regular people will aware, then know the 
difference https/http and switch to https by force just to not see ing 
warning.

HTTP was not made to be encrypted and showing warnings in it is stipid.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Xidorn Quan]

On Sun, May 3, 2015 at 2:46 PM,  wrote:

> воскресенье, 3 мая 2015 г., 5:39:55 UTC+3 пользователь Xidorn Quan написал:
> > This has been happening in the Internet in China. I would suggest you use
> > "360 Secure Browser", one of the major browsers in China. They completely
> > consider the experience of developers and users. Their browser allows
> user
> > to access a website even if the website provides a broken certificate :)
>
> In usual situation, "allows user to access a website even if the website
> providers a broken certificate" is OK. The truth is, that usually that
> happens by mistake of webmaster, not when someone tries to hack you.
> However what Chrome & Firefox do is better i think, give user a choice.
>
> Basically, to shorte my message - If Mozilla will deprecate HTTP, we will
> deprecate Mozilla.
>

I don't think anyone will ever completely drop support of HTTP. What we
probably will do, at very most, is to treat HTTP websites just like the
websites provide a broken certificate.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[mofforg]

воскресенье, 3 мая 2015 г., 5:39:55 UTC+3 пользователь Xidorn Quan написал:
> This has been happening in the Internet in China. I would suggest you use
> "360 Secure Browser", one of the major browsers in China. They completely
> consider the experience of developers and users. Their browser allows user
> to access a website even if the website provides a broken certificate :)
> 
> - Xidorn

In usual situation, "allows user to access a website even if the website 
providers a broken certificate" is OK. The truth is, that usually that happens 
by mistake of webmaster, not when someone tries to hack you. However what 
Chrome & Firefox do is better i think, give user a choice.

Basically, to shorte my message - If Mozilla will deprecate HTTP, we will 
deprecate Mozilla.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Xidorn Quan]

On Sun, May 3, 2015 at 1:51 PM,  wrote:

> My vote would be never use your browser if you will deprecate HTTP. That's
> very easy to find an alternative or to fork you code, so think yourself how
> much such decision can cost you. This phrase i want also to said to Chrome
> dev team. Internet is live on developers. If you will start to do shit
> things, you will be replaced.
>

This has been happening in the Internet in China. I would suggest you use
"360 Secure Browser", one of the major browsers in China. They completely
consider the experience of developers and users. Their browser allows user
to access a website even if the website provides a broken certificate :)

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[mofforg]

You should never force HTTPS.

The win's are rather subjective and hard to confirm.

But using HTTPS give problems for regular webmaster.

Website will be slower on average. Webmaster need better hardware or pay more 
to his hosting provider.
HTTPS support is not always possible. For example some CDN's can't support 
HTTPS in some specific modes.
Third-party resources linked in HTML can miss HTTPS support and it will cause 
website work incorrectly in HTTPS. And you need to monitor this forever... for 
all links on website! This point is valid for a huge % of websites.
By enabling HTTPS-only you can easily lose 20% of visitors. Not all browsers 
support your certificate.
HTTPS libraries vulnerability can lead to website's origin server hack. The 
problem here, is that libraries are just like code executed directly on server. 
If there are vulnerability, you can not only decrypt the traffic, but also 
execute code on the server.
Certificates are just bunches with problems.. revocation, revalidation, 
libraries deprecation. And it worth mentioning, that certificate system makes 
web centralized. When someone visit your HTTPS website it basically query some 
other central server. If someone will have this server, he can get information 
about all your visitors. And that's shocky, i think.

I am not against of encryption, but do not FORCE. HTTP is not LEGACY, it's 
HTTP, the protocol which should be here forever. It's good, fast, and well 
enough. That's really tricky question does HTTPS securer than HTTP. Encryption 
helps sometimes to prevent injections, but it's rather easy to bypass that. Can 
NSA decrypt your HTTPS? Most probably yes. Can webmater of website spy on you 
in HTTPS? Yes and it's even easier with HTTPS and HSTS because of HSTS super 
cookie. Does HTTPS protect your password? Well, there are a chance, but if you 
think that HTTPS is a magic cure, you are complete idiot.

My vote would be never use your browser if you will deprecate HTTP. That's very 
easy to find an alternative or to fork you code, so think yourself how much 
such decision can cost you. This phrase i want also to said to Chrome dev team. 
Internet is live on developers. If you will start to do shit things, you will 
be replaced.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[imfasterthanneutrino]

On Friday, May 1, 2015 at 3:06:18 PM UTC-4, Richard Barnes wrote:
> On Thu, Apr 30, 2015 at 9:50 PM,  wrote:
> 
> > > 1.Setting a date after which all new features will be available only to
> > secure websites
> >
> > I propose the date to be one year after Let's Encrypt is launched, which
> > is about mid-2016.
> >
> 
> I was hoping for something a little sooner, given that we're talking about
> *future* stuff.  But I'm open to discuss.

Fully agree! After reconsidering, now I think mid-2016 is too conservative. 
Since the first step is only about limiting new features, no websites will be 
broken due to this change. Developers and users don't *have to* do anything 
before that date. And we don't have to cooperate with other browsers in 
choosing this date, since different browsers already implement different set of 
features today. So how about starting with Firefox 41, which will be released 
on September 22, 2015?

Actually, it's better to enter phase 1 as soon as possible. People generally 
don't complain too much if a feature is not supported from the beginning, but 
do complain if the feature is dropped after it is widely used.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Nicholas Nethercote]

On Sat, May 2, 2015 at 2:20 AM,   wrote:
>
> In summary, you're batshit insane, power hungry, and mad, and you're using 
> double speek at its finest.

Please refrain from further discussion until you can avoid making
crude personal attacks such as these.

Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[oliver]

When plans like this aren't rolled out across all browsers together, users 
inevitably come across a broken site and say "Firefox works with this site, but 
Safari gives a warning.  Safari must be broken".  Better security is punished.

Having this determined by a browser release is also bad.   "My up to date 
Firefox is broken, but my old Safari works.  Updating breaks things and must be 
bad!".  Secure practices are punished.

All browsers could change their behaviour on a specific date and time.   But 
that would lead to stampedes of webmasters having issues all at once.  And if 
theres any unforeseen compatibility issue, you just broke the entire world.  
Not so great.

So might I suggest the best rollout plan is to apply policies based on a hash 
of the origin and a timestamp.   Ie. on a specific date, 1% of sites have the 
new policies enforced, while 99% do not.  Then a month later, it's up to 51%, 
and another month later it's up to 100%.

Web masters can now see the date and time policies will be enforced for their 
site, and there is no risk of breaking the entire internet on the same day.

Developer builds could apply the policies a few weeks early to give a heads up.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-01 3:40 PM, Eric Shepherd wrote:
In my case, the situation is that I have classic computers running 
1-10 megahertz processors, for which encrypting and decrypting SSL is 
not a plausible option. These computers have a burgeoning "retro" 
fanbase trying to push them to do new and interesting things, and a 
lot of that involves writing software that works over the Web using 
standard protocols. These efforts cannot be sustained in an HTTPS-only 
world. 


Nobody right in the head is going to be plugging an antique with a 1mhz 
processor directly into an unfiltered, internet-facing network 
connection, but I guess people who aren't right in the head like that 
are still people whose concerns deserve consideration.


Hobbyists in that situation will certainly be able to - and someday 
need, but for now "deprecate" isn't "disable" and it's just "be able to" 
- put RasPi and an ethernet dongle between their 1mhz steam-powered 
contraptions and the rest of modernity with an http->https proxy on it, 
and everything will continue to work for them. As well as it did before, 
at least.


It's pretty easy - though I concede not free - to stand up proxies for 
those rare cases that absolutely cannot deliver encrypted connections. 
That those cases exist should not weigh heavily in this discussion, in 
my opinion.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

On Fri, May 1, 2015 at 11:30 AM, Martin Thomson  wrote:

> On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann 
> wrote:
> > Is there a wiki page or some other comprehensive reference that defines
> the
> > issues and arguments around  this central question?
>
> Richard was - I think - in the process of assembling an FAQ that
> covered this and other issues.  This is definitely FAQ territory.
>

Yup, working on it.  Hopefully have a first draft up today.

--Richard


>
> Joe also provided this link up-thread:
>
> https://cdt.org/files/2015/02/CDT-comments-on-the-use-of-encryption-and-anonymity-in-digital-communcations.pdf
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd 
wrote:

> Martin Thomson wrote:
>
>> There are two aspects to this: the software, and the content.
>>
>> If software cannot be updated, that a problem in its own right.  The
>> idea that you could release your server onto the Internet to fend for
>> itself for 20 years was a dream of the 90s that has taken a while to
>> die.  Just as you have to feed it electricity and packets, you have to
>> maintain software too.
>>
> In my case, the situation is that I have classic computers running 1-10
> megahertz processors, for which encrypting and decrypting SSL is not a
> plausible option.


Have you tried?  I have distinct memories of running Netscape Navigator on
an SE/30, which according to wikipedia had a 16MHz processor.  It seems
like without having to run the UI, you could run an HTTPS server that did
OK.

--Richard


> These computers have a burgeoning "retro" fanbase trying to push them to
> do new and interesting things, and a lot of that involves writing software
> that works over the Web using standard protocols. These efforts cannot be
> sustained in an HTTPS-only world.
>
> This has personal meaning to me as a long-time member of the
> retrocomputing community, and as the author of software that runs on these
> machines, including multiple programs that use HTTP to do so. If things
> start requiring HTTPS, our ability to continue to innovate and try to push
> these machines to do more and more things previously unheard of starts to
> come to an end. I don't like that notion very much.
>
> Is it a niche case? Sure. But it's not one to be dismissed outright
> without at least having its voice heard, so here I am, representing our
> little crowd.
>
> I'm not trying to stir up trouble or be a pain in the ass. Just pointing
> out that there honestly, truly are valid use cases for straight-up HTTP,
> even if they're rare.
>
> (FWIW, I concede that the "not everything needs encryption" position is a
> little overstated, but I also think that there really is stuff that doesn't
> need encrypting, even if it's a tiny fraction of the Web's traffic).
>
> --
>
> Eric Shepherd
> Senior Technical Writer
> Mozilla 
> Blog: http://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

Martin Thomson wrote:

There are two aspects to this: the software, and the content.

If software cannot be updated, that a problem in its own right.  The
idea that you could release your server onto the Internet to fend for
itself for 20 years was a dream of the 90s that has taken a while to
die.  Just as you have to feed it electricity and packets, you have to
maintain software too.
In my case, the situation is that I have classic computers running 1-10 
megahertz processors, for which encrypting and decrypting SSL is not a 
plausible option. These computers have a burgeoning "retro" fanbase 
trying to push them to do new and interesting things, and a lot of that 
involves writing software that works over the Web using standard 
protocols. These efforts cannot be sustained in an HTTPS-only world.


This has personal meaning to me as a long-time member of the 
retrocomputing community, and as the author of software that runs on 
these machines, including multiple programs that use HTTP to do so. If 
things start requiring HTTPS, our ability to continue to innovate and 
try to push these machines to do more and more things previously unheard 
of starts to come to an end. I don't like that notion very much.


Is it a niche case? Sure. But it's not one to be dismissed outright 
without at least having its voice heard, so here I am, representing our 
little crowd.


I'm not trying to stir up trouble or be a pain in the ass. Just pointing 
out that there honestly, truly are valid use cases for straight-up HTTP, 
even if they're rare.


(FWIW, I concede that the "not everything needs encryption" position is 
a little overstated, but I also think that there really is stuff that 
doesn't need encrypting, even if it's a tiny fraction of the Web's traffic).


--

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

On Fri, May 1, 2015 at 10:13 AM,  wrote:

> Here we go again. Listen up, guys. There are vast numbers of legacy sites
> without the technical or financial means to convert to https:,


Of course I agree that we should not be brushing aside the little guys.
But from where I sit, I'm seeing lots of evidence that deploying HTTPS is
getting a lot easier (Universal SSL, Mozilla TLS Config generator, etc.),
and no actual owners of small sites saying that they have seriously looked
at deploying HTTPS and found that they could not.  Do you know any that you
could get to chime in here?


> nor are many serving material that fundamentally needs to be encrypted.


Please keep in mind that "needs to be encrypted" is a very tough question
to get right.  Who would have thought that Baidu's analytics JS needed to
be encrypted until Github got DDoS'ed?  Who would have thought that you
needed to encrypt your ads until Comcast started replacing them?

A big part of the motivation for having HTTPS be the default is that
historically we have gotten decisions about what needs to be encrypted
wrong over and over again.  Using HTTPS by default avoids having to take
the risk of getting it wrong.

--Richard



> While I've long been a proponent of opportunistic crypto -- particularly
> by leveraging self-signed certs which I know you all despise with a
> vengeance -- moves to turn http: sites generally into pariahs is a display
> of technological arrogance par excellence, *unless* you intend to also
> provide funding and personnel to handle the conversions for legacy sites
> that do not have the financial or time resources to make the necessary
> initial and ongoing changes for themselves. There is crypto-reality and
> crypto-religion. And what I mostly see here is the latter, with concern for
> the little guys brushed under the carpet as usual. For shame.
>





>
> --Lauren--
> Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren
> Founder:
>  - Network Neutrality Squad: http://www.nnsquad.org
>  - PRIVACY Forum: http://www.vortex.com/privacy-info
> Co-Founder: People For Internet Responsibility:
> http://www.pfir.org/pfir-info
> Member: ACM Committee on Computers and Public Policy
> Lauren's Blog: http://lauren.vortex.com
> Google+: http://google.com/+LaurenWeinstein
> Twitter: http://twitter.com/laurenweinstein
> Tel: +1 (818) 225-2800 / Skype: vortex.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[scoughlin]

Whoopie... I can jump through hoops and make TLS fast.  Why should I have to?  
The user should be the decision maker. If they want to visit an unsecured HTTP 
site of cat videos... let them. IF a hacker wants to edit those cat videos 
while in transit... LET THEM.  Why strong-arm everyone into using HTTPS when it 
is not necessary?  This is an immensely expensive (man-hours) solution to a 
non-problem.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

On Thu, Apr 30, 2015 at 9:50 PM,  wrote:

> > 1.Setting a date after which all new features will be available only to
> secure websites
>
> I propose the date to be one year after Let's Encrypt is launched, which
> is about mid-2016.
>

I was hoping for something a little sooner, given that we're talking about
*future* stuff.  But I'm open to discuss.



> By the way, I hope Mozilla's own official website (Mozilla.org) should
> move to HTTPS-only as soon as possible. Currently www.mozilla.org forces
> HTTPS, but many mozilla.org subdomains do not, such as
> http://people.mozilla.org/, http://release.mozilla.org/, and
> http://website-archive.mozilla.org. It will be great if *.Mozilla.org can
> be added to browsers' built-in HSTS list.
>

100% agree.  There's already a bunch of Mozilla domains on the HSTS preload
list, but they should all be there.

--Richard

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-01 2:06 PM, Eric Shepherd wrote:
There are a lot of things that don't need encryption, and sites that 
serve legacy purposes and/or audiences, and cannot be updated to https 
in the first place.


Encryption is not about protecting data. Encryption is about protecting 
people.




- mhoye


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[hrzindler]

Honestly, this is a terrible idea. The whole point of a browser is providing 
user access - this would take power away from users by deciding for them what 
is permissible. It also fails to account for the bulk of web traffic which does 
not require encryption (and is the reason HTTP exists in the first place).
Traditionally developers have been the ones to decide what traffic merits 
encryption and what does not. An argument could be made that the decision 
should not rest solely with them, but also with users (who are stakeholders); 
however, browsers certainly should not be involved in deciding whether a site 
is accessed.

If there are security concerns, then inform the user but do not make a blanket 
decision that would make unencrypted cat pictures inaccessible.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Joseph Lorenzo Hall]

On Fri, May 1, 2015 at 2:37 PM, Patrick McManus  wrote:
> It is afterall likely stored in cleartext on each computer. This is an
> important distinction no matter the nature of the content because  Firefox,
> as the User's Agent, has a strong interest in the user seeing the content
> she asked for and protecting her confidentiality (as best as is possible)
> while doing the asking.Those are properties transport security gives you.
> Sadly, both of those fundamental properties of transport are routinely
> broken to the user's detriment, when http:// is used.

Yes, I'll add something Patrick knows very well, but just to hammer it
home: HTTPS as transport protection isn't just about confidentiality
but integrity of the transport.

So, even if those of you out there are saying "The web doesn't have
much private stuff! jeez!" the web sure has a lot of stuff that is
highly dynamic with javascript and other active content. That stuff
needs be protected in transit lest the Great Cannon or any number of
user-hostile crap on the net start owning your UAs, even if you don't
think the content need be private.

best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
j...@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Patrick McManus]

On Fri, May 1, 2015 at 2:07 PM,  wrote:

> Why encrypt (and slow down) EVERYTHING


I think this is largely outdated thinking. You can do TLS fast, and with
low overhead. Even on the biggest and most latency sensitive sites in the
world. https://istlsfastyet.com


> when most web content isn't worth encrypting?


Fundamentally HTTPS protects the transport of the content - not the secrecy
of the content itself.

It is afterall likely stored in cleartext on each computer. This is an
important distinction no matter the nature of the content because  Firefox,
as the User's Agent, has a strong interest in the user seeing the content
she asked for and protecting her confidentiality (as best as is possible)
while doing the asking.Those are properties transport security gives you.
Sadly, both of those fundamental properties of transport are routinely
broken to the user's detriment, when http:// is used.

As Martin and Richard have noted, we have a strong approach with HSTS for
the migration of legacy markup onto https as long as the server is
appropriately provisioned - and doing that is much more feasible now than
it used to be. So sites that are deploying new features can make the
transition with a minimum of fuss.

For truly untouched and embedded legacy services I agree this is a harder
problem and compatibility needs to be considered a managed risk.

-P
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Martin Thomson]

On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann  wrote:
> Is there a wiki page or some other comprehensive reference that defines the
> issues and arguments around  this central question?

Richard was - I think - in the process of assembling an FAQ that
covered this and other issues.  This is definitely FAQ territory.

Joe also provided this link up-thread:
https://cdt.org/files/2015/02/CDT-comments-on-the-use-of-encryption-and-anonymity-in-digital-communcations.pdf
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Joseph Lorenzo Hall]

+freaking1

On Fri, May 1, 2015 at 2:16 PM, Martin Thomson  wrote:
> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd  wrote:
>> There are a lot of things that don't need encryption,
>
> This assertion is made quite often in this context. It's been shown to
> be false in every example I've seen.  I think Richard provided several
> citations where this was believed to be correct, to the detriment of
> us all (great cannon being a prime example).
>
>> and sites that serve
>> legacy purposes and/or audiences, and cannot be updated to https in the
>> first place.
>
> There are two aspects to this: the software, and the content.
>
> If software cannot be updated, that a problem in its own right.  The
> idea that you could release your server onto the Internet to fend for
> itself for 20 years was a dream of the 90s that has taken a while to
> die.  Just as you have to feed it electricity and packets, you have to
> maintain software too.
>
> The content issue is a serious one, but there are several answers that
> could fit (HSTS, upgrade-insecure, and maybe opportunistic security).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform



-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
j...@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Chris Hofmann]

On Fri, May 1, 2015 at 11:16 AM, Martin Thomson  wrote:

> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd 
> wrote:
> > There are a lot of things that don't need encryption,
>
> This assertion is made quite often in this context. It's been shown to
> be false in every example I've seen.  I think Richard provided several
> citations where this was believed to be correct, to the detriment of
> us all (great cannon being a prime example).
>

Is there a wiki page or some other comprehensive reference that defines the
issues and arguments around  this central question?

That seems like it would be good reading, and is key to developing
widespread understanding and support if this is going to move forward.

-chofmann
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Martin Thomson]

On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd  wrote:
> There are a lot of things that don't need encryption,

This assertion is made quite often in this context. It's been shown to
be false in every example I've seen.  I think Richard provided several
citations where this was believed to be correct, to the detriment of
us all (great cannon being a prime example).

> and sites that serve
> legacy purposes and/or audiences, and cannot be updated to https in the
> first place.

There are two aspects to this: the software, and the content.

If software cannot be updated, that a problem in its own right.  The
idea that you could release your server onto the Internet to fend for
itself for 20 years was a dream of the 90s that has taken a while to
die.  Just as you have to feed it electricity and packets, you have to
maintain software too.

The content issue is a serious one, but there are several answers that
could fit (HSTS, upgrade-insecure, and maybe opportunistic security).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[scoughlin]

Why encrypt (and slow down) EVERYTHING, when most web content isn't worth 
encrypting? I just don't see the point.  This is the dumbest thing I've heard 
in a long while. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Shepherd]

lauren4...@gmail.com wrote:

There are vast numbers of legacy sites without the technical or financial means 
to convert to https:, nor are many serving material that fundamentally needs to 
be encrypted.
While the tone of the rest of this message was a little harsh, I agree 
with this. There are a lot of things that don't need encryption, and 
sites that serve legacy purposes and/or audiences, and cannot be updated 
to https in the first place.


--

Eric Shepherd
Senior Technical Writer
Mozilla 
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Matthew Phillips]

You must have missed my original email:

>I understand that there are proposed solutions to these problems but
>they don't exist today and won't be ubiquitous for a while.

Let's let these solutions prove themselves out first.

There are no free wildcard cert vendors and, at least in my experience,
what you do get is a heavy upsell and/or slow delivery of certificates.
If this is your standard for good-enough I'm really fearful for the
future of the web.

It's paramount that the web remain a frictionless place where creating a
website is dead simple. This is infinitely more important than making
people feel safe knowing that http doesn't exist any more. My fear is
that the pendulum has swung away from this (previously self-evident)
position and the people running the web today have other priorities.

On Fri, May 1, 2015, at 01:03 PM, Adam Roach wrote:
> On 5/1/15 05:03, Matthew Phillips
  wrote:
>> All mandatory https will do is discourage people from
>> participating in
speech unless they can afford the very high costs (both in dollars and
in time) that you are now suggesting be required.
>
>
Let's be clear about the costs and effort involved.
>
>
There are already several deployed CAs that issue certs for free.
And within a couple of months, it will take users two simple
commands, zero fiscal cost, and several tens of seconds to obtain
and activate a cert:
>
> https://letsencrypt.org/howitworks/
>
>
There is great opportunity for you to update your knowledge about
how the the world of CAs has changed in the past decade. Seize it.
>
> --
> Adam Roach Principal Platform Engineer a...@mozilla.com +1 650 903
> 0800 x863

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-01 1:13 PM, lauren4...@gmail.com wrote:

Here we go again. Listen up, guys.

That's not going to be a winning approach here.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[pyalot]

On Friday, May 1, 2015 at 7:03:32 PM UTC+2, Adam Roach wrote:
> On 5/1/15 05:03, Matthew Phillips wrote:
> > All mandatory https will do is discourage people from participating in
> > speech unless they can afford the very high costs (both in dollars and
> > in time) that you are now suggesting be required.
> 
> Let's be clear about the costs and effort involved.
> 
> There are already several deployed CAs that issue certs for free. And 
> within a couple of months, it will take users two simple commands, zero 
> fiscal cost, and several tens of seconds to obtain and activate a cert:
> 
> https://letsencrypt.org/howitworks/
> 
> There is great opportunity for you to update your knowledge about how 
> the the world of CAs has changed in the past decade. Seize it.

That's not how it works. That's how you and letsencrypt imagine it'll work. In 
reality, it's anybodies guess if that's even feasible (I don't think so, but I 
digress).

Let's even assume that every shared host, CDN, etc. can use this (which they 
can't, because custom deployments, whatever), do you think the long-established 
SSL cert racket syndicate is going to take this lying down? Ok, so let's assume 
all the other pricey CAs are ok with this, magically, and aren't gonna torpedo 
truly free CAs with any lobbying dollar they can muster. What happens in the 
glorious future where the letsencrypt CA has attracted say, 90% of all certs 
(because, duh, free), and then they get PWNed? Ooops.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[lauren4321]

Here we go again. Listen up, guys. There are vast numbers of legacy sites 
without the technical or financial means to convert to https:, nor are many 
serving material that fundamentally needs to be encrypted. While I've long been 
a proponent of opportunistic crypto -- particularly by leveraging self-signed 
certs which I know you all despise with a vengeance -- moves to turn http: 
sites generally into pariahs is a display of technological arrogance par 
excellence, *unless* you intend to also provide funding and personnel to handle 
the conversions for legacy sites that do not have the financial or time 
resources to make the necessary initial and ongoing changes for themselves. 
There is crypto-reality and crypto-religion. And what I mostly see here is the 
latter, with concern for the little guys brushed under the carpet as usual. For 
shame.  

--Lauren--
Lauren Weinstein (lau...@vortex.com): http://www.vortex.com/lauren
Founder:
 - Network Neutrality Squad: http://www.nnsquad.org
 - PRIVACY Forum: http://www.vortex.com/privacy-info
Co-Founder: People For Internet Responsibility: http://www.pfir.org/pfir-info
Member: ACM Committee on Computers and Public Policy
Lauren's Blog: http://lauren.vortex.com
Google+: http://google.com/+LaurenWeinstein
Twitter: http://twitter.com/laurenweinstein
Tel: +1 (818) 225-2800 / Skype: vortex.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Adam Roach]

On 5/1/15 05:03, Matthew Phillips wrote:

All mandatory https will do is discourage people from participating in
speech unless they can afford the very high costs (both in dollars and
in time) that you are now suggesting be required.


Let's be clear about the costs and effort involved.

There are already several deployed CAs that issue certs for free. And 
within a couple of months, it will take users two simple commands, zero 
fiscal cost, and several tens of seconds to obtain and activate a cert:


https://letsencrypt.org/howitworks/

There is great opportunity for you to update your knowledge about how 
the the world of CAs has changed in the past decade. Seize it.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Adam Roach]

On 5/1/15 02:54, 王小康 wrote:

P.S.:And finally, accept Cacert or a easy to use CA.


CAs can only be included at their own request. As it stands, CACert has 
withdrawn its request to be included in Firefox until they have 
completed an audit with satisfactory results. If you want CACert to be 
included, contact them and ask what you can do to help.


In the meanwhile, as has been brought up many times in this thread 
already, there are already deployed or soon-to-be-deployed "easy to use 
CAs" in the world.


--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[pyalot]

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
There is no such agreement, and even if there was, that doesn't mean you get to 
force people to agree.
 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
You're using the wrong word here, what you're proposing is a coercion scheme.

> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
No, it just tells the world that you're a paid shill for the SSL cert racket.

This idea of yours is bad. it's bad for the reasons very articulately outlined 
in this blog entry: 
http://cryto.net/~joepie91/blog/2015/05/01/on-mozillas-forced-ssl/

the TL;DR of it is this:

- TLS is broken because of the CA structure, which allows any CA to sign a 
certificate for any website.
- SSL certificates are a racket, I think this shouldn't require explanation 
really.
- "Free" SSL certificate providers don't exist (startcom is also a racket)
- "Let's encrypt it" doesn't solve the variety of usecases (and it's setup 
scheme is also batshit insane)

I would personally like to add a few more to the list:

- The freedom of speech should not require you to buy into an expensive racket
- SSL still has a non zero speed impact, which is a problem in some scenarios.
- Edge-routing/CDN etc. is a very useful technique that's currently practically 
free to do, and allows scrummy startups to build awesome services. TLS 
virtually kills all of that.
- Not everything is even encryptable, really not. For instance UDP packets 
carrying game-player positions aren't, because they arrive out of order.
- There's an enormous amount of legacy content on the web you will *never* get 
to move to TLS, you want to throw that all away too?
- Implementing and using small, dedicated, quirky HTTP servers for the variety 
of usecases there are is a very productive activity. Mandating/coercing TLS 
makes all those existing deployments impossible, and it also makes it 
impossible in the first place to have them at all.

In summary, you're batshit insane, power hungry, and mad, and you're using 
double speek at its finest.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-05-01 8:03 AM, Matthew Phillips wrote:

Of course you know this is not true. There have been many petabytes of
free speech floating around on the internet for the last 2 decades,
despite not having mandatory https.
There are some philosophical discussions to be had here around "freedom 
from" and "freedom to", maybe. As one example, for a long time there 
weren't rules about what side of the road you drive on. It just wasn't 
necessary. Over time that changed, obviously, and the rules of the road 
we have now make driving much safer, and that safety facilitates more 
real freedom for everyone than having no rules would.


The risks and realities of the modern web are very different than they 
were 20 years go, and it's reasonable - and should be expected, IMO - 
that the web's rules of the road should have to grow and adapt as well.


For what it's worth, I think you're making a leap to "mandatory" here 
that is not supported by the proposal, but you do have a good point 
about the cost of participating in speech that's worth digging into, so 
here's a question:


If you run an ASP.NET site straight out of VS, you get HTTP-only, and 
lots of developers do this. Same thing AFAIK with pretty much all the 
serve-what-I-have-up-now tools on Linux, python, node, whatever. Do we 
have a clear sense of the impact this has on developers, and how to 
address that?


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Matthew Phillips]

Of course you know this is not true. There have been many petabytes of
free speech floating around on the internet for the last 2 decades,
despite not having mandatory https. 

All mandatory https will do is discourage people from participating in
speech unless they can afford the very high costs (both in dollars and
in time) that you are now suggesting be required.  Or worse, handing
over their speech to a big company (like the ones many people in this
discussion work for) instead of hosting it themselves.

This is the antithesis of what the web has always, and should, be.

On Fri, May 1, 2015, at 07:53 AM, Joseph Lorenzo Hall wrote:
> On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips 
> wrote:
> > I understand that there are proposed solutions to these problems but they 
> > don't exist today and won't be ubiquitous for a while.  That *has* to come 
> > first. Nothing is more important than the free speech the web allows. Not 
> > even security.
> 
> This is a false choice... you cannot have free speech without safe
> spaces. Many, many have written about this, e.g.,
> https://cdt.org/files/2015/02/CDT-comments-on-the-use-of-encryption-and-anonymity-in-digital-communcations.pdf
> 
> -- 
> Joseph Lorenzo Hall
> Chief Technologist
> Center for Democracy & Technology
> 1634 I ST NW STE 1100
> Washington DC 20006-4011
> (p) 202-407-8825
> (f) 202-637-0968
> j...@cdt.org
> PGP: https://josephhall.org/gpg-key
> fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Joseph Lorenzo Hall]

On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips  wrote:
> I understand that there are proposed solutions to these problems but they 
> don't exist today and won't be ubiquitous for a while.  That *has* to come 
> first. Nothing is more important than the free speech the web allows. Not 
> even security.

This is a false choice... you cannot have free speech without safe
spaces. Many, many have written about this, e.g.,
https://cdt.org/files/2015/02/CDT-comments-on-the-use-of-encryption-and-anonymity-in-digital-communcations.pdf

-- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
j...@cdt.org
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[王小康]

restriction might be:
unless website is severing from local network,
1. you can't use a password input(treat it equal to normal text input).
2. you can't set cookie.
3. javascript is disabled.

A header is provided to prevent a content from https being load to a http page.
(maybe work like same-origin.) 

Insecure content never load to a secure page.(unless you open advanced 
configure)

P.S.:And finally, accept Cacert or a easy to use CA.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Eric Rescorla]

On Thu, Apr 30, 2015 at 5:57 PM,  wrote:

> Here's two relevant Bugzilla bugs:
>
> Self-signed certificates are treated as errors:
> https://bugzilla.mozilla.org/show_bug.cgi?id=431386
>
> Switch generic icon to negative feedback for non-https sites:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1041087
>
> Here's a proposed way of phasing this plan in over time:
>
> 1. Mid-2015: Start treating self signed certificates as unencrypted
> connections (i.e. stop showing a warning, but the UI would just show the
> globe icon, not the lock icon). This would allow website owners to choose
> to block passive surveillance without causing any cost to them or any
> problems for their users.
>

I think you're over-focusing on the lock icon and not thinking enough about
the referential semantics.

The point of the https: URI is that it tells the browser that this is
supposed to be a secure connection and the browser needs to enforce
this regardless of the UI it shows.

To give a concrete example, say the user enters his password in a form that
is intended to be submitted over HTTPS and the site presents a self-signed
certificate. If the browser send the password, then it has possible
compromised the user's password even if it subsequently doesn't show the
secure UI (because the attacker could supply a self-signed certificate).

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[imfasterthanneutrino]

> 1.Setting a date after which all new features will be available only to 
> secure websites

I propose the date to be one year after Let's Encrypt is launched, which is 
about mid-2016. 

By the way, I hope Mozilla's own official website (Mozilla.org) should move to 
HTTPS-only as soon as possible. Currently www.mozilla.org forces HTTPS, but 
many mozilla.org subdomains do not, such as http://people.mozilla.org/, 
http://release.mozilla.org/, and http://website-archive.mozilla.org. It will be 
great if *.Mozilla.org can be added to browsers' built-in HSTS list.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Matthew Phillips]

I think this is a grave mistake.

The simplicity of the web was the primary factor in its explosive growth. By 
putting up barriers to entry you are discouraging experimentation, discouraging 
one-off projects, and discouraging leaving inactive websites running (as 
keeping certs up to date will be a yearly burden).

I understand that there are proposed solutions to these problems but they don't 
exist today and won't be ubiquitous for a while.  That *has* to come first. 
Nothing is more important than the free speech the web allows. Not even 
security.

That the leading minds of the web no longer value this makes me feel like an 
old fogey, an incredibly sad one.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[peter . eckersley]

On Thursday, April 30, 2015 at 6:02:44 PM UTC-7, peter.e...@gmail.com wrote:
> On Thursday, April 30, 2015 at 5:57:13 PM UTC-7, dia...@gmail.com wrote:
> 
> > 1. Mid-2015: Start treating self signed certificates as unencrypted 
> > connections (i.e. stop showing a warning, but the UI would just show the 
> > globe icon, not the lock icon). This would allow website owners to choose 
> > to block passive surveillance without causing any cost to them or any 
> > problems for their users.
> 
> In Mid-2015 we will be launching Let's Encrypt to issue free certificates 
> using automated protocols, so we shouldn't need to do this.

The thing that may actually be implemented, which is similar to what you want, 
is the HTTP opportunistic encryption feature of HTTP/2.0.  That's strictly 
better than unencrypted HTTP (since it is safe against passive attacks) and 
strictly worse than authenticated HTTPS (because it fails instantly against 
active attacks).  So if clients implement it, it has a natural ordinal position 
in the UI and feature-access hierarchy.

If the Let's Encrypt launch goes as planned, it would probably be a mistake to 
encourage sites to use unauthenticated opportunistic HTTP encryption.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[peter . eckersley]

On Thursday, April 30, 2015 at 5:57:13 PM UTC-7, dia...@gmail.com wrote:

> 1. Mid-2015: Start treating self signed certificates as unencrypted 
> connections (i.e. stop showing a warning, but the UI would just show the 
> globe icon, not the lock icon). This would allow website owners to choose to 
> block passive surveillance without causing any cost to them or any problems 
> for their users.

In Mid-2015 we will be launching Let's Encrypt to issue free certificates using 
automated protocols, so we shouldn't need to do this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[diafygi]

Here's two relevant Bugzilla bugs:

Self-signed certificates are treated as errors: 
https://bugzilla.mozilla.org/show_bug.cgi?id=431386

Switch generic icon to negative feedback for non-https sites: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1041087

Here's a proposed way of phasing this plan in over time:

1. Mid-2015: Start treating self signed certificates as unencrypted connections 
(i.e. stop showing a warning, but the UI would just show the globe icon, not 
the lock icon). This would allow website owners to choose to block passive 
surveillance without causing any cost to them or any problems for their users.

2. Late-2015: Switch the globe icon for http sites to a gray unlocked lock. The 
self signed certs would still be the globe icon. The would incentivize website 
owners to at least start blocking passive surveillance if they want to keep the 
same user experience as previous. Also, this new icon wouldn't be loud or 
intrusive to the user.

3. Late-2016: Change the unlocked icon for http sites to a yellow icon. 
Hopefully, by the end of 2016, Let's Encrypt has taken off and has a lot of 
frameworks like wordpress including tutorials on how to use it. This increased 
uptake of free authenticated https, plus the ability to still use self-signed 
certs for unauthenticated https (remember, this still blocks passive 
adversaries), would allow website owners enough alternative options to start 
switching to https. The yellow icon would push most over the edge.

4. Late-2017: Switch the unlocked icon for http to red. After a year of yellow, 
most websites should already have switched to https (authenticated or 
self-signed), so now it's time to drive the nail in the coffin and kill http on 
any production site with a red icon.

5. Late-2018: Show a warning for http sites. This experience would be similar 
to the self-signed cert experience now, where users have to manually choose to 
continue. Developers building websites would still be able to choose to 
continue to load their dev sites, but no production website would in their 
right mind choose to use http only.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

Hey all,

Thanks a lot for the really robust discussion here.  There have been
several important points raised here:

1. People are more comfortable with requiring HTTPS for new features than
requiring it for features that are currently accessible to non-HTTPS
origins.  Removing or limiting features that are currently available will
require discussion of trade-offs between security and compatibility.

2. Enabling HTTPS can still be a challenge for some website operators.

3. HTTP caching is an important feature for constrained networks.  Content
served over

4. There will still be a need for the browser to be able to connect to
things like home routers, which often don’t have certificates

5. It may be productive to take some interim steps, such as placing
limitations on cookies stored by non-HTTPS sites.

It seems to me that these are important considerations to keep in mind as
we move more of the web to HTTPS, but they don’t need to be blocking on a
gradual deprecation of non-secure HTTP.  (More detailed comments are
below.)  So I’m concluding that there’s rough consensus here behind the
idea of limiting features to secure contexts as a way to move the web
toward HTTPS.   I’ve posted a summary of our plans going forward on the
Mozilla security blog [1].

Thanks
--Richard

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

Some more detailed thoughts:

1. Obviously, lots of caution will be necessary if and when we start
removing features from non-secure contexts.  However, based on the
discussions of things like limiting cookies in this thread, and other
discussions in the “powerful features” threads, it seems that there’s still
some interest in trying to find features where the degree of breakage is
small enough to be compensated by the security benefit.  So it makes sense
to keep the removal or limitation of existing features on the overall
roadmap, with the caveat that we will need to calibrate the
breakage/security trade-offs before taking action.

2. While enabling HTTPS inherently involves more work than enabling
non-secure HTTP, there’s a lot of work going on to make it easier, ranging
from Cloudflare’s Universal SSL to Let’s Encrypt.  Speaking practically,
this non-secure HTTP deprecation process won’t be causing problems for
existing non-secure websites for some time, so there’s time for these
efforts to make progress before the pressure to use HTTPS really sets in.

3. Caching and performance are important, but so is user privacy.  It is
possible to do secure caching, but it will need to be carefully engineered
to avoid leaking more information than necessary.  (I think Martin Thomson
and Patrick McManus have done some initial work here.)  As with the prior
point, the fact that this non-secure HTTP deprecation will happen gradually
means that we have time to evaluate the requirements here and develop any
technology that might be necessary.

4. This seems like a problem that can be solved by the home router vendors
if they want to solve it.  For example, Vendor X could provision routers
with names like “router-123.vendorx.com” and certificates for those names,
and print the router name on the side of the router (just like WPA keys
today).  Also, interfaces to these sorts of devices don’t typically use a
lot of advanced web features, so may not be impacted by this deprecation
plan for a long time (if ever).

5. We can take these interim steps *and* work toward deprecation.


On Mon, Apr 13, 2015 at 7:57 AM, Richard Barnes  wrote:

> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
>
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
>
>
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
>
> Some earlier threads on this list [5] and elsewhere [6] have discussed
> deprecating insecure HTTP for "powerful features".  We think it would be a
> simpler and clearer statement to avoid the discussion of which features are
> "powerful" and focus on moving all features to HTTPS, powerful or not.
>
> The goal of this thread is to determine whether there is support in the
> Mozilla community for a plan of this gener

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

On 24/04/15 23:06, Roger Hågensen wrote:
> On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham
> wrote:
>> This makes checking in with the browser maker a necessary
>> prerequisite for secure connections. That has problems.
> 
> How so? Certificates have to be checked today as well (if they have
> been revocated or not).

Yes, and this has privacy problems too. Hence the move towards OCSP
stapling, which does not.

>>> 3. When the user later connect to a server that support automatic
>>> encryption, the browser sends a (public) session key that the
>>> server should use, this key is signed with the browser
>>> installation key, the server can verify the signature and that
>>> this key is not modified by checking the certificate server.
>> 
>> What you just built is a unique identifier for every browser which
>> can be tracked across sites.
> 
> How can this be tracked? This can be tracked just like any other
> client certificate can be tracked currently, no difference.

Right. And that's one reason why people don't use client certificates! :-)

Client certificates allow users to be tracked with 100% accuracy across
every site which requests the cert. Which is why IIRC, by default, users
are prompted in Firefox before sending a client certificate.

> DNSSEC exists and should help mitigate who you are talking to issue. 

And is not fully deployed, and certainly not where it's most needed, at
the endpoints.

> Also certificates have been falsified (didn't Mozilla just untrust
> all certificates by a certain certificate issuer recently that
> allowed fake Google.com certificates to be made?)

"Sometimes certs are misissued -> certs can never be trusted" is not
good logic.

> Also with certificates like the free ones from StartSSL the only site
> identity you can see is "identity not verified" yet the connection is
> still HTTPS. 

The domain name is the site identity for a DV certificate.

> DNSSEC enabled (does all latest browsers support that?) So one can be
> relatively sure to be talking to skuldwyrm.no without https.

Perhaps, in this one case, if Firefox checked DNSSEC, which it doesn't.
But you would have no guarantee of content integrity without HTTPS - an
attacker could alter the content during transmission.

> What I'm proposing is no worse than automatic domain verified
> certificates currently are.

Then why re-engineer the entire secure Internet just to get something
which is "no worse"?

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Martin Thomson]

This is a digression, but it touches on an important question that
others are asking in response to this general push [1].

Fundamentally, better client authentication doesn't do anything to
help make the web a more secure place (in any of the dimensions that
we're primarily concerned about in this thread, anyway).  They can
actually make things worse by creating more ways of tracking users.

On Fri, Apr 24, 2015 at 3:28 PM, Roger Hågensen  wrote:
> How about HTTP/2 ?
> Also a lot of smart minds completely ignored HTTP Digest Authentication for 
> years, allowing Basic (plain text) password to be sent when login in on sites.

The problems with both digest and basic are primarily poor UX.  This
is well-known.  From a security perspective, both are pretty poor, but
since the UX was so poor they weren't used that much.  Consequently,
they were neglected.

HTTP APIs have been used more in recent years, so we're seeing more
demand for better mechanisms that are native to the protocol.  OAuth
is one such thing.  And new authentication methods are being developed
in the httpauth working group in the IETF [2].  Participation is open
there, feel free to sign up.  You can also look into essentially
proprietary systems like hawk [3], which Mozilla services have decided
they quite like.

> HTTP/2 could be extended to improve the way HTTP Digest Authentication works, 
> adding a HMAC(PSWD+SALT) + Challenge(NONCE) = Response(HASH) method.

HTTP/2 is not the place for authentication improvements.  We
specifically removed the mechanism Google invented for SPDY early in
the HTTP/2 process for that reason (and others).

The mechanisms cited above all work perfectly well with HTTP/1.1, and
that's still considered an important property.

[1] http://www.w3.org/DesignIssues/Security-ClientCerts.html
[2] https://tools.ietf.org/wg/httpauth
[3] https://github.com/hueniverse/hawk
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Roger Hågensen]

On Tuesday, April 21, 2015 at 3:56:31 PM UTC+2, Mike Hoye wrote:
> On 2015-04-21 6:43 AM, Roger Hågensen wrote:
> > I know, not that well explained and over simplified. But the concept 
> > is hopefully clear, but in case it's not...
> For what it's worth, a lot of really smart people have been thinking 
> about this problem for a while and there aren't a lot of easy buckets 
> left on this court. Even if we had the option of starting with a clean 
> slate it's not clear how much better we could do, and scrubbing the 
> internet's security posture down to the metal and starting over isn't 
> really an option. We have to work to improve the internet as we find it, 
> imperfections and tradeoffs and all.

How about HTTP/2 ?
Also a lot of smart minds completely ignored HTTP Digest Authentication for 
years, allowing Basic (plain text) password to be sent when login in on sites.

I hate plain text logins, how many blogs and forums out there have plain text 
logins right now? The number is scary I'm sure.
MITM attacks are one thing, what is worse are network eavesdropping, login to 
your blog or forum from a Cafe and you are screwed basically. IT has been shown 
that despite using WPA2 to the router, others on the same router can catch 
packets and decrypt them. And then they have your login/password.

Now when I make logins for web projects I use a Javascript client side based 
HMAC and a challenge-response so I do not even send the HMAC/hash over the 
network.

The server gives the javascript/client a challenge and a nonce, the password 
which the user knows and server knows (actually the server only knows a hmac of 
the pass and salt) is used with the challenge and then the result is sent back 
as a answer.
An eaves dropper will not be able to get the password.

Now, there are other attacks that could be used like session exploits but this 
is true even for HTTPS connections.

And a javascript/client solution like this is open to a MITTM attack since it's 
not encrypted or signed in any way (code signing certificates are even more 
expensive than site certificates).

I'd like to see a Client based HMAC Challenge-Responsive built in and a way for 
a browser and a serverside script to establish a encrypted connection without 
he need for certificates.
This would solve the plaintext login headache, and would be attractive to sites 
that only have HTTP (no HTTPS option) but has for example PHP support or some 
other scripting language.

HTTP/2 could be extended to improve the way HTTP Digest Authentication works, 
adding a HMAC(PSWD+SALT) + Challenge(NONCE) = Response(HASH) method.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Roger Hågensen]

On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham wrote:
> Very briefly:
> 
> On 21/04/15 12:43, Roger Hågensen wrote:
> > 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.)
> > securely (https?) from the official download location. 2. Upon
> > installation a private key is created for that browser installation
> > and signed by the browser's certificate server. 
> 
> This makes checking in with the browser maker a necessary prerequisite
> for secure connections. That has problems.

How so? Certificates have to be checked today as well (if they have been 
revocated or not).
Also, it would only be at installation time for the user.
The server itself would heck if it's been revocated or not.
StartSSL uses client certificates for logins, so does several other sites.

If you an have a client-server connection where only the server has a 
certifiate then the opposite is also possible, where the client-server 
connection is secured with only the client having a certificate.

> > 3. When the user
> > later connect to a server that support automatic encryption, the
> > browser sends a (public) session key that the server should use, this
> > key is signed with the browser installation key, the server can
> > verify the signature and that this key is not modified by checking
> > the certificate server.
> 
> What you just built is a unique identifier for every browser which can
> be tracked across sites.

How can this be tracked? This can be tracked just like any other client 
certificate can be tracked currently, no difference.

> > 4. The server exchanges it's session key with
> > the browser. 5. A secure/encrypted connection is now possible.
> 
> Except that the browser has not yet identified the site. It is important
> for the user to check the site is genuine before the user sends any
> important information to it.
> 
> > The benefit is that there is no server side certificates needed to
> > establish a encrypted connection. 
> 
> They are needed if the user wants to have any confidence in who they are
> actually talking to.

DNSSEC exists and should help mitigate who you are talking to issue.
Also certificates have been falsified (didn't Mozilla just untrust all 
certificates by a certain certificate issuer recently that allowed fake 
Google.com certificates to be made?)

Also with certificates like the free ones from StartSSL the only site identity 
you can see is "identity not verified" yet the connection is still HTTPS. Just 
look at https://skuldwyrm.no/ which uses a free StartSSL certificate.
Do note however that this .no domain do have DNSSEC enabled (does all latest 
browsers support that?)
So one can be relatively sure to be talking to skuldwyrm.no without https.

What I'm proposing is no worse than automatic domain verified certificates 
currently are.
The important thing is that the connection is encrypted here.
Not whether the site is trusted or not.
Heck, there are sites with a "green url bar" that do rip people off, so trust 
or ensuring you do'nt get fooled is not automagic with any type of HTTPS in 
that regard.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-24 1:02 AM, butrus.but...@gmail.com wrote:
I think this is very very bad idea. There are many resources which are 
not worth being protected by HTTPS.

This is about protecting people, not resources.

I think an eight-year-old article about a hacked-up, homebrew 8-bit 
webserver is the edgiest of edge case I've ever seen, but there's a seed 
of an idea in there about embedded devices that's important.


The common case there, though, will be home users who do not know the 
first thing about network security but have a house full of wireless 
embedded devices and appliances, not the lo-fi hacker community who 
you'd expect to have a better sense of what they're in for. In that 
context HTTPS is a security measure you expect to be there by default, 
as basic and universal as the locks on your front door.



- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[rbarnes]

On Friday, April 24, 2015 at 1:03:00 AM UTC-4, butrus...@gmail.com wrote:
> On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> > There's pretty broad agreement that HTTPS is the way forward for the web.
> > In recent months, there have been statements from IETF [1], IAB [2], W3C
> > [3], and even the US Government [4] calling for universal use of
> > encryption, which in the case of the web means HTTPS.
> > 
> > In order to encourage web developers to move from HTTP to HTTPS, I would
> > like to propose establishing a deprecation plan for HTTP without security.
> > Broadly speaking, this plan would entail  limiting new features to secure
> > contexts, followed by gradually removing legacy features from insecure
> > contexts.  Having an overall program for HTTP deprecation makes a clear
> > statement to the web community that the time for plaintext is over -- it
> > tells the world that the new web uses HTTPS, so if you want to use new
> > things, you need to provide security.  Martin Thomson and I drafted a
> > one-page outline of the plan with a few more considerations here:
> > 
> > https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
> > 
> > Some earlier threads on this list [5] and elsewhere [6] have discussed
> > deprecating insecure HTTP for "powerful features".  We think it would be a
> > simpler and clearer statement to avoid the discussion of which features are
> > "powerful" and focus on moving all features to HTTPS, powerful or not.
> > 
> > The goal of this thread is to determine whether there is support in the
> > Mozilla community for a plan of this general form.  Developing a precise
> > plan will require coordination with the broader web community (other
> > browsers, web sites, etc.), and will probably happen in the W3C.
> > 
> > Thanks,
> > --Richard
> 
> 
> I think this is very very bad idea. There are many resources which are not 
> worth being protected by HTTPS. Moreover, it doesn't make sense e.g. for 
> resources in the local network. And there are devices which CANNOT use HTTPS, 
> e.g. a webserver on a 8-bit MCU (like 
> http://tuxgraphics.org/electronics/200611/article06111.shtml).
> 
> So, please, let it be the responsibility of the webmaster and/or the user 
> whether to use HTTP or HTTPS!

To be clear, we are not proposing to remove that choice, only limiting the set 
of web features that non-HTTPS pages can use.

There are also plenty of small platforms that can support HTTPS.  Slightly 
bigger than what you're talking about, but still small.
http://hypernephelist.com/2014/08/19/https_on_arduino_yun.html

--Richard


> 
> P.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[richard . barnes]

On Thursday, April 23, 2015 at 11:47:14 PM UTC-4, voracity wrote:
> Just out of curiosity, is there an equivalent of:
> 
> python -m SimpleHTTPServer
> 
> in the TLS world currently, or is any progress being made towards that?

openssl req -new -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem
openssl s_server -accept 8000 -key key.pem -cert cert.pem -HTTP

Not quite as simple, but not far off.  With the above, you can get 
, as long as you're willing to click through a 
certificate warning.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[butrus . butrus]

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> There's pretty broad agreement that HTTPS is the way forward for the web.
> In recent months, there have been statements from IETF [1], IAB [2], W3C
> [3], and even the US Government [4] calling for universal use of
> encryption, which in the case of the web means HTTPS.
> 
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.
> Broadly speaking, this plan would entail  limiting new features to secure
> contexts, followed by gradually removing legacy features from insecure
> contexts.  Having an overall program for HTTP deprecation makes a clear
> statement to the web community that the time for plaintext is over -- it
> tells the world that the new web uses HTTPS, so if you want to use new
> things, you need to provide security.  Martin Thomson and I drafted a
> one-page outline of the plan with a few more considerations here:
> 
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
> 
> Some earlier threads on this list [5] and elsewhere [6] have discussed
> deprecating insecure HTTP for "powerful features".  We think it would be a
> simpler and clearer statement to avoid the discussion of which features are
> "powerful" and focus on moving all features to HTTPS, powerful or not.
> 
> The goal of this thread is to determine whether there is support in the
> Mozilla community for a plan of this general form.  Developing a precise
> plan will require coordination with the broader web community (other
> browsers, web sites, etc.), and will probably happen in the W3C.
> 
> Thanks,
> --Richard


I think this is very very bad idea. There are many resources which are not 
worth being protected by HTTPS. Moreover, it doesn't make sense e.g. for 
resources in the local network. And there are devices which CANNOT use HTTPS, 
e.g. a webserver on a 8-bit MCU (like 
http://tuxgraphics.org/electronics/200611/article06111.shtml).

So, please, let it be the responsibility of the webmaster and/or the user 
whether to use HTTP or HTTPS!

P.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[voracity]

Just out of curiosity, is there an equivalent of:

python -m SimpleHTTPServer

in the TLS world currently, or is any progress being made towards that?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Richard Barnes]

On Tue, Apr 21, 2015 at 9:56 AM, Mike Hoye  wrote:

> On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote:
>
>> I know, not that well explained and over simplified. But the concept is
>> hopefully clear, but in case it's not...
>>
> For what it's worth, a lot of really smart people have been thinking about
> this problem for a while and there aren't a lot of easy buckets left on
> this court. Even if we had the option of starting with a clean slate it's
> not clear how much better we could do, and scrubbing the internet's
> security posture down to the metal and starting over isn't really an
> option. We have to work to improve the internet as we find it,
> imperfections and tradeoffs and all.
>
> Just to add to this discussion, one point made to me in private was that
> HTTPS-everywhere defangs the network-level malware-prevention tools a lot
> of corporate/enterprise networks use. My reply was that those same
> companies have tools available to preinstall certificates in browsers they
> deploy internally - most (all?) networking-hardware companies will sell you
> tools to MITM your own employees - which would be an acceptable solution in
> those environments where that's considered an acceptable solution, and not
> a thing to block on.
>

Yeah, I agree this is an issue, but not a blocker.  It's already a problem
for the ~65% of web transactions that are already encrypted, and people are
already thinking about how to manage these enterprise roots better /
improve user visibility.

--Richard



>
> - mhoye
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Mike Hoye]

On 2015-04-21 6:43 AM, skuldw...@gmail.com wrote:
I know, not that well explained and over simplified. But the concept 
is hopefully clear, but in case it's not...
For what it's worth, a lot of really smart people have been thinking 
about this problem for a while and there aren't a lot of easy buckets 
left on this court. Even if we had the option of starting with a clean 
slate it's not clear how much better we could do, and scrubbing the 
internet's security posture down to the metal and starting over isn't 
really an option. We have to work to improve the internet as we find it, 
imperfections and tradeoffs and all.


Just to add to this discussion, one point made to me in private was that 
HTTPS-everywhere defangs the network-level malware-prevention tools a 
lot of corporate/enterprise networks use. My reply was that those same 
companies have tools available to preinstall certificates in browsers 
they deploy internally - most (all?) networking-hardware companies will 
sell you tools to MITM your own employees - which would be an acceptable 
solution in those environments where that's considered an acceptable 
solution, and not a thing to block on.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Gervase Markham]

Very briefly:

On 21/04/15 12:43, skuldw...@gmail.com wrote:
> 1. User downloads a browser (be it Firefox, Chrome, Opera, etc.)
> securely (https?) from the official download location. 2. Upon
> installation a private key is created for that browser installation
> and signed by the browser's certificate server. 

This makes checking in with the browser maker a necessary prerequisite
for secure connections. That has problems.

> 3. When the user
> later connect to a server that support automatic encryption, the
> browser sends a (public) session key that the server should use, this
> key is signed with the browser installation key, the server can
> verify the signature and that this key is not modified by checking
> the certificate server.

What you just built is a unique identifier for every browser which can
be tracked across sites.

> 4. The server exchanges it's session key with
> the browser. 5. A secure/encrypted connection is now possible.

Except that the browser has not yet identified the site. It is important
for the user to check the site is genuine before the user sends any
important information to it.

> The benefit is that there is no server side certificates needed to
> establish a encrypted connection. 

They are needed if the user wants to have any confidence in who they are
actually talking to.

Gerv
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[skuldwyrm]

On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> In order to encourage web developers to move from HTTP to HTTPS, I would
> like to propose establishing a deprecation plan for HTTP without security.

I think server side SSL certificates should be deprecated as a means to encrypt 
a connection.

Ideally this is what should happen:

1. User downloads a browser (be it Firefox, Chrome, Opera, etc.) securely 
(https?) from the official download location.
2. Upon installation a private key is created for that browser installation and 
signed by the browser's certificate server.
3. When the user later connect to a server that support automatic encryption, 
the browser sends a (public) session key that the server should use, this key 
is signed with the browser installation key, the server can verify the 
signature and that this key is not modified by checking the certificate server.
4. The server exchanges it's session key with the browser.
5. A secure/encrypted connection is now possible.


I know, not that well explained and over simplified.
But the concept is hopefully clear, but in case it's not...

This is today's server certificates system but in reverse.

This concept does not replace https as it is today, but does allow "free" 
encrypted connections.
Web designers, hosting companies etc only need to ensure their server software 
is up to date and are able to support this.

The benefit is that there is no server side certificates needed to establish a 
encrypted connection.
The browser/client installation certificate can easily be changed each time a 
browser is updated. And can be set to expire within a certain number of months.

Not sure what to call this concept. "Reverse-HTTPS" maybe? RHTTPS for short?

Traditional serverside certificates are still needed, especially the "green 
bar" ones.
And free basic ones like StartSSL gives out are still of use, to allow old 
browsers to use HTTPS, and to support a fallback in case a browser certificate 
has expired (and still allow a secure connection).


The issue today (even with free certificates like StartSSL gives out) is that 
webmasters ans hosting companies have to do a yearly dance to update the 
certificates.
And not all hosting companies support HTTPS for all their packages.
Sites that make some profit can probably afford to pay for the extra HTTPS 
feature and pay for a certificate.

Myself I'm lucky in that my host provides free HTTPS support for the particular 
package I have (though not for the smallest package).


My concept has a flaw though. Browser makers need to set up their own 
certificate server to sign the generated browser installation keys.
And server software (Apache, nginx, etc.) need to support a type of RHTTPS so 
they can send a session key to the browser.

The benefit though is that servers do not need a certificate installed to 
create a encrypted connection.


Further security could be built on top of this where the server or client or 
both have authenticated certificate (so that there is not only a encrypted 
connection but also identified server and client)


A concept like RHTTPS would allow a slow migration with no direct need for 
webmasters nor browser users to change anything themselves, with zero cost to 
webmasters/hosters nor the end users.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: Insecure HTTP

[Daniel Veditz]

On Thu, Apr 16, 2015 at 5:16 AM,  wrote:

> - You don't want to hear about non-centralized security models.  DANE
> provides me with control over certificate pinning for people visiting my
> websites.
> ​[...] If you don't like DANE, explain why, and propose something else
> that is non-centralized and not under Mozilla's control.
>

​For certificate pinning Firefox and Chrome support the Public Key Pinning
Extension for HTTP (HPKP​
​), which is non-centralized, not under Mozilla's control, and was recently
ratified as a formal IETF internet standard​

https://tools.ietf.org/html/rfc7469
​
-
​Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform