Mozilla Restricts All New Firefox Features To HTTPS Only (bleepingcomputer.com)
An anonymous reader shares a report: In a groundbreaking statement earlier this week, Mozilla announced that all web-based features that will ship with Firefox in the future must be served on over a secure HTTPS connection (a "secure context"). "Effective immediately, all new features that are web-exposed are to be restricted to secure contexts," said Anne van Kesteren, a Mozilla engineer and author of several open web standards. This means that if Firefox will add support for a new standard/feature starting tomorrow, if that standard/feature carries out communications between the browser and an external server, those communications must be carried out via HTTPS or the standard/feature will not work in Firefox. The decision does not affect already existing standards/features, but Mozilla hopes all Firefox features "will be considered on a case-by-case basis," and will slowly move to secure contexts (HTTPS) exclusively in the future.
Users say "Firewhatnow" ? Too bad, it was a great browser when it was introduced as Pheonix. Leave it to Mozilla to continue the Netscape tradition of going downhill.
"Not to mention all the idiots who use words like boxen."
Anonymous Coward on Monday August 04, @06:49PM
"Anne van Kesteren, a Mozilla nanny"
FTFY.
"National Security is the chief cause of national insecurity." - Celine's First Law
Everything should be encrypted at all times. I know the usual idiots will come out here and say âoeoh now you will be trackedâ, but lol if you think you werenâ(TM)t anyways and double lol if you think server side TLS makes it in any way worse as opposed to increasing your ability to mask all activities on the net
I look forward to seeing the bull market in crypto that will result from this audacious announcment! Whilst the world decries our movement, the fine open source software people at Mozilla are helping to ensure our freedoms.
From the article: "Google never announced a formal rule that all new standards/features must work via HTTPS, but its engineers have always implemented recent features to work in secure contexts only"
...and this might be the one thing that gets me off the Firefox bandwagon as it is an incredibly backwards move. TONS of stuff does NOT need https and does not need the overhead HTTPS incurs both in processing time and certificate management. Also, do I really need HTTPS for stuff on my trusted LAN? No? So now I have to jump through hoops to enable developer mode? Just... what are they thinking? What is the recommended fork of Firefox these days? Pale Moon?
No? Then we will stick with Waterfox, Pale Moon and Basilisk then. Putting things that require setting up "secure" severs (which aren't anymore due to Meltdown and Spectre) means that enterprises will cling harder to Internet Explorer.
I badly need a proxy to put in front of firefox to do the heavy lifting (yes, a MITM proxy). Otherwise FF does what it wants and not what I want.
I *hate* authoritarian people. I *hate* authoritarian software *with passion*
I'll agree that having most of the web SSL is good, but it should not be mandated. Some things just don't need it.
Lets say I make a temperature sensor that serves up a page from a microcontroller with the temperature. You are now mandating that I put an SSL engine into a microcontroller If i want to serve it in some way that makes use of a new web technology?
If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...
Come on Mozilla Foundation! Those heavy-handed tactics could work when your market share was about 50%, but not anymore...
JM2C, YMMV
*** Suerte a todos y Feliz dia!
If everything is HTTPS will that stop nosy ISPs and even nosier government agencies (or anyone else for that matter) from snooping? So far as I know, it won't.
Then we can talk.
Last month bitcoin was the new fad. These silicon valley types must have been drinking too much Raw Water(TM) picked up some brain parasites.
Very little needs to be encrypted or authenticated. Not everything that needs to be encrypted when going through the open internet needs to be encrypted or authenticated when happening on a closed LAN. Encryption isn't for free. SSL certificate management isn't for free. When stepping away from the half of web browser use that happens on the open internet and into the other half that happens on closed networks, it is wasted effort for no benefit.
"Let's Encrypt" is a US-based service, so no, this will not stop nosy governments.
Since the article at bleepingcomputer makes no sense, I went to Mozilla's site. It isn't much better. It says:
Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.
What is "observable from a web page or server?" I get that they are trying to prevent information leakage, but this statement is overbroad. I call B.S. on it.
Mozilla programmers will not waste their time checking if HTTPS is enabled before supporting a new CSS property, or a new SVG feature. That would be a moronic waste of developer time. Heck, I bet they couldn't even implement that if they wanted to. Suppose their audio library or JPEG library or SVG library adds a new format or feature? Are they going to modify the library to check if the connection is secure then selectively disable that code? That would be somewhere between impossible and moronic.
My hope is that this is just a badly worded press release.
Theres no cost any more to getting an TLS cert
Yes there is. You need a domain, for instance, and it has to be a fully qualified domain name (FQDN), not something like .local from mDNS or .internal from a private DNS server. For example, what would the FQDN of the configuration page of the router, printer, or NAS on your LAN be? Mozilla acknowledged the difficulty of securing such nameless devices on the LAN in "Deprecating Non-Secure HTTP Frequently Asked Questions":
But since May 2015, when Mozilla published this FAQ, I haven't seen it endorse a solution.
The indieweb people seem to think every householder ought to buy (and continue to renew) a personal domain from a commercial domain registrar. I guess the owner of such a personal domain could allot subdomains of that domain for devices on his own home network and use the DNS challenge of Let's Encrypt to obtain certificates for these devices. Is this practical for most people?
The only issues was Lan IP addresses and maybe an exception should be made for private IP addresses.
You propose to exempt RFC 1918 private internets from requirements related to "Secure Contexts". If Firefox were to go this route, what logic would it contain to distinguish your home network from a probably less secure coffee shop network?
I run several websites, and not a single one of them needs HTTPS for anything.
How do you assure visitors of the several websites you run that the markup, stylesheets, images, fonts, and possibly scripts on your site have not been modified in transit by an intercepting proxy between your server and the viewer's machine? Comcast, for example, has been shown to inject advertisement scripts into HTML documents delivered through cleartext HTTP.
OMG, a MITM might substitute fake data! How awful!
Thus you answer your own question. It is awful.
This means that if Firefox will add support for a new standard/feature ...
If ? I spend bunches of time with each new release trying to figure out how to disable new Firefox "features".
It must have been something you assimilated. . . .
He did mention explicitly private addresses.
It is a valid point that https on embedded devices and for unmanaged local networks is pretty awkward, with no one really stepping up to make that use case a bit more friendly (even if it can't be made secure).
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
XML is like violence. If it doesn't solve the problem, use more.
Creimer YouTube link spam.
If the Standard call for a feature to work on Both HTTP and HTTPS, and you implement only HTTPS, then is not an standards compliant implementation...
Nor does an implementation comply if the browser implements it over cleartext HTTP but the standard specifies that it shall not work over cleartext HTTP. A growing number of web standards specify such, citing things like the W3C Candidate Recommendation "Secure Contexts".
Those heavy-handed tactics could work when your market share was about 50%, but not anymore...
That'd be a good comeback if plurality browser Chrome weren't also doing it.
Can't be Chrome since it is less secure than Firefox, even pre-Quantum.
Since when did Firefox start using OS-level process sandboxing the way Chromium and Google Chrome do?
comcarp payed them so it will cost you $10 device /outlet on ipv6 and it will get an FQDN over the Comcast gateway (must rent at $12/mo) with IPV6 DHCP
Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.
Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
The "local network devices" problem is a real problem, and its never given proper attention in these HTTPS proclamations.
I "solved" it for myself by setting up a local CA to make certs for my stuff. Unfortunately, getting the cert for that CA into all my browsers is annoying, and can introduce its own share of issues.
It's of course very weird that browsers treat unvalidated https as *worse* than http, in terms of scaring the user.
Cleartext HTTP gives the user a true sense of insecurity, as the scheme portion of the URL doesn't say https. Self-signed HTTPS gives the user a false sense of security, as it increases the chance for MITM to intercept the connection, unless the user has already verified the certificate fingerprint out of band. (It shares this false sense of security with SSH servers that don't publish server key fingerprints elsewhere.) I guess Mozilla considers the sense important to users' privacy and safety.
system behind reverse proxies do not run https in all places
So I have to put severs IPMI on the internet so maybe use Let's Encrypt (with maybe auto renew) or just keep them offline and manually update certs all the time on each on
Let's Encrypt has short-lived certificates, which are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts.
What is the web server itself running on if not "a general-purpose computer"? If a special-purpose computer locked down to run only particular web server software, this particular web server software can include an ACME client. Certbot is not the only ACME client that can retrieve a certificate from Let's Encrypt or another ACME CA.
Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
No. The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.
The real problem is configuring which domain a device uses, as Let's Encrypt issues only 20 certificates per domain per week under a particular registrable domain based on Mozilla's Public Suffix List. And I'm told it takes months for a dynamic DNS host or other subdomain provider to get onto that list. But if you manufacture hardware devices or publish commercial software, as opposed to gratis software that a user can install on a generic computer, you can do what Plex did: become a reseller for some trusted CA to issue certificates for subdomains of your domain.
COMODO had reseller programs to get Certs for less than $3/yr depending on volume.
I buy my certs from GoGetSSL.com and can get very basic certs for around $6/yr.
Q. What about my home router? Or my printer?
Don't worry--they'll just do some shitty hack like requiring you to use your router as your DNS server and then intercepting requests for https://mylocalrouter.com/ and point it to 192.168.1.1. At least until DNSSEC is fully implemented and it can't inject that crap into the global DNS space. But by then *every* router and printer will be a 'cloud router' and 'cloud printer' that can only be managed online through a website for a small nominal monthly fee...so you won't have to worry about it.
The web browser caches resources delivered through HTTPS the same way as resources delivered through cleartext HTTP. The only thing you lose is being able to cache on an intermediate proxy, but that is relevant if you're splitting one dial-up connection among multiple clients.
Then there is the issue of small timers who want to serve a web page from home, using an old computer and dynamic hostname.
File a support ticket with your dynamic DNS provider to request addition to the Public Suffix List. If a dynamic DNS provider is on the Public Suffix List, Let's Encrypt issues 20 certificates per customer per week instead of 20 per provider per week. The other benefit of being on the PSL is that sites on the same dynamic DNS provider can't see each others' cookies.
My ISP supplied me with a Fritzbox for a router. They have Let's Encrypt support in their current beta firmware.
Although they still give people shitty netgear routers if they don't have gigabit plans...
If the functionality of your system depends on yet another third party, then it isn't free.
DNS registries and registrars are third parties. What makes a CA any different from DNS in this respect?
If you don't want to expose your server to the Internet, you can use Let's Encrypt with an ACME client that supports the DNS challenge instead of the HTTP challenge.
Good luck getting ISP's to support your personal domain with fixed IP's and open ports.
People need to remember that non-mainstream browser numbers are usually distorted, due to the incentives for less-popular browsers to send user-agent strings to masquerade as more popular browsers. So, you can't believe the numbers themselves. But you probably can somewhat infer relative popularity. The whole reason the numbers get polluted, is because some browsers aren't popular enough to have the clout to use their own name. So it's simultaneously real and unreal.
That said, I can't imagine why the fuck Safari would do that. I bet the above numbers are just plain wrong, or else taken from some site whose content doesn't fit with the Safari user niche. (e.g. perhaps the numbers were taken from a site that does Android SDK downloads or has Visual Basic documentation.) On my non-technical site (content doesn't have a bias toward users having any particular software) Safari measures (for whatever that's worth; see 1st paragraph) at 34%.
Theres no cost any more to getting an TLS cert
Yes there is. You need a domain, for instance, and it has to be a fully qualified domain name (FQDN), not something like .local from mDNS or .internal from a private DNS server. For example, what would the FQDN of the configuration page of the router, printer, or NAS on your LAN be?
You do not need your own top level domain (example.com). You can get a FQDN for free under other existing domains.
That said, you have a point, since that would significantly lower the level of trust (if you own the domain, the registrar could steal it out from under you, so you have to have some trust in them; if you get a subdomain off a third party, they can easily steal your subdomain, so you would have to trust them not to do so).
That risk is probably why the market for free FQDN's isn't very big. Most people that need one would rather just buy one for the few bucks a year it costs.
I'm okay with a warning mechanism, such as yellow bar, or a pop-up confirmation that has a "do not show this message for this site any more" option. But to outright not allow, or repetitious prompts is too much. The little guy can't afford a fricken certificate.
Table-ized A.I.
The manufacturer of "every cable modem, WAP, router, printer, switch, AP, IoT device, etc" will include an ACME client (or some other means of renewing a certificate) in the software package that runs the web server in said device.
Does letsencrypt.org issue certificates for private IP addresses now? Most such devices limit their configuration interface to the internal facing interfaces.
Mil, security services have the keys so nothing stops them from collect it all over any generation of tech.
Police who get ISP logs will be the interesting change.
ISP will have to get some new skills if they want to keep looking over a users communications.
Ad will have to change and become part of a site in some way.
Domestic spying is now "Benign Information Gathering"
Ultimately it's a flawed system that is more about making money for the handful of Certificate authorities than about providing security to your average home user. Forcing everyone to HTTPS doesn't do much more than highlight CAs as the chokepoint of the Internet.
“Common sense is not so common.” — Voltaire
You can get a FQDN for free under other existing domains.
But then you're more likely to run into CA-imposed rate limits because many subdomain providers aren't on the Public Suffix List yet.
Hosts on a personal domain need not accept connections from the public. If the domain needs a public presence, it can be hosted on some cheap static site host.
Let's Encrypt will issue a certificate to the domain owner even if the hostname in the certificate is not the hostname of a server reachable through the Internet. For unreachable hosts, Let's Encrypt verifies domain control through the ACME dns-01 challenge, which requires putting a temporary TXT record in your domain's DNS zone.
For a long time now, I've been thinking: how do corporations like Microsoft, Google, Apple, et al, compete with the burgeoning open source movement? The only answer I can come up with is the old MSFT "embrace and extinguish". These guys with all their money can easily buy out and pay for people to infiltrate and then royally screw over what were once great open source programs. How else can anyone explain wtf Mozilla has been doing for the last few years? (Serious question, btw. I would appreciate your answers so I can unweld this tinfoil hat.) It should be easy to spot Open Source Saboteurs. Mozilla's executive board are clearly bought and paid for in my view, as is Lennart Poettering. More care needs to be take to expose other Open Source Saboteurs.
Been bothering me for a while now. Why are the massive corporations so desperate to get us ALL on https? So desperate they're giving it away for free? Sure, secure comms are an instrinsically good idea in theory. But a lot of the Internet doesn't actually need it. Unless, of course, you want to close the Internet so that individuals and small entities can no longer play in future...
For a corallary, look at the old movie industry in the early 20th century. Anything went! But then the money moved in and took over...
...uses Intel, or AMD, or Power, or ARM, or SPARC processors?
Seriously, an el-cheapo Chinese smartphone has enough processor power to run SSL. A Raspberry Pi has enough CPU. An Xbox or PS/3 controller has enough CPU!
What are you using, a Lego CPU? Oh, wait, that still has enough horsepower to run SSL!
On my non-technical site (content doesn't have a bias toward users having any particular software) Safari measures (for whatever that's worth; see 1st paragraph) at 34%.
Safari is currently Mac-only among desktop platforms. I'd be surprised if over 34 percent of visitors to your site use a Mac. Or are you counting Safari for iOS in your 34 percent? Rick Schumann doesn't appear to be.
And Mozilla refused to fix HTTPS MITM.
even "free" things like Let's Encrypt are not free. They will not give me a cert. What they will do is let me run their software which will magically do the cert shit for me.
Or you could read the published specification for Automatic Certificate Management Environment (ACME) and write your own such software.
It also protects against spoofing servers, MITM (Man in the Middle) attacks, altering / faking / changing content in-transit (as AT&T / Verizon has done in the past).
Probably they think this is more about protecting their users than just ensuring the data can't be seen by prying EYE5.
See subject: I like Waterfox (& CyberFox + PaleMoon too) so I look forward to a new FF 57++ engine stripped of tracking/advertising (or other unwanted in/out bound communique in 'modern browsers' (advertising & tracking engines)).
* Again, thanks!
APK
P.S.=> All the 3rd party modders of FF (especially for 64-bit do a really good job of it & I use them (w/ classic Opera + Vivaldi too))... apk
It makes snooping much more expensive and it makes passive undetectable snooping impossible. To snoop, they have to install software on the user's computer, or the target server, or else get a CA to generate a certificate they can use to MITM the connection. All of these things are expensive to do at scale, and detectable. In the latter case, the bad certificate can be recorded and constitutes proof of the CA's misbehavior; if a rogue CA is found to have misissued a certificate, there are consequences, as Symantec and Startcom found out.
And this helps home routers how?
From my cold, dead hands.
Using an Intel CPU for encryption probably now incurs significant overhead.
Sorry, what DNS zone is being used in a general private network???
Nope, SSL ciphers fall all the time, fresh vulnerabilities, fresh attacks. Can't assume passive snooping is impossible.
A split-horizon public dummy mirror with the same hostnames as the private network.
The home router firmware would presumably use the ACME dns-01 or http-01 challenge to obtain a certificate from Let's Encrypt for the hostname (not the IP address) that the user has entered into its configuration. Even if the hostname has no public CNAME, A, or AAAA record, the DNS zone can still contain the TXT record that dns-01 requires.
> ...[short-lived TLS certs] are kinda useless and annoying when you have a device that is *not* a general-purpose computer capable of running their scripts. ... Am I really going to do a manual process on every cable modem, WAP, router, printer, switch, AP, IoT device, etc, every 3 months?
So use some software that implements ACME that happens to meet your needs? ACME's DNS Identifier Validation Challenge method seems to be tailor-made for just your situation: https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.5
Run your ACME client on a full-featured computer, save the certs that LE sends to you, then feed them to the automation scripts for whatever method you use to get TLS certs onto your modem/WAP/printer/whatever. (You _do_ know that there are tools out there that can manually enter SSH passwords for you, or even script clicking on or typing into a web page, right?)
some ipmi still use java only others the html5 part is missing a few things that the java one can do.
Most people don't realize that they're being ripped off so badly.
None of their platforms are actually the most popular in terms of market and have less than most companies have in market share. They just get a lot of money from them. 3% isn't unexpected considering how gimp their browsers are (why focus on it? You can Rob then going inside the store)
the percentage of less popular browser users that actually change their user agent would not even amount to a rounding error. at 34% whether you think so or not your site is either a statistical anomaly or you do have a significant bias towards Apple users as even with mobile devices you are unlikely to climb much beyond 20% without some sort of bias as apple marketshare is just too small overall to account for a 3rd of users.
You're describing a non-issue while ignoring the real issue.
Let's Encrypt works by scripting. If you're doing it manually you're doing it wrong. The problem should be scripted around. However .... the real issue is that you can't issue a certificate to an IP address or to local domains. The problem isn't Lets Encrypt, the problem is there's literally no one who would give you the certificate you need.
What is needed is either some protocol change to allow this to be done in a different way, or some simple and and universal easy method to run your own CA for these purposes along with the ability to upload the cert. Or maybe devices should come with a universal certificate that never expires and on first access needs to be manually imported. Think of it like SSH.
-1 Incoherent.
What on Earth are you trying to say, AC?
No, they issue certificates for domains, not IP addresses. If you want to get certificates for home network devices, then the simplest thing to do is set up a subdomain like home.example.com and point a public wildcard DNS record at a machine running acme-client. Configure all of the subdomains of that you want (e.g. printer.home.example.com) and have the deploy script push them to the things on your local network. On your local network, provide a DNS server via the DHCP reply which gives local addresses for printer.home.example.com, rather than the publicly routable one.
I am TheRaven on Soylent News
You really want to integrate this with the DHCP response (though that's also not authenticated in any way). The problem with .local is that names in that namespace are not guaranteed to be unique. mycomputer.local probably exists on hundreds of LANs and the point of a DNS cert is to prove that your endpoint is who it says it is.
A good first step would be for the DHCP response to include a root cert that can be used only for things on the current network. Ideally, you probably also want something integrated with mDNS so that devices that publish their names via mDNS can also publish their cert via the same mechanism and have other parties automatically reject names if the signing cert changes. Neither of these mechanisms is very secure, but they both probably better than nothing - at least they give you reasonable protection against passive eavesdroppers.
I am TheRaven on Soylent News
I'm sure my 82 year old father in-law will have no problem registering his own domain name, configuring public and private DNS servers and setting up his acme-dns client. Thanks for making life easier for him.
Anonymous Coward is trying to say that despite Apple's user base not being the largest, it has been successful at making a large profit from a smaller, richer user base. In some years, it has earned over 90 percent of all smartphone profit. Thus despite a smaller number of people using Safari, these users on the whole make more purchases in larger amounts.
Nice straw man. Why is your 82-year-old father-in-law doing configuring web servers on his local network if he finds these things so difficult? Oh, right, he isn't, he's buying off-the-shelf equipment that handles this stuff automatically for him.
I am TheRaven on Soylent News
It is not just bias towards technical content. you probably either target the hippy crowd or the young/deluded crowd, rich youth, i.e. people with more money then brains where the apple percentage could actually reach 34%. 34% is insanely high number for safari and doesn't make any sense unless your numbers are wrong or you are targeting Apple users in some way.
The straw man here is your imaginary world in which "off-the-shelf equipment handles this stuff automatically for him"
Have you actually bought any consumer network equipment in the past decade? Most of the things I've bought handle https already. Even a cheap (under £10) TP-Link WiFi router does (via a fairly complex dance involving public DNS records). My ISP-provided router does with a self-signed cert that I have to explicitly mark as trusted (but which is then pinned). The manual config is only an issue if you're manually configuring your own intranet server, and if you're doing that then you should know what you're doing.
I am TheRaven on Soylent News
Good work. What difference a username makes.