Intent to deprecate: Insecure HTTP

Showing 1-236 of 236 messages
Intent to deprecate: Insecure HTTP Richard Barnes 4/13/15 7:57 AM
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
Re: Intent to deprecate: Insecure HTTP DDD 4/13/15 10:40 AM
I think that you'll need to define a number of levels of security, and decide how to distinguish them in the Firefox GUI:

- Unauthenticated/Unencrypted [http]
- Unauthenticated/Encrypted   [https ignoring untrusted cert warning]
- DNS based auth/Encrypted    [TLSA certificate hash in DNS]
- Ditto with TLSA/DNSSEC
- Trusted CA Authenticated    [Any root CA]
- EV Trusted CA               [Special policy certificates]

Ironically, your problem is more a GUI thing.  All the security technology you need actually exists already...
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 4/13/15 10:57 AM
On Mon, Apr 13, 2015 at 10:40 AM, DDD <david....@gmail.com> wrote:

> I think that you'll need to define a number of levels of security, and
> decide how to distinguish them in the Firefox GUI:
>
> - Unauthenticated/Unencrypted [http]
> - Unauthenticated/Encrypted   [https ignoring untrusted cert warning]
> - DNS based auth/Encrypted    [TLSA certificate hash in DNS]
> - Ditto with TLSA/DNSSEC
>

Note that Firefox does not presently support either DANE or DNSSEC,
so we don't need to distinguish these.

-Ekr




> - Trusted CA Authenticated    [Any root CA]
> - EV Trusted CA               [Special policy certificates]
>
> Ironically, your problem is more a GUI thing.  All the security technology
> you need actually exists already...
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/13/15 11:29 AM
>
> Note that Firefox does not presently support either DANE or DNSSEC,
> so we don't need to distinguish these.
>
> -Ekr
>

Nor does Chrome, and look what happened to both browsers...

http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/

...the keys to the castle are in the DNS registration process.  It is illogical not to add TLSA support.

Re: Intent to deprecate: Insecure HTTP mh.in...@gmail.com 4/13/15 11:33 AM
> 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.

May I suggest defining "security" here as either:

1) A secure host (SSL)

or

2) Protected by subresource integrity from a secure host

This would allow website operators to securely serve static assets from non-HTTPS servers without MITM risk, and without breaking transparent caching proxies.

Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/13/15 11:52 AM

> 2) Protected by subresource integrity from a secure host
>
> This would allow website operators to securely serve static assets from non-HTTPS servers without MITM risk, and without breaking transparent caching proxies.

Is that a complicated word for SHA512 HASH? :)  You could envisage a new http URL pattern http://video.vp9?<SHA512-HASH>
Re: Intent to deprecate: Insecure HTTP Frederik Braun 4/13/15 12:00 PM
I suppose Subresource Integrity would be http://www.w3.org/TR/SRI/ -

But, note that this will not give you extra security UI (or less
warnings): Browsers will still disable scripts served over HTTP on an
HTTPS page - even if the integrity matches.

This is because HTTPS promises integrity, authenticity and
confidentiality. SRI only provides the former.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/13/15 12:04 PM
I agree that we should probably not allow insecure HTTP resource to be
looped in through SRI.

There are several issues with this idea, but the one that sticks out for me
is the risk of leakage from HTTPS through these http-schemed resource
loads.  For example, that fact that you're loading certain images might
reveal which Wikipedia page you're reading.

--Richard
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/13/15 12:11 PM
On 13/04/15 15:57, Richard Barnes wrote:
> 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

Are you sure "privileged contexts" is the right phrase? Surely contexts
are "secure", and APIs or content is "privileged" by being only
available in a secure context?

There's nothing wrong with your plan, but that's partly because it's
hard to disagree with your principle, and the plan is pretty high level.
I think the big arguments will be over when and what features require a
secure context, and how much breakage we are willing to tolerate.

I know the Chrome team have a similar plan; is there any suggestion that
we might coordinate on feature re-privilegings?

Would we put an error on the console when a privileged API was used in
an insecure context?

Gerv

Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/13/15 12:12 PM
On 13/04/15 18:40, DDD wrote:
> I think that you'll need to define a number of levels of security, and decide how to distinguish them in the Firefox GUI:
>
> - Unauthenticated/Unencrypted [http]
> - Unauthenticated/Encrypted   [https ignoring untrusted cert warning]
> - DNS based auth/Encrypted    [TLSA certificate hash in DNS]
> - Ditto with TLSA/DNSSEC
> - Trusted CA Authenticated    [Any root CA]
> - EV Trusted CA               [Special policy certificates]

I'm not quite sure what this has to do with the proposal you are
commenting on, but I would politely ask you how many users you think are
both interested in, able to understand, and willing to take decisions
based on _six_ different security states in a browser?

The entire point of this proposal is to reduce the web to 1 security
state - "secure".

Gerv


Re: Intent to deprecate: Insecure HTTP Martin Thomson 4/13/15 12:28 PM
On Mon, Apr 13, 2015 at 12:11 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Are you sure "privileged contexts" is the right phrase? Surely contexts
> are "secure", and APIs or content is "privileged" by being only
> available in a secure context?

There was a long-winded group bike-shed-painting session on the
public-webappsec list and this is the term they ended up with.  I
don't believe that it is the right term either, FWIW.

> There's nothing wrong with your plan, but that's partly because it's
> hard to disagree with your principle, and the plan is pretty high level.
> I think the big arguments will be over when and what features require a
> secure context, and how much breakage we are willing to tolerate.

Not much, but maybe more than we used to.

> I know the Chrome team have a similar plan; is there any suggestion that
> we might coordinate on feature re-privilegings?

Yes, the intent is definitely to collaborate, as the original email
stated.  Chrome isn't the only stakeholder, which is why we suggested
that we go to the W3C so that the browser formerly known as IE and
Safari are included.

> Would we put an error on the console when a privileged API was used in
> an insecure context?

Absolutely.  That's likely to be a first step once the targets have
been identified.  That pattern has already been established for bad
crypto and a bunch of other things that we don't like but are forced
to tolerate for compatibility reasons.
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/13/15 12:35 PM
I would politely ask you how many users you think are
> both interested in, able to understand, and willing to take decisions
> based on _six_ different security states in a browser?

I think this thread is about deprecating things and moving developers onto more secure platforms.  To do that, you'll need to tell me *why* I need to make the effort.  The only thing that I am going to care about is to get users closer to that magic green bar and padlock icon.

You may hope that security is black and white, but in practice it isn't.  There is always going to be a sliding scale.  Do you show me a green bar and padlock if I go to www.google.com, but the certificate is issued by my intranet?  Do you show me the same certificate error I'd get as if I was connecting to a clearly malicious certificate.

What if I go to www.google.com, but the certificate has been issued incorrectly because Firefox ships with 500 equally trusted root certificates?


So - yeah, you're going to need a rating system for your security:  A, B, C, D, Fail.  You're going to have to explain what situations get you into what group, how as a developer I can move to a higher group (e.g. add a certificate hash into DNS, get an EV certificate costing $10,000, implement DNSSEC, use PFS ciphersuites and you get an A rating). I'm sure that there'll be new security vulnerabilities and best practice in future, too.

Then it is up to me as a developer to decide how much effort I can realistically put into this...

...for my web-site containing pictures of cats...
Re: Intent to deprecate: Insecure HTTP commod...@gmail.com 4/13/15 12:36 PM
Great, peachy, more authoritarian dictation of end-user behavior by the Elite is just what the Internet needs right now. And hey, screw anybody trying to use legacy systems for anything, right? Right!
Re: Intent to deprecate: Insecure HTTP stu...@testtrack4.com 4/13/15 1:29 PM
HTTP should remain optional and fully-functional, for the purposes of prototyping and diagnostics. I shouldn't need to set up a TLS layer to access a development server running on my local machine, or to debug which point before hitting the TLS layer is corrupting requests.
Re: Intent to deprecate: Insecure HTTP byu...@gmail.com 4/13/15 1:43 PM
On Monday, April 13, 2015 at 3:36:56 PM UTC-4, commod...@gmail.com wrote:
> Great, peachy, more authoritarian dictation of end-user behavior by the Elite is just what the Internet needs right now. And hey, screw anybody trying to use legacy systems for anything, right? Right!

Let 'em do this. When Mozilla and Google drop HTTP support, then it'll be open season for someone to fork/make a new browser with HTTP support, and gain an instant 30% market share. These guys have run amok with major decisions (like the HTTP/2 TLS mandate) because of a lack of competition.

These guys can go around thinking they're secure while trusting root CAs like CNNIC whilst ignoring DNSSEC and the like; the rest of us can get back on track with a new, sane browser. While we're at it, we could start treating self-signed certs like we do SSH, rather than as being *infinitely worse* than HTTP (I'm surprised Mozilla doesn't demand a faxed form signed by a notary public to accept a self-signed cert yet. But I shouldn't give them any ideas ...)
Re: Intent to deprecate: Insecure HTTP ipar...@gmail.com 4/13/15 1:48 PM
I have given this a lot of thought lately, and to me the only way forward is to do exactly what is suggested here: phase out and eventually drop plain HTTP support. There are numerous reasons for doing this:

- Plain HTTP allows someone to snoop on your users.

- Plain HTTP allows someone to misrepresent your content to the users.

- Plain HTTP is a great vector for phishing, as well as injecting malicious code that comes from your domain.

- Plain HTTP provides no guarantees of identity to the user. Arguably, the current HTTPS implementation doesn't do much to fix this, but more on this below.

- Lastly, arguing that HTTP is cheaper than HTTPS is going to be much harder once there are more providers giving away free certs (looking at StartSSL and Let's Encrypt).

My vision would be that HTTP should be marked with the same warning (except for wording of course) as an HTTPS site secured by a self-signed cert. In terms of security, they are more or less equivalent, so there is no reason to treat them differently. This should be the goal.

There are problems with transitioning to giving a huge scary warning for HTTP. They include:

- A large number of sites that don't support HTTPS. To fix this, I think the best method is to show the "http://" part of the URL in red, and publicly announce that over the next X months Firefox is moving to the model of giving a big scary warning a la self-signed cert warning if HTTPS is not enabled.

- A large number of corporate intranets that run plain HTTP. Perhaps a build-time configuration could be enabled that would enable system administrators to ignore the warning for certain subdomains or the RFC 1918 addresses as well as localhost. Note that carrier grade NAT in IPv4 might make the latter a bad choice by default.

- Ad supported sites report a drop in ad revenue when switching to HTTPS. I don't know what the problem or solution here is, but I am certain this is a big hurdle for some sites.

- Lack of free wildcard certificates. Ideally, Let's Encrypt should provide these.

- Legacy devices that cannot be upgraded to support HTTPS or only come with self-signed certificates. This is a problem that can be addressed by letting the user bypass the scary warning (just like with self-signed certs).

Finally, some people conflate the idea of a global transition from plain HTTP to HTTPS as a move by CA's to make more money. They might argue that first, we need to get rid of CA's or provide an alternative path for obtaining certificates. I disagree. Switching from plain HTTP to HTTPS is step one. Step two might include adding more avenues for establishing trust and authentication. There is no reason to try to add additional methods of authenticating the servers while still allowing them to use no encryption at all. Let's kill off plain HTTP first, then worry about how to fix the CA system. Let's Encrypt will of course make this a lot easier by providing free certs.
Re: Intent to deprecate: Insecure HTTP ipar...@gmail.com 4/13/15 1:55 PM
On Monday, April 13, 2015 at 4:43:25 PM UTC-4, byu...@gmail.com wrote:

> These guys can go around thinking they're secure while trusting root CAs like CNNIC whilst ignoring DNSSEC and the like; the rest of us can get back on track with a new, sane browser. While we're at it, we could start treating self-signed certs like we do SSH, rather than as being *infinitely worse* than HTTP (I'm surprised Mozilla doesn't demand a faxed form signed by a notary public to accept a self-signed cert yet. But I shouldn't give them any ideas ...)

A self-signed cert is worse than HTTP, in that you cannot know if the site you are accessing is supposed to have a self-signed cert or not. If you know that, you can check the fingerprint and bypass the warning. But let's say you go to download a fresh copy of Firefox, just to find out that https://www.mozilla.org/ is serving a self-singed cert. How can you possibly be sure that you are not being MITM'ed? Arguably, it's worse if we simply ignore the fact that the cert is self-signed, and simply let you download the compromised version, vs giving you some type of indication that the connection is not secure (e.g.: no green bar because it's plain HTTP).

That is not to say that we should continue as is. HTTP is insecure, and should give the same warning as HTTPS with a self-signed cert.
Re: Intent to deprecate: Insecure HTTP Joshua Cranmer �� 4/13/15 2:08 PM
On 4/13/2015 3:29 PM, stu...@testtrack4.com wrote:
> HTTP should remain optional and fully-functional, for the purposes of prototyping and diagnostics. I shouldn't need to set up a TLS layer to access a development server running on my local machine, or to debug which point before hitting the TLS layer is corrupting requests.

If you actually go to read the details of the proposal rather than
relying only on the headline, you'd find that there is an intent to
actually let you continue to use http for, e.g., localhost. The exact
boundary between "secure" HTTP and "insecure" HTTP is being actively
discussed in other forums.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

Re: Intent to deprecate: Insecure HTTP bryan....@gmail.com 4/13/15 2:11 PM
One limiting factor is that Firefox doesn't treat form data the same on HTTPS sites.

Examples:

http://stackoverflow.com/questions/14420624/how-to-keep-changed-form-content-when-leaving-and-going-back-to-https-page-wor

http://stackoverflow.com/questions/10511581/why-are-html-forms-sometimes-cleared-when-clicking-on-the-browser-back-button

After loosing a few forum posts or wiki edits to this bug in Firefox, you quickly insist on using unsecured HTTP as often as possible.
Re: Intent to deprecate: Insecure HTTP Boris Zbarsky 4/13/15 2:29 PM
On 4/13/15 5:11 PM, bryan....@gmail.com wrote:
> After loosing a few forum posts or wiki edits to this bug in Firefox, you quickly insist on using unsecured HTTP as often as possible.

This is only done in cases in which the page explicitly requires that
nothing about the page be cached (no-cache), yes?

That said, we should see if we can stop doing the state-not-saving thing
for SSL+no-cache and tell banks who want it to use no-store.

-Boris

Re: Intent to deprecate: Insecure HTTP Joseph Lorenzo Hall 4/13/15 2:57 PM
Late to the thread, but I'll use this reply to say we're very
supportive of the proposal at CDT.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@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
Re: Intent to deprecate: Insecure HTTP Eugene 4/13/15 3:53 PM
I fully support this proposal. In addition to APIs, I'd like to propose prohibiting caching any resources loaded over insecure HTTP, regardless of Cache-Control header, in Phase 2.N. The reasons are:
1) MITM can pollute users' HTTP cache, by modifying some JavaScript files with a long time cache control max-age.
2) It won't break any websites, just some performance penalty for them.
3) Many website operators and users avoid using HTTPS, since they believe HTTPS is much slower than plaintext HTTP. After deprecating HTTP cache, this argument will be more wrong.
Re: Intent to deprecate: Insecure HTTP Martin Thomson 4/13/15 4:03 PM
On Mon, Apr 13, 2015 at 3:53 PM, Eugene <imfasterth...@gmail.com> wrote:
> In addition to APIs, I'd like to propose prohibiting caching any resources loaded over insecure HTTP, regardless of Cache-Control header, in Phase 2.N.

This has some negative consequences (if only for performance).  I'd
like to see changes like this properly coordinated.  I'd rather just
treat "caching" as one of the features for Phase 2.N.
Re: Intent to deprecate: Insecure HTTP Karl Dubost 4/13/15 4:13 PM
Richard,

Le 13 avr. 2015 à 23:57, Richard Barnes <rba...@mozilla.com> a écrit :
> There's pretty broad agreement that HTTPS is the way forward for the web.

Yes, but that doesn't make deprecation of HTTP a consensus.

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

This is not encouragement. This is call forcing. ^_^ Just that we are using the right terms for the right thing.


In the document
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing

You say:
        Phase 3: Essentially all of the web is HTTPS.  

I understand this is the last hypothetical step, but it sounds like a bit let's move the Web to XML. It didn't work out very well.

I would love to have a more secure Web, but this can not happen without a few careful consideration.

* Third tier person for certificates being mandatory is a no-go. It creates a system of authority and power, an additional layer of hierarchy which deeply modify the ability for anyone to publish and might in some circumstances increase the security risk.

* If we have to rely, cost of certificates must be zero. These for the simple reason than not everyone is living in a rich industrialized country.

* Setup and publication through HTTPS should be as easy as HTTP. The Web brought a publishing power to any individuals. Imagine cases where you need to create a local network, web developing on your computer, hacking a server for your school, community, etc. If it relies on a heavy process, it will not happen.


So instead of a plan based on technical features, I would love to see a: "Let's move to a secure Web. What are the user scenarios, we need to solve to achieve that."

These user scenarios are economical, social, etc.


my 2 cents.
So yes, but not the way it is introduced and plan now.


--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/13/15 4:48 PM
> * If we have to rely, cost of certificates must be zero. These for the simple reason than not everyone is living in a rich industrialized country.

Certificates (and paying for them) is an artificial economy.  If I register a DNS address, I should get a certificate to go with it.  Heck, last time I got an SSL certificate, they effectively bootstrapped the trust based on my DNS MX record...

Hence IMO TLS should be:
- DANE for everyone
- DANE & Trusted Third Party CAs for the few
- DANE & TTP & EV for sites that accept financial and medical details

The Firefox opportunistic encryption feature is a good first step towards this goal.  If they could just nslookup the TLSA certificate hash, we'd be a long way down the road.  
Re: Intent to deprecate: Insecure HTTP northrupt...@gmail.com 4/13/15 5:57 PM
On Monday, April 13, 2015 at 7:57:58 AM UTC-7, 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.
> 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.

I'd be fully supportive of this if - and only if - at least one of the following is implemented alongside it:

* Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure
* Support for a decentralized (blockchain-based, ala Namecoin?) certificate authority

Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken.  Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse.
Re: Intent to deprecate: Insecure HTTP imfasterth...@gmail.com 4/13/15 6:43 PM
On Monday, April 13, 2015 at 8:57:41 PM UTC-4, northrupt...@gmail.com wrote:
>
> * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure

This feature (i.e. opportunistic encryption) was implemented in Firefox 37, but unfortunately an implementation bug made HTTPS insecure too. But I guess Mozilla will fix it and make this feature available in a future release.

> * Support for a decentralized (blockchain-based, ala Namecoin?) certificate authority
>
> Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken.  Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse.

I don't think the current CA system is broken. The domain name registration is also centralized, but almost every website has a hostname, rather than using IP address, and few people complain about this.
Re: Intent to deprecate: Insecure HTTP Karl Dubost 4/13/15 7:10 PM

Le 14 avr. 2015 à 10:43, imfasterth...@gmail.com a écrit :
> I don't think the current CA system is broken.

The current CA system creates issues for certain categories of population. It is broken in some ways.

> The domain name registration is also centralized, but almost every website has a hostname, rather than using IP address, and few people complain about this.

Two points:

1. You do not need to register a domain name to have a Web site (IP address)
2. You do not need to register a domain name to run a local blah.test.site

Both are still working and not deprecated in browsers ^_^

Now the fact to have to rent your domain name ($$$) and that all the URIs are tied to this is in terms of permanent identifiers and the fabric of time on information has strong social consequences. But's that another debate than the one of this thread on deprecating HTTP in favor of HTTPS.

I would love to see this discussion happening in Whistler too.

--
Karl Dubost, Mozilla
http://www.la-grange.net/karl/moz

Re: Intent to deprecate: Insecure HTTP ipar...@gmail.com 4/13/15 8:26 PM
> * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure

I am against this. Both are insecure and should be treated as such. How is your browser supposed to know that gmail.com is intended to serve a self-signed cert? It's not, and it cannot possibly know it in the general case. Thus it must be treated as insecure.

> * Support for a decentralized (blockchain-based, ala Namecoin?) certificate authority

No. Namecoin has so many other problems that it is not feasible.

> Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken.  Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse.

Agree that it's broken. The fact that any CA can issue a cert for any domain is stupid, always was and always will be. It's now starting to bite us.

However, HTTPS and the CA system don't have to be tied together. Let's ditch the immediately insecure plain HTTP, then add ways to authenticate trusted certs in HTTPS by means other than our current CA system. The two problems are orthogonal, and trying to solve both at once will just leave us exactly where we are: trying to argue for a fundamentally different system.
Re: Intent to deprecate: Insecure HTTP ipar...@gmail.com 4/13/15 8:31 PM
On Monday, April 13, 2015 at 10:10:44 PM UTC-4, Karl Dubost wrote:

> Now the fact to have to rent your domain name ($$$) and that all the URIs are tied to this is in terms of permanent identifiers and the fabric of time on information has strong social consequences. But's that another debate than the one of this thread on deprecating HTTP in favor of HTTPS.

The registrars are, as far as I'm concerned, where the solution to the CA problem lies. You buy a domain name from someone, you are already trusting them with it. They can simply redirect your nameservers elsewhere and you can't do anything about it. Remember, you never buy a domain name, you lease it.

What does this have to do with plain HTTP to HTTPS transition? Well, why are we trusting CA's at all? Why not have the registrar issue you a wildcard cert with the purchase of a domain, and add restrictions to the protocol such that only your registrar can issue a cert for that domain?

Or even better, have the registrar sign a CA cert for you that is good for your domain only. That way you can issue unlimited certs for domains you own and *nobody but you can do that*.

However, like you said that's a separate discussion. We can solve the CA problem after we solve the plain HTTP problem.
Re: Intent to deprecate: Insecure HTTP commod...@gmail.com 4/13/15 9:27 PM
On Monday, April 13, 2015 at 1:43:25 PM UTC-7, byu...@gmail.com wrote:
> Let 'em do this. When Mozilla and Google drop HTTP support, then it'll be open season for someone to fork/make a new browser with HTTP support, and gain an instant 30% market share.
Or, more likely, it'll be a chance for Microsoft and Apple to laugh all the way to the bank. Because seriously, what else would you expect to happen when the makers of a web browser announce that, starting in X months, they'll be phasing out compatibility with the vast majority of existing websites?
Re: Intent to deprecate: Insecure HTTP vic 4/13/15 10:16 PM
On Monday, April 13, 2015 at 4:57:58 PM UTC+2, Richard Barnes wrote:
> HTTP deprecation

I'm strongly against the proposal as it is described here. I work with small embedded devices (think sensor network) that are accessed over HTTP. These devices have very little memory, only a few kB, implementing SSL is simply not possible. Who are you to decree these devices become unfit hosts?

Secondly the proposal to restrain unrelated new features like CSS attributes to HTTPS sites only is simply a form of strong-arming. Favoring HTTPS is fine but authoritarianism is not. Please consider that everyone is capable of making their own decisions.

Lastly deprecating HTTP in the current state of the certificate authority business is completely unacceptable. These are *not* separate issues, to implement HTTPS without warnings you must be able to obtain certificates (including wildcard ones) easily and affordably and not only to rich western country citizens. The "let's go ahead and we'll figure this out later" attitude is irresponsible considering the huge impact that this change will have.

I would view this proposal favorably if 1) you didn't try to force people to adopt the One True Way and 2) the CA situation was fixed.
Re: Intent to deprecate: Insecure HTTP b...@hutchins.co 4/13/15 10:18 PM
This isn't at all what Richard was trying to say. The original discussion states that the plan will be to make all new browser features only work under HTTPS, to help developers and website owners to migrate to HTTPS only. This does mean these browsers will remove support for HTTP ever; but simply to deprecate it. Browsers still support many legacy and deprecated features.
Re: Intent to deprecate: Insecure HTTP b...@hutchins.co 4/13/15 10:28 PM
An embedded device would not be using a web browser such as Firefox, so this isn't really much of a concern. The idea would be to only enforce HTTPS deprecation from browsers, not web servers. You can continue to use HTTP on your own web services and therefore use it through your embedded devices.

As all technology protocols change over time, enforcing encryption is a natural and logical step to evolve web technology. Additionally, while everyone is able to make their own decisions, it doesn't mean people make the right choice. A website that uses sensitive data insecurely over HTTP and the users are unaware, as most web consumers are not even aware what the difference of HTTP vs HTTPS means, is not worth the risk. It'd be better to enforce security and reduce the risks that exist with internet privacy. Mozilla though never truly tries to operate anything with an authoritarianism approach, but this suggestion is to protect the consumers of the web, not the developers of the web.

Mozilla is trying to get https://letsencrypt.org/ started, which will be free, removing all price arguments from this discussion.

IMHO, this debate should be focused on improving the way HTTP is deprecated, but I do not believe there are any valid concerns that HTTP should not be deprecated.
Re: Intent to deprecate: Insecure HTTP Yoav Weiss 4/13/15 10:53 PM
IMO, limiting new features to HTTPS only, when there's no real security
reason behind it will only end up limiting feature adoption.
It directly "punishing" developers and adds friction to using new features,
but only influence business in a very indirect manner.

If we want to move more people to HTTPS, we can do any or all of the
following:
* Show user warnings when the site they're on is insecure
* Provide an opt-in "don't display HTTPS" mode as an integral part of the
browser. Make it extremely easy to opt in.

Search engines can also:
* Downgrade ranking of insecure sites in a significant way
* Provide a "don't show me insecure results" button

If you're limiting features to HTTPS with no reason you're implicitly
saying that developer laziness is what's stalling adoption. I don't believe
that the case.

There's a real eco-system problem with 3rd party widgets and ad networks
that makes it hard for large sites to switch until all of their site's
widgets have. Developers have no saying here. Business does.

What you want is to make the business folks threaten that out-dated 3rd
party widget that if it doesn't move to HTTPS, the site would switch to the
competition. For that you need to use a stick that business folks
understand: "If you're on HTTP, you'd see less and less traffic". Limiting
new features does absolutely nothing in that aspect.
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/13/15 11:23 PM
On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> Limiting new features does absolutely nothing in that aspect.

Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
Workers as a reason to start deploying HTTPS:

  http://open.blogs.nytimes.com/2014/11/13/embracing-https/

(And anecdotally, I find it easier to convince developers to deploy
HTTPS on the basis of some feature needing it than on merit. And it
makes sense, if they need their service to do X, they'll go through
the extra trouble to do Y to get to X.)


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/13/15 11:25 PM
On Tue, Apr 14, 2015 at 1:48 AM,  <david....@gmail.com> wrote:
> - DANE for everyone

TLS through DNS is happening anytime soon, if ever:

  http://sockpuppet.org/blog/2015/01/15/against-dnssec/
  http://sockpuppet.org/stuff/dnssec-qa.html
  https://www.imperialviolet.org/2015/01/17/notdane.html


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/14/15 12:29 AM
On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost <kdu...@mozilla.com> wrote:
> 1. You do not need to register a domain name to have a Web site (IP address)

Name one site you visit regularly that doesn't have a domain name. And
even then, you can get certificates for public IP addresses.


> 2. You do not need to register a domain name to run a local blah.test.site

We should definitely allow whitelisting of sorts for developers. As a
start localhost will be a privileged context by default. We also have
an override in place for Service Workers.

This is not a reason not to do HTTPS. This is something we need to
improve along the way.


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/14/15 12:29 AM
>   http://sockpuppet.org/blog/2015/01/15/against-dnssec/
>   http://sockpuppet.org/stuff/dnssec-qa.html
>   https://www.imperialviolet.org/2015/01/17/notdane.html

Yawn - those were all terrible articles.  To summarise their points: "NSA is bad, some DNS servers are out of date, DNSSEC may be still using shorter 1024bit RSA key lengths  (hmm... much like TLS then)"

The trouble is:  Just because something isn't perfect, doesn't make it a bad idea.  Certificates are not perfect, but they are not a bad idea.  Putting certificate thumbprints in DNS is not perfect, but it's not half a *good* idea.

Think about it: if your completely clear-text, unauthenticated DNS connection is compromised, then your browser is going to go to the wrong server anyway.  If it goes to the wrong server, so will your email, as will the identity verification messages from your CA.

Your browser needs to retrieve A and AAAA addresses from DNS anyway, so why not pull TLSA certificate hashes at the same time?  Even without DNSSEC, this could only improve things.

Casepoint, *absolutely* due to the frankly incomprehensible refusal to do this:  http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/

There is nothing you can do to fix this with traditional X509, or any single chain of trust.  You need multiple, independent proofs of identity.  A combination of X509 and a number of different signed DNS providers seem like a good way to approach this.

Finally - you can audit DNSSEC/TLSA responses programmatically as the response records are cached publicly in globally dispersed DNS servers, it's really hard to do the equivalent of "send a different chain when IP address 1.2.3.4 connects".  

I have my own opinions why TLSA certificate pinning records are not being checked and, having written an implementation myself, I can guarantee you that it isn't due to any technical complexity.
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/14/15 12:39 AM
On Tue, Apr 14, 2015 at 9:29 AM,  <david....@gmail.com> wrote:
> The trouble is:  Just because something isn't perfect, doesn't make it a bad idea.

I think it's a pretty great idea and it's one people immediately think
of. However, as those articles explain in detail, it's also a far from
realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
and is the focus of this thread. Whether we can achieve similar
guarantees through DNS at some point is orthogonal and is best
discussed elsewhere:

  https://tools.ietf.org/wg/dane/


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/14/15 12:47 AM
> realistic idea. Meanwhile, HTTPS exists, is widely deployed, works,
> and is the focus of this thread.

http://www.zdnet.com/article/google-banishes-chinas-main-digital-certificate-authority-cnnic/

Sure it works :)
Re: Intent to deprecate: Insecure HTTP imm...@gmail.com 4/14/15 12:48 AM
> Secondly the proposal to restrain unrelated new features like CSS attributes to HTTPS sites only is simply a form of strong-arming. Favoring HTTPS is fine but authoritarianism is not. Please consider that everyone is capable of making their own decisions.

One might note that this has already been tried, *and succeeded*, with SPDY and then HTTP 2.

HTTP 2 is faster than HTTP 1, but both Mozilla and Google are refusing to allow unencrypted HTTP 2 connections. Sites like http://httpvshttps.com/ intentionally mislead users into thinking that TLS improves connection speed, when actually the increased speed is from HTTP 2.
Re: Intent to deprecate: Insecure HTTP lorenz...@gmail.com 4/14/15 12:51 AM
> 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.
>

From the user/sysadmin point of view it would be very helpful to have information on how the following issues will be handled:

1) Caching proxies: resources obtained over HTTPS cannot be cached by a proxy that doesn't use MITM certificates. If all users must move to HTTPS there will be no way to re-use content downloaded for one user to accelerate another user. This is an important issue for locations with many users and poor internet connectivity.

2) Self signed certificates: in many situations it is hard/impossible to get certificates signed by a CA (e.g. provisioning embedded devices). The current approach in many of these situations is not to use HTTPS. If the plan goes into effect what other solution could be used?

Regarding problem 1: I guess that allowing HTTP for resources loaded with subresource integrity could be some sort of alternative, but would require collaboration from the server owner. Being more work than simply letting the webserver send out automatically caching headers I wonder how many sites will implement it.

Regarding problem 2: in my opinion it can be mitigated by offering the user a new standard way to validate self-signed certificates: the user is prompted to enter the fingerprint of the certificate that she must have received out-of-band, if the user enters the correct fingerprint the certificate is marked as trusted (see [1]). This clearly opens up some attacks that should be carefully assessed.

Best,
Lorenzo


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1012879
Re: Intent to deprecate: Insecure HTTP Alex C 4/14/15 12:55 AM
Another note:

Nobody, to within experimental error, uses IP addresses to access public websites.

But plenty of people use them for test servers, temporary servers, and embedded devices. (My home router is http://192.168.1.254/, do they need to get a certificate for 192.168.1.254? Or do home routers need to come with installation CDs that install the router's root certificate? How is that not a worse situation, where every web user has to trust the router manufacturer?)

And even though nobody uses IP addresses, and many public websites don't work with IP addresses (because vhosts), nobody in their right mind would ever suggest removing the possibility of accessing web servers without domain names.
Re: Intent to deprecate: Insecure HTTP Yoav Weiss 4/14/15 12:56 AM
On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

> On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> > Limiting new features does absolutely nothing in that aspect.
>
> Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
> Workers as a reason to start deploying HTTPS:
>
>   http://open.blogs.nytimes.com/2014/11/13/embracing-https/


I stand corrected. So it's the 8th reason out of 9, right before technical
debt.

I'm not saying using new features is not an incentive, and I'm definitely
not saying HTTP2 and SW should have been enabled on HTTP.
But, when done without any real security or deployment issues that mandate
it, you're subjecting new features to significant adoption friction that is
unrelated to the feature itself, in order to apply some indirect pressure
on businesses to do the right thing.
You're inflicting developer pain without any real justification. A sort of
collective punishment, if you will.

If you want to apply pressure, apply it where it makes the most impact with
the least cost. Limiting new features to HTTPS is not the place, IMO.


>
> (And anecdotally, I find it easier to convince developers to deploy
> HTTPS on the basis of some feature needing it than on merit. And it
> makes sense, if they need their service to do X, they'll go through
> the extra trouble to do Y to get to X.)
>
>
Don't convince the developers. Convince the business. Drive users away to
secure services by displaying warnings, etc.
Anecdotally on my end, I saw small Web sites that care very little about
security, move to HTTPS over night after Google added HTTPS as a (weak)
ranking signal
<http://googlewebmastercentral.blogspot.fr/2014/08/https-as-ranking-signal.html>.
(reason #4 in that NYT article)
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/14/15 1:05 AM
On Tue, Apr 14, 2015 at 9:51 AM,  <lorenz...@gmail.com> wrote:
> 1) Caching proxies: resources obtained over HTTPS cannot be cached by a proxy that doesn't use MITM certificates. If all users must move to HTTPS there will be no way to re-use content downloaded for one user to accelerate another user. This is an important issue for locations with many users and poor internet connectivity.

Where is the evidence that this is a problem in practice? What do
these environments do for YouTube?


> 2) Self signed certificates: in many situations it is hard/impossible to get certificates signed by a CA (e.g. provisioning embedded devices). The current approach in many of these situations is not to use HTTPS. If the plan goes into effect what other solution could be used?

Either something like
https://bugzilla.mozilla.org/show_bug.cgi?id=1012879 as you mentioned
or overrides for local devices. This definitely needs more research
but shouldn't preclude rolling out HTTPS on public resources.


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/14/15 1:07 AM
On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> You're inflicting developer pain without any real justification. A sort of
> collective punishment, if you will.

Why is that you think there is no justification in deprecating HTTP?


>> (And anecdotally, I find it easier to convince developers to deploy
>> HTTPS on the basis of some feature needing it than on merit. And it
>> makes sense, if they need their service to do X, they'll go through
>> the extra trouble to do Y to get to X.)
>
> Don't convince the developers. Convince the business.

Why not both? There's no reason to only attack this top-down.


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Yoav Weiss 4/14/15 1:39 AM
On Tue, Apr 14, 2015 at 10:07 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> On Tue, Apr 14, 2015 at 9:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> > You're inflicting developer pain without any real justification. A sort
> of
> > collective punishment, if you will.
>
> Why is that you think there is no justification in deprecating HTTP?
>

Deprecating HTTP is totally justified. Enabling some features on HTTP but
not others is not, unless there's a real technical reason why these new
features shouldn't be enabled.
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/14/15 1:44 AM
On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> Deprecating HTTP is totally justified. Enabling some features on HTTP but
> not others is not, unless there's a real technical reason why these new
> features shouldn't be enabled.

I don't follow. If HTTP is no longer a first-class citizen, why do we
need to treat it as such?


--
https://annevankesteren.nl/
unk...@googlegroups.com 4/14/15 1:53 AM <This message has been deleted.>
Re: Intent to deprecate: Insecure HTTP Alex C 4/14/15 1:54 AM
On Tuesday, April 14, 2015 at 8:44:25 PM UTC+12, Anne van Kesteren wrote:
> I don't follow. If HTTP is no longer a first-class citizen, why do we
> need to treat it as such?

When it would take more effort to disable a feature on HTTP than to let it work, and yet the feature is disabled anyway, that's more than just HTTP being "not a first class citizen".
Re: Intent to deprecate: Insecure HTTP Yoav Weiss 4/14/15 2:33 AM
On Tue, Apr 14, 2015 at 10:43 AM, Anne van Kesteren <ann...@annevk.nl>
wrote:

> On Tue, Apr 14, 2015 at 10:39 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> > Deprecating HTTP is totally justified. Enabling some features on HTTP but
> > not others is not, unless there's a real technical reason why these new
> > features shouldn't be enabled.
>
> I don't follow. If HTTP is no longer a first-class citizen, why do we
> need to treat it as such?
>

I'm afraid the second class citizens in that scenario would be the new
features, rather than HTTP.
Re: Intent to deprecate: Insecure HTTP intell...@gmail.com 4/14/15 2:42 AM
Op maandag 13 april 2015 16:57:58 UTC+2 schreef Richard Barnes:
> 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.

Each organisation has it own reasons to move away from HTTPS.
It doesn't mean that each of those reasons are ethical.


> In order to encourage web developers to move from HTTP to HTTPS

Why ?
Large multinationals do not allow HTTPS traffic within their border gateways of their own infrastructure, why make it harder for them?

Why give people the impression in the future that because they are using HTTPS they are much safer, but instead the implication are much larger. (no dependability anymore, forced to trust root-CA etc..)

Why force hosting companies and webmasters with extra costs ?


Do not forget that most used webmaster/webhoster controle panels do not support SNI, and that each HTTPS site has to have it own unique IP address.
Here in EUROPE we are still using IPv4 and RIPE can't issue new IPv4 address because they are all gone. So as long that isn't resolved it can't be done.


IMHO HTTPS would be safer if no larger companies or governments are involved with issuing the certificates, and the certificates would be free or somehow other wise being compensated.

The countries where the people have lesser profiting from HTTPS because human rights are more respected have the means to pay for SSL certificates, but the people who you want to protect don't and even if they would have, they always have a government(s) to deal with.

As long you think that ROOT-CA are 100% trustworthy and governments can't  manipulate or do a replay attack afterwards, HTTPS is the way to go... until that (and SNI/IPv4) issue are not handled, don't, because it will cause more harm in the long run.

Do not get me wrong, the intention is good. But trying to protect humanity from humanity also means to keep in mind the issues surrounding it.
Re: Intent to deprecate: Insecure HTTP Mike de Boer 4/14/15 3:11 AM

> On 14 Apr 2015, at 11:42, intell...@gmail.com wrote:
>

Something entirely off-topic: I’d like to inform people that your replies to popular threads like this unsigned, with only a notion of identity in an obscure email address, makes me - and I’m sure others too - skip your message or worse; not take it seriously. In my mind I fantasize your message signed off with something like:

"Cheers, mYLitTL3P0nIEZLuLZrAinBowZ.

 - Sent from a Galaxy Tab Nexuzzz Swift Super, Gold & Ruby Edition by an 8yr old stuck in Kindergarten.”

… which doesn’t feel like the identity anyone would prefer to assume.

Best, Mike.
Re: Intent to deprecate: Insecure HTTP Henri Sivonen 4/14/15 3:30 AM
On Mon, Apr 13, 2015 at 5:57 PM, Richard Barnes <rba...@mozilla.com> 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.

I agree that we should get the Web onto https and I'me very happy to
see this proposal.

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

I understand that especially in debates about crypto, there's a strong
desire to avoid ratholing and bikeshedding. However, I think avoiding
the discussion on which features are "powerful" is the wrong way to
get from the current situation to where we want to be.

Specifically:

 1) I expect the non-availability on http origins of e.g. new CSS
effects that are equally non-privacy-sensitive as existing CSS effects
just as a way to force sites onto https to create resentment among Web
devs that would be better avoided in order to have Web devs support
the cause of encrypting the Web and that could be avoided by
withholding features from http on grounds that tie clearly to the
downsides of http relative to https.

 2) I expect withholding certain *existing* privacy-sensitive features
from http to have a greater leverage to push sites to https than
withholding privacy-neutral *new* features.

Specifically, on point #2, I think we should start by, by default,
forgetting all cookies that don't have the "secure" flag set at the
end of the Firefox session. Persistent cookies have two main use
cases:
 * On login-requiring sites, not requiring the user to have to
re-enter credentials in every browser session.
 * Behavioral profiling.

The first has a clear user-facing benefit. The second is something
that users typically don't want and breaking it has no obvious
user-visible effect of breaking Web compat of the browser.

Fortunately, the most-used login-requiring sites use https already, so
forgetting insecure cookies at the end of the session would have no
adverse effect on the most-user-visible use of persistent cookies.
Also, if a login-requiring site is not already using https, it's
pretty non-controversial that they are Doing It Wrong and should
migrate to https.

One big reason why mostly content-oriented sites, such as news sites,
haven't migrated to https is that they are ad-funded and the
advertising networks are lagging behind in https deployment. Removing
persistence from insecure cookies would give a reason for the ad
networks to accelerate https deployment and do so in a way that
doesn't break the Web in user-visible ways during the transition. That
is, if ad networks want to track users, at least they shouldn't enable
collateral tracking by network eavesdroppers while doing so.

So I think withholding cookie persistence from insecure cookies could
well be way more effective per unit of disruption of user-perceived
Web compat than anything in your proposal.

In addition to persistent cookies, I think we should seek to be more
aggressive in making other features that allow sites to store
persistent state on the client https-only than in making new features
in general https-only. (I realize that applying this consistently to
the HTTP cache could be infeasible on performance grounds in the near
future at least.)

Furthermore, I think this program should have a UI aspect to it:
Currently, the UI designation for http is neutral while the UI
designation for mixed content is undesirable. I think we should make
the UI designation of plain http undesirable once x% the sites that
users encounter on a daily basis are https. Since users don't interact
with the whole Web equally, this means that the UI for http would be
made undesirable much earlier than the time when x% of Web sites
migrates to https. x should be chosen to be high enough as to avoid
warning fatigue that'd desensitize users to the undesirable UI
designation.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/
Re: Intent to deprecate: Insecure HTTP Boris Zbarsky 4/14/15 4:47 AM
On 4/14/15 3:28 AM, Anne van Kesteren wrote:
> On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost <kdu...@mozilla.com> wrote:
>> 1. You do not need to register a domain name to have a Web site (IP address)
>
> Name one site you visit regularly that doesn't have a domain name.

My router's configuration UI.  Here "regularly" is probably once a month
or so.

> And even then, you can get certificates for public IP addresses.

It's not a public IP address.

We do need a solution for this space, which I expect includes the
various embedded devices people are bringing up; I expect those are
behind firewalls more often than on the publicly routable internet.

-Boris
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/14/15 4:53 AM
> Something entirely off-topic: I'd like to inform people that your replies to popular threads like this unsigned, with only a notion of identity in an obscure email address, makes me - and I'm sure others too - skip your message or worse; not take it seriously.


Not everyone has the luxury of being public on the Internet.  Especially in discussions about default Internet encryption.  The real decision makers won't be posting at all.
Re: Intent to deprecate: Insecure HTTP Eric Shepherd 4/14/15 5:32 AM
Joshua Cranmer 🐧 wrote:
> If you actually go to read the details of the proposal rather than
> relying only on the headline, you'd find that there is an intent to
> actually let you continue to use http for, e.g., localhost. The exact
> boundary between "secure" HTTP and "insecure" HTTP is being actively
> discussed in other forums.
My main concern with the notion of phasing out unsecured HTTP is that
doing so will cripple or eliminate Internet access by older devices that
aren't generally capable of handling encryption and decryption on such a
massive scale in real time.

While it may sound silly, those of us who are intro classic computers
and making them do fun new things use HTTP to connect 10 MHz (or even 1
MHz) machines to the Internet. These machines can't handle the demands
of SSL. So this is a step toward making their Internet connections go away.

This may not be enough of a reason to save HTTP, but it's something I
wanted to point out.

--

Eric Shepherd
Senior Technical Writer
Mozilla <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/14/15 5:36 AM
Yep. That's the system working. CA does something they shouldn't, we
find out, CA is no longer trusted (perhaps for a time).

Or do you have an alternative system design where no-one ever makes a
mistake and all the actors are trustworthy?

Gerv

Re: Intent to deprecate: Insecure HTTP ena...@gmail.com 4/14/15 5:37 AM
On Tuesday, April 14, 2015 at 3:05:09 AM UTC-5, Anne van Kesteren wrote:

> This definitely needs more research
> but shouldn't preclude rolling out HTTPS on public resources.

The proposal as presented is not limited to public resources. The W3C Privileged Context draft which it references exempts only localhost and file:/// resources, not resources on private networks. There are hundreds of millions of home routers and similar devices with web UIs on private networks, and no clear path under this proposal to keep them fully accessible (without arbitrary feature limitations) except to set up your own local CA, which is excessively burdensome.

Eli Naeher
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/14/15 5:39 AM
On 14/04/15 01:57, northrupt...@gmail.com wrote:
> * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do
> with HTTPS+selfsigned now); the fact that self-signed HTTPS is
> treated as less secure than HTTP is - to put this as politely and
> gently as possible - a pile of bovine manure

http://gerv.net/security/self-signed-certs/ , section 3.

But also, Firefox is implementing opportunistic encryption, which AIUI
gives you a lot of what you want here.

Gerv

Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/14/15 5:45 AM
On 14/04/15 08:51, lorenz...@gmail.com wrote:
> 1) Caching proxies: resources obtained over HTTPS cannot be cached by
> a proxy that doesn't use MITM certificates. If all users must move to
> HTTPS there will be no way to re-use content downloaded for one user
> to accelerate another user. This is an important issue for locations
> with many users and poor internet connectivity.

Richard talked, IIRC, about not allowing subloads over HTTP with
subresource integrity. This is one argument to the contrary. Sites could
use HTTP-with-integrity to provide an experience which allowed for
better caching, with the downside being some loss of coarse privacy for
the user. (Cached resources, by their nature, are not going to be
user-specific, so there won't be leak of PII. But it might leak what you
are reading or what site you are on.)

Gerv
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/14/15 5:47 AM
> Yep. That's the system working. CA does something they shouldn't, we
> find out, CA is no longer trusted (perhaps for a time).
>
> Or do you have an alternative system design where no-one ever makes a
> mistake and all the actors are trustworthy?
>
> Gerv

Yes - as I said previously.  Do the existing certificate checks to a trusted CA root, then do a TLSA DNS look up for the certificate PIN and check that *as well*.  If you did this (and Google publish their SHA512 hashes in DNS) you'd could have had lots of copies of Firefox ringing back "potential compromise" messages.  Who knows how long those certificates were out there (or what other ones are currently out there that you could find just by implementing TLSA).

The more routes to the trust the better.  Trusted Root CA is "all eggs in one basket".  DANE is "all eggs in one basket", DNSSEC is "all eggs in one basket".

Put them all together and you have a pretty reliable basket :)

This is what I mean by working a security rating A,B,C,D,Fail - not just a "yes/no" answer.
Re: Intent to deprecate: Insecure HTTP hugoosval...@gmail.com 4/14/15 6:57 AM
I'm curious as to what would happen with things that cannot have TLS certificates: routers and similar web-configurable-only devices (like small PBX-like devices, etc).

They don't have a proper domain, and may grab an IP via radvd (or dhcp on IPv4), so there's no certificate to be had.

They'd have to use self-signed, which seems to be treated pretty badly (warning message, etc).

Would we be getting rid of the self-signed warning when visiting a website?
Re: Intent to deprecate: Insecure HTTP Aryeh Gregor 4/14/15 7:01 AM
On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham <ge...@mozilla.org> wrote:
> Yep. That's the system working. CA does something they shouldn't, we
> find out, CA is no longer trusted (perhaps for a time).
>
> Or do you have an alternative system design where no-one ever makes a
> mistake and all the actors are trustworthy?

No, but it would make sense to require that sites be validated through
a single specific CA, rather than allowing any CA to issue a
certificate for any site.  That would drastically reduce the scope of
attacks: an attacker would have to compromise a single specific CA,
instead of any one of hundreds.  IIRC, HSTS already allows this on an
opt-in basis.  If validation was done via DNSSEC instead of the
existing CA system, this would follow automatically, without sites
having to commit to a single CA.  It also avoids the bootstrapping
problem with HSTS, unless someone has solved that in some other way
and I didn't notice.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 7:11 AM
On Mon, Apr 13, 2015 at 5:11 PM, <bryan....@gmail.com> wrote:

> One limiting factor is that Firefox doesn't treat form data the same on
> HTTPS sites.
>
> Examples:
>
>
> http://stackoverflow.com/questions/14420624/how-to-keep-changed-form-content-when-leaving-and-going-back-to-https-page-wor
>
>
> http://stackoverflow.com/questions/10511581/why-are-html-forms-sometimes-cleared-when-clicking-on-the-browser-back-button
>
> After loosing a few forum posts or wiki edits to this bug in Firefox, you
> quickly insist on using unsecured HTTP as often as possible.
>

Interesting observation.  ISTM that that's a bug in HTTPS.  At least I
don't see an obvious security reason for the behavior to be that way.

More generally: I expect that this process will turn up bugs in HTTPS
behavior, either "actual" bugs in terms of implementation errors, or
"logical" bugs where the intended behavior does not meet the expectations
or needs of websites.  So we should be open to adapting our HTTPS behavior
some (within the bounds of the security requirements) in order to
facilitate this transition.

--Richard



> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 7:15 AM
On Mon, Apr 13, 2015 at 7:03 PM, Martin Thomson <m...@mozilla.com> wrote:

> On Mon, Apr 13, 2015 at 3:53 PM, Eugene <imfasterth...@gmail.com>
> wrote:
> > In addition to APIs, I'd like to propose prohibiting caching any
> resources loaded over insecure HTTP, regardless of Cache-Control header, in
> Phase 2.N.
>
> This has some negative consequences (if only for performance).  I'd
> like to see changes like this properly coordinated.  I'd rather just
> treat "caching" as one of the features for Phase 2.N.
>

That seem sensible.

I was about to propose a lifetime limit on caching (say a few hours?) to
limit the persistence scope of MitM, i.e., require periodic re-infection.
There may be ways to circumvent this (e.g., the MitM's code sending cache
priming requests), but it seems incrementally better.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 4/14/15 7:16 AM
On Tue, Apr 14, 2015 at 7:01 AM, Aryeh Gregor <a...@aryeh.name> wrote:

> On Tue, Apr 14, 2015 at 3:36 PM, Gervase Markham <ge...@mozilla.org> wrote:
> > Yep. That's the system working. CA does something they shouldn't, we
> > find out, CA is no longer trusted (perhaps for a time).
> >
> > Or do you have an alternative system design where no-one ever makes a
> > mistake and all the actors are trustworthy?
>
> No, but it would make sense to require that sites be validated through
> a single specific CA, rather than allowing any CA to issue a
> certificate for any site.  That would drastically reduce the scope of
> attacks: an attacker would have to compromise a single specific CA,
> instead of any one of hundreds.  IIRC, HSTS already allows this on an
> opt-in basis.


This is called "pinning".

https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-21


>   If validation was done via DNSSEC instead of the
> existing CA system, this would follow automatically, without sites
> having to commit to a single CA.


Note that pinning does not require sites to commit to a single CA. You can
pin
multiple CAs.

Using DNS and DNSSEC for this purpose is described in
http://tools.ietf.org/html/rfc6698.
However, to my knowledge no mainstream browser presently accepts DANE/TLSA
authentication for reasons already described upthread.

-Ekr
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 7:17 AM
On Mon, Apr 13, 2015 at 9:43 PM, <imfasterth...@gmail.com> wrote:

> On Monday, April 13, 2015 at 8:57:41 PM UTC-4, northrupt...@gmail.com
> wrote:
> >
> > * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
> HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less
> secure than HTTP is - to put this as politely and gently as possible - a
> pile of bovine manure
>
> This feature (i.e. opportunistic encryption) was implemented in Firefox
> 37, but unfortunately an implementation bug made HTTPS insecure too. But I
> guess Mozilla will fix it and make this feature available in a future
> release.
>
> > * Support for a decentralized (blockchain-based, ala Namecoin?)
> certificate authority
> >
> > Basically, the current CA system is - again, to put this as gently and
> politely as possible - fucking broken.  Anything that forces the world to
> rely on it exclusively is not a solution, but is instead just going to make
> the problem worse.
>
> I don't think the current CA system is broken. The domain name
> registration is also centralized, but almost every website has a hostname,
> rather than using IP address, and few people complain about this.
>

I would also note that Mozilla is contributing heavily to Let's Encrypt,
which is about as close to a decentralized CA as we can get with current
technology.

If people have ideas for decentralized CAs, I would be interested in
listening, and possibly adding support in the long run.  But unfortunately,
the state of the art isn't quite there yet.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 7:18 AM
On Mon, Apr 13, 2015 at 11:26 PM, <ipar...@gmail.com> wrote:

> > * Less scary warnings about self-signed certificates (i.e. treat
> HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with
> HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less
> secure than HTTP is - to put this as politely and gently as possible - a
> pile of bovine manure
>
> I am against this. Both are insecure and should be treated as such. How is
> your browser supposed to know that gmail.com is intended to serve a
> self-signed cert? It's not, and it cannot possibly know it in the general
> case. Thus it must be treated as insecure.
>

This is a good point.  This is exactly why the opportunistic security
feature in Firefox 37 enables encryption without certificate checks for
*http* resources.

--Richard



> > * Support for a decentralized (blockchain-based, ala Namecoin?)
> certificate authority
>
> No. Namecoin has so many other problems that it is not feasible.
>
> > Basically, the current CA system is - again, to put this as gently and
> politely as possible - fucking broken.  Anything that forces the world to
> rely on it exclusively is not a solution, but is instead just going to make
> the problem worse.
>
> Agree that it's broken. The fact that any CA can issue a cert for any
> domain is stupid, always was and always will be. It's now starting to bite
> us.
>
> However, HTTPS and the CA system don't have to be tied together. Let's
> ditch the immediately insecure plain HTTP, then add ways to authenticate
> trusted certs in HTTPS by means other than our current CA system. The two
> problems are orthogonal, and trying to solve both at once will just leave
> us exactly where we are: trying to argue for a fundamentally different
> system.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 7:40 AM
On Mon, Apr 13, 2015 at 10:10 PM, Karl Dubost <kdu...@mozilla.com> wrote:

>
> Le 14 avr. 2015 à 10:43, imfasterth...@gmail.com a écrit :
> > I don't think the current CA system is broken.
>
> The current CA system creates issues for certain categories of population.
> It is broken in some ways.
>
> > The domain name registration is also centralized, but almost every
> website has a hostname, rather than using IP address, and few people
> complain about this.
>
> Two points:
>
> 1. You do not need to register a domain name to have a Web site (IP
> address)
> 2. You do not need to register a domain name to run a local blah.test.site
>
> Both are still working and not deprecated in browsers ^_^
>
> Now the fact to have to rent your domain name ($$$) and that all the URIs
> are tied to this is in terms of permanent identifiers and the fabric of
> time on information has strong social consequences. But's that another
> debate than the one of this thread on deprecating HTTP in favor of HTTPS.
>

This is a fair point, and we should probably figure out a way to
accommodate these.  My inclination is to mostly punt this to manual
configuration (e.g., installing a new trusted cert/override), since we're
not talking about generally available public service on the Internet.  But
if there are more elegant solutions that don't reduce security, I would be
interested to hear them.



> I would love to see this discussion happening in Whistler too.
>

Agreed.  That sounds like an excellent opportunity to hammer out details
here, assuming we can agree on overall  direction in the meantime.

--Richard



>
> --
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 8:01 AM
On Tue, Apr 14, 2015 at 3:55 AM, Yoav Weiss <yo...@yoav.ws> wrote:

> On Tue, Apr 14, 2015 at 8:22 AM, Anne van Kesteren <ann...@annevk.nl>
> wrote:
>
> > On Tue, Apr 14, 2015 at 7:52 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> > > Limiting new features does absolutely nothing in that aspect.
> >
> > Hyperbole much? CTO of the New York Times cited HTTP/2 and Service
> > Workers as a reason to start deploying HTTPS:
> >
> >   http://open.blogs.nytimes.com/2014/11/13/embracing-https/
>
>
> I stand corrected. So it's the 8th reason out of 9, right before technical
> debt.
>
> I'm not saying using new features is not an incentive, and I'm definitely
> not saying HTTP2 and SW should have been enabled on HTTP.
> But, when done without any real security or deployment issues that mandate
> it, you're subjecting new features to significant adoption friction that is
> unrelated to the feature itself, in order to apply some indirect pressure
> on businesses to do the right thing.
>

Please note that there is no inherent security reason to limit HTTP/2 to be
used only over TLS (as there is for SW), at least not any more than the
security reasons for carrying HTTP/1.1 over TLS.  They're semantically
equivalent; HTTP/2 is just faster.  So if you're OK with limiting HTTP/2 to
TLS, you've sort of already bought into the strategy we're proposing here.



> You're inflicting developer pain without any real justification. A sort of
> collective punishment, if you will.
>
> If you want to apply pressure, apply it where it makes the most impact with
> the least cost. Limiting new features to HTTPS is not the place, IMO.
>

I would note that these options are not mutually exclusive :)  We can apply
pressure with feature availability at the same time that we work on the
ecosystem problems.  In fact, I had a call with some advertising folks last
week about how to get the ad industry upgraded to HTTPS.

--Richard



>
>
> >
> > (And anecdotally, I find it easier to convince developers to deploy
> > HTTPS on the basis of some feature needing it than on merit. And it
> > makes sense, if they need their service to do X, they'll go through
> > the extra trouble to do Y to get to X.)
> >
> >
> Don't convince the developers. Convince the business. Drive users away to
> secure services by displaying warnings, etc.
> Anecdotally on my end, I saw small Web sites that care very little about
> security, move to HTTPS over night after Google added HTTPS as a (weak)
> ranking signal
> <
> http://googlewebmastercentral.blogspot.fr/2014/08/https-as-ranking-signal.html
> >.
> (reason #4 in that NYT article)
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 8:09 AM
On Tue, Apr 14, 2015 at 8:32 AM, Eric Shepherd <eshe...@mozilla.com>
wrote:

> Joshua Cranmer [image: 🐧] wrote:
>
>> If you actually go to read the details of the proposal rather than
>> relying only on the headline, you'd find that there is an intent to
>> actually let you continue to use http for, e.g., localhost. The exact
>> boundary between "secure" HTTP and "insecure" HTTP is being actively
>> discussed in other forums.
>>
> My main concern with the notion of phasing out unsecured HTTP is that
> doing so will cripple or eliminate Internet access by older devices that
> aren't generally capable of handling encryption and decryption on such a
> massive scale in real time.
>
> While it may sound silly, those of us who are intro classic computers and
> making them do fun new things use HTTP to connect 10 MHz (or even 1 MHz)
> machines to the Internet. These machines can't handle the demands of SSL.
> So this is a step toward making their Internet connections go away.
>
> This may not be enough of a reason to save HTTP, but it's something I
> wanted to point out.


As the owner of a Mac SE/30 with an 100MB Ethernet card, I sympathize.
However, consider it part of the challenge!  :)  There are definitely TLS
stacks that work on some pretty small devices.

--Richard



>
>
> --
>
> Eric Shepherd
> Senior Technical Writer
> Mozilla <https://www.mozilla.org/>
> Blog: http://www.bitstampede.com/
> Twitter: http://twitter.com/sheppy
>
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 8:14 AM
Well, no. :)

Note that the primary difference between opportunistic security (which is
HTTP) and HTTPS is authentication.  We should think about what sorts of
expectations people have for these devices, and to what degree those
expectations can be met.

Since you bring up IPv6, there might be some possibility that devices could
authenticate their IP addresses automatially, using cryptographically
generated addresses and self-signed certificates using the same public key.
http://en.wikipedia.org/wiki/Cryptographically_Generated_Address

--Richard
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 8:24 AM
On Mon, Apr 13, 2015 at 7:13 PM, Karl Dubost <kdu...@mozilla.com> wrote:

> Richard,
>
> Le 13 avr. 2015 à 23:57, Richard Barnes <rba...@mozilla.com> a écrit :
> > There's pretty broad agreement that HTTPS is the way forward for the web.
>
> Yes, but that doesn't make deprecation of HTTP a consensus.
>
> > 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.
>
> This is not encouragement. This is call forcing. ^_^ Just that we are
> using the right terms for the right thing.
>

If so, then it's about the most gentle forcing we could do.  If your web
page works today over HTTP, it will continue working for a long time,
O(years) probably, until we get around to removing features you care about.

The idea of this proposal is to start communicating to web site operators
that in the *long* run, HTTP will no longer be viable, while giving them
time to transition.



> In the document
> >
> https://docs.google.com/document/d/1IGYl_rxnqEvzmdAP9AJQYY2i2Uy_sW-cg9QI9ICe-ww/edit?usp=sharing
>
> You say:
>         Phase 3: Essentially all of the web is HTTPS.
>
> I understand this is the last hypothetical step, but it sounds like a bit
> let's move the Web to XML. It didn't work out very well.
>

The lack of XML doesn't enable things like the Great Cannon.
https://citizenlab.org/2015/04/chinas-great-cannon/



> I would love to have a more secure Web, but this can not happen without a
> few careful consideration.
>
> * Third tier person for certificates being mandatory is a no-go. It
> creates a system of authority and power, an additional layer of hierarchy
> which deeply modify the ability for anyone to publish and might in some
> circumstances increase the security risk.
>
> * If we have to rely, cost of certificates must be zero. These for the
> simple reason than not everyone is living in a rich industrialized country.
>

There are already multiple sources of free publicly-trusted certificates,
with more on the way.
https://www.startssl.com/
https://buy.wosign.com/free/
https://blog.cloudflare.com/introducing-universal-ssl/
https://letsencrypt.org/



> * Setup and publication through HTTPS should be as easy as HTTP. The Web
> brought a publishing power to any individuals. Imagine cases where you need
> to create a local network, web developing on your computer, hacking a
> server for your school, community, etc. If it relies on a heavy process, it
> will not happen.
>

I agree that we should work on this, and Let's Encrypt is making a big push
in this direction.  However, we're not that far off today.   Most hosting
platforms already allow HTTPS with only a few more clicks.  If you're
running your own server, there's lots of documentation, including
documentation provided by Mozilla:

https://mozilla.github.io/server-side-tls/ssl-config-generator/?1

In other words, this is a gradual plan, and while you've raised some
important things to work on, they shouldn't block us getting started.

--Richard




>
>
> So instead of a plan based on technical features, I would love to see a:
> "Let's move to a secure Web. What are the user scenarios, we need to solve
> to achieve that."
>
> These user scenarios are economical, social, etc.
>
>
> my 2 cents.
> So yes, but not the way it is introduced and plan now.
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/14/15 8:39 AM

> There are already multiple sources of free publicly-trusted certificates,
> with more on the way.
> https://www.startssl.com/
> https://buy.wosign.com/free/
> https://blog.cloudflare.com/introducing-universal-ssl/
> https://letsencrypt.org/
>

I think that you should avoid making this an exercise in marketing Mozilla's "Let's Encrypt" initiative.  "Let's Encrypt" is a great idea and definitely has a place in the world, but it's very important to be impartial.

In my mind there is no particular advantage in swapping lock in from one CA to another.  Even if the Mozilla one is free.  
Re: Intent to deprecate: Insecure HTTP justin...@gmail.com 4/14/15 8:53 AM
Dynamic DNS might be difficult to run on HTTPS as the IP address needs to change when say your cable modem IP updates.  HTTPS only would make running personal sites more difficult for individuals, and would make the internet slightly less democratic.

On Monday, April 13, 2015 at 7:57:58 AM UTC-7, 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

Re: Intent to deprecate: Insecure HTTP Adam Roach 4/14/15 9:02 AM
On 4/14/15 10:53, justin...@gmail.com wrote:
> Dynamic DNS might be difficult to run on HTTPS as the IP address needs to change when say your cable modem IP updates.  HTTPS only would make running personal sites more difficult for individuals, and would make the internet slightly less democratic.

I'm not sure I follow. I have a cert for a web site running on a dynamic
address using DynDNS, and it works just fine. Certs are bound to names,
not addresses.

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
Re: Intent to deprecate: Insecure HTTP Boris Zbarsky 4/14/15 9:07 AM
On 4/14/15 11:53 AM, justin...@gmail.com wrote:
> Dynamic DNS might be difficult to run on HTTPS as the IP address needs to change when say your cable modem IP updates.

Justin, I'm not sure I follow the problem here.  If I understand
correctly, you're talking about a domain name, say "foo.bar", which is
mapped to different IPs via dynamic DNS, and a website running on the
machine behind the relevant cable modem, right?

Is the site being accessed directly via the IP address or via the
foo.bar hostname?  Because if it's the latter, then a cert issued to
foo.bar would work fine as the IP changes; certificates are bound to a
hostname string (which can happen to have the form "123.123.123.123", of
course), not an IP address.

And if the site is being accessed via (changeable) IP address, then how
is dynamic DNS relevant?

I would really appreciate an explanation of what problem you're seeing
here that I'm missing.

-Boris
Re: Intent to deprecate: Insecure HTTP j...@chromium.org 4/14/15 9:47 AM
Hi Mozilla friends. Glad to see this proposal! As Richard mentions, we over on Chromium are working on a similar plan, albeit limited to "powerful features."

I just wanted to mention that regarding subresource integrity (https://w3c.github.io/webappsec/specs/subresourceintegrity/), the general consensus over here is that we will not treat origins as secure if they are over HTTP but loaded with integrity. We believe that security includes confidentiality, which that would approach would lack.
--Joel
Re: Intent to deprecate: Insecure HTTP mh.in...@gmail.com 4/14/15 10:09 AM
> We believe that security includes confidentiality, which that would approach would lack.

Hey Joel,

SSL already leaks which domain name you are visiting anyway, so the most confidentiality this can bring you is hiding the specific URL involved in a cache miss. That's a fairly narrow upgrade to confidentiality.

A scenario where it would matter: a MITM wishes to block viewing of a specific video on a video hosting site, but is unwilling to block the whole site. In such cases you would indeed want full SSL, assuming the host can afford it.

A scenario where it would not matter: some country wishes to fire a Great Cannon. There integrity is enough.

I think the case for requiring integrity for all connections is strong: malware injection is simply not on. The case for confidentiality of user data and cookies is equally clear. The case for confidentiality of cache misses of static assets is a bit less clear:  sites that host a lot of very different content like YouTube might care and a site where all the content is the same (e.g. a porn site) might feel the difference between a URL and a domain name is so tiny that it's irrelevant - they'd rather have the performance improvements from caching proxies. Sites that have a lot of users in developing countries might also feel differently to Google engineers with workstations hard-wired into the internet backbone ;)

Anyway, just my 2c.
Re: Intent to deprecate: Insecure HTTP Martin Thomson 4/14/15 10:21 AM
On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:
> Specifically, on point #2, I think we should start by, by default,
> forgetting all cookies that don't have the "secure" flag set at the
> end of the Firefox session. Persistent cookies have two main use
> cases:
>  * On login-requiring sites, not requiring the user to have to
> re-enter credentials in every browser session.
>  * Behavioral profiling.

This is a reasonable proposal.  I think that this, as well as the
caching suggestion up-thread, fall into the general category of things
we've identified as "persistence" features.  Persistence has been
identified as one of the most dangerous aspects of the unsecured web.

I like this sort of approach, because it can be implemented at a much
lower https:// adoption rate (i.e., today's rate) than other more
obvious things.
Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 4/14/15 10:39 AM
Richard Barnes wrote:
> As the owner of a Mac SE/30 with an 100MB Ethernet card, I
> sympathize.  However, consider it part of the challenge!  :)  There
> are definitely TLS stacks that work on some pretty small devices.
That's a lot faster machine than the ones I play with. My fastest retro
machine is an 8-bit unit with a 10 MHz processor and 4 MB of memory,
with a 10 Mbps ethernet card. And the ethernet is underutilized because
the bus speed of the computer is too slow to come anywhere close to
saturating the bandwidth available. :)
Re: Intent to deprecate: Insecure HTTP conno...@gmail.com 4/14/15 11:26 AM
HTTPS has its moments, but the majority of the web does not need it. I certainly wouldn't appreciate the encryption overhead just for visiting David's lolcats website. As one of the most important organizations related to free software, it's sad to see Mozilla developers join the war on plaintext: http://arc.pasp.de/ The owners of websites like this have a right to serve their pages in formats that do not make hypocrites of themselves.
Re: Intent to deprecate: Insecure HTTP emmanuel...@gmail.com 4/14/15 1:35 PM
Hello,

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.
>
> <snip>
>
> Thanks,
> --Richard

While I fully understand what's at stake here and the reasoning behind this, I'd like to ask an admittedly troll-like question :

  Will Mozilla start to offer certificates to every single domain name owner ?

Without that, your proposal tells me: either you pay for a certificate or you don't use the latest supported features on your personal (or professional) web site. This is a call for a revival of the "best viewed with XXX browser" banners.

Making the warning page easier to bypass is a very, very bad idea. The warning page is here for a very good reason, and its primary function is to scare non-technical literate people so that they don't put themselves in danger. Make it less scary and you'll get the infamous Windows Vista UAC dialog boxes where people click OK without even reading the content.

The proposal fails to foresee another consequence of a full HTTPS web: the rise and fall of root CAs. If everyone needs to buy a certificate you can be sure that some companies will sell them for a low price, with limited background check. These companies will be spotted - and their root CA will be revoked by browser vendors (this already happened in the past and I fail to see any reason why it would not happen again). Suddenly, a large portion of the web will be seen as even worse than "insecure HTTP" - it will be seen as "potentially dangerous HTTPS". The only way to avoid this situation is to put all the power in a very limited number of hands - then you'll witness a sharp rise on certificate prices.

Finally, Mozilla's motto is to keep the web open. Requiring one to pay a fee - even if it's a small one - in order to allow him to have a presence on the Intarweb is not helping.

Best regards,

-- Emmanuel Deloget
Re: Intent to deprecate: Insecure HTTP Adam Roach 4/14/15 1:45 PM
On 4/14/15 15:35, emmanuel...@gmail.com wrote:
> Will Mozilla start to offer certificates to every single domain name owner ?

Yes [1].

https://letsencrypt.org/


____
[1] I'll note that Mozilla is only one of several organizations involved
in making this effort happen.
Re: Intent to deprecate: Insecure HTTP Chris Peterson 4/14/15 2:30 PM
On 4/14/15 3:29 AM, Henri Sivonen wrote:
> Specifically, on point #2, I think we should start by, by default,
> forgetting all cookies that don't have the "secure" flag set at the
> end of the Firefox session. Persistent cookies have two main use
> cases:
>   * On login-requiring sites, not requiring the user to have to
> re-enter credentials in every browser session.
>   * Behavioral profiling.

I searched for an existing bug to treat non-secure cookies as session
cookies, but I couldn't find one.

However, I did find bug 530594 ("eternalsession"). Firefox's session
restore, as the name suggests, restores session cookies even after the
user quits and restarts the browser. This is somewhat surprising, but
the glass-half-full perspective is that the negative effects of Henri's
suggestion would be lessened (until bug 530594 is fixed).
Re: Intent to deprecate: Insecure HTTP northrupt...@gmail.com 4/14/15 2:32 PM
On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote:
> > * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure
>
> I am against this. Both are insecure and should be treated as such. How is your browser supposed to know that gmail.com is intended to serve a self-signed cert? It's not, and it cannot possibly know it in the general case. Thus it must be treated as insecure.

Except that one is encrypted, and the other is not.  *By logical measure*, the one that is encrypted but unauthenticated is more secure than the one that is neither encrypted nor authenticated, and the fact that virtually every HTTPS-supporting browser assumes the precise opposite is mind-boggling.

I agree that authentication/verification is necessary for security, but to pretend that encryption is a non-factor when it's the only actual subject of this thread as presented by its creator is asinine.

>
> > * Support for a decentralized (blockchain-based, ala Namecoin?) certificate authority
>
> No. Namecoin has so many other problems that it is not feasible.

Like?

And I'm pretty sure none of those problems (if they even exist) even remotely compare to the clusterfsck that is our current CA system.

>
> > Basically, the current CA system is - again, to put this as gently and politely as possible - fucking broken.  Anything that forces the world to rely on it exclusively is not a solution, but is instead just going to make the problem worse.
>
> Agree that it's broken. The fact that any CA can issue a cert for any domain is stupid, always was and always will be. It's now starting to bite us.
>
> However, HTTPS and the CA system don't have to be tied together. Let's ditch the immediately insecure plain HTTP, then add ways to authenticate trusted certs in HTTPS by means other than our current CA system. The two problems are orthogonal, and trying to solve both at once will just leave us exactly where we are: trying to argue for a fundamentally different system.

Indeed they don't, but with the current ecosystem they are, which is my point; by deprecating HTTP *and* continuing to treat self-signed certs as literally worse than Hitler *and* relying on the current CA system exclusively for verification of certificates, we're doing nothing to actually solve anything.

As orthogonal as those problems may seem, an HTTPS-only world will fail rather spectacularly without significant reform and refactoring on the CA side of things.
Re: Intent to deprecate: Insecure HTTP Cameron Kaiser 4/14/15 2:51 PM
On 4/14/15 10:38 AM, Eric Shepherd wrote:
> Richard Barnes wrote:
>> As the owner of a Mac SE/30 with an 100MB Ethernet card, I
>> sympathize.  However, consider it part of the challenge!  :)  There
>> are definitely TLS stacks that work on some pretty small devices.
> That's a lot faster machine than the ones I play with. My fastest retro
> machine is an 8-bit unit with a 10 MHz processor and 4 MB of memory,
> with a 10 Mbps ethernet card. And the ethernet is underutilized because
> the bus speed of the computer is too slow to come anywhere close to
> saturating the bandwidth available. :)

Candidly, and not because I still run such a site, I've always found
Gopher to be a better fit for resource-constrained computing. The
Commodore 128 sitting next to me does very well for that because the
protocol and menu parsing conventions are incredibly trivial.

What is your 10MHz 8-bit system?

Cameron Kaiser
gopher://gopher.floodgap.com/
Re: Intent to deprecate: Insecure HTTP Adam Roach 4/14/15 2:57 PM
On 4/14/15 16:32, northrupt...@gmail.com wrote:
> *By logical measure*, the [connection] that is encrypted but unauthenticated is more secure than the one that is neither encrypted nor authenticated, and the fact that virtually every HTTPS-supporting browser assumes the precise opposite is mind-boggling.

That depends on what kind of resource you're trying to access. If the
resource you're trying to reach (in both circumstances) isn't demanding
security -- i.e., it is an "http" URL -- then your logic is sound.
That's the basis for enabling OE.

The problem here is that you're comparing:

  * Unsecured connections working as designed

with

  * Supposedly secured connections that have a detected security flaw


An "https" URL is a promise of encryption _and_ authentication; and when
those promises are violated, it's a sign that something has gone wrong
in a way that likely has stark security implications.

Resources loaded via an "http" URL make no such promises, so the
situation isn't even remotely comparable.
Re: Intent to deprecate: Insecure HTTP northrupt...@gmail.com 4/14/15 2:59 PM
On Tuesday, April 14, 2015 at 5:39:24 AM UTC-7, Gervase Markham wrote:
> On 14/04/15 01:57, northrupt...@gmail.com wrote:
> > * Less scary warnings about self-signed certificates (i.e. treat
> > HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do
> > with HTTPS+selfsigned now); the fact that self-signed HTTPS is
> > treated as less secure than HTTP is - to put this as politely and
> > gently as possible - a pile of bovine manure
>
> http://gerv.net/security/self-signed-certs/ , section 3.

That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap.

The article assumes that when folks connect to something via SSH and something changes - causing MITM-attack warnings and a refusal to connect - folks default to just removing the existing entry in ~/.ssh/known_hosts without actually questioning anything.  This conveniently ignores the fact that - when people do this - it's because they already know there's been a change (usually due to a server replacement); most folks (that I've encountered at least) *will* stop and think before editing their known_hosts if it's an unexpected change.

"The first important thing to note about this model is that key changes are an expected part of life."

Only if they've been communicated first.  In the vast majority of SSH deployments, a host key will exist at least as long as the host does (if not longer).  If one is going to criticize SSH's model, one should, you know, actually freaking understand it first.

"You can't provide [Joe Public] with a string of hex characters and expect it to read it over the phone to his bank."

Sure you can.  Joe Public *already* has to do this with social security numbers, credit card numbers, checking/savings account numbers, etc. on a pretty routine basis, whether it's over the phone, over the Internet, by mail, in person, or what have you.  What makes an SSH fingerprint any different?  The fact that now you have the letters A through F to read?  Please.

"Everyone can [install a custom root certificate] manually or the IT department can use the Client Customizability Kit (CCK) to make a custom Firefox. "

I've used the CCK in the past for Firefox customizations in enterprise settings.  It's a royal pain in the ass, and is not nearly as viable a solution as the article suggests (and the alternate suggestion of "oh just use the broken, arbitrarily-trusted CA system for your internal certs!" is a hilarious joke at best; the author of the article would do better as a comedian than as a serious authority when it comes to security best practices).

A better solution might be to do this on a client workstation level, but it's still a pain and usually not worth the trouble for smaller enterprises v. just sticking to the self-signed cert.

The article, meanwhile, also assumes (in the section before the one you've cited) that the CA system is immune to being compromised while DNS is vulnerable.  Anyone with a number of brain cells greater than or equal to one should know better than to take that assumption at face value.

>
> But also, Firefox is implementing opportunistic encryption, which AIUI
> gives you a lot of what you want here.
>
> Gerv

Then that needs to happen first.  Otherwise, this whole discussion is moot, since absolutely nobody in their right mind would want to be shoehorned into our current broken CA system without at least *some* alternative.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/14/15 3:23 PM
OE shipped in Firefox 37.  It's currently turned off pending a bugfix, but
it will be back soon.
Re: Intent to deprecate: Insecure HTTP Joshua Cranmer �� 4/14/15 3:25 PM
On 4/14/2015 4:59 PM, northrupt...@gmail.com wrote:
> The article assumes that when folks connect to something via SSH and  > something changes - causing MITM-attack warnings and a refusal to >
connect - folks default to just removing the existing entry in >
~/.ssh/known_hosts without actually questioning anything.  This >
conveniently ignores the fact that - when people do this - it's >
because they already know there's been a change (usually due to a >
server replacement); most folks (that I've encountered at least) >
*will* stop and think before editing their known_hosts if it's an >
unexpected change.
I've had an offending key at least 5 times. Only once did I seriously
think to consider what specifically had changed to cause the ssh key to
change. The other times, I assumed there was a good reason and deleted it.

This illustrates a very, very, very important fact about UX: the more
often people see a dialog, the more routine it becomes to deal with
it--you stop considering whether or not it applies, because it's always
applied and it's just yet another step you have to go through to do it.

--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

Re: Intent to deprecate: Insecure HTTP commod...@gmail.com 4/14/15 3:47 PM
On Tuesday, April 14, 2015 at 2:51:32 PM UTC-7, Cameron Kaiser wrote:
> Candidly, and not because I still run such a site, I've always found
> Gopher to be a better fit for resource-constrained computing. The
> Commodore 128 sitting next to me does very well for that because the
> protocol and menu parsing conventions are incredibly trivial.
Certainly true on a "how well can it keep up?" level, but unfortunately precious few sites support Gopher these days, so while it may be a better fit it offers vastly more constricted access to online resources.
Re: Intent to deprecate: Insecure HTTP Cameron Kaiser 4/14/15 5:19 PM
The counter argument is, of course, that the "modern Web" (however you
define it) is effectively out of reach of computers older than a decade
or so, let alone an 8-bit system, due to loss of vendor or browser
support, or just plain not being up to the task. So even if they could
access the pages, meaningfully displaying them is another thing
entirely. I won't dispute the much smaller amount of content available
in Gopherspace, but it's still an option that has *some* support, and
that support is often in the retrocomputing community already.

Graceful degradation went out the window a couple years back, unfortunately.

Anyway, I'm derailing the topic, so I'll put a sock in it now.
Cameron Kaiser
Re: Intent to deprecate: Insecure HTTP Karl Dubost 4/14/15 5:33 PM
Henri,
great points, about…

Le 14 avr. 2015 à 19:29, Henri Sivonen <hsiv...@hsivonen.fi> a écrit :
> Currently, the UI designation for http is neutral while the UI
> designation for mixed content is undesirable. I think we should make
> the UI designation of plain http undesirable once x% the sites that
> users encounter on a daily basis are https.

What about changing the color of the grey world icon for http into something which is more telling.
An icon that would mean "eavesdropping possible". but yes UI should be part of the work.

About mixed content, insecure Web site, wrong certificates, etc. People should head to these bugs to understand, that it's not that simple.

* https://bugzilla.mozilla.org/show_bug.cgi?id=1126620
  [Bug 1126620] [META] TLS 1.1/1.2 version intolerant sites
* https://bugzilla.mozilla.org/show_bug.cgi?id=1138101
  [Bug 1138101] [META] Sites that still haven't upgraded to something better than RC4
* https://bugzilla.mozilla.org/show_bug.cgi?id=844556
  [Bug 844556] [tracking] compatibility issues with mixed content blocker on non-Mozilla websites


For Web Compatibility, dropping non secure cookies would be an interesting survey to do and see how much it breaks (or not) the Web and user experience.
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/15/15 2:37 AM
On 14/04/15 13:32, Eric Shepherd wrote:
> My main concern with the notion of phasing out unsecured HTTP is that
> doing so will cripple or eliminate Internet access by older devices that
> aren't generally capable of handling encryption and decryption on such a
> massive scale in real time.
>
> While it may sound silly, those of us who are intro classic computers
> and making them do fun new things use HTTP to connect 10 MHz (or even 1
> MHz) machines to the Internet. These machines can't handle the demands
> of SSL. So this is a step toward making their Internet connections go away.

If this is important to you, then you could simply run them through a
proxy. That's what jwz did when he wanted to get Netscape 1.0 running again:
http://www.jwz.org/blog/2008/03/happy-run-some-old-web-browsers-day/

Gerv


Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/15/15 2:44 AM
On 14/04/15 22:59, northrupt...@gmail.com wrote:
> The article assumes that when folks connect to something via SSH and
> something changes - causing MITM-attack warnings and a refusal to
> connect - folks default to just removing the existing entry in
> ~/.ssh/known_hosts without actually questioning anything.

https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

> "The first important thing to note about this model is that key
> changes are an expected part of life."
>
> Only if they've been communicated first.

How does a website communicate with all its users that it is expecting
to have (or has already had) a key change? After all, you can't exactly
put a notice on the site itself...

> "You can't provide [Joe Public] with a string of hex characters and
> expect it to read it over the phone to his bank."
>
> Sure you can.  Joe Public *already* has to do this with social
> security numbers, credit card numbers, checking/savings account
> numbers, etc. on a pretty routine basis, whether it's over the phone,
> over the Internet, by mail, in person, or what have you.  What makes
> an SSH fingerprint any different?  The fact that now you have the
> letters A through F to read?  Please.

You have missed the question of motivation. I put up with reading a CC
number over the phone (begrudgingly) because I know I need to do that in
order to buy something. If I have a choice of clicking "OK" or phoning
my bank, waiting in a queue, and eventually saying "Hi. I need to verify
the key of your webserver's cert so I can log on to do my online
banking. Is it 09F9.....?" then I'm just going to click "OK" (or
"Whatever", as that button should be labelled).

Gerv
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/15/15 2:47 AM
On 14/04/15 16:39, david....@gmail.com wrote:
>
>> There are already multiple sources of free publicly-trusted certificates,
>> with more on the way.
>> https://www.startssl.com/
>> https://buy.wosign.com/free/
>> https://blog.cloudflare.com/introducing-universal-ssl/
>> https://letsencrypt.org/
>
> I think that you should avoid making this an exercise in marketing Mozilla's "Let's Encrypt" initiative.

Perhaps that's why Richard took the time to make a comprehensive list of
all known sources of free certs, rather than just mentioning LE?

Gerv


Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/15/15 2:50 AM
On 14/04/15 17:46, j...@chromium.org wrote:
> I just wanted to mention that regarding subresource integrity
> (https://w3c.github.io/webappsec/specs/subresourceintegrity/), the
> general consensus over here is that we will not treat origins as
> secure if they are over HTTP but loaded with integrity. We believe
> that security includes confidentiality, which that would approach
> would lack. --Joel

Radical idea: currently, the web has two states, insecure and secure.
What if it still had two states, with the same UI, but insecure meant
"HTTPS top-level, but some resources may be loaded using HTTP with
integrity", and secure meant "HTTPS throughout"?

That is to say, we don't have to tie the availability of new features to
the same criteria as we tie the HTTP vs. HTTPS icon/UI in the browser.
We could allow powerful features for
HTTPS-top-level-and-some-HTTP-with-integrity, while still displaying it
as insecure.

Gerv


Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/15/15 3:00 AM
On Wed, Apr 15, 2015 at 11:50 AM, Gervase Markham <ge...@mozilla.org> wrote:
> Radical idea: currently, the web has two states, insecure and secure.
> What if it still had two states, with the same UI, but insecure meant
> "HTTPS top-level, but some resources may be loaded using HTTP with
> integrity", and secure meant "HTTPS throughout"?

HTTPS already has mixed content, we should not make it worse.


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/15/15 3:10 AM
On 15/04/15 10:59, Anne van Kesteren wrote:
> HTTPS already has mixed content, we should not make it worse.

What's actually wrong with mixed content?

1) The risk of content tampering. Subresource integrity makes that risk
go away.

2) Reduced privacy. And that's why the connection would be marked as
insecure in the UI.

Gerv


Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/15/15 3:32 AM
On Wed, Apr 15, 2015 at 12:10 PM, Gervase Markham <ge...@mozilla.org> wrote:
> 2) Reduced privacy. And that's why the connection would be marked as
> insecure in the UI.

We need to move away from HTTPS being able to go into an insecure
state. We can't expect the user to keep an eye on the address bar the
whole time.


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Joseph Lorenzo Hall 4/15/15 6:56 AM
If you're addicted to cleartrext, the future is going to be hard for you...

On Tue, Apr 14, 2015 at 2:26 PM,  <conno...@gmail.com> wrote:
> HTTPS has its moments, but the majority of the web does not need it. I certainly wouldn't appreciate the encryption overhead just for visiting David's lolcats website. As one of the most important organizations related to free software, it's sad to see Mozilla developers join the war on plaintext: http://arc.pasp.de/ The owners of websites like this have a right to serve their pages in formats that do not make hypocrites of themselves.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@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
Re: Intent to deprecate: Insecure HTTP commod...@gmail.com 4/15/15 7:03 AM
On Wednesday, April 15, 2015 at 6:56:48 AM UTC-7, Joseph Lorenzo Hall wrote:
> If you're addicted to cleartrext, the future is going to be hard for you...
Only because people like you insist on trying to push it across-the-board, rather than let webmasters make their own decisions.
Re: Intent to deprecate: Insecure HTTP Patrick McManus 4/15/15 7:36 AM
On Wed, Apr 15, 2015 at 10:03 AM, <commod...@gmail.com> wrote:

>   rather than let webmasters make their own decisions.


I firmly disagree with your conclusion, but I think you have identified the
central property that is changing.

Traditionally transport security has been a unilateral decision of the
content provider. Consumers could take it or leave it as content providers
tried to guess what content was sensitive and what was not. They could
never really know, of course. The contents of a public library are not
private - but my reading history may or may not be. An indexed open source
repository is not private - but my searching for symbols involved in a
security bug may be. The content provider can't know apriori and even if
they do may not share the interests of the consumer. The decision is being
made by the wrong party.

The HTTPS web says that data consumers have the right to (at least
transport) confidentiality and data integrity all of the time, regardless
of the content. It is the act of consumption that needs to be protected as
we go through our day to day Internet lives. HTTPS is certainly not perfect
at doing this, but its the best thing we've got.

So yes, this is a consumer-first, rather than provider-first, policy.

-Patrick
Re: Intent to deprecate: Insecure HTTP Mike Hoye 4/15/15 8:00 AM
Webmasters are already restricted in how they can run their services in
many ways, some standards-based, some inherent to the web as we find it
in the wild.

For what it's worth I think that the fact that it is (at present) way
more difficult to obtain, install, and update a certificate for a web
server than it is to obtain, install and update a web server means that
_mandating_ HTTPS would represent a real barrier to participation in a
free and open Web.

Having said that, "deprecated" clearly doesn't mean "prohibited", and
the Let's Encrypt's "How It Works" page suggests that setting up a cert
won't be all that difficult in the near future. So, while you may be
right that the benefits here seem to be all client side and the up-front
costs seem to be all server-side, it looks like work is well underway to
reduce server-side costs to almost nothing. Moving from "TLS if the
server wants to" to "TLS is what the client expects" is a meaningful
change in incentive structure underneath web security, and sounds like
the right thing to me.

- mhoye

* https://letsencrypt.org/howitworks/
Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/15/15 8:20 AM
Boris Zbarsky schrieb:
> On 4/14/15 3:28 AM, Anne van Kesteren wrote:
>> On Tue, Apr 14, 2015 at 4:10 AM, Karl Dubost <kdu...@mozilla.com> wrote:
>>> 1. You do not need to register a domain name to have a Web site (IP
>>> address)
>>
>> Name one site you visit regularly that doesn't have a domain name.
>
> My router's configuration UI.  Here "regularly" is probably once a month
> or so.
>
>> And even then, you can get certificates for public IP addresses.
>
> It's not a public IP address.
>
> We do need a solution for this space, which I expect includes the
> various embedded devices people are bringing up; I expect those are
> behind firewalls more often than on the publicly routable internet.

Definitely. Right now, esp. those router configs and similar web
interfaces to devices are in a very bad state - either they run
unencrypted (most of them) or they can only go with self-signed certs
with mostly-bogus domain descriptors, which is pretty bad as well, or
the user needs to create a cert and install it into the device, which is
too much hassle for the vast majority of people.

Are there any good proposals on how to make those decently secure and
keep them easy to use?

KaiRo
Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/15/15 8:23 AM
northrupt...@gmail.com schrieb:
> On Monday, April 13, 2015 at 8:26:59 PM UTC-7, ipar...@gmail.com wrote:
>>> * Less scary warnings about self-signed certificates (i.e. treat HTTPS+selfsigned like we do with HTTP now, and treat HTTP like we do with HTTPS+selfsigned now); the fact that self-signed HTTPS is treated as less secure than HTTP is - to put this as politely and gently as possible - a pile of bovine manure
>>
>> I am against this. Both are insecure and should be treated as such. How is your browser supposed to know that gmail.com is intended to serve a self-signed cert? It's not, and it cannot possibly know it in the general case. Thus it must be treated as insecure.
>
> Except that one is encrypted, and the other is not.  *By logical measure*, the one that is encrypted but unauthenticated is more secure than the one that is neither encrypted nor authenticated, and the fact that virtually every HTTPS-supporting browser assumes the precise opposite is mind-boggling.

Right, the transport is encrypted, but it's completely unverified that
you are accessing the actual machine you wanted to reach (i.e. there is
no domain verification, which is what you need a 3rd-party system for,
the CA system being the usual one in the TLS/web realm). You could just
as much be connected to a MitM with that encrypted transport.

KaiRo
Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/15/15 8:24 AM
northrupt...@gmail.com schrieb:
> That whole article is just additional shovelfuls of bovine manure slopped onto the existing heap.

Please refrain from language like that in lists like this if you want to
be taken seriously.

KaiRo

Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/15/15 8:27 AM
vic schrieb:
> I would view this proposal favorably if 1) you didn't try to force people to adopt the One True Way and 2) the CA situation was fixed.

Please define of what alternatives to what you call the "One True Way"
are acceptable to you and still secure to access, and also what specific
issues with the CA system you would want/need to see fixed.

It's hard to discuss improvements when you are low on specifics.

KaiRo

Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/15/15 8:29 AM
Yoav Weiss schrieb:
> IMO, limiting new features to HTTPS only, when there's no real security
> reason behind it will only end up limiting feature adoption.
> It directly "punishing" developers and adds friction to using new features,
> but only influence business in a very indirect manner.

That's my concern as well, I think we need to think very hard about what
reasons people have to still not use TLS and how we can help them to do
so. Let's Encrypt will be one step easing the solution to one class of
reasons, but there's more.

KaiRo
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/15/15 8:55 AM
On Wed, Apr 15, 2015 at 5:20 PM, Robert Kaiser <ka...@kairo.at> wrote:
> Are there any good proposals on how to make those decently secure and keep
> them easy to use?

I believe Chrome is experimenting with different UI for self-signed
certificates when connecting to a local server. A good outline of the
problem space is here:

  https://noncombatant.org/2014/10/12/brainstorming-security-for-the-internet-of-things/


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Trevor Saunders 4/15/15 11:46 AM
On Wed, Apr 15, 2015 at 10:44:35AM +0100, Gervase Markham wrote:
> On 14/04/15 22:59, northrupt...@gmail.com wrote:
> > The article assumes that when folks connect to something via SSH and
> > something changes - causing MITM-attack warnings and a refusal to
> > connect - folks default to just removing the existing entry in
> > ~/.ssh/known_hosts without actually questioning anything.
>
> https://www.usenix.org/system/files/login/articles/105484-Gutmann.pdf

 That is somewhat discouraging, but I wonder what the conditions of
 these organizations are.  At the very risky end you could ignore a key
 change you were not told of ahead of time for <my chinese hosting
 provider>.  On the other hand if I'm sitting at my desk using my laptop
 and change the key for the sshd on my desktop there isn't nearly as
 much risk in ignoring the key my laptop sees.

> > "The first important thing to note about this model is that key
> > changes are an expected part of life."
> >
> > Only if they've been communicated first.
>
> How does a website communicate with all its users that it is expecting
> to have (or has already had) a key change? After all, you can't exactly
> put a notice on the site itself...

Well, you can put up a notice while using the old cert, and in principal
you can sign the new cert with the old one similar to what you do when
changing gpg keys.  However in the case the old cert needs to be revoked
all users do need to go back to the out of band verification method.

> > "You can't provide [Joe Public] with a string of hex characters and
> > expect it to read it over the phone to his bank."
> >
> > Sure you can.  Joe Public *already* has to do this with social
> > security numbers, credit card numbers, checking/savings account
> > numbers, etc. on a pretty routine basis, whether it's over the phone,
> > over the Internet, by mail, in person, or what have you.  What makes
> > an SSH fingerprint any different?  The fact that now you have the
> > letters A through F to read?  Please.
>
> You have missed the question of motivation. I put up with reading a CC
> number over the phone (begrudgingly) because I know I need to do that in
> order to buy something. If I have a choice of clicking "OK" or phoning
> my bank, waiting in a queue, and eventually saying "Hi. I need to verify
> the key of your webserver's cert so I can log on to do my online
> banking. Is it 09F9.....?" then I'm just going to click "OK" (or
> "Whatever", as that button should be labelled).

I wonder if there's a reasonable way to make it hard to click "whatever",
but fairly easy to say
"I expect the finger print for the cert for foo.com is ab:cd:de:fg..."
if that's correct I'm happy this is secure.  As an asside I personally
find the manual comparison to be a pain even if I have both finger
prints easily available.

Trev


>
> Gerv
Re: Intent to deprecate: Insecure HTTP Karl Dubost 4/15/15 6:14 PM
As Robert is saying:

Le 16 avr. 2015 à 00:29, Robert Kaiser <ka...@kairo.at> a écrit :
> I think we need to think very hard about what reasons people have to still not use TLS and how we can help them to do so.

Definitely.
The resistance in this thread is NOT about "people against security", but
1. we want to be able to choose
2. if we choose safe, we want that choice to be easy to activate.

# Drifting

Socially, eavesdropping is part of our daily life. We go to a café, we are having a discussion and people around you may listen what you are saying. You read a book in the train, a newspaper and people might see what you are reading.

We adjust the type of discussions depending on the context. The café is too "dangerous", too "privacy invasive" and we decide to go to a safer environment, sometimes a safer environment is not necessary being hidden (encryption), but being more public. As I said contexts.

(Note above my usage of the word safe and not secure)

# Back to the topic

It's important for the user to understand the weaknesses and the strength of the environment so they can make a choice. You could almost imagine that you do not care to be plain text until a moment where you activate a secure mode. (change of place in the cafe)

Also we need to think in terms of P2P communications, not only broadcaster-consumers (1-to-many). If the Web becomes something which is harder and harder to start hacking on and communicating with your peers, then we reinforce the power of big hierarchical structures and we change the balance that Web brought over the publishing/media industry. We should always strive for bringing the tools that empower individual people with their ideas and expressions.

Security is part of it. But security doesn't necessary equate to safer. It's just a tool that can be used in some circumstances.

Do we want to deprecate HTTP? Or do we want to make it more obvious when the connection is not secure? These are two very different things.
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/16/15 1:49 AM
On 16/04/15 02:13, Karl Dubost wrote:
> Definitely. The resistance in this thread is NOT about "people
> against security", but 1. we want to be able to choose 2. if we
> choose safe, we want that choice to be easy to activate.

I'd have it the other way. If you even assume choice should be possible
then:

1) We want to be able to choose
2) If we choose unsafe, we want that choice to be relatively hard to
activate.

In other words, "safe" should be the default.

Gerv
Re: Intent to deprecate: Insecure HTTP Katelyn Gadd 4/16/15 2:36 AM
I expressed my opinion on this subject at length on the Chrome lists
when they made a similar proposal. I'll summarize it here, though,
since I feel the same way about FF deprecating non-encrypted HTTP:

I think HTTPS-everywhere is a great ideal if we can achieve it, but in
the vast majority of discussions it feels like people are
underestimating the difficulties involved in deploying HTTPS in
production. In particular, I think this puts a significant group of
people at risk and they don't necessarily have the ability to advocate
for themselves in environments like this. Low-income internet users,
teenagers, and people in less-developed nations are more likely to be
dependent on inexpensive-or-free services to put content up on the
internet. In the best case they might have a server of their own they
can configure for HTTPS (given sufficient public documentation & time)
but the task of getting a certificate is a huge hurdle. I've acquired
personal certificates in the past through the normal paid CA pipeline
and the experience was bad enough as someone who lives in Silicon
Valley and can afford a certificate.

There are some steps being taken to reduce the difficulty here, and I
think that's a good start. StartSSL offers free certs, and that's
wonderful (aside from the fact that their OCSP servers broke and took
down a portion of the web the other day...) and if letsencrypt ships
it seems like it could be a comprehensive solution to the problem. If
unencrypted HTTP is deprecated it *must* be not only simple for
individuals to acquire a certificate, but it shouldn't require them to
interact with western governments/business regulations, and it
shouldn't require them to compromise anonymity. Anonymity is an
important feature of web services and especially important for
disadvantaged people. Unencrypted pages mean that visitors are
potentially at risk and their sites can be MITMd, but a MITM is at
least not going to expose their real name or real identity and put
them at risk from attack. Past security breaches at various internet
services & businesses suggest that if an individual has to provide
identifying information to a CA - even if it is promised to be kept
private - they are putting themselves at risk. Letsencrypt seems to
avoid this requirement so I look forward to it launching in the near
future.

I also think there are potential negative consequences to deprecating
HTTP if the process of rolling out HTTPS is prohibitively difficult
for amateur/independent developers: In practice it may force many of
them to move to hosting their content on third-party servers/services
that provide HTTPS, which puts them at risk of having their content
tampered with or pulled by the service provider. In this scenario I'm
not sure we've won anything because we've made the site look secure
when in fact we've simplified the task of altering site content
without the author or visitor's knowledge.
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/16/15 5:16 AM
> > I think that you should avoid making this an exercise in marketing Mozilla's "Let's Encrypt" initiative.
>
> Perhaps that's why Richard took the time to make a comprehensive list of
> all known sources of free certs, rather than just mentioning LE?

Yeah, that's what I thought when I first posted here.  Now I'm not so sure.  You do not seem interested in hearing about any other technical possibilities other than Let's Encrypt, which you seem to have already chosen.

For example:
- You say "there is only secure/not secure".  Traditionally, we have things like defense in depth, and multiple levels of different sources of authentication.  I am hearing: "You will either have a Let's Encrypt certificate or you don't".  Heck, let's get rid of EV certificate validation too while we are at it: we don't want to have to do special vetting for banking and medical websites, because that doesn't fit in with Let's Encrypt's business model.

- You don't want to hear about non-centralized security models.  DANE provides me with control over certificate pinning for people visiting my websites.  You seem to be saying: Mozilla's CA will have full control over all websites.  I'm not sure why you'd want that level of responsibility.  If you don't like DANE, explain why, and propose something else that is non-centralized and not under Mozilla's control.

- Personally, I think that the move away from http:// is a good idea, and the opportunistic encryption features are an excellent start.  I am not clear why you think that we *technically* need to go beyond this.  Other than to force people to use a centralized identity system.  Which is?  Hmm... Let's Encrypt.


I *really* hope I am misunderstanding this thread...  I don't think of Mozilla as a company that would try to do this.
Re: Intent to deprecate: Insecure HTTP Adam Roach 4/16/15 7:55 AM
On 4/16/15 07:16, david....@gmail.com wrote:
> For example:
> - You say "there is only secure/not secure".  Traditionally, we have things like defense in depth, and multiple levels of different sources of authentication.  I am hearing: "You will either have a Let's Encrypt certificate or you don't".  Heck, let's get rid of EV certificate validation too while we are at it: we don't want to have to do special vetting for banking and medical websites, because that doesn't fit in with Let's Encrypt's business model.

You're pretty far off in the weeds here. I'll try to help you with some
of your misconceptions.

First, no one is proposing that Let's Encrypt should become the sole
source of TLS certificates. Let's Encrypt was started to solve a
specific set of valid complaints about the complexity and financial
issues surrounding acquiring a TLS certificate for certain individuals.

Second, Let's Encrypt is run by ISRG, not Mozilla -- Mozilla is one of
several supporters for ISRG, but we are separate entities.

Finally, ISRG is a 501(c)(3) non-profit public benefit corporation.
There's no business model in the traditional sense, since the goal is
not profit. The goal is to fulfill its mission, which is "to reduce
financial, technological, and education barriers to secure communication
over the Internet." Accusing ISRG of having a pro-TLS agenda is akin to
accusing a soup kitchen of having a pro-soup agenda: it shows a
fundamental misunderstanding of what they're doing and why.

> - You don't want to hear about non-centralized security models.  DANE...

...is a centralized security model. The difference is that you're
trading a set of predominantly commercial CA entities for a different
set of governmental or governmentally-contracted entities. It is
arguably more centralized than the current CA system.

--
Adam Roach
Principal Platform Engineer
a...@mozilla.com
+1 650 903 0800 x863
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/16/15 8:41 AM
On Wed, Apr 15, 2015 at 9:13 PM, Karl Dubost <kdu...@mozilla.com> wrote:

> As Robert is saying:
>
> Le 16 avr. 2015 à 00:29, Robert Kaiser <ka...@kairo.at> a écrit :
> > I think we need to think very hard about what reasons people have to
> still not use TLS and how we can help them to do so.
>
> Definitely.
> The resistance in this thread is NOT about "people against security", but
> 1. we want to be able to choose
> 2. if we choose safe, we want that choice to be easy to activate.
>

Please see McManus's argument for why putting all the choice in webmasters'
hands is not really the best option for today's web.



> # Drifting
>
> Socially, eavesdropping is part of our daily life. We go to a café, we are
> having a discussion and people around you may listen what you are saying.
> You read a book in the train, a newspaper and people might see what you are
> reading.
>
> We adjust the type of discussions depending on the context. The café is
> too "dangerous", too "privacy invasive" and we decide to go to a safer
> environment, sometimes a safer environment is not necessary being hidden
> (encryption), but being more public. As I said contexts.
>
> (Note above my usage of the word safe and not secure)
>

Of course, in the café, you can evaluate who has access to your
communication -- you can look around and see.  When you load a web page,
your session traverses, on average, four different entities [1], any of
whom can subvert your communications.  The user has no visibility in to
this path, not least because it often can't be predicted in advance.
You're in the UK, talking to a server in Lebanon.  Does your path traverse
France?  Possibly!  (Probably!)

The idea that the user can evaluate the trustworthiness of every ISP
between his computer and a web server seems pretty outlandish.  Maybe in
some limited development or enterprise environments, but certainly not for
the general web.


# Back to the topic
>
> It's important for the user to understand the weaknesses and the strength
> of the environment so they can make a choice. You could almost imagine that
> you do not care to be plain text until a moment where you activate a secure
> mode. (change of place in the cafe)
>
> Also we need to think in terms of P2P communications, not only
> broadcaster-consumers (1-to-many). If the Web becomes something which is
> harder and harder to start hacking on and communicating with your peers,
> then we reinforce the power of big hierarchical structures and we change
> the balance that Web brought over the publishing/media industry. We should
> always strive for bringing the tools that empower individual people with
> their ideas and expressions.
>
> Security is part of it. But security doesn't necessary equate to safer.
> It's just a tool that can be used in some circumstances.
>
> Do we want to deprecate HTTP? Or do we want to make it more obvious when
> the connection is not secure? These are two very different things.
>

http://i.imgur.com/c7NJRa2.gif

--Richard

[1] http://bgp.potaroo.net/as6447/
[2]
http://www.lemonde.fr/pixels/article/2015/04/16/les-deputes-approuvent-un-systeme-de-surveillance-du-trafic-sur-internet_4616652_4408996.html



>
> --
> Karl Dubost, Mozilla
> http://www.la-grange.net/karl/moz
>
Re: Intent to deprecate: Insecure HTTP david....@gmail.com 4/16/15 10:47 AM

>
> You're pretty far off in the weeds here. I'll try to help you with some
> of your misconceptions.
>

I pretty much knew I was.  Good luck with the project, I'm looking forward to at least no-passive attack encryption being on-by-default...  I hope that you don't get abducted by people in black helicopters!
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/16/15 7:03 PM
Hey Katelyn,

Thanks for bringing up these considerations.

On Thu, Apr 16, 2015 at 5:35 AM, Katelyn Gadd <k...@luminance.org> wrote:

> I expressed my opinion on this subject at length on the Chrome lists
> when they made a similar proposal. I'll summarize it here, though,
> since I feel the same way about FF deprecating non-encrypted HTTP:
>
> I think HTTPS-everywhere is a great ideal if we can achieve it, but in
> the vast majority of discussions it feels like people are
> underestimating the difficulties involved in deploying HTTPS in
> production. In particular, I think this puts a significant group of
> people at risk and they don't necessarily have the ability to advocate
> for themselves in environments like this. Low-income internet users,
> teenagers, and people in less-developed nations are more likely to be
> dependent on inexpensive-or-free services to put content up on the
> internet. In the best case they might have a server of their own they
> can configure for HTTPS (given sufficient public documentation & time)
> but the task of getting a certificate is a huge hurdle. I've acquired
> personal certificates in the past through the normal paid CA pipeline
> and the experience was bad enough as someone who lives in Silicon
> Valley and can afford a certificate.
>

Let me try to disentangle two threads here:

1. "Zero-rated" services [1].  These are services where the carrier agrees
not to charge the user for data to access certain web sites.  Obviously,
these can play an important role for carriers in developing economies
especially.  HTTPS can have an impact here, since it prevents the carrier
from seeing anything beyond the hostname that the user is connecting to.  I
would observe, however, that (1) most zero-rating is done on a hostname
basis anyway, and (2) even if more granularity is desired, there are
solutions for this that don't involve DPI, e.g., having the zero-rated site
send a ping to the carrier in JS.

2. Requirement for free/inexpensive/hobbyist services to get certificates.
Examples of free certificate services have been given several times in this
thread.  Several hosting platforms already offer HTTPS helper tools.  And
overall, I think the trend is toward greater usability.  So the situation
is pretty OK (not great) today, and it's getting better.  If we think of
this HTTP deprecation plan not as something we're doing today, but
something we'll be doing over the next few years, it seems like deprecating
HTTP and improved HTTPS deployability can develop together.



> There are some steps being taken to reduce the difficulty here, and I
> think that's a good start. StartSSL offers free certs, and that's
> wonderful (aside from the fact that their OCSP servers broke and took
> down a portion of the web the other day...) and if letsencrypt ships
> it seems like it could be a comprehensive solution to the problem. If
> unencrypted HTTP is deprecated it *must* be not only simple for
> individuals to acquire a certificate, but it shouldn't require them to
> interact with western governments/business regulations, and it
> shouldn't require them to compromise anonymity. Anonymity is an
> important feature of web services and especially important for
> disadvantaged people. Unencrypted pages mean that visitors are
> potentially at risk and their sites can be MITMd, but a MITM is at
> least not going to expose their real name or real identity and put
> them at risk from attack. Past security breaches at various internet
> services & businesses suggest that if an individual has to provide
> identifying information to a CA - even if it is promised to be kept
> private - they are putting themselves at risk. Letsencrypt seems to
> avoid this requirement so I look forward to it launching in the near
> future.
>

I'm not sure what the state of the art with StartCom is, but when I got a
certificate from WoSign the other day [2], they didn't require any
identification besides an email address.  As far as I know, Let's Encrypt
will require about the same level of information.  There's certainly
nothing about the standards or norms for the web PKI that requires CAs to
collect identifying information about applicants for certificates.



> I also think there are potential negative consequences to deprecating
> HTTP if the process of rolling out HTTPS is prohibitively difficult
> for amateur/independent developers: In practice it may force many of
> them to move to hosting their content on third-party servers/services
> that provide HTTPS, which puts them at risk of having their content
> tampered with or pulled by the service provider. In this scenario I'm
> not sure we've won anything because we've made the site look secure
> when in fact we've simplified the task of altering site content
> without the author or visitor's knowledge.
>

Maybe I'm coming from a position of privilege here, but the difficulty of
setting up HTTPS seems exaggerated to me.  Mozilla already provides an
HTTPS config generator [3], and I know Let's Encrypt is already having some
conversations with platform vendors about adding more automation to HTTPS
config.

--Richard


[1] http://en.wikipedia.org/wiki/Zero-rating
[2] https://buy.wosign.com/free/
[3] https://mozilla.github.io/server-side-tls/ssl-config-generator/


>
> On 16 April 2015 at 01:49, Gervase Markham <ge...@mozilla.org> wrote:
> > On 16/04/15 02:13, Karl Dubost wrote:
> >> Definitely. The resistance in this thread is NOT about "people
> >> against security", but 1. we want to be able to choose 2. if we
> >> choose safe, we want that choice to be easy to activate.
> >
> > I'd have it the other way. If you even assume choice should be possible
> > then:
> >
> > 1) We want to be able to choose
> > 2) If we choose unsafe, we want that choice to be relatively hard to
> > activate.
> >
> > In other words, "safe" should be the default.
> >
> > Gerv
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/16/15 7:14 PM
On Thu, Apr 16, 2015 at 8:16 AM, <david....@gmail.com> wrote:

> > > I think that you should avoid making this an exercise in marketing
> Mozilla's "Let's Encrypt" initiative.
> >
> > Perhaps that's why Richard took the time to make a comprehensive list of
> > all known sources of free certs, rather than just mentioning LE?
>
> Yeah, that's what I thought when I first posted here.  Now I'm not so
> sure.  You do not seem interested in hearing about any other technical
> possibilities other than Let's Encrypt, which you seem to have already
> chosen.
>

I hope it's clear that I and others have brought up Let's Encrypt only as
an example of how it's becoming easier to get a certificate -- along with
other offerings from folks like StartCom and WoSign.



> For example:
> - You say "there is only secure/not secure".  Traditionally, we have
> things like defense in depth, and multiple levels of different sources of
> authentication.  I am hearing: "You will either have a Let's Encrypt
> certificate or you don't".  Heck, let's get rid of EV certificate
> validation too while we are at it: we don't want to have to do special
> vetting for banking and medical websites, because that doesn't fit in with
> Let's Encrypt's business model.
>

The focus of this thread is moving the web toward a basic level of
security.  The fact of HTTPS today is that DV is the minimum acceptable
standard.   Additional levels above HTTPS+DV are great, but they're gravy
on top of having protection against network attackers.  Opportunistic
security is also a fine idea, but it's no HTTPS.  And of course non of this
has to do with Let's Encrypt.

- You don't want to hear about non-centralized security models.  DANE
> provides me with control over certificate pinning for people visiting my
> websites.  You seem to be saying: Mozilla's CA will have full control over
> all websites.  I'm not sure why you'd want that level of responsibility.
> If you don't like DANE, explain why, and propose something else that is
> non-centralized and not under Mozilla's control.
>

Whether or not DANE is supported is not germane to this thread, unless you
think a lack of DANE support is a blocker to broader HTTPS adoption.

(I look forward to your explanation of how a strict hierarchy like the DNS
is not "centralized".)



> - Personally, I think that the move away from http:// is a good idea, and
> the opportunistic encryption features are an excellent start.  I am not
> clear why you think that we *technically* need to go beyond this.  Other
> than to force people to use a centralized identity system.  Which is?
> Hmm... Let's Encrypt.
>
>
> I *really* hope I am misunderstanding this thread...  I don't think of
> Mozilla as a company that would try to do this.
>

As I hope is apparent by now from the above and from Adam's response, this
thread has nothing to do with promoting LE.  It's all about promoting
HTTPS, whether your cert comes from LE, from another CA, or from DANE.

--Richard
Re: Intent to deprecate: Insecure HTTP Henri Sivonen 4/17/15 1:34 AM
On Wed, Apr 15, 2015 at 3:33 AM, Karl Dubost <kdu...@mozilla.com> wrote:
> Le 14 avr. 2015 à 19:29, Henri Sivonen <hsiv...@hsivonen.fi> a écrit :
>> Currently, the UI designation for http is neutral while the UI
>> designation for mixed content is undesirable. I think we should make
>> the UI designation of plain http undesirable once x% the sites that
>> users encounter on a daily basis are https.
>
> What about changing the color of the grey world icon for http into something which is more telling.
> An icon that would mean "eavesdropping possible". but yes UI should be part of the work.

I indeed meant changing the grey globe icon to something else
eventually, but I deliberately wanted to avoid starting a bikeshed in
*this* thread about what the new icon should be. Usually something on
the theme of the Eye of Sauron comes up in discussion about the icon.

> For Web Compatibility, dropping non secure cookies would be an interesting survey to do and see how much it breaks (or not) the Web and user experience.

Note that I didn't propose dropping support for insecure cookies right
away. I proposed forgetting (by default) insecure cookies when
quitting Firefox. At least at the start, it would probably make sense
not to forget cookies from sites that the users has put in the
explicit "Allow" category in the cookie manager.

AFAICT, this can't "Break the Web" for the usual definition of that
phrase, since the forgetting behavior wouldn't be site-detectable in
mid-browsing. It would affect the UX on non-https login-requiring
sites (including ones whose login is https but whose session cookie is
insecure to allow everything except supposedly sensitive things like
sending the password or sending a credit card number happen over http
due to legacy performance memes), which are, as noted, Doing It Wrong.

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/
Re: Intent to deprecate: Insecure HTTP andrew...@gmail.com 4/17/15 9:13 AM
As a non-tech person, the only thing I know is https means my browser runs even slower on DSL, which is all that is available in many rural areas. Would this not mean that I'd be back to dial-up times to load a story or post, all of which are larded up with ads and videos these days? At 7 mbps tops, my browsing is already difficult.
 
Meanwhile: "Deprecate" it?? Has anyone in the tech community used an English dictionary?  To deprecate Http would mean to speak badly of it. Or disapprove of it. I think you mean you want to abolish it, pressure it out of existence, or create a disincentive to use it.
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/17/15 9:21 AM
On Fri, Apr 17, 2015 at 6:13 PM,  <andrew...@gmail.com> wrote:
> As a non-tech person, the only thing I know is https means my browser runs even slower on DSL.

This has already been addressed earlier in the thread. HTTPS has
negligible performance impact. See e.g.:

  https://istlsfastyet.com/


> Meanwhile: "Deprecate" it?? Has anyone in the tech community used an English dictionary?

http://en.wikipedia.org/wiki/Deprecation#Software_deprecation


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Mike Hoye 4/17/15 9:46 AM
On 2015-04-17 12:20 PM, Anne van Kesteren wrote:
> On Fri, Apr 17, 2015 at 6:13 PM,  <andrew...@gmail.com> wrote:
>> As a non-tech person, the only thing I know is https means my browser runs even slower on DSL.
> This has already been addressed earlier in the thread. HTTPS has
> negligible performance impact. See e.g.:
>
>    https://istlsfastyet.com/
I don't see where that document speaks to the impact of TLS on caching
proxies, which I'm guessing is the source of the performance hit Andrew
mentions.

It's been a while since I've looked, but in Canada (and probably other
geographically large countries) the telcos/ISP with large exurban/rural
client bases used to use caching proxies a lot.


- mhoye
Re: Intent to deprecate: Insecure HTTP Bob Clary 4/17/15 11:17 AM
 From my past experience with satellite based connections https was
appreciably slower than http. I don't know how much of the affect was
due to the loss of the caching proxy or how much was due to the
latency+handshake issue. This was also several years ago and I don't
have experience with the improved networking in Firefox over satellite .

In third world countries, such as the United States, many people in
rural areas are limited to satellite base connections and may be
adversely affected by the move to encrypted connections. This isn't to
say we shouldn't move to encryption, just that the network experience in
major metropolitan areas isn't indicative of what someone in rural
Virginia might experience for example.

/bc


Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 4/17/15 11:23 AM
On Fri, Apr 17, 2015 at 6:46 PM, Mike Hoye <mh...@mozilla.com> wrote:
> I don't see where that document speaks to the impact of TLS on caching
> proxies, which I'm guessing is the source of the performance hit Andrew
> mentions.
>
> It's been a while since I've looked, but in Canada (and probably other
> geographically large countries) the telcos/ISP with large exurban/rural
> client bases used to use caching proxies a lot.

As I said early on in this thread, this claim often comes up, but is
never backed up. Where is the research that shows we need public
caching proxies?


--
https://annevankesteren.nl/
Re: Intent to deprecate: Insecure HTTP Martin Thomson 4/17/15 12:56 PM
On Fri, Apr 17, 2015 at 11:22 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> As I said early on in this thread, this claim often comes up, but is
> never backed up. Where is the research that shows we need public
> caching proxies?

This is early days, but I'm working with a partner on two things:
 - working out how to cache https resources
 - working out if it's worthwhile doing

I can share what material I have on the topic; it's very rough right
now and we have no actual data, but I expect the project to be in a
better shape as things progress.  This is all part of the overall plan
to make HTTPS as usable as possible.

The latter question is a real concern, but we won't know until we go
and collect some data.  When we get measurements for these sorts of
things, it's usually from services that have the resources to acquire
the measurements.  At the same time, those services likely have the
resources to have a CDN and so probably will have less need for
caches.
Re: Intent to deprecate: Insecure HTTP Robert Kaiser 4/17/15 2:06 PM
Karl Dubost schrieb:
> Henri,
> great points, about…
>
> Le 14 avr. 2015 à 19:29, Henri Sivonen <hsiv...@hsivonen.fi> a écrit :
>> Currently, the UI designation for http is neutral while the UI
>> designation for mixed content is undesirable. I think we should make
>> the UI designation of plain http undesirable once x% the sites that
>> users encounter on a daily basis are https.
>
> What about changing the color of the grey world icon for http into something which is more telling.
> An icon that would mean "eavesdropping possible". but yes UI should be part of the work.

I believe we could think about potentially starting with only marking
HTTP that contains any script as insecure. There's much less danger of
evesdropping or other stuff on completely static HTML+CSS that doesn't
contain any scripts or iframes or somesuch. Of course, we'd need to get
some data to find out if completely static/passive sites vs. those with
scripts etc. make any significant difference in terms of how many sites
are affected.

KaiRo

Re: Intent to deprecate: Insecure HTTP mh.in...@gmail.com 4/19/15 1:08 AM
> The latter question is a real concern, but we won't know until we go
> and collect some data.  When we get measurements for these sorts of
> things, it's usually from services that have the resources to acquire
> the measurements.  At the same time, those services likely have the
> resources to have a CDN and so probably will have less need for
> caches.

It seems the right people to work with on this are the people at rural/edge/mobile ISPs, as these are the people who will know the size of their caches, the hit rates, the amount of bandwidth they take off their transit links and the amount of money they'd have to raise from their customers to pay for increased peering/transit costs if their caching proxies all broke (extrapolated out over the expected transition time, of course).

Providers of web services themselves don't seem in a good position to calculate the value of caching http proxies, as they aren't the ones benefiting except in an indirect latency based way.
Re: Intent to deprecate: Insecure HTTP Philip Chee 4/19/15 8:11 AM
On 18/04/2015 00:13, andrew...@gmail.com wrote:

> Meanwhile: "Deprecate" it?? Has anyone in the tech community used an
> English dictionary?  To deprecate Http would mean to speak badly of
> it. Or disapprove of it. I think you mean you want to abolish it,
> pressure it out of existence, or create a disincentive to use it.

"Deprecate" is a term of art in the IT world.

http://en.wikipedia.org/wiki/Deprecation

http://www.thefreedictionary.com/deprecated
3.  Computers To mark (a component of a software standard) as obsolete
to warn against its use in the future so that it may be phased out.

Thesaurus: An educated dinosaur

Phil

--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Re: Intent to deprecate: Insecure HTTP Daniel Veditz 4/19/15 9:27 PM
On Tue, Apr 14, 2015 at 3:29 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> I think we should make
> ​ ​
> the UI designation of plain http undesirable once x% the sites that
> ​ ​
> users encounter on a daily basis are https. Since users don't interact
> ​ ​
> with the whole Web equally, this means that the UI for http would be
> ​ ​
> made undesirable much earlier than the time when x% of Web sites
> ​ ​
> migrates to https.


​Currently about a third of Firefox user page views are TLS:
http://telemetry.mozilla.org/#filter=release%2F37%2FHTTP_PAGELOAD_IS_SSL%2Fsaved_session%2FFirefox&aggregates=multiselect-all!Submissions&evoOver=Builds&locked=true&sanitize=true&renderhistogram=Graph


-
​Dan Veditz​
Re: Intent to deprecate: Insecure HTTP Daniel Veditz 4/19/15 10:20 PM
On Wed, Apr 15, 2015 at 6:13 PM, Karl Dubost <kdu...@mozilla.com> wrote:

> Socially, eavesdropping is part of our daily life. We go to a café, we are
> having a discussion and people around you may listen what you are saying.
> You read a book in the train, a newspaper and people might see what you are
> reading.
>

​The HTTP equivalent to those is a "passive MITM"--listening in (but unlike
a  few strangers around you in the cafe that might hear a few words it's a
global surveillance regime storing every word for years). That's problem
enough, but using HTTP also allows "active MITM" where the attacker
intercepts your words and changes them so that your companion hears
something different -- perhaps instead of ordering 2 boxes of Girl Scout
cookies you're heard to say 20, and that they should be delivered to the
house across the street. Or instead of proposing to your SO you're heard to
break up with them because you can't stand their mother (oh hey, is that
your ex over in the corner with the computer?).

-Dan Veditz
Re: Intent to deprecate: Insecure HTTP Daniel Veditz 4/19/15 10:36 PM
On Thu, Apr 16, 2015 at 5:16 AM, <david....@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP skul...@gmail.com 4/21/15 3:43 AM
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.
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/21/15 5:56 AM
Very briefly:

On 21/04/15 12:43, skul...@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
Re: Intent to deprecate: Insecure HTTP Mike Hoye 4/21/15 6:56 AM
On 2015-04-21 6:43 AM, skul...@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
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/23/15 6:26 AM
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
Re: Intent to deprecate: Insecure HTTP voracity 4/23/15 8:47 PM
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?
Re: Intent to deprecate: Insecure HTTP butrus...@gmail.com 4/23/15 10:03 PM
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.
Re: Intent to deprecate: Insecure HTTP richar...@gmail.com 4/24/15 6:12 AM
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 <https://localhost:8000/>, as long as you're willing to click through a certificate warning.
Re: Intent to deprecate: Insecure HTTP rba...@mozilla.com 4/24/15 6:29 AM
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.
Re: Intent to deprecate: Insecure HTTP Mike Hoye 4/24/15 7:29 AM
On 2015-04-24 1:02 AM, butrus...@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
Re: Intent to deprecate: Insecure HTTP Roger Hågensen 4/24/15 3:06 PM
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.
Re: Intent to deprecate: Insecure HTTP Roger Hågensen 4/24/15 3:28 PM
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.
Re: Intent to deprecate: Insecure HTTP Martin Thomson 4/24/15 6:52 PM
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 <skul...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP Gervase Markham 4/28/15 2:18 AM
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
Re: Intent to deprecate: Insecure HTTP Richard Barnes 4/30/15 3:25 PM
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.
> [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
>
>
Re: Intent to deprecate: Insecure HTTP dia...@gmail.com 4/30/15 5:57 PM
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.
Re: Intent to deprecate: Insecure HTTP peter.e...@gmail.com 4/30/15 5:59 PM
Richard & Martin,

Thanks for your work on this initiative. This will improve Web security, and if the roadmap is laid our correctly it should provide good incentives for more sites to migrate without ever causing real problems for many developers. So we strongly support it.

One thing which may deserve inclusion is re-ordering the browser UI states so that http is correctly marked as the least secure, followed by various imperfect-HTTPS states such as mixed content, followed by DV/OV HTTPS and then EV HTTPS.
Re: Intent to deprecate: Insecure HTTP peter.e...@gmail.com 4/30/15 6:02 PM
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.
Re: Intent to deprecate: Insecure HTTP peter.e...@gmail.com 4/30/15 6:12 PM
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.
Re: Intent to deprecate: Insecure HTTP Matthew Phillips 4/30/15 7:49 PM
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.
Re: Intent to deprecate: Insecure HTTP imfasterth...@gmail.com 4/30/15 9:50 PM
> 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.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 4/30/15 10:04 PM
On Thu, Apr 30, 2015 at 5:57 PM, <dia...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP 王小康 5/1/15 2:54 AM
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.
Re: Intent to deprecate: Insecure HTTP Joseph Lorenzo Hall 5/1/15 4:54 AM
On Thu, Apr 30, 2015 at 10:49 PM, Matthew Phillips <phill...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP Matthew Phillips 5/1/15 5:46 AM
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.
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/1/15 6:48 AM
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
Re: Intent to deprecate: Insecure HTTP pya...@gmail.com 5/1/15 9:20 AM
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.
Re: Intent to deprecate: Insecure HTTP Adam Roach 5/1/15 9:38 AM
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
Re: Intent to deprecate: Insecure HTTP Adam Roach 5/1/15 10:03 AM
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.
Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/1/15 10:11 AM
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.
Re: Intent to deprecate: Insecure HTTP laure...@gmail.com 5/1/15 10:13 AM
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
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/1/15 11:04 AM
On 2015-05-01 1:13 PM, laure...@gmail.com wrote:
> Here we go again. Listen up, guys.
That's not going to be a winning approach here.


- mhoye
Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 5/1/15 11:07 AM
laure...@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 <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Re: Intent to deprecate: Insecure HTTP scou...@cpeip.fsu.edu 5/1/15 11:07 AM
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.
Re: Intent to deprecate: Insecure HTTP Matthew Phillips 5/1/15 11:07 AM
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.
>
Re: Intent to deprecate: Insecure HTTP Martin Thomson 5/1/15 11:16 AM
On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd <eshe...@mozilla.com> 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).
Re: Intent to deprecate: Insecure HTTP Chris Hofmann 5/1/15 11:25 AM
On Fri, May 1, 2015 at 11:16 AM, Martin Thomson <m...@mozilla.com> wrote:

> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd <eshe...@mozilla.com>
> 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
Re: Intent to deprecate: Insecure HTTP Joseph Lorenzo Hall 5/1/15 11:30 AM
+freaking1

On Fri, May 1, 2015 at 2:16 PM, Martin Thomson <m...@mozilla.com> wrote:
> On Fri, May 1, 2015 at 11:06 AM, Eric Shepherd <eshe...@mozilla.com> 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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deprecate: Insecure HTTP Martin Thomson 5/1/15 11:31 AM
On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann <chof...@mozilla.com> 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
Re: Intent to deprecate: Insecure HTTP Patrick McManus 5/1/15 11:37 AM
On Fri, May 1, 2015 at 2:07 PM, <scou...@cpeip.fsu.edu> 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
Re: Intent to deprecate: Insecure HTTP hrzi...@gmail.com 5/1/15 11:41 AM
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.
Re: Intent to deprecate: Insecure HTTP Joseph Lorenzo Hall 5/1/15 11:45 AM
On Fri, May 1, 2015 at 2:37 PM, Patrick McManus <pmcm...@mozilla.com> 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
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/1/15 11:47 AM
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


Re: Intent to deprecate: Insecure HTTP Coughlin, R. Shawn 5/1/15 12:05 PM
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.
Re: Intent to deprecate: Insecure HTTP Richard Barnes 5/1/15 12:06 PM
On Thu, Apr 30, 2015 at 9:50 PM, <imfasterth...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP Richard Barnes 5/1/15 12:22 PM
On Fri, May 1, 2015 at 10:13 AM, <laure...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 5/1/15 12:40 PM
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).
Re: Intent to deprecate: Insecure HTTP Richard Barnes 5/1/15 1:00 PM
On Fri, May 1, 2015 at 12:40 PM, Eric Shepherd <eshe...@mozilla.com>
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
Re: Intent to deprecate: Insecure HTTP Richard Barnes 5/1/15 1:06 PM
On Fri, May 1, 2015 at 11:30 AM, Martin Thomson <m...@mozilla.com> wrote:

> On Fri, May 1, 2015 at 11:25 AM, Chris Hofmann <chof...@mozilla.com>
> 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
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/1/15 1:36 PM
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
Re: Intent to deprecate: Insecure HTTP oli...@omattos.com 5/1/15 1:50 PM
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.
Re: Intent to deprecate: Insecure HTTP Nicholas Nethercote 5/2/15 2:57 AM
On Sat, May 2, 2015 at 2:20 AM,  <pya...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP imfasterth...@gmail.com 5/2/15 6:28 PM
On Friday, May 1, 2015 at 3:06:18 PM UTC-4, Richard Barnes wrote:
> On Thu, Apr 30, 2015 at 9:50 PM, <imfasterth...@gmail.com> 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.
Re: Intent to deprecate: Insecure HTTP mof...@gmail.com 5/2/15 6:51 PM
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.
Re: Intent to deprecate: Insecure HTTP Xidorn Quan 5/2/15 7:39 PM
On Sun, May 3, 2015 at 1:51 PM, <mof...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP mof...@gmail.com 5/2/15 7:46 PM
воскресенье, 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.
Re: Intent to deprecate: Insecure HTTP Xidorn Quan 5/2/15 8:06 PM
On Sun, May 3, 2015 at 2:46 PM, <mof...@gmail.com> 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
Re: Intent to deprecate: Insecure HTTP mof...@gmail.com 5/2/15 8:08 PM
воскресенье, 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.
Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 5/3/15 6:43 PM
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. :)
Re: Intent to deprecate: Insecure HTTP Gervase Markham 5/4/15 3:01 AM
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


Re: Intent to deprecate: Insecure HTTP Gervase Markham 5/4/15 3:03 AM
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

Re: Intent to deprecate: Insecure HTTP Gervase Markham 5/4/15 3:04 AM
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


Re: Intent to deprecate: Insecure HTTP Robert O'Callahan 5/4/15 3:36 AM
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 ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
Re: Intent to deprecate: Insecure HTTP Henri Sivonen 5/4/15 5:37 AM
On Fri, May 1, 2015 at 1:25 AM, Richard Barnes <rba...@mozilla.com> 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
hsiv...@hsivonen.fi
https://hsivonen.fi/
Re: Intent to deprecate: Insecure HTTP Gervase Markham 5/4/15 6:02 AM
Re: Intent to deprecate: Insecure HTTP Gervase Markham 5/4/15 6:02 AM
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.

Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/4/15 6:02 AM
On Sat, May 2, 2015 at 11:57 AM, Nicholas Nethercote <n.net...@gmail.com
> 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).
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/4/15 6:38 AM
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
Re: Intent to deprecate: Insecure HTTP Adam Roach 5/4/15 6:40 AM
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
Re: Intent to deprecate: Insecure HTTP Coughlin, R. Shawn 5/4/15 7:17 AM
"Nothing goes over my head! My reflexes are too fast, I would catch it."
 -- Drax the Destroyer
Re: Intent to deprecate: Insecure HTTP Adam Roach 5/4/15 9:34 AM
On 5/4/15 11:24, Florian Bösch wrote:
> On Mon, May 4, 2015 at 3:38 PM, Adam Roach <a...@mozilla.com
> <mailto:a...@mozilla.com>> 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.
Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/4/15 9:40 AM
On Mon, May 4, 2015 at 6:33 PM, Adam Roach <a...@mozilla.com> 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.
Re: Intent to deprecate: Insecure HTTP Coughlin, R. Shawn 5/4/15 9:40 AM
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" <j...@cdt.org> wrote:

>On Fri, May 1, 2015 at 2:37 PM, Patrick McManus <pmcm...@mozilla.com>
>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

Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/4/15 9:40 AM
On Mon, May 4, 2015 at 3:38 PM, Adam Roach <a...@mozilla.com> 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.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 5/4/15 10:44 AM
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
Re: Intent to deprecate: Insecure HTTP Daniel Holbert 5/4/15 11:00 AM
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
Re: Intent to deprecate: Insecure HTTP Martin Thomson 5/4/15 11:04 AM
On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert <dhol...@mozilla.com> 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.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 5/4/15 11:06 AM
On Mon, May 4, 2015 at 10:52 AM, Florian Bösch <pya...@gmail.com> wrote:

> On Mon, May 4, 2015 at 7:43 PM, Eric Rescorla <e...@rtfm.com> 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
Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/4/15 1:01 PM
On Mon, May 4, 2015 at 8:06 PM, Eric Rescorla <e...@rtfm.com> 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.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 5/4/15 1:13 PM
Thanks for clarifying that you're not interested in engaging at a technical
level.

Feel free to flame on.

-Ekr
Re: Intent to deprecate: Insecure HTTP Xidorn Quan 5/4/15 1:57 PM
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
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 5/4/15 2:04 PM
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
Re: Intent to deprecate: Insecure HTTP Jet Villegas 5/4/15 2:55 PM
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
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Re: Intent to deprecate: Insecure HTTP Daniel Holbert 5/4/15 3:03 PM
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 <e...@rtfm.com
> <mailto:e...@rtfm.com>> wrote:
>
>     On Mon, May 4, 2015 at 1:57 PM, Xidorn Quan <quanx...@gmail.com
>     <mailto:quanx...@gmail.com>> wrote:
>
>     > On Tue, May 5, 2015 at 6:04 AM, Martin Thomson <m...@mozilla.com <mailto:m...@mozilla.com>> wrote:
>     >
>     > > On Mon, May 4, 2015 at 11:00 AM, Daniel Holbert <dhol...@mozilla.com <mailto:dhol...@mozilla.com>>
>     > > 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-pl...@lists.mozilla.org <mailto:dev-pl...@lists.mozilla.org>
>     https://lists.mozilla.org/listinfo/dev-platform
>
>
Re: Intent to deprecate: Insecure HTTP sn...@arbor.net 5/5/15 1:59 AM
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
Re: Intent to deprecate: Insecure HTTP Florian Bösch 5/5/15 6:29 AM
On Tue, May 5, 2015 at 12:03 AM, Daniel Holbert <dhol...@mozilla.com>
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).
Re: Intent to deprecate: Insecure HTTP Mike Hoye 5/5/15 6:49 AM
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
Re: Intent to deprecate: Insecure HTTP Matthew Phillips 5/6/15 6:49 AM
It's absolutely true for hosting yourself today. The only thing even
slightly difficult is setting up dynamic dns.
Re: Intent to deprecate: Insecure HTTP Anne van Kesteren 5/6/15 6:57 AM
On Wed, May 6, 2015 at 2:04 PM, Matthew Phillips
<mat...@matthewphillips.info> 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/
Re: Intent to deprecate: Insecure HTTP Cameron Kaiser 5/6/15 7:29 PM
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

Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 5/6/15 8:51 PM
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 <https://www.mozilla.org/>
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy
Re: Intent to deprecate: Insecure HTTP Adam Roach 5/7/15 10:03 AM
> On May 6, 2015, at 22:51, Eric Shepherd <eshe...@mozilla.com> 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
Re: Intent to deprecate: Insecure HTTP Steve Fink 5/7/15 10:20 AM
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.
Re: Intent to deprecate: Insecure HTTP Eric Shepherd (Sheppy) 5/7/15 2:47 PM
On Thu, May 7, 2015 at 12:43 AM, Adam Roach <aro...@mozilla.com> 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
Re: Intent to deprecate: Insecure HTTP cody....@gmail.com 12/20/16 6:38 AM
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.
Re: Intent to deprecate: Insecure HTTP Jim Blandy 12/20/16 9:47 AM
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-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Re: Intent to deprecate: Insecure HTTP Cody Wohlers 12/20/16 10:28 AM
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.
Re: Intent to deprecate: Insecure HTTP Eric Rescorla 12/20/16 11:13 AM
On Tue, Dec 20, 2016 at 10:28 AM, Cody Wohlers <cody....@gmail.com>
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)."
> >
> >
>
>
Re: Intent to deprecate: Insecure HTTP Edmund Wong 12/20/16 6:21 PM
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
Re: Intent to deprecate: Insecure HTTP Steve Fink 12/20/16 9:39 PM
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 <script> tag, I can
inject it into all of the HTTP network traffic on my LAN. Not so nice if
visiting an HTTP website at Starbucks or the public library gets you pwned.

Re: Intent to deprecate: Insecure HTTP Edmund Wong 12/21/16 12:14 AM
Point taken. Someone could just as well crack into a server that
has HTTPS and hijack it to inject HTTPS-enabled browser exploits.  Sure,
it's not as simple as injecting it in HTTP traffic, but that still
could happen.  No amount of HTTPS could prevent your system being pwned,
which is why defense in layers is the best security.

In any event, the choice is Mozilla's.

Edmund


More topics »