Slashdot Mirror
Firefox Prepares To Mark All HTTP Sites 'Not Secure' After HTTPS Adoption Rises (bleepingcomputer.com)
An anonymous reader quotes a report from Bleeping Computer: The increased adoption of HTTPS among website operators will soon lead to browsers marking HTTP pages as "Not Secure" by default, and Mozilla is taking the first steps. The current Firefox Nightly Edition (version 59) includes a secret configuration option that when activated will show a visible visual indicator that the current page is not secure. In its current form, this visual indicator is a red line striking through a classic lock that's normally used to signal the presence of encrypted HTTPS pages. According to Let's Encrypt, 67% of web pages loaded by Firefox in November 2017 used HTTPS, compared to only 45% at the end of last year.
Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature. If it's valid, the file is usable. Encrypting the entire download is a waste of resources for both the server and client. Not everything needs to be encrypted, so this is a little silly. Plus, hosting providers often charge extra fees for https, at least based on my experience.
This is completely retarded. Not every site needs https.
HTTPS requires a certificate, and a certificate that requires a fully qualified domain name. The CA/Browser Forum's Baseline Requirements forbid issuing certificates in RFC 1918 private networks (such as 10/8 and 192.168/16) or the mDNS reserved domain (.local). This means everything on the average user's local area network will end up marked "Not Secure", such as the administration interface of the user's router, printer, or network attached storage (NAS) device.
The document "Deprecating Non-Secure HTTP" states that Mozilla is aware of this problem but fails to offer a solution:
Great. How your site won't be browsable at all by default in Firefox until you pony up cash to a certification company.
I guess we know who paid for all those Quantum puff pieces now.
Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature.
How can you be sure that the SHA-256 value against which you are verifying the disk image hasn't itself been tampered with on its way to your device?
Encrypting the entire download is a waste of resources for both the server and client.
No it isn't. If you fail to encrypt, your ISP, your ISP's ISP, and any snooping government can tell conclusively what you have downloaded. If you do encrypt, the eavesdropper can see only what domain you're accessing and the sizes of what you download. You can obfuscate even the sizes by using range requests to pull the 4 GB disk image a 4 MB chunk at a time.
Plus, hosting providers often charge extra fees for https
Then take your business elsewhere. Switch from a hosting provider that charges extra for HTTPS to a competing hosting provider that does not charge extra for HTTPS.
I guess it depends; but when your rival has about 5 times your market share, you do not matter that much...or do you?
Outstanding. Now how will I disable this problem?
I read at +2. If your post doesn't reach that level I will not see or respond to it.
The only "certification company" to which you'd need to "pony up cash" is the domain registrar, which you need anyway for a public website. Once you have a domain, you can automate provisioning of certificates issued without charge by Let's Encrypt using an ACME client such as Certbot.
http (IP on private network) = secure
How so? When your laptop or phone is on restaurant or public library Wi-Fi, you don't know who has 192.168.123.45. This is why the definition of a "potentially trustworthy origin" in the W3C candidate recommendation "Secure Contexts" includes localhost but not RFC 1918 private IP addresses.
Thanks for pouring napalm on the fire.
Let's say I'm downloading a file that's several GB, like a disk image. When I download it, I'll verify the signature. If it's valid, the file is usable. Encrypting the entire download is a waste of resources for both the server and client.
As long as the signature file was delivered over HTTPS and you didn't have any evil root certificate authorities installed on your client, you would be fine. If the insecure download was tampered with, signature verification would fail, as you say.
Encrypting downloads is not that big of a deal resource-wise these days, though. Why not let HTTPS handle MITM detection for you? ;) Most users won't check a sig file anyway.
I mentioned the same planned obsolescence concern in my question to Jacob at Let's Encrypt in an AMA on reddit a year ago.
How is "make and install your own certificates" practical when users bring their own devices, such as public library patrons bringing their laptops or phones to a branch or friends or relatives bringing their laptops or phones to someone's home?
"...when activated will show a visible visual indicator..."
In my 35 years in the computer industry, I have always found that visual indicators that were visible were much more effective than ones that weren't. But then, I'm kind of old-school...
The percentage covers only the subset of users who have opted into Firefox telemetry. If you want to make your votes not count, that choice is yours. Just don't whine when Mozilla cuts your pet feature for lack of usage share justifying the maintenance cost.
You know what cost isn't zero?
Changing the billions of http: links on billions of web pages to billions of other web pages, that's what.
Firefox - and Google, for that matter - are damaging the very integrity of the net, ironically, while claiming to improve it. They're not improving it. This is anal-retentive nonsense. Not everything needs to be encrypted. If something does need to be encrypted, that falls into the realm of the reasonable decision of the page owner, not the web browser author or the search engine.
We've gotten along just fine without this nonsense thus far; I see no reason - other than the use of force by these bad actors - that we should have to arbitrarily change huge portions of the Internet.
You want to encrypt, go ahead. You can if you want. And of course, if you do, it'll be fine. But using force to make you do it... no. That's just evil.
And we know that browser warnings will put people off. This isn't an "otherwise-harmless" act. It'll do real damage.
I've fallen off your lawn, and I can't get up.
ftp;//
telnet://
smb://
I got a nice Let's Encrypt certificate than auto-renewed, and I've pushed any external HTTP requests to HTTPS on my router.
And I have a pretty big list of CIDR ranges and URL strings that result in blocked transactions.
It's why a CA can charge hundreds of dollars to perform 50ms of compute effort.
The "50 ms of compute effort" certificates are domain-validated, with just CRL and OCSP as ancillary services. Those typically cost $15 for three years (ssls.com) or nothing for 90 days (letsencrypt.org). The certificates that cost hundreds of dollars are Extended Validation, which ensure not only a connection between the certificate and the domain owner but also that a vandal isn't typosquatting the domain itself. These often come with greater insurance guarantees.
I can't answer that question, but this..
.. is easy. You don't want ISPs altering the flier. And people may recall, one of the big calls to arms for the whole Network Neutrality thing everyone has been talking about, is that ISPs were altering web replies to insert ads. I've heard Comcast users even say that Comcast still communicates some kinds of things to their customers by just barging into whatever web page a user happens to have loaded, and changing it to include a message from Comcast. (Because apparently email is too hard.)
MitM can't only snoop; they can also change things.
Examples involving intranets, though, I can't possibly get into Firefox's head. I am pretty sure whatever reason they come up with, will be bullshit. But I guess I ought to hear 'em, first...
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Forge a cert for yourself, it's not hard.
It's a bit harder to get the devices of friends and relatives visiting your home to trust the certificate of your private CA so that they can (say) view the videos on your NAS or print to your printer. In addition, Android displays a persistent warning about "Network monitoring" if a private CA certificate is installed.
Univ. of Michigan, Firefox, and Cisco researchers founded the Let's Encrypt project.
And even doing this, there is still no additional benefit for the servers themselves. Secure the transmission all you like, but if you mess up your server security, then bad-guy (even state actors) don't need to worry about breaking ssl, they can just get all the stuff on the server itself.
Changing the billions of http: links on billions of web pages to billions of other web pages, that's what.
If your HTTPS server sends the Strict-Transport-Security header for one request, the browser will automatically rewrite subsequent requests to http: scheme URLs on the same domain to use the https: scheme instead. If you enable this long-term for all subdomains, you can get the header "preloaded", or included with the browser itself so that even the first request gets rewritten. The HTTPS Everywhere extension by EFF is an additional source of preloads.
>"a red line striking through a classic lock that's normally used to signal the presence of encrypted HTTPS pages"
Really, that sounds OK to me. it is a reasonable warning "for the masses." But ONLY if it stops there. No pop-ups, no dialogs, no animation, no nagging, no striking through the URL, etc.
Not everything needs to be https, and things that aren't are not necessarily any problem. Mozilla can have bonus points by keeping the about:config that allows the user to en/disable the insecure http icon feature.
all sites will start using the fake CA let's encrypt that issues certs to anyone for anything
By the same criteria under which Let's Encrypt is a "fake CA", the vast majority of domain registrars are "fake registrars". They'll issue domains such as bankofarnerica.com to typosquatters and phishers and then not do anything until someone brings action pursuant to UDRP.
Every Wifi captive portal now wont work as the redirect will fail, coffee shops, guest wifi, all broken, great.
I don't know the details by default Firefox transmits some kind of captive portal probe to determine this. You can see it go over the network if you run a capture when starting Firefox.
Theoretically, guest Wi-Fi should be presenting the terms in a RADIUS access challenge instead of HTTP interception anyway.
I run software that distributes non-sensitive data across wide area networks... many people at each site want the same data, so I stick a web caching proxy on the site, and the big data (many gigs worth) are all transferred once, and then served from the local caching proxy. encrypting means the caching proxy needs to man-in-the middle, or it's just borked. stupid.
The nice why? To save the world from the security services and their contractors changing unencrypted network connections globally.
Collect it all was easy without encryption.
Now encryption is a set standard global collection by the security services will not be so easy?
A more realistic thought would be to save ads. Ads now know they have a direct link into a browsers from a site. The browser trusts the site and now has to trust the sites ads.
Encryption keeps 3rd party ads out and paying site ads displayed.
Domestic spying is now "Benign Information Gathering"
Oh good, now I can pay like $100 a year for an encryption cert that I don't need just to run my static, read-only website that tells people what my business does and where it is and how to contact me. Awesome.
The geniuses at Mozilla decided to hide the http: prefix from the user some time ago, so instead of http://www.cnn.com/ the user sees www.cnn.com
The http: prefix indicates that THERE IS NO ENCRYPTION.
Why hide it from the user and then add a non-standard indicator that there is no encryption?
So many UI designers should be shot...
Firefox has become overrun by nannies lately, and is now purposely breaking itself. I've dumped it for Chrome. Not that I'm wild about Chrome, but at least it hasn't become a malfunctioning mess. Say hi to Netscape for us when you reach your destination, Mozilla.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
I am generally curious why someone would need EVERY site to be secured by https.
Because without https, you have no assurance that the data that arrived at your web browser was the data sent by the server you wanted to reach. https is usually thought of as a data secrecy mechanism, but it's also a data integrity mechanism, and while secrecy doesn't matter everywhere, integrity does.
Note that this is true even when you don't particularly care about whether the cat video you got was the cat video you wanted, because your browser and your computer are not secure. For the same reason you don't point your browser at the dodgy corners of the Internet -- because you may just get pwned -- going to trustworthy non-https sites can screw you if there happens to be anyone malicious on the route between your computer and their server.
Moreover, if we make a habit of encrypting All The Things, we don't have to worry about snoopers seeing something that we accidentally failed to protect. Its just good network hygiene.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
It does concern me about some of the smaller sites struggling to survive. If a hypothetical site is barely able to pay the server bills, the last thing they need is an additional $15 charge per year (or more) tacked on just to allow a percentage of users to access their site without having users complain about alarms blaring that it's an unsecured site. I mean, sure, $15 a year doesn't sound like much, but if you're not a major site pulling in hundreds off of ad impressions or subscription fees, that seemingly small fee is going to sting on the bottom line. No matter how you slice it, this is going to raise the barrier for entry for new sites.
This added to what is going on with the destruction of network neutrality in the US is almost like pouring salt on the wound. The number of users being able to reasonably access your site may very well drop, but Mozilla decided that web admins need to add another layer of security that come with fees in the process.
Daily read for tech news: Freezenet.ca
Haha... you think they actually give a hoot about that telemetry data? Management makes their decisions and then interprets the telemetry to justify their posisions, no the other way around.
Remember, Microsoft collected huge amounts of telemetry with Windows7. The result was Windows 8.
Whether your site needs to be secure or not is not for you to decide. It's up to the person potentially being persecuted for viewing it.
You'd think copyright law would be more than enough to stop that kind of behaviour though. Comcast is altering an original work without permission, for financial benefit, and as part of an organisation. Seems an easy court case...
A browser can be configured to trust a particular CA only if the CA submits all certificates it issues to a Certificate Transparency log. I seem to remember at least Symantec being put in this penalty box.
But by then it's too late. Preventing this sort of abuse is better than relying on a court case.
I'd say triple damages plus a racketeering conviction, followed by jail time for the CEO and a breakup of the company, should be enough to convince the next runner up that doing this is a fundamentally bad idea. But of course I could be wrong.
run a dynamic dns name
Many domains used by dynamic DNS providers are still not on the Public Suffix List. If a domain is not on the Public Suffix List, Let's Encrypt won't issue more than 20 certificates in a 7-day period for subdomains of that domain. (Source: Let's Encrypt rate limits; Ratelimit for dyndns domain) Instead, the service will produce an error message to the effect:
This means 20 other customers of the same dynamic DNS provider are likely to have already obtained their certificates before you have a chance to.