Mozilla: Deprecating Non-Secure HTTP [LWN.net]

The Mozilla community has declared its intent to phase out "non-secure" (not encrypted with TLS) web access. "Since the goal of this effort is to send a message to the web developer community that they need to be secure, our work here will be most effective if coordinated across the web community. We expect to be making some proposals to the W3C WebAppSec Working Group soon."

to post comments

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 2:06 UTC (Fri) by charlieg (guest, #102307) [Link] (41 responses)

Why does all web traffic need securing?

I don't want my company website (the public facing bit) to be HTTPS. It's freely available information. Newsletters, magazines etc. The HTTPS is just overhead for 90% of what they put online. Of course, for user interaction you want that over HTTPS, but for just serving up public information - NO!

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 2:10 UTC (Fri) by roskegg (subscriber, #105) [Link] (5 responses)

Full agreement. And encryption makes debugging hell on earth. Plaintext must always be a first-class option.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:50 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

> And encryption makes debugging hell on earth.

It's easy enough to feed an encryption key into Wireshark and have it dissect packets. Or you can use built-in debugging tools in your browser or HTTP libraries.

I'd like to make sure nobody *else* can debug *my* HTTP connections, thank you.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:51 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

No, it's not easy. If PFS is used, you _have_ to actively MITM connections.

Knowing private keys is not enough.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 10:19 UTC (Fri) by farnz (subscriber, #17727) [Link]

NSS makes this easy, though - SSLKEYLOGFILE can log CLIENT_RANDOM lines to be fed to Wireshark, which include the actual master secret chosen in the TLS negotiation, not the private key.

This lets you log packets and session keys separately, then combine them at analysis time, without an active MITM.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 22:47 UTC (Fri) by proski (guest, #104) [Link]

I'm sure http will stay there for debugging. Just like telnet and ftp. It's not like they are banned.

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 19:05 UTC (Mon) by javispedro (guest, #83660) [Link]

So maybe we need to make HTTPS debugging easier, instead of falling back to plain text. Whenever someone says "but it's easier to debug!" I'm always reminded of this guy who used to hexedit binaries to fix bugs, instead of redoing the full build cycle.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 2:45 UTC (Fri) by noahm (subscriber, #40155) [Link] (10 responses)

Just because it's public information doesn't mean you don't need to consider the privacy of those accessing it. Think of it this way, libraries (the kind with books) contain nothing but publicly accessible information, yet they fight fiercely to preserve the privacy of their patrons. Why? Because who reads what and when they read it is important. Think of information at some place like webmd.com. All of that information is public, yet I don't want the world to know it if I start researching herpes treatment.

Your argument sounds a lot like the "it's just metadata" argument presented in support of bulk surveillance.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 5:37 UTC (Fri) by rsidd (subscriber, #2582) [Link] (9 responses)

I don't think https protects you from that. You will still know who (ip address) is accessing what website. True, usernames will be encrypted but I'm not sure how big a deal that is.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 6:54 UTC (Fri) by josh (subscriber, #17465) [Link] (3 responses)

https hides the URL, too.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 15:04 UTC (Fri) by cortana (subscriber, #24596) [Link] (2 responses)

Presumably the hostname is also transmitted in plaintext if SNI is in use.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 21:04 UTC (Fri) by luto (subscriber, #39314) [Link] (1 responses)

TLS 1.3 will hopefully fix this.

Mozilla: Deprecating Non-Secure HTTP

Posted May 5, 2015 17:08 UTC (Tue) by dkg (subscriber, #55359) [Link]

unfortunately, encrypting the SNI is not guaranteed for TLS 1.3. We need more people to advocate for it. I'm still hopeful that we'll make it *possible* to encrypt the SNI, if both parties want to, but it looks unlikely for that to be the default, unfortunately.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:54 UTC (Fri) by job (guest, #670) [Link]

It depends on who your adversary is. It is clear from the Snowden leaks that NSA, and presumably simliar organizations around the globe, are interested in who you email and what servers you speak with. When that dragnet flags something as interesting they concern themselves with the contents of those messages. So I think you are right. The "who" is just as important as the "what", and much more difficult to protect.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 15:58 UTC (Fri) by noahm (subscriber, #40155) [Link] (3 responses)

The whole HTTP exchange is encrypted. Request and response headers and bodies. Consider a site like wikipedia. If I send an HTTPS request to one of its servers, all you know is that somebody at my IP is accessing content on that host, but you have no idea what content I'm accessing. Yes, the IP is metadata leakage, and if it's too much leakage then you need to consider something like a VPN and TOR for protection. But without HTTPS, you're leaking the entire HTTP conversation and body content. The premise of Mozilla's work here is that this is too much information to leak by default on the modern internet. There's a lot of evidence to support this position, from Snowden's leaks to Jewel v. NSA, etc.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 20:09 UTC (Fri) by richmoore (guest, #53133) [Link] (2 responses)

Note that TLS doesn't hide the length of the messages, so in the case of a site like wikipedia it's actually possible to identify the page looked at in many cases.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 22:04 UTC (Fri) by roc (subscriber, #30627) [Link]

Yeah, traffic analysis is a big problem, but HTTP/2 plus some extra work in the browser can help with that.

Mozilla: Deprecating Non-Secure HTTP

Posted May 6, 2015 12:58 UTC (Wed) by hkario (subscriber, #94864) [Link]

protecting from traffic analysis is second step, first we need to get to a place where it's the only thing the attacker can get to, and not the plaintext

yes, PKI with current CA model is broken, TLS is not without faults and leaks information, it's easy to misconfigure so you don't get perfect forward secrecy, etc.

but even this flawed system is vastly superior to using plaintext!

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:04 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Because in a world rife with evil actors such as governments (NSA, the Great Cannon, etc.), massive botnets which go undetected for years, misconfigured routers broadcasting rather than sending targeted traffic (yeah, I've seen it), firesheep, and ad networks, and so on, you have no idea what needs to be considered private anymore to actually keep things private.

In the US, knowing the ZIP code of your work and your home block (fairly easily determined by your cell phone provider, or any website you log into from both locations) is uniquely identifying for something upwards of 90+% of people (I do not know whether this was targeted at cities or rural areas; I suspect at least suburban). Your pattern of DNS or TCP endpoints queries (or even just the aggregate distribution of it) is almost certainly uniquely identifying for the vast majority of people. That would need Tor to really cover that, but that will take much longer to complete. This is a step in the right direction.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:04 UTC (Fri) by thestinger (guest, #91827) [Link]

Authentication is important for nearly all content. Not using HTTP means anyone can impersonate your company's website and abuse the trust relationship with the visitors for evil. For example, they can be tricked into downloading malware.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:32 UTC (Fri) by flussence (guest, #85566) [Link]

Time to bring back Gopher! No security headaches to deal with when your entire protocol is just ls + cat over TCP.

(only half joking... I'd really like a cacheable, non-interactive subset of HTTP with signatures and modern compression baked in though.)

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:51 UTC (Fri) by josh (subscriber, #17465) [Link] (2 responses)

So you're comfortable with an end-user's ISP or malware changing the content of your page to inject ads? Or hijacking your page to lead somewhere else? How about subtly changing the "login" link in the corner to lead to a phishing site, in an attempt to spear-phish your employees?

*All* content needs privacy and integrity protection.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 6:56 UTC (Fri) by ebirdie (guest, #512) [Link]

> *All* content needs privacy and integrity protection.

In addtion to the above I think that even the comments to this news item also show there is still too little common sense and wisdom about JavaScripts as web-content which gets too little attention, to begin with, for trust where and how scripts get loaded.

For getting a sense one just have to browse web long and diverse enough with NoScript extension in Firefox and enabling sites one by one just to see, where each site loads scripts from.

My perception is that on many and increasing number of sites one can't get to useful content until one enables enough scripts from sites, which by their source domain names, for one vague point to evaluate, seem to look like consumer information harvesting scripts. That is, you give, or are taken information from, before you get a chance to decide whether the web-site and the given information was any worth to get information from you (even the standard web-server logging information when and from what IP a script got loaded from as the web-server lives in a domain, where you have no trust relationship to).

And because of scripts the web-site one sees in the browser address bar for a loaded web-page has little to build trust on in today's concept of 'loading a web-page'. And although the web-site, like LWN.net, wants to be trustworthy to its consumers, there isn't very much in common knowledge for showing trustworthiness to users except the browser address bar and the lock icon presenting https to 'the main site'. There are way too many and diverse knobs for an avarage web-consumers to affect the outcome of web trust.

Mozilla: Deprecating Non-Secure HTTP

Posted May 16, 2015 5:47 UTC (Sat) by ghane (guest, #1805) [Link]

josh, I assume you are replying to charlieg.

Maybe he is OK, maybe he has not considered the advantages of what Mozilla want. But consider, till the end of this sentence, that perhaps has _has_ done a cost-benefit evaluation, and then decided to use HTTP instead of HTTPS.

You certainly have the right to demand HTTPS-only, and Mozilla developers can do what they deem best; but neither changes charlieg's stated requirements.

Educate me, help me, ignore me; but why make fun of me?

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 4:34 UTC (Fri) by shmerl (guest, #65921) [Link]

Because it's a mess when it's optional (just look at the current situation). In the worsening Big Brother climate, I'd say HTTPS always provides good benefits, even if in practice it's not always needed.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 7:25 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Freely available information like your endorsement of the Flat Earth model and rejection of the germ theory of disease ?

Oh, maybe when you wrote the page that endorsement wasn't there? Sorry, there was no way for us to tell because you chose an unsecured protocol.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:51 UTC (Fri) by alanjwylie (subscriber, #4794) [Link] (7 responses)

Because encryption stops MITM javascript injection DOS attacks, e.g. the Chinese "Great Cannon".

http://googleonlinesecurity.blogspot.com.au/2015/04/a-jav...

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 9:11 UTC (Fri) by oldtomas (guest, #72579) [Link] (6 responses)

[Great Cannon]

Oh, yeah. That was the Great Firewall (or Baidu itself) injecting Javascript in Baidu content.

Opening the certificates list in my Iceweasel, I see among others, not less shady:

"China Internet Network Information Center EV Certificates Root"

Do I need to say more?

I mean: authenticated+encrypted is all well and good, but Mozilla's oversimplifying stance "unencrypted == bad; encrypted == good; ugh!" is slowly getting on my nerves. That's actively de-educating people, while everyone knows by now that an educated user is an integral part of a security (uh -- what's the current marketdroid term: ecosystem? solution? HAH! "experience"!).

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 9:56 UTC (Fri) by roc (subscriber, #30627) [Link] (5 responses)

The CA situation sucks but it can get better. Misbehaving CAs can be detected and punished --- and are, CINIC in particular.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 15:30 UTC (Fri) by oldtomas (guest, #72579) [Link] (4 responses)

The CA situation sucks but it can get better [...]

The CA situation wasn't my point, just one (particularly painful) illustration. My point was rather the false sense of security conveyed by this obsession on HTTPS.

I do agree, without HTTPS:

content is unencrypted, so everyone can eavesdrop.
content is unauthenticated, so everyone can man-in-the-middle/inject content (so yes, bad news for those saying "open content ain't a problem": injecting malicious Javascript in Wikipedia is a problem too).

But the CA situation ain't the only elephant in the room (and I wish I could be half as optimistic as you are about this detecting and punishing thing, but I can't)

Another elephant in the room is active, executable content (hello, Javascript), and Mozilla is making it ever more difficult for normal users to switch that off (because users are idiots?).

Yet another pet peeve of mine: hiding half of the URL (or even all of it), for the sake of some (ick!) "experience"

There is a whole herd of elephants out there, and I think signalling to the user "now you're secure" just because (s)he has HTTPS is the wrong kind of signal.

Making the users dumber: what could possibly go wrong?

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 20:20 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> I think signalling to the user "now you're secure" just because (s)he has HTTPS is the wrong kind of signal.

What I remember of the browser vendor proposals was that the default would be SSL but that wouldn't be highlighted as any different than HTTP is today, EV certificates would still get the green bar and the lack of SSL (cleartext HTTP) would get a warning the same as a failed cert check, because the possibility of MITM is the same.

So you have three states
- MITM-able (HTTP or HTTPS-without-known-cert)
- Normal (HTTPS with known cert)
- Securified (HTTPS with EV cert)

Mozilla: Deprecating Non-Secure HTTP

Posted May 5, 2015 8:18 UTC (Tue) by epa (subscriber, #39769) [Link]

At last, some sanity. The current situation where big scary warnings are displayed for self-signed certificates, but *no warning whatsoever* for unsecured http, is entirely daft.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 22:12 UTC (Fri) by roc (subscriber, #30627) [Link] (1 responses)

Simplifying security makes users more secure. Emphasizing the TLD+1 hostname in the URL bar is not for the sake of some "experience", it's to reduce the effectiveness of attacks that confuse users with URLs like "https://google.com.evil.com".

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 14:04 UTC (Sat) by oldtomas (guest, #72579) [Link]

@raven: thanks for the clarification. Yes, it makes sense.
@roc: make no mistake: basically, pushing encryption (and authentication) is a direction I *do* support[1]. But I'm fiercely opposed to wholesale dumbing down of the user, because (s)he is the weakest link in the security chain (and I don't exclude myself there).

OTOH security is hard, so users need all the help they can get. But to get anywhere (I'm convinced), this help should *include* the user.

> Simplifying security makes users more secure.

All generalizations suck :-)

(on a more serious note: I don't think "simplifying at all costs" => "dumbing down the user" helps here. (Trivial) case in point: hiding part of the URL (I wasn't talking about highlighting part of the URL: that's a good thing, IMO).

[1] as I do appreciate what you and others are doing!

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:54 UTC (Fri) by sytoka (guest, #38525) [Link]

I agree. I have for example web site in SPIP, the public side is in http and the private part is in htts after authentification by apache (before any php code). I thinks this is a good way.

Maybe Cookies could be forbiden in http, as well as hidden parameter in form ... So http continue to exists but it will be clear that every thing is public on it.

I still want anonymous to my web site and maybe we can integrate far more better authentification in web browser and https... (for example with a standart session button in the firefox interface)

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 14:04 UTC (Fri) by cesarb (subscriber, #6266) [Link] (3 responses)

> I don't want my company website (the public facing bit) to be HTTPS. It's freely available information. Newsletters, magazines etc.

TLS does not only protect against eavesdropping. Most importantly, it also protects against modification in transit.

You would not want some joker to be able to replace the images on your company website with shock site images. Or, as has been done recently, inject malicious JavaScript on your company's pages, such that it is blamed for attacking another website.

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 18:17 UTC (Mon) by sytoka (guest, #38525) [Link] (2 responses)

> TLS does not only protect against eavesdropping. Most importantly, it also protects against modification in transit.

It's possible to sign a message without crypt it ! The same is possible with HTTP. It's just possible to sign HTTP page...

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 22:20 UTC (Mon) by cesarb (subscriber, #6266) [Link] (1 responses)

> > TLS does not only protect against eavesdropping. Most importantly, it also protects against modification in transit.

> It's possible to sign a message without crypt it ! The same is possible with HTTP. It's just possible to sign HTTP page...

Yes, TLS can do that too. The following cipher suites sign without encrypting: TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA, TLS_RSA_WITH_NULL_SHA256.

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 15:53 UTC (Wed) by gerv (guest, #3376) [Link]

I very much doubt any browser supports those suites.

Gerv

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 13:23 UTC (Sat) by Lennie (subscriber, #49641) [Link] (2 responses)

I won't mention profiling and anything like that, but this isn't just an effort by Mozilla. Did you see what the blog started with:

"IETF, IAB (even the other IAB), W3C, and the US Government"

Organisations like the IETF and W3C have literally said: no more plain text protocols, encryption should be the norm for Internet traffic. They are collectively working on fixing any problems in existing protocols.

A certain other browser builder had similar ideas:
https://www.chromium.org/Home/chromium-security/marking-h...

You prefer the reputation of your company to be tarnished because some man-in-the-middle attacker changed the website before it arrived at the viewer of the content ?

A simple example:
do you think Apple was happy about an ISP inserting ads on their website ?: http://arstechnica.com/tech-policy/2013/04/07/how-a-banne...

http://www.reddit.com/r/programming/comments/1bku8g/this_...

How about a website that uses ads to make some money to keep the website running having their ads replaced ?:

https://www.webmasterworld.com/google_adsense/3649194.htm

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 20:28 UTC (Sat) by Wol (subscriber, #4433) [Link] (1 responses)

How about trying to run a SCAD system over http, only to find that your router was injecting ads into your data stream ...

There was a router manufacturer that thought injecting ads into port 80 traffic was fine, and it did screw up a bunch of systems that used port 80 for transmitting data streams ...

Cheers,
Wol

Mozilla: Deprecating Non-Secure HTTP

Posted May 7, 2015 10:26 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

How about trying to find what is crapping your SCADA, only to find everything is encrypted and no one but the manufacturer (who denies any problem) or hackers (who took the time to identify vulnerabilities) can see what actually happens.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 2:09 UTC (Fri) by gerdesj (subscriber, #5446) [Link] (7 responses)

Lovely idea, however I think I should have the power to define what is "secure" or not within my LAN(s). I take it that this proposal will require me to run all my websites with https.

Unfortunately I have a nasty habit of creating my own CAs that are well secured and I can personally trust, following the model, but are not in my browser's trust store by default but I consider them secure because I have personally touched them and followed my procedures.

Now I also have several websites that I don't want to encrypt - I can't be arsed: I own the perimeter and there will be no gain with encryption. Will you give me an easy opt out?

Anyway, is encrypt everywhere the right thing to do?

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:05 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Could it not determine it based on the routing tables? At least as an initial approximation? And just ignore all "local IP" ranges on unencrypted wireless.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:53 UTC (Fri) by josh (subscriber, #17465) [Link]

You can either install your CA into your browser/system certificate store, or use certificate pinning to install just the particular certificates for your own sites.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:55 UTC (Fri) by josh (subscriber, #17465) [Link] (4 responses)

> Now I also have several websites that I don't want to encrypt - I can't be arsed: I own the perimeter and there will be no gain with encryption.

"I own the perimeter" sounds like the start of a lovely post-mortem for how an exploit happened. https://en.wikipedia.org/wiki/Defence_in_depth

Consider that Google has moved to encrypting all traffic within their datacenters, between machines, specifically to combat any traffic-sniffing within those data centers, just in case one random box got exploited.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 9:42 UTC (Fri) by gerdesj (subscriber, #5446) [Link] (3 responses)

> "I own the perimeter" sounds like the start of a lovely post-mortem for how an exploit happened.

Fair enough but I'd like to have the choice. It's not as though I'm asking for a stay of execution for Active X but I think its a bit harsh to deprecate http without the s. You might as well mandate blacked out windows on all cars.

Cheers
Jon

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 15:10 UTC (Fri) by jezuch (subscriber, #52988) [Link] (2 responses)

> Fair enough but I'd like to have the choice. (...) You might as well mandate blacked out windows on all cars.

You might as well mandate having headlights on all the time, even at midday in summer...

...which they actually did [over here].

Be careful with your car analogies ;)

Mozilla: Deprecating Non-Secure HTTP

Posted May 5, 2015 15:15 UTC (Tue) by Wol (subscriber, #4433) [Link] (1 responses)

Actually, even if it's NOT mandated, I will turn my headlights on on the motorway if it's sunny. It really does make you MUCH more visible in the mirror of the guy in front.

Cheers,
Wol

Mozilla: Deprecating Non-Secure HTTP

Posted May 5, 2015 21:15 UTC (Tue) by bronson (subscriber, #4806) [Link]

Be careful when driving with the sun behind you: http://en.wikipedia.org/wiki/Counter-illumination#Militar...

Some friends and I tested this in college (pre-Wikipedia, alas)... When oncoming traffic crests a hill against a bright sky, the cars with headlights on are much harder to see. This is a rare enough situation that it's probably negligible but it does hint that there's no 100% solution.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 3:52 UTC (Fri) by k8to (guest, #15413) [Link] (12 responses)

I don't think this is going to work.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 13:14 UTC (Fri) by ballombe (subscriber, #9523) [Link] (11 responses)

Agreed. As long as more serious security vulnerability are found in HTTPS implementations than in plain HTTP implementations, the claim that HTTPS adds security is dubious. Heartbleed did not affect HTTP servers that were
not configured to do SSL.

Encryption adds complexity. Complexity adds potential for vulnerability.
Until there is an TSL implementation which is highly trusted to be safe, adding HTTPS will be an hard sell.

This is before taking into account the fact that HTTPS does not protect against MITM by actors which can coerce registrars to create forged keys.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 16:18 UTC (Fri) by pizza (subscriber, #46) [Link] (10 responses)

> Heartbleed did not affect HTTP servers that were not configured to do SSL.

While you are technically correct, this statement leaves out the fact that non-SSL servers offer no security at all.

> Until there is an TSL implementation which is highly trusted to be safe, adding HTTPS will be an hard sell.

...So what you're saying is that until we have a perfect implementation, we're better off with no security whatsoever?

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 20:18 UTC (Fri) by ballombe (subscriber, #9523) [Link]

>> Heartbleed did not affect HTTP servers that were not configured to do SSL.

>While you are technically correct, this statement leaves out the fact that non-SSL servers offer no security at all.

You are mixing server side and client side security.
Yes non-SSL server offer no security to the client.
However SSL server is a potential security issue to the server.
Guess what the server admin will choose ?

> ...So what you're saying is that until we have a perfect implementation, we're better off with no security whatsoever?

Bad implementations does not offer any security either.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 23:59 UTC (Fri) by flussence (guest, #85566) [Link] (8 responses)

No security at all is a net improvement over negative security (e.g. a SSL implementation handing over other users' credentials due to a bug that was reported and ignored for over a year) combined with a false sense of security (a hundred shady CAs being quietly spoonfed to you by Big Browsers).

I'd like to direct you to https://bugzilla.mozilla.org/476766 - but if you can't be bothered reading all that, here's the first highlight:
> If CNNIC root certificate is added by default as Builtin Object, they can forge verified gmail certificates to cheat the Chinese users by using MITM attack against the SSL protocol.

Sound familiar? It should - CNNIC made headlines a few weeks ago... that comment (and many others), however, predicted it five years in advance.

One thing's for sure; I don't trust Mozilla to be a good steward of the web any more, not as long as they're making security decisions on behalf of a hundred million people by religiously adhering to idiotic policies and procedures like this.

This meme of blithely issuing proclamations of "SSL is secure and CAs are good for you and browsers know best" (which you've just partaken in) *causes* these problems, and it's about time this particular security theatre should be burned down. Preferably before the pen-pushers give us another self-inflicted security massacre — we don't have an infinite stockpile of clever names and logos for SSL-related CVEs.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 12:02 UTC (Sat) by pizza (subscriber, #46) [Link]

See, here's the difference between you and . -- I don't throw the whole baby out along with the bathwater.

I recognize that security is a social process, not a technical product.
I recognize that multiple independent layers is better than relying on just one thing.
I also recognize that perfection is the enemy of good.

I don't expect SSL to cure everything; it's but one layer in the system. There are, and will always be implementation bugs, but the presence of those bugs isn't proof that you're better off with nothing.

Even with Heartbleed and other "exploits with a cute PR logo" where do the mass security breaches actually come from? Unsanitized inputs that allow SQL injection, keylogging, and social engineering on a truly massive scale. Or if someone really wants my credentials or data that badly, they'll throw me in jail and/or employ a Guido wielding a rubber hose.

So you no longer trust Mozilla? In all seriousness, who does that leave? You think the "globally trusted" CA system is a festering pile of swill? I don't think there's anyone out there who wouldn't agree with you. Unfortunately, it is the best we have at the moment, and undeniably better than nothing because it raises the bar from "everyone" to "a much smaller subset of everyone". Meanwhile, the replacement infrastructure (ie DNSSEC+DANE) still isn't remotely ready yet -- and I'm talking about the F/OSS stuff like cURL and wget on the client side, and more mundanely, resolver libraries on the back end. Even once that stuff is finally usable by folks that haven't read the RFCs backwards and forwards, it's still going to take some time to deploy to the world at large -- and I'm not going to leave the barn doors completely open in the mean time, and continue to employ a layered security approach to my stuff.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 13:56 UTC (Sat) by Lennie (subscriber, #49641) [Link] (6 responses)

Well, you might not know this, but the this field isn't standing still. They are busy improving HTTPS/CA-system:

- with proper certificate revocation:

Firefox and Chromium* both have a way to revoke intermediate CA-certificates:
https://blog.mozilla.org/security/2015/03/03/revoking-int...

Vendors are working on making OCSP-stapeling mandatory:
https://blog.mozilla.org/security/2013/07/29/ocsp-staplin...
https://www.grc.com/revocation/ocsp-must-staple.htm

This also speeds up visiting websites and improves your privacy.

- detecting certificates issues by the wrong CA and preventing them being used:

http://www.certificate-transparency.org/

Did you know Firefox and Chromium both support Public Key Pinning ?:

If you operate a website you can make sure regular visitors on your website can not be mitm'd by anyone as long as nobody steals your private keys:

https://developer.mozilla.org/en-US/docs/Web/Security/Pub...

The Mozilla documentation doesn't mention it, but you can pin it to any certificate in the chain. So supposedly you can also use it to pin it to one or multiple CA's:
http://www.internetsociety.org/deploy360/blog/2015/05/new...

And there are other improvements as well.

* Chromium, I assume this means at least Opera and Chrome.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 22:49 UTC (Sat) by flussence (guest, #85566) [Link] (5 responses)

> Did you know Firefox and Chromium both support Public Key Pinning ?:

Actually, yes. I tried that out a few weeks ago and couldn't figure out why the browser was silently ignoring the header on a test server, until I saw that page and noticed Mozilla wants a minimum of two different key sha256es.

I ended up abandoning that plan in favour of adding the functionally equivalent DANE entries; those are cacheable, compact binary as opposed to base64, and more maintainable in the long run since it's a standardised, specced format with tooling and automation as opposed to pasting an ad-hoc string into the middle of $webserver's config file.

Yes, I'm aware that doing this is effectively a security no-op for anyone using a current mainstream browser to visit my site. So is conditioning them to click through SSL warning spam — the first browser to offer DNSSEC support as an alternative to that UX farce will be getting some strong word-of-mouth recommendations from me.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 8:38 UTC (Sun) by Lennie (subscriber, #49641) [Link] (1 responses)

Did you think you needed to get a second certificate ?

Because you don't.

All Mozilla (and possibly others, maybe it's even in the RFC, I haven't checked) is trying to do is prevent you from 'bricking' your website/domain.

How could you brick your website/domain ? Well, if someone breaks into your webserver and gets a copy of the private key or your private key gets lost or corrupted including the backup. Maybe your CA needs to create a new certificate and has a policy how they don't want you to send them the same private key again. For all those types of cases you need an extra key.

All you need to do is generate a private key (preferable on an other computer). For example like so:

openssl genrsa -out website_backup.key 2048

It's called public key pinning, so after that all you need to do is extract the public part and you transform it in the right format and add it as the second header:

openssl rsa -in website_backup.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

After that you save your second key offline so it can't be compromised.

And you are done.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 8:48 UTC (Sun) by Lennie (subscriber, #49641) [Link]

Yes, the RFC requires a backup-Pin:

http://tools.ietf.org/html/rfc7469#section-4.3

Because having a backup key pair is so important to recovery, UAs
MUST require that hosts set a Backup Pin (see Section 2.5). The down
side of keeping a not-yet-deployed key pair is that, if an attacker
gains control of the private key, she will be able to perform a MITM
attack without being discovered. Operators must take care to avoid
leaking the key such as keeping it offline.

http://tools.ietf.org/html/rfc7469#section-2.5

The given set of Pins contains at least one Pin that does NOT
refer to an SPKI in the certificate chain. (That is, the host
must set a Backup Pin; see Section 4.3.)

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 15:57 UTC (Wed) by gerv (guest, #3376) [Link] (2 responses)

I think you may be waiting a while - Adam Langley of Chrome on DANE: https://www.imperialviolet.org/2015/01/17/notdane.html . And I believe our team at Mozilla has similar feelings.

Gerv

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 16:36 UTC (Wed) by Lennie (subscriber, #49641) [Link] (1 responses)

Part of that blog post is already outdated:

"DNSSEC, however, is littered with 1024-bit RSA." ... "The RFC suggests that 1024-bit RSA is good for “most zones” until 2022."

Funny little fact about that is that 80% of currently deployed DNSSEC-validating resolvers supports the newer/beter/more secure ECDSA. That was 66% in Sept. last year:

https://ripe70.ripe.net/archives/video/40/

And Cloudflare will be deploying with DNSSEC with ECDSA this year for their domains. So, pretty sure that last 20% is going to melt away pretty fast too.

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 20:23 UTC (Wed) by gerv (guest, #3376) [Link]

One of the trees may have fallen over, but there's still pretty much a whole wood left...

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 4:04 UTC (Fri) by jcm (subscriber, #18262) [Link] (2 responses)

This is terrible nonsense.

Security is a great thing to have. Especially when transmitting personal information. But what benefit is there is encrypting the delivery of all content? So I visit Wikipedia.org to look up something. Sure, maybe I want an SSL option, especially in some geos, but why do I need this by default for every site, all the time? All that does is needlessly add computation and overhead to every operation.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 5:00 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

If most traffic is unencrypted, encrypted traffic stands out. Your use of Wikipedia may not be of interest, but if I'm in a repressive regime and reading a large number of articles on popular uprisings then I'm taking a risk. Having everybody around me use HTTPS as well mitigates that.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 5:03 UTC (Fri) by roc (subscriber, #30627) [Link]

See Josh's comments above. Surfing Wikipedia non-encrypted means:
-- Exposes which Wikipedia topics you visit. That could be a problem for lots of people.
-- Gives ISPs the opportunity to inject ads.
-- Gives ISPs (and governments) the ability to invisibly alter Wikipedia content for their users.
-- When encryption is a non-default option, anyone using it makes themselves a target of suspicion.

Most people, most of the time cannot know whether it's safe to turn off encryption. The "computation and overhead" is a minor cost and decreasing all the time. It's simpler and safer for encryption to always be on.

Step in the right direction.

Posted May 1, 2015 6:37 UTC (Fri) by grahame (guest, #5823) [Link] (11 responses)

It's embarrassing that the web as it stands doesn't provide anything close to privacy by default. Or even a basic guarantee that when you browse to a page you're getting the content it sent you, unmodified.

A lot of the nonsense with hotel wifi intercepting traffic and inserting adverts will go away. The same nonsense with wifi providers scooping up traffic and selling the information (even if in aggregate) to market research companies.

To folks like us this is a moderate pain - we'll have to use a MITM proxy when we want to see traffic in the clear. We can build better tooling to make that less of a hassle.

For users this is a step towards a web providing better security, better privacy, with some confidence you are retrieving the resources you asked for and nothing else.

There are problems with the CA infrastructure, etc - it's not perfect - but this is a wonderful step forward. As an industry we should be happy to embrace an encrypted, more private web - there's no justification for the web of today, which puts people and their information at risk.

I've presented at a few cryptoparties in Australia. We've just had mandatory data retention laws passed. Those parties were attended by hundreds of people; people without a tech background, who just don't want their data scooped up into a giant database thousands of people can access without a warrant. The public cares about privacy. The level of skill and knowledge required to achieve it on today's web is ridiculous.

Step in the right direction.

Posted May 1, 2015 6:52 UTC (Fri) by dlang (guest, #313) [Link] (7 responses)

so you want it that when you try to use the hotel wireless, instead of going through a permission screen, you want to get an error page instead, unless you manually go to the correct page (which will look almost exactly like the current MITM page)

this is an advantage how?

Step in the right direction.

Posted May 1, 2015 6:57 UTC (Fri) by josh (subscriber, #17465) [Link] (5 responses)

There's a standard for routers with captive portals to state that in their DHCP response. Failing that, many systems know to work around this by trying to fetch a known-http page to test connectivity (such as Google's static generate_204 page).

Step in the right direction.

Posted May 1, 2015 18:19 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

pointer on how to do this 'correctly' please?

Step in the right direction.

Posted May 1, 2015 20:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

Captive portal-based wireless have popped up a notification on Android that a login is required. I imagine NetworkManager could be updated to do the same (it might even already do so). Those of us who just use wpa_supplicant and ifcfg scripts (myself included) really can't complain that they don't notify that a login is required (though wpa_supplicant does talk to DBus, so maybe it is just a patch or two away…hmm).

Step in the right direction.

Posted May 7, 2015 4:44 UTC (Thu) by asaz989 (guest, #67798) [Link]

From the behavior when you click that notification after signing in through a separate browser tab, Android is NOT using any DHCP/standards-defined method - Google just has a server at some fixed IP address serving up known content, and whenever you first connect to a new network it tries fetching from that IP to see if it gets anything unexpected.

Step in the right direction.

Posted May 1, 2015 21:31 UTC (Fri) by josh (subscriber, #17465) [Link]

http://datatracker.ietf.org/doc/draft-wkumari-dhc-capport/ documents the DHCP option to identify a captive portal.

http://tools.ietf.org/rfc/rfc6585 defines HTTP status code 511, "Network Authentication Required"; that doesn't help when the client requests an https page, but it does at least distinguish expected content from a hijack by a captive portal.

On the client side, look for the DHCP option, and if you don't see that, automatically fetch a page like http://gstatic.com/generate_204 , and if that doesn't return a 204, show it to the user as a captive portal page before you assume connectivity.

Step in the right direction.

Posted May 2, 2015 0:23 UTC (Sat) by flussence (guest, #85566) [Link]

In hostapd, it's the "network_auth_type" setting.

Step in the right direction.

Posted May 1, 2015 15:56 UTC (Fri) by lsl (subscriber, #86508) [Link]

Well, if they can't use the current MITM crap model anymore due to default mandatory DNSSEC and TLS auth, maybe those wireless providers will learn to do it the proper way. Worst case they just put some piece of paper with usage notes in the hotel room. Can't be worse than spewing garbage down the pipe with the assumption that only modern web browsers will ever make use of the network.

Even better would be if lawmakers started to get a clue and stop making laws that seem to mandate those ridiculous click-through screens.

Step in the right direction.

Posted May 1, 2015 15:00 UTC (Fri) by raven667 (subscriber, #5198) [Link] (2 responses)

> A lot of the nonsense with hotel wifi intercepting traffic and inserting adverts will go away.

This will also break all usage of captive portals which may be a deal breaker, every purveyor of convenience public internet service who needs a billing portal or AUP sign off is going to resist anything that makes their cost per customer to go up, if they need to hand out dot1x credentials from a kiosk or manually register MAC addresses or whatever that will be additional cost rather than the automated portal systems that exist now.

Step in the right direction.

Posted May 1, 2015 16:28 UTC (Fri) by nybble41 (subscriber, #55106) [Link] (1 responses)

> This will also break all usage of captive portals...

The way we currently handle captive portals is a problem. It already breaks various protocols which don't expect to be redirected to a portal, and can't function without performing what amounts to a MitM attack. A better approach would be to have a protocol for the router to announce the URL of the portal page to new clients and simply block any attempt to connect to anything else, without otherwise tampering with the traffic.

Step in the right direction.

Posted May 2, 2015 0:55 UTC (Sat) by zlynx (guest, #2285) [Link]

It is already a problem for my net usage. If I go to a coffee shop I have to intentionally load a HTTP page to get the portal. Something like msn.com. Almost everything else I go to regularly is forced to HTTPS.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 7:30 UTC (Fri) by mm7323 (subscriber, #87386) [Link] (2 responses)

I always considered Mozilla Firefox to have damaged adoption of HTTPS by throwing up big warning pages for self-signed certificates. After that, I think most webmasters saw no value in self signed certs and disabled HTTPS rather than jumping through the hoops and paying the money to get their certificates signed.

Now I think Mozilla will push their browser to irrelevance if they take similar steps for HTTP.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 11:50 UTC (Fri) by pboddie (guest, #50784) [Link]

There really needs to be a more widely-supported/documented way of deploying certificates that encapsulate the required trust relationships for the purposes concerned, and where people don't have to be Bruce Schneier to be sure that they've just done the right thing.

In other words, people shouldn't have to be paying serious money to random corporations to get "official" certificates when those corporations probably cannot be trusted anyway and where the notion of trust in that corporation's role is somewhat dubious in the first place (they're in the browser's list of authorities), nor are more "economical" options involving more limited certificates necessarily any better.

Whether that means embracing stuff like Monkeysphere and PGP trust networks is perhaps something that should be seriously considered. Having an "all or nothing" approach with scary errors is not a constructive way of improving the security situation.

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 16:02 UTC (Wed) by gerv (guest, #3376) [Link]

This essay from 2010 - http://www.gerv.net/security/self-signed-certs/ - still makes most of the right points about why self-signed certs are not the way forward.

Opportunistic encryption is much more promising as a technology.

And certs are $0 today, from WoSign, StartCom or Cloudflare, and soon there will be Let's Encrypt.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:12 UTC (Fri) by bmur (guest, #52954) [Link] (18 responses)

Even though the mozilla foundation is a political organization who can't be trusted, most of the arguments against switching to a https world are reminiscent of the telnet vs ssh battle. Some tools will need to be updated, we adjust, life moves on.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 14:27 UTC (Fri) by mm7323 (subscriber, #87386) [Link] (17 responses)

Then maybe HTTPS needs to be a little bit more like SSH, and not require the cost and complexity of CAs (for dubious value too).

Still, CAs provide security which is much more needed for webservers than sshd - if I logged into an impersonated server I'd think something was suspect pretty quickly if my files and processes weren't there. Being served a modified page or download is much harder to notice, especially if the site isn't one that's been visited before. I'd also imagine that a browser touches more servers in a session than a ssh client does in a year.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 20:17 UTC (Fri) by richmoore (guest, #53133) [Link] (16 responses)

Unfortunately the evidence shows that the ssh model doesn't work:

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

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 0:44 UTC (Sat) by lsl (subscriber, #86508) [Link] (15 responses)

If you assume the SSH model to be "on the initial connection you're vulnerable to MITM, but then it's pretty secure" then the linked article doesn't contradict it at all. It almost exclusively describes ways to make attacks on the initial attempt somewhat more believable, e.g. by generating keys whose fingerprints match the legit ones in the first few digits.

The single exception seems to be the downgrade attack to SSH1. This only works if the user has explicitly enabled SSH1 (it's disabled by default in OpenSSH) and then never used it before so the server's SSH1 key is unknown to the client.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 9:16 UTC (Sat) by roc (subscriber, #30627) [Link] (13 responses)

Then you've misunderstood the linked article. Quoting it:

> In order to determine the base rate for the experiment, I asked the IT
> support staff how many users had called or emailed to verify
> the SSH server key whenever it had changed in the past several years.
> They were unable to recall a single case, or locate any records, of any
> user ever verifying any SSH server key out-of-band.

I.e. host key changes (such as those triggered by MITM attacks) are (almost?) always blindly accepted by SSH users.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 11:26 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (4 responses)

The problem is that Gutmann persuades himself that he needn't even do the _real_ experiment based on that purely anecdotal information. So we actually don't know what happens. You could just as well argue that the baseline is lower, not higher, because the MITM would be unexpected whereas most key changes fall out of infrastructure changes (e.g. "We are upgrading all servers to FooOS 8 tomorrow" -> MITM alert -> "I guess those buffoons didn't copy the keys across" -> no enquiry to IT support).

I actually spent a few minutes _yesterday_ verifying the unexpected new keys for the machine I'm typing this on, because I hadn't used the SSH client on my phone for a while and when it connected on Thursday I got the MITM message, and I thought to myself "Well, that's strange, because I most certainly haven't re-installed or re-built that PC, so I guess I cannot do anything until I have physical access to verify the keys".

In the end it turned out that at some point I upgraded to a newer key algorithm, or maybe the phone SSH client upgraded to support that any my SSH server had all along, and either way the fingerprints checked out & all was well.

On the other hand, when I connected to the fifth of nine servers tasked with running a particular piece of software from a relatively new laptop at work last week, I can't say I even glanced at the (non-MITM) SSH key fingerprint verification step. I asked the Powers That Be to do DNSSEC with SSHFP when I arrived and found they had no PKI worth the name, they said it wasn't a priority, so I don't worry about it - it's their business reputation on the line not mine.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 12:03 UTC (Sat) by roc (subscriber, #30627) [Link] (3 responses)

So you're arguing that users are always aware of the administrative events that cause SSH key changes, and that's why they never call to verify SSH keys?

That's ludicrous in any organization big enough to actually have IT staff.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 19:36 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (2 responses)

Firstly, actually you'll find I've already previously said that this anecdotal enquiry probably doesn't capture very much because of how human memory works. If you ask people how often an uninteresting thing happened, they say they don't remember it happening, and you can write that down as "zero" if you like, but it just means you aren't actually measuring what you thought you were.

Secondly, who said /always/ ? The opposite of "never" isn't "always" it's "sometimes". The number of people who need to spot a MITM to detect the attack isn't "everybody" but only "someone".

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 12:31 UTC (Sun) by roc (subscriber, #30627) [Link] (1 responses)

If the number of key verification contacts was non-negligible, IT staff would know "yeah it happens" even if they can't remember any specific call. If it was negligible but nonzero, they'd recall specific cases because they would be unusual. Thus, for IT staff to recall zero contacts suggest strongly that the number of contacts was actually zero (for those staff).

And if no-one's contacting IT, but some set of people are actually taking SSH connection warnings seriously, then it must be true that all those people are able to correctly correlate key changes with announced updates. Yes, all of them. And that flies in the face of every study I know of of user behavior.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 22:11 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

So, elsewhere in this thread we see that _you_ remembered just having to type "yes" to continue after the SSH key mis-match MITM error. In fact something _completely different_ happened. That's how human memory works, it's not very good on facts, but it tells a useful story. Often your memory is... loose on things you didn't exactly pay attention to at the time. Sometimes it has all the key facts plain wrong. But most of all, it's hugely selective. Most things simply don't impinge on your long term memory at all. That's why I don't trust these negatives.

I kinda want to do an actual experiment, since I know a bunch of systems administrators who have been asked about key mismatches (by me) and I suspect they don't remember it at all. But doing it properly is a bunch of effort (e.g. I need a third party to ask, because if I do it that prompts them to specifically recall incidents involving me). I am lazy.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 12:32 UTC (Sat) by lsl (subscriber, #86508) [Link] (6 responses)

> I.e. host key changes (such as those triggered by MITM attacks) are (almost?) always blindly accepted by SSH users.

Yeah, but that's the same problem as with web browser certificate warnings due to MITM, right? Except that browser vendors probably spent more effort educating users and web server admins. I can imagine that 10 years ago the blind acceptance rate for cert warnings in browsers was much higher, too.

If admins are able to prevent presenting expired certificates to users they should be able to avoid unannounced host key changes.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 18:23 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

> I can imagine that 10 years ago the blind acceptance rate for cert warnings in browsers was much higher, too.

do you have any evidence to show that it's dropped and not risen?

I actually think that it's gone up because so many people deploy self signed certs or let their certs expire that users almost always ignore the warnings.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 18:25 UTC (Sat) by dlang (guest, #313) [Link]

in addition to self-signed certs you have companies that have an internal CA, but don't deploy the CA to all their clients, so people get cert warnings.

Then there are the warnings because people go to https://foo instead of https://foo.company.com

the more people push to use HTTPS because "it's better" but then don't actually do it properly, the more users are trained that cert warnings are indications of admin issues, not security issues.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 3:30 UTC (Sun) by roc (subscriber, #30627) [Link] (3 responses)

It's a lot harder to click through a "bad certificate" warning in Firefox than it is to type "yes" to the SSH warning. It's hard enough that if I click on a search result and get a page with a bad certificate warning, I go back and try another search result. So the warnings are providing some value.

Having said that, it's hard to compare SSH with TLS because the usage patterns are so different.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 8:21 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (1 responses)

There is no click through for the SSH warning we're mostly discussing (the one for MITM that shows up when incompetent people change the keys for a host by mistake), in the most popular implementations. You get a scary message and then OpenSSH (and other command line clients I've seen) exit immediately. The minimum action to "dismiss" the warning is editing the known hosts list to remove the conflicting entry, either manually or with the ssh-keygen tool, and then trying to connect again.

The prompt you can say "yes" to is only for hosts which SSH has never seen before and has no independent means of verifying. Effectively SSH /already/ has the protect-after-first-use policy that is common in anti-MITM systems for the web these last few years. And you can default it on (the client configuration for OpenSSH lets you effectively always say "Yes" here) if like most people you have never verified the fingerprint of a new remote system on first use.

However: If you didn't know there even was a fatal error for MITM, congratulations, none of the people who maintain SSH servers you connect to are incompetent fools, if they're professionally maintained this means someone was doing their job properly. Hooray.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 12:12 UTC (Sun) by roc (subscriber, #30627) [Link]

That's a good point. I have in fact edited known_hosts in the past to get past those warnings, I just forgot about it. (There's only one machine I don't control that I regularly ssh into).

I still think SSH and TLS are different enough in usage patterns (and characteristics of their users) that a comparison is not instructive.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 20:08 UTC (Sun) by flussence (guest, #85566) [Link]

> It's a lot harder to click through a "bad certificate" warning in Firefox than it is to type "yes" to the SSH warning.

Sure, by some metric of how cleverly hidden the buttons are and how many hoops you force the user to jump through on the way to their destination, it's harder. But whoever came up with that idea completely misses the point: how *easy* it is to sleepwalk through them.

A SSH key warning is a rare surprise that stops someone in their tracks, whereas bypassing a browser SSL alert is just another everyday nuisance like Windows UAC prompts: the overuse of them has trained people to click through them without thinking. I'd hazard a guess that forced-HTTPS will coincide with a spike in downloads for SSL error bypass addons.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 15:23 UTC (Sun) by k8to (guest, #15413) [Link]

I don't think this is a user problem.

Every time my administrators fail to maintain host keys, I send them a nastygram explaining exactly what they did wrong, how easy it is to not do it wrong, and how this error compromises the security of our company/etc. They don't care.

The problem here is that admins just don't care about security, so the result is that ssh trains the users not to care about host keys changing.

I don't know that you can design a system to produce security-conscious users in the face of security-unconcious admins.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 10:32 UTC (Sun) by Lennie (subscriber, #49641) [Link]

There seem to be a lot of people that think HTTPS isn't being improved.

And this also isn't just Mozilla doing this on their own.

The Mozilla blog post even mentions some of the organisations which have pledged over a year ago that things need to improve drastically.

These are organizations like W3C and IETF, they basically said and I quote:
"Pervasive Monitoring Is an Attack"

http://tools.ietf.org/html/rfc6973

"The IAB now believes it is important for protocol designers, developers, and operators to make encryption the norm for Internet traffic."

"The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default."

https://www.iab.org/2014/11/14/iab-statement-on-internet-...

It's not just Mozilla, it's Chromium developers as well:
https://www.chromium.org/Home/chromium-security/marking-h...

Look at some of the changes the IETF community are making:
http://www.internetsociety.org/articles/ietf-privacy-update

Anyway, if you like the SSH-model. You might like this new RFC: "RFC7469 HTTP Public Key Pinning"

This allows the operator of a website/webserver to make sure the next time a user visits his site the browser will check if it's using the proper keys.

So the first time you visit a site it will be verified by using the existing CA-system, the next time you visit the website it will use the key-information the operator has given the browser to verify if it's the real site.

It's still a bit new and I think better documentation is in order, but it's supported by Chrome and Firefox so here are some links:

https://developer.mozilla.org/en-US/docs/Web/Security/Pub...

https://noncombatant.org/2015/05/01/about-http-public-key...

http://www.internetsociety.org/deploy360/blog/2015/05/new...

http://tools.ietf.org/html/rfc7469

That to me, seems is sort of better than the default SSH-model.

At least more appropriate for visiting websites: you don't want to get a 'do you want to accept this key' multiple times for each different domains on every website you visit.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 8:24 UTC (Fri) by seneca6 (guest, #63916) [Link] (26 responses)

I maintain many very small, not very confidential web sites. Some run even on non-commercial shared hosting. Now I don't want to appear as the last telnet-user, but in exchange I need a reasonable, Free mechanism to generate certificates, including wildcard certificates. I need something that works right now. I need CAcert pre-installed in the browser's stores!

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 11:34 UTC (Fri) by roc (subscriber, #30627) [Link] (6 responses)

You don't need something that works "right now" ... HTTP is not going away overnight, not until Let's Encrypt and other initiatives are in place for your needs.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 11:55 UTC (Fri) by seneca6 (guest, #63916) [Link] (5 responses)

Even if HTTP will not go away overnight, scary-looking warning pages would be bad enough for, say, non-techie community sites.

Isn't the whole point of announces like this one - and the one from the Chromium team - that people start thinking and preparing their sites? It certainly would help it Let's Encrypt and said other initiatives would have been in place by the time of the those announces!

Having CAcert browser support would be nice as that particular initiative has been in place now for a long time. I know about its history and the audit saga, to me the project and its community is way more trustworthy than other systems that are yet to be finished.

Mozilla: Deprecating Non-Secure HTTP

Posted May 1, 2015 22:20 UTC (Fri) by roc (subscriber, #30627) [Link] (4 responses)

Actually, the user-visible behavior of existing sites probably won't change at all, at least not for a long time. A proposed first step to start restricting certain new Web API features to encrypted pages. That creates an incentive to encrypt new content without breaking old content.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 12:06 UTC (Sat) by drago01 (subscriber, #50715) [Link] (3 responses)

Well people usally develop in an environment without HTTPS (embedded servers or whatever) ... restricting APIs to only the deployment configuration would just piss people off.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 12:33 UTC (Sun) by roc (subscriber, #30627) [Link]

There are lots of ways to address developer issues; the best one depends on the specifics of the developer's situation.

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 3:12 UTC (Mon) by oshepherd (guest, #90163) [Link] (1 responses)

localhost is explicitly exempted

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 7:56 UTC (Mon) by osma (guest, #6912) [Link]

> localhost is explicitly exempted

So this creates yet another situation where you have something working on localhost, but which will fail when deployed (to a plain HTTP site in this case).

Oh well, I hope that the JS methods affected by this at least give sensible error/log messages instead of just silently failing.

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 21:01 UTC (Sat) by mmonaco (guest, #84041) [Link] (18 responses)

What's wrong with StartSSL?

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 21:41 UTC (Sat) by anselm (subscriber, #2796) [Link] (7 responses)

Nothing really, except that as a commercial CA, at the end of the day they're about making money, not about security (even if they're handing out certificates for free).

The aggravating thing is how there are so many dodgy commercial CAs out their with their root certificates in the popular browsers, while a non-commercial project like CAcert, which can afford to be about security rather than making money, isn't allowed in.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 3:35 UTC (Sun) by roc (subscriber, #30627) [Link] (6 responses)

You make it sound like a conspiracy, but Mozilla doesn't decide arbitrarily which CAs to "allow in. We try to be fair by having a published policy wand "allowing in" any CA that meets the policy. Unfortunately CAcert is still working on their audit plans etc so doesn't meet the criteria (while those "dodgy" CAs do).

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 9:07 UTC (Sun) by anselm (subscriber, #2796) [Link] (3 responses)

True, and that's probably a good thing in principle. The problem with this in practice is that (a) many of the audits of commercial CAs aren't really worth the paper they're printed on, but there is no real way of getting rid of a CA again if later on it turns out that they've been misbehaving, and (b) the way CAcert operates is different enough from the way commercial CAs operate that the usual audit procedures don't really work, which tends to complicate things.

Let's hope that the good people at CAcert eventually get their act together so we'll see their roots in the browser trust stores.

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 16:11 UTC (Wed) by gerv (guest, #3376) [Link] (2 responses)

I give you CNNIC as the counter-example to your point a). https://blog.mozilla.org/security/2015/04/02/distrusting-...

Gerv

Mozilla: Deprecating Non-Secure HTTP

Posted May 14, 2015 1:38 UTC (Thu) by anselm (subscriber, #2796) [Link] (1 responses)

Sort of. It turns out that many CAs are really “too big to fail”, which is why, if there are problems, browser makers such as Mozilla prefer to go through intricate gyrations trying to salvage as much use out of their existing root certificates as possible instead of removing those outright. In the CNNIC case, instead of throwing their root certificates out, the Firefox certificate checking code will apparently receive special patches such that older CNNIC-issued certificates are still allowed. Whether that is a great idea from a software robustness POV is at least debateable.

And that's for a CA whose international impact is a lot less than that of, say, VeriSign/Thawte/Symantec, GoDaddy, or StartCom. (Nobody in Internet circles seems to like the Chinese government all that much, anyway.) If the same thing happened to one of those then the incident would probably just be shrugged off because there is no way one could remove VeriSign's certificates from the root store no matter what sort of blooper they commit.

Mozilla: Deprecating Non-Secure HTTP

Posted May 14, 2015 8:17 UTC (Thu) by gerv (guest, #3376) [Link]

If the same thing happened to one of those then the incident would probably just be shrugged off

That's just not true. One of the reasons we took the action we did with CNNIC (effectively, banning any new certificates from being issued while continuing to recognise the old ones) is precisely because it is the sort of action that we could envisage taking against a larger CA if they were in a similar position. These "intricate gyrations" you talk about are actually a decent solution to the Too Big To Fail problem. We can't wave a magic wand and turn the CA market into 20 companies each with 5% market share; but what we can do is figure out how we can have an enforcement regime which can apply to any of the companies in the market. And this is it.

Policy

Posted May 4, 2015 9:26 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)

While the individual decisions aren't arbitrary the _policy_ is. If it were effective, you could point to that. But it isn't effective so far as I can tell - the incidents that have gone public in recent years didn't stem from problems found in audit but were instead detected independently.

"We have a policy" isn't good enough. The policy should be effective, and so long as it isn't as effective as you'd like (in this case, so long as CAs are sometimes subsequently found to have fallen short of what we expect and require) you need to be actively improving it.

One popular way to design a racing yacht has the keel as a completely separate piece which is then bolted to the hull late in construction. "Obviously" if the bolts were to fail, the keel would detach from the boat leaving it top-heavy and leaky as a sieve. Loss of the vessel is certain, loss of life is likely. The _policy_ for maintenance of these yachts says that it's sometimes necessary to remove the keel in order to properly inspect the otherwise concealed structures by which it's attached. But it doesn't specify when that would be, and in practice such work is difficult and expensive so it is rarely undertaken unless there is obvious damage. Thus sometimes the keel falls off an apparently perfectly good yacht in open water, and people die.

They too have a policy, but hopefully you can see that it needs to be improved.

Policy

Posted May 13, 2015 16:13 UTC (Wed) by gerv (guest, #3376) [Link]

Saying that "problems were found" doesn't mean the audits were ineffective, it means that they weren't 100% effective. If there were no audit regime at all, I suspect the quality of CAs and their security practices would be significantly lower.

As audit is not 100% effective, many other things are being done - lists of which have been posted at least twice in this thread. Certificate Transparency in particular will be very useful.

Gerv

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 21:54 UTC (Sat) by seneca6 (guest, #63916) [Link] (8 responses)

I don't want a freebie from a gentle for-profit, I want a community CA. One that gives me a wildcard certificate for free, for as many domains as I want. One that lets me revoke keys for free. One whose source code is FOSS.

If I'm not mistaken, CAcert does all of that. It's the very best we have right now within the whole messed up CA "ecosystem", and I think it's a great pity that it does not come included by default in FOSS browsers. Not even on Debian any longer...

Mozilla: Deprecating Non-Secure HTTP

Posted May 2, 2015 23:27 UTC (Sat) by mmonaco (guest, #84041) [Link] (6 responses)

So do you guys not use Google to search, or gmail, etc because they're tributaries to Google's revenue streams? I agree the the CA system is a bust, but StartSSL lets me get certs for my personal services that just work; it's a concession I'm willing to make until a proper solution comes along. Ideally it would be one that intrinsically delegates the ability of a (sub)domain owner to generate their own certs, punting to DNSSec I suppose.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 9:23 UTC (Sun) by oldtomas (guest, #72579) [Link] (5 responses)

> So do you guys not use Google to search,

I can't speak for all "you guys", but I don't search via Google. I use DuckDuckGo (there are other alternatives out there)

> or gmail, etc

Definitely not: I host my mail myself

> because they're tributaries to Google's revenue streams?

I'm not a 100% anti-Google. They're doing a couple of cool things. But there's something as "too big to succeed".

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 17:28 UTC (Sun) by mmonaco (guest, #84041) [Link] (4 responses)

> I can't speak for all "you guys", but I don't search via Google. I use DuckDuckGo (there are other alternatives out there)

I knew that was coming

> Definitely not: I host my mail myself

I do as much as I can from my non-business ISP connection (mainly Calendar, Contacts, Data). But I don't have a good solution for email without $$$. I can set up my own IMAP server, sure, but unless I'm able to do SMTP it's really just an exercise. So for now I use my grandfathered free google apps with my own domain.

Mozilla: Deprecating Non-Secure HTTP

Posted May 10, 2015 6:53 UTC (Sun) by mgedmin (guest, #34497) [Link] (3 responses)

I've been doing my own SMTP for the last 12 years. What am I missing?

Mozilla: Deprecating Non-Secure HTTP

Posted May 10, 2015 7:14 UTC (Sun) by anselm (subscriber, #2796) [Link] (2 responses)

You probably have a fixed IP address for your mail server and mmonaco hasn't. An e-mail server without a fixed IP address isn't a great idea.

Mozilla: Deprecating Non-Secure HTTP

Posted May 11, 2015 5:28 UTC (Mon) by mgedmin (guest, #34497) [Link]

Yes, I have a static IP.

Mozilla: Deprecating Non-Secure HTTP

Posted May 11, 2015 10:33 UTC (Mon) by nye (guest, #51576) [Link]

Also residential connections commonly block port 25 outbound; depending on where you live you might find that the only way to get an un-blocked connection is to pay (perhaps a lot) more.

Mozilla: Deprecating Non-Secure HTTP

Posted May 13, 2015 16:14 UTC (Wed) by gerv (guest, #3376) [Link]

Your wish is my command - https://letsencrypt.org/ .

Gerv

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 17:45 UTC (Mon) by gidoca (subscriber, #62438) [Link]

For starters, they don't offer free wildcard certificates.

Captive portals

Posted May 1, 2015 15:44 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] (1 responses)

HTTPS is already ubiquitous enough that I have to deliberately load a non-HTTPS URL in my browser in order to discover and log in to captive portals.

I look forward to the proposed solution to make captive portals do something other than hijacking your HTTP connection...

Captive portals

Posted May 4, 2015 8:48 UTC (Mon) by abo (subscriber, #77288) [Link]

When connecting to a new network the network stack detects any captive portal by loading a well-known HTTP URL and verifying the result. If needed a sandboxed browser is opened and the user logs in, after which the routing tables and DNS resolvers for the rest of the system are updated to use the new connection.

Similar functionality have already been implemented in various systems (Fedora, Symbian and I believe MacOS X).

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 14:29 UTC (Sun) by jdulaney (subscriber, #83672) [Link] (5 responses)

So, I have to go and drop my (limited) cash on someone to sign an SSL so that someone can look at my plain text and pictures of trains? I'm sorry, but there are situations where HTTPS simply does not make any sort of sense at all. On top of that, I am not entirely sure I trust the various signing authorities, anyway. However, if I don't get them to sign my cert, then it is rejected by browsers.

So, unless Mozilla is willing to start signing certs, and not charge for it, then this is not cool.

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 18:07 UTC (Sun) by tetromino (subscriber, #33846) [Link] (3 responses)

Do you want to allow a malicious ISP or a hacked hotel router or a neighbor's teenage kid to inject javascript into your plain text and pictures of trains?

Mozilla: Deprecating Non-Secure HTTP

Posted May 3, 2015 19:41 UTC (Sun) by flussence (guest, #85566) [Link] (2 responses)

No, but thankfully most modern browsers offer fine-grained, usable whitelisting controls to specify which domain names are allowed to silently execute arbitrary code on my computer.

Perhaps Mozilla would like to join that list, which includes the likes of Internet Explorer 5, instead of proposing antivirus-esque reactive measures all over the map.

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 1:46 UTC (Mon) by roc (subscriber, #30627) [Link]

There's NoScript. But the number of users willing to whitelist domains for JS execution is very very small, and not worth designing the Internet for.

Mozilla: Deprecating Non-Secure HTTP

Posted May 6, 2015 21:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> No, but thankfully most modern browsers offer fine-grained, usable whitelisting controls to specify which domain names are allowed to silently execute arbitrary code on my computer.
Which unfortunately doesn't help at all against the man-in-the-middle scenario that tetromino was talking about.

Mozilla: Deprecating Non-Secure HTTP

Posted May 10, 2015 6:52 UTC (Sun) by mgedmin (guest, #34497) [Link]

> So, unless Mozilla is willing to start signing certs, and not charge for it, then this is not cool.

They are: Mozilla is one of the sponsors of letsencrypt.org.

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 14:33 UTC (Mon) by ccchips (subscriber, #3222) [Link] (1 responses)

This is ridiculous. I don't even want to go into all the reasons, either.

I have said this before, and I will say it again; behavioral problems will NEVER be solved with technology, and these kinds of measures just make things harder and harder on people with limited resources.

I have come to believe that the real problem here is that the powers-that-be don't WANT to address this problem by finding the perpetrators, and until that is addressed, all the technological measures in the world will be a waste of time.

...but if requiring "signed" certificates for everything under the Sun will make people feel better....

Mozilla: Deprecating Non-Secure HTTP

Posted May 4, 2015 14:49 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

> I have come to believe that the real problem here is that the powers-that-be don't WANT to address this problem by finding the perpetrators, and until that is addressed, all the technological measures in the world will be a waste of time.

We know the (or at least parts) of the answer to who is behind this: governments, ISPs, advertizing agencies, information brokers, and malware. Some governments can be fixed, but those wheels tend to be *slow* (without blood). ISPs own the equipment handling your data, so there's not much around that other than laws that will never get passed. The next two are just parasitic entities let in for the lure of "free", and the last is a persistent threat that will only get more prevalent as time goes on as IoT gets off the ground and common router infrastructure has more and more holes poked in it.