Well, that means I can remove HTTPS Everywhere now. It's surprising how many sites are still holding out on HTTPS – there really is no excuse these days.
HTTPS-only mode arrives in Firefox 83 as Mozilla finds new home for Rust-y Servo engine
Mozilla has released Firefox 83, including up to 15 per cent faster JavaScript and an optional HTTPS-only mode. The company has also found a new home for its Rust-based Servo project, which has been adopted by the Linux Foundation. The adoption by Mozilla of a four-week release schedule for Firefox means that some builds are …
COMMENTS
-
-
Wednesday 18th November 2020 17:24 GMT Elledan
I do not have a certificate for my personal website. Do I need one? It doesn't have any online shopping or exchanging of sensitive information. What motivation do I have to set up an SSL certificate and maintain it?
To me it just seems like an unnecessary bother, but maybe someone can convince me otherwise.
-
Wednesday 18th November 2020 18:38 GMT Anonymous Coward
The motivation is to protect yourself from a man-in-the-middle attack where any trespasser onto your wifi can feed malicious javascript into your personal website (and all others for that matter) which then rootkits your entire computer. Obviously that's a worst case scenario but you get the idea. I mean, remember Phorm?
Eventually web servers should be generating certificates automatically and you'll have nothing to maintain.
-
-
Friday 20th November 2020 13:38 GMT Anonymous Coward
Not against state actor who can get a 100% valid certificate generated for any domain. Always remember that there are thousands of certificate authorities and all of them can issue a valid certificate for any domain. This was a design requirement. MITM is a trivial if you can print your own certificates.
-
Friday 20th November 2020 17:53 GMT Anonymous Coward
Which is why I painstakingly disable nearly all prebundled CA certs in Firefox. Only about half a dozen commonly used authorities (amongst the sites that I visit) are all that's needed. The odd site that pops up a warning, once every few months, can be handled by either clicking through to it after checking (but not trusting) the certificate, or closing the tab.
They should really make it easy to choose which certs you want to trust.
-
-
-
Thursday 19th November 2020 18:21 GMT Morten Bjoernsvik
but a pain to manage
I need to open port80 from the firewall to my server, then add a http/80 on my proxy so certbot can update the cert every third month.
Lots of acme services out there that let you install a vpn to fix this but they all cost money. I have an ssl terminator in my proxy, so I just link any service through it and I do not have to bother with certs in my apps until the next 3 months.
-
-
Friday 20th November 2020 03:26 GMT Anthropornis
I have public website at a hoster, with nothing that needs security - some plain text, some images, some PDFs of text (and if you are worried about PDFs you can download them and open them in your own secure viewer). That site is rarely updated, AFAICS adding and maintaining a certificate is not worth the aggravation.
I also have a local website on my home server, only accessible from my local network, with the above, copies of photos from mailing lists, and copies of the html output from projects I work on (so that if I update something on whichever desktop I'm using, I can check how it renders). A MITM attack is the least of my worries if someone gets onto my home server. So again, AFAICS https just adds more things to go wrong.
-
-
-
Wednesday 18th November 2020 19:22 GMT Anonymous Coward
Re: there really is no excuse these days
It's more like your website was set up with Adobe Flash and it works fine for you.
If you don't care if others find your website broken for them because browsers no longer support Flash, then you don't have to change.
However, I would not be surprised if Chrome eventually adopted something like HTTPS Everywhere so changing now would be proactive if you care about other users of your website.
-
-
-
Friday 20th November 2020 04:07 GMT swm
Re: Excuse!
I run a website on bluehost and about a year ago I discovered I could use http or https on my pages and subdomains. I also discovered some pages on my website I didn't put there but appeared to be challenge/response pages to get the certificates. I do have a "plus" account though.
Getting a free certificate apparently just requires having the ability to put up a web page to show you own/control the website.
-
-
Thursday 19th November 2020 13:47 GMT a_yank_lurker
I run a couple of information only websites that does not even set cookies. No logins, no data collected, no transactions. So a certificate seems silly. But if there must be a standard I guess https is better than http as a default because so many sites do have logins, etc. were they need to store user data.
-
Thursday 19th November 2020 16:20 GMT doublelayer
The risk of injection attacks on your users has already been detailed above, so I'll give another reason why you might still care, namely your users' privacy. With a certificate, you can help your users keep information away from any ISP or attacker capable of listening to their traffic including things like which pages they visit or form input. You said that they don't log in, but that doesn't mean they don't view the content they get from you as ideally private. It's a courtesy to them to give them the option to fetch these things in an encrypted form. This doesn't mean you have to do it, but it's nicer if you do.
-
Friday 20th November 2020 08:33 GMT Mage
, you can help your users keep information away from any ISP
Most ISPs are not the problem on privacy. Mostly the problem is websites that probably HAVE HTTPS and have an offensive amount of tracking using every known technique.
HTTPS is needed if a user is logging in, i.e. doing other than simply anonymously viewing except most commercial websites are determined to help Google, Facebook etc know everything and they already run HTTPS
-
Friday 20th November 2020 20:09 GMT doublelayer
Re: , you can help your users keep information away from any ISP
That is a separate issue. An important issue, but nonetheless a different one. Tracking content placed on the page by the page creator is a privacy issue between the requester of the data and its provider, whereas HTTPS solves a privacy issue between the data requester and a third party which can access network traffic. What you're doing here is dismissing a real privacy issue and its solution because you can name another one. This classic argument (XKCD) doesn't really make any good argument why the HTTPS privacy feature either doesn't work or doesn't matter.
-
-
-
-
Friday 20th November 2020 08:26 GMT Mage
Arrogant copy of Google
" but version 83 packs in more than most. Introduced this time round is HTTPS-only mode, off by default. If enabled, navigating to an HTTP site automatically redirects to HTTPS, and if no secure connection is available, a warning comes up with an option to continue."
This is the responsibly of a website operator.
Also if you are not logging in, just viewing, how important is the extra security given all tracking via third party analytics, clear pixels, cookies, javascript and everything else? That is the real problem and only has a limited solution via plugins.
At least HTTPS-only is off by default. I've tested some browsers where it's on by default and one where you can't turn it off.
-
-
Wednesday 18th November 2020 15:10 GMT Ben Tasker
> If a site never asks for a login or passwords, does it need to be encrypted? Arguably not, though there is still a risk from spoofing.
I don't think there's any valid argument against encryption.
It's not just about protecting credentials, it's about ensuring that what the client receives is what they were supposed to receive, and not in fact something that their ISP, or someone else on the network path has injected (cough.... ads).
It's also about ensuring a modicum of privacy. If you visit Reddit and follow a link out to a plain HTTP only site, then network observers can see you browse /r/goatporn (Reddit, of course could prevent this by returning a Referrer-Policy header, but they don't because.... there isn't really a good reason). Watch those long enough and we can start to build what might be an interesting profile of you.
It also helps guard against leaky services like LinkedIn. Side note, that post was 5 years ago now, and half the capabilities discussed are still possible because various sites don't use HTTPS.
I have, in the past, flagged up use-cases on mailing lists where using HTTPS might not be as "duh it's easy" as some assume, but the average website doesn't encounter those, being much more of an issue for people delivering certain content types at scale.
-
Wednesday 18th November 2020 16:48 GMT Mike 137
"it's about ensuring that what the client receives is what they were supposed to receive"
Not realistically, in this age of cut price self-signed certificates that actually certify Bu**er all.
I actually believe that decisions like this should be left to the user. Having some external self-appointed nanny decide on our behalf what content we can see in our browsers seems a bit too much like loss of independence (yet again being Gooooooglefied).
Add to that a "four week update cycle" and the user has effectively handed away any control they might once have had.
-
Wednesday 18th November 2020 18:52 GMT Demmers
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
As a user, how much control do you have regarding how the internet works in the first place? If https was a standard to begin with, would you still be complaining about it? I don't see the difference between this and car manufacturers having to make cars heavier due to extra safety features. The driver lost nimbleness, in return for better safety. I'll take that.
-
Wednesday 18th November 2020 20:04 GMT batfastad
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
> decisions like this should be left to the user
This is literally an option the user can choose to enable. Eventually it will likely be default because most people will be fine with it and when that happens the user can disable it.
> four week update cycle
I think for most users (and web developers/engineers) frequent updates to browsers are a good thing. If that's not acceptable then there's an LTS version of Firefox available.
-
Thursday 19th November 2020 11:33 GMT Ben Tasker
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
> Not realistically, in this age of cut price self-signed certificates that actually certify Bu**er all.
I think you may have misunderstood what a SSL cert is supposed to verify. Also, if they're actually self-signed, they're not going to be trusted by the end-user's device.
It *doesn't* tell you that you've definitely reached ACME Corp. It *doesn't* tell you that MyDodgyCorp is legit and can be trusted to handle your card details.
What it signifies is that you've reached a server authorised to serve content for foo.example.com, and that that authorisation has been signed off on by an org that has (in theory at least) significant audit requirements put upon it.
That CAs sometimes screw up and do stupid things really isn't a justifiable reason to go HTTP only.
> I actually believe that decisions like this should be left to the user.
It's quite clear that this isn't something that users can take on board, nor is it something that the vast majority would want to take on either, it's simply not realistic to think that that would ever work.
And you know what? You *do* have the ability to do that - you can delete CAs from your browser, just as you can add them. You've got the level of control you suggest, it's just that exercising that level of control is a royal pain in the arse.
> Add to that a "four week update cycle" and the user has effectively handed away any control they might once have had.
Again, you have control over this - although if you don't update you may find that you wind up vulnerable to known exploits, or that sites stop working because they're using something new that your browser is now too old to handle.
-
Thursday 19th November 2020 18:29 GMT heyrick
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
"and that that authorisation has been signed off on by an org that has (in theory at least) significant audit requirements put upon it."
While that might be the case for online shopping and banks, my site has a Let's Encrypt certificate which proves, well, that somebody issued a cert for that domain name, but it doesn't guarantee much of anything.
-
Friday 20th November 2020 16:54 GMT Ben Tasker
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
I think you've misunderstood which way those audit requirements go - I don't mean that the CA has done intensive investigations before issuing the cert - I mean that they are audited to ensure they're not improperly issuing certs.
Your site having LE tells my browser that the server I've connected to is (or at least was) authorised to speak on behalf of heyrick.invalid. In order to get the cert, you have to show proof of control, whether via HTTP(S) or DNS challenge, it's not simply "give me a cert" and they go "here you go".
It's not perfect, someone could perhaps have poisoned DNS or BGP in order to have LetsEncrypt (other ACME providers exist) go to their server instead of yours, but that's still a much, much smaller surface of attack than "screw CAs, let the user figure it out for themselves".
It doesn't tell me that heyrick.invalid is definitely your site/operated by you, but that's not the point of a SSL cert (despite EV sellers perhaps trying to convince you otherwise). It's purpose is to authenticate that the connection has terminated where it should, rather than somewhere unauthorised in the middle.
-
-
-
Thursday 19th November 2020 13:20 GMT Anonymous Coward
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
Having some external self-appointed nanny decide on our behalf what content we can see in our browsers seems a bit too much like loss of independence (yet again being Gooooooglefied).
Or, in a few months, "Harris-ed".
-
Thursday 19th November 2020 16:33 GMT doublelayer
Re: "it's about ensuring that what the client receives is what they were supposed to receive"
Basically none of the things you said have any accuracy.
"in this age of cut price self-signed certificates that actually certify Bu**er all."
There's so much wrong in that sentence fragment. I'm going to have to take that apart.
"in this age of cut price": So if the certs are cheap this is a problem? When they were expensive, this wasn't a problem?
"self-signed certificates": Self-signed certs aren't trusted. Let's Encrypt certs are not self-signed. Let's Encrypt certs require verification of domain control, external signing by someone else, and can easily be revoked.
"that actually certify Bu**er all.": They certify that the server which has the private key is able to serve content from the domain at the time of initialization. Some certs additionally audit who has them and that that's the person who owns the domain concerned. This means that a hijacked DNS request can't impersonate my server because the certificate won't match or won't be signed by a trustworthy CA.
"I actually believe that decisions like this should be left to the user.": What part of "turn it on if you want it" is not getting through? Don't worry, even when this becomes on by default, you can still turn it off. We know this for three reasons. First, HTTP is inside of HTTPS, so nobody can remove that part of the code. Second, people will need plain HTTP for things like network administration, so the setting will necessarily be present. Third, Firefox is open source, so anyone who knows how to edit code can hack out this feature and anyone who can download a file can get a new build from that person.
"Having some external self-appointed nanny decide on our behalf what content we can see in our browsers seems a bit too much like loss of independence": I'd agree if certs did that. They don't do that. Few certification authorities will enforce a content restriction on their users. A few will only give you a cert if you appear to be a legitimate, verifiable organization or person, but several including the free Let's Encrypt will give you one for basically anything so long as you can demonstrate control. Nobody at their automated system is running editorial review on your site.
"Add to that a "four week update cycle" and the user has effectively handed away any control they might once have had.": Options, updates, automatically install updates, switch to off. You may have security vulnerabilities now. When new features are ready, they release them. The major possible downside is insufficient testing, but that's it. If you don't want the update, don't install it.
-
-
Thursday 19th November 2020 18:37 GMT heyrick
"something that their ISP, or someone else on the network path has injected"
How much of a problem is this in reality? I am not aware of my ISP ever messing with what I receive, and if they tried pushing adverts (given how much I pay for their service), I'd break my contact with some extremely colourful language and a report to CNIL (I live in France).
"Watch those long enough and we can start to build what might be an interesting profile of you."
Something of a non-issue given that it only counts for the one site. A much bigger privacy issue is stuff like the Facebook "Like" thumb icon and links to Google analytics and such that appear on numerous websites and can track you all over the place to build a much more detailed profile. Of course, all of this junk is served up via https so unless your browser is set to block all that rubbish, you'll still be tracked to kingdom come and back again.
-
Thursday 19th November 2020 21:36 GMT doublelayer
It well can be. There are a few historical examples of large ISPs doing it, the most memorable of which is the "great cannon" DDOS tool operated by the Chinese government which allows them to use Chinese residents' network traffic as a targeted cohesive force to knock objectionable sites offline. It did this in a couple of ways, but one easy one is to add references to the victim in any HTTP traffic which the user's browser will access.
It also happens at a much smaller level. Public networks can be set up by malicious people or replaced by an impersonator doing the same thing. Someone who does this could inject scripts into HTTP traffic and get your computer to execute them. There are risks that remain if your connections are through HTTPS, but they both are harder for the attacker to implement and easier for you to detect.
Another issue is that an ISP can record traffic going over unencrypted HTTP, even if they don't modify it. That traffic is usually used for advertising purposes, but could be used for anything nefarious you can imagine. Since you live in the EU, this would be a clear GDPR violation. As we know, data protection authorities find those out immediately and instantly impose major penalties, so there's never a need to worry at all. Other countries which don't have GDPR don't usually even offer any redress if an ISP should do this, and some countries even allow that data to be made available for sale. HTTPS is a very useful guard against things like this.
-
Friday 20th November 2020 17:05 GMT Ben Tasker
> How much of a problem is this in reality?
Bigger than you realise, clearly.
I can't give you any specific examples for France, but in the US (which lets face it, is a market with a massive amount of influence on tech) various ISPs have been caught doing things like:
- Verizon injected a subscriber specific advertising ID into HTTP requests, allowing their advertising partners to track you across sites (and you, of course, can't see it as a user, because it happens on the wire)
- Comcast removed advertising code from pages and injected their own, removing revenue from the site you're visiting (and "supporting" by enabling ads)
- If you followed the UK news about 10 years ago, you'll likely have heard of Phorm, a business contingent on intercepting and profiling your HTTP traffic (BT ran a trial without notifying users, it got to the point the EU had to threaten our govt if they didn't enforce their own laws)
There are plenty of other examples spread across the globe, before we even get onto some of the Snowden revelations and what the security services were found to be getting up to.
> Something of a non-issue given that it only counts for the one site.
The *example* was one site, it applies to plenty of others too, that's just the way examples work.
There's a reason why browsers are concerned about mixed content (i.e. embedding content fetched with plain http in a https page) - because they're available to be manipulated by a man on the wire, those assets can be used in order to inject unwanted content and potentially compromise the page (much like why having unvetted ads on a payment page is a horrible idea).
-
-
-
Wednesday 18th November 2020 15:57 GMT Jamie Jones
Eggs and baskets
Is Lets Encrypt the only provider of free certificates?
We should be seeing a push to DANE acceptance before further forcing https.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
-
-
-
-
-
Thursday 19th November 2020 17:02 GMT Charles 9
Re: Eggs and baskets
"There's a huge quality difference between those that sign the dnssec root zones, and the huge array of disparate companies allowed to issue browser-recognised certs."
I disagree. It still relies on parties who can easily be subverted (if not subversive parties themselves--like governments). It still all depends on Trent, and there's no way to tell if Trent is really Mallory...or Gene. Like I said, you're simply moving the target. It all boils down to how much trust can you place, as the problem is otherwise intractable.
-
Friday 20th November 2020 01:16 GMT Jamie Jones
Re: Eggs and baskets
There have been many cockups with CAs:
https://www.theregister.com/2015/10/29/google_symantec_dodgy_certs/
Additionally, do you trust that there is no rogue employee in one of the CA's based in (say) Panama City?
Compare that with how dnnsec is signed: https://www.cloudflare.com/en-gb/dns/dnssec/root-signing-ceremony/
No contest!
P.S. I haven't been downvoting you.
-
Friday 20th November 2020 17:35 GMT Charles 9
Re: Eggs and baskets
But that's just the root certs. There's also the TLD level and anywhere in between. Can you really, really trust Verisign (who owns thus is responsible for signing .com) to not do things on the sly? The same for any other country's TLD, and then you get to the smaller registrars and so on. DNSSEC relies on a chain of trust. Well, like any chain, it's only as good as it's weakest link, and it can be hard to determine a compromised link if your adversary is really determined or resourced (like a government).
-
Friday 20th November 2020 21:25 GMT Jamie Jones
Re: Eggs and baskets
Ok, fair enough . I have verisign in the chain, and should have mentioned that.
Verisign is also one of the recognised CA's, so you gain nothing there.
Also:
As of 24 August 2020, 147 root certificates, representing 52 organizations, are trusted in the Mozilla Firefox web browser,[8] 168 root certificates, representing 60 organizations, are trusted by macOS,[9] and 255 root certificates, representing 101 organizations, are trusted by Microsoft Windows.[10] As of Android 4.2 (Jelly Bean), Android currently contains over 100 CAs that are updated with each release.[11]
Again, how can that be just as safe as the DNSSEC signing mechanism?
-
-
-
-
-
-
-
-
-
Thursday 19th November 2020 11:40 GMT Anonymous Coward
Re: Eggs and baskets
I've been playing around with Cloudflare the last few days FWIW
Fuck me, I don't know how they've managed to get so big: mgmt and feature wise, their product is absolutely abysmal.
Billy basic functionality requiring an Enterprise level sub, unintuitive set ups for caching etc.
If you want to just "try" them, unless you shell out for a Business sub, you're going to have an issue because you'll have to let them be the authoritatives for your domain (no, you can't just delegate a zone, that'd be too simple). So you have to go balls-deep from day 1 (or buy a second domain to test with).
In the UI there's stuff that's defaulted to On, but that doesn't actually work until you turn it off (or to a lower setting) and then back to what it was.
Their edge network lies between fantastic and pretty good (depending on where the end-user is), but then you can get that with the likes of Akamai and other CDN providers with far fewer trade-offs.
TBH, unless you're going to be using the "free" account, I'd skip them - even their $20/mo offering doesn't stack up against the competition.
-
Thursday 19th November 2020 18:52 GMT Anonymous Coward
Re: Eggs and baskets
> If you want to just "try" them, unless you shell out for a Business sub, you're going to have an issue
...
> but then you can get that with the likes of Akamai and other CDN providers with far fewer trade-offs.
...
> TBH, unless you're going to be using the "free" account, I'd skip them - even their $20/mo offering doesn't stack up against the competition.
I'd be interested to see someone just casually try out Akamai. Fill out a form, spammed by enterprise sales to gauge how much to charge, sign NDA, a week later you're up and running and then need to contact your account manager to change a settings. Comparing a Cloudflare $20 plan with Akamai (at least $1k per month, likely $50k) is quite optimistic. Akamai is not an option for anyone but enterprise.
As a Cloudflare user for various projects I'm always interested in checking out the competition at the $20/mo level so please elaborate! I have used Fastly in the past but bandwidth quickly became incredibly expensive. Again I'd certainly not put them in the small business bracket.
-
Friday 20th November 2020 16:48 GMT Anonymous Coward
Re: Eggs and baskets
> Comparing a Cloudflare $20 plan with Akamai (at least $1k per month, likely $50k) is quite optimistic
I wasn't referring to Akamai there. Sorry if it wasn't clear, but the CDN market is huge, with a huge range of options open.
You're right that Akamai is more at the enterprise end, so isn't going to be a great choice on a budget of $20.
You've mentioned Fastly, there's also maxcdn, edgecast (though they were bought by Verizon), as well as middle-man providers like SpaceCDN.
There's an entire world of choice out there, some are going to be better (performance wise) in certain markets, others fare well. Bear in mind though, that there's more to comparison that just the price - some might cost a little more, but be better value because the offering is a better fit for your needs.
Course, Cloudflare might be the best fit for you. But I really was surprised at just how poor their offering was in terms of features and management (and no, saying "we've got a fantastic API" doesn't really cut it, that's great, but I shouldn't have to mitigate a crap UI by building my own tools to use your API).
-
-
-
-
-
-
Thursday 19th November 2020 16:39 GMT doublelayer
Re: Thank goodness...
So, out of curiosity, what would you like your current browser to do in a situation where you visit a site, it has an HTTPS certificate, which is issued by a random CA nobody's heard of and never got trusted by anyone else. Would you like it to just use the cert and connect you because you don't want your browser warning you about a security risk? Remember that, in both situations, it tells you why there is a risk and gives you a continue anyway button. Why is this one so terrible when I'm guessing you view the other as a reasonable security precaution?
-
-
Thursday 19th November 2020 20:31 GMT Anonymous Coward
SERVO??? How do they dare to call something with a word that means "SLAVE"?????
Do they know SERVO comes from SERVUS which is the Latin word for SLAVE????
All those hours spent to remove blacklist, master, slave, and then SERVO???? Really?????
C'mon developers, you have to study all the living and dead languages to avoid any word that may look offensive to any of the billions inhabitants of this planet, until aliens show themselves and we should stop to call them aliens as well, because it is offensive. They live in the same universe, they are not aliens at all!!!!
Please, El Reg, ask Mozilla how they could name something SERVO!!!
-
Thursday 19th November 2020 22:19 GMT Pen-y-gors
Bit of a faff
I do development on Apache on my laptop. Really don't need https there. But anytime a page fails Firefox heads off to google instead of giving me a 404. I'm sure I can fix it but I just can't be asked!
And I have a load of public sites that I need to add Lets Encrypt to. Great idea until it fails to renew and I have to force it manually.
-
Friday 20th November 2020 08:41 GMT Norman Nescio
Managing off-Internet kit?
I manage equipment over a network that is not connected to the Internet. It is convenient to use the GUI interface that is implemented using html/http, so I would prefer it if browsers do not remove http access.
From a security and privacy point of view, I really would prefer not to be dependant on a third party for access to 'my' equipment. Some of the kit may well not support https. For the kit that does, I'll have to set up my own local CA, then add that into the trusted CAs in the browsers of all the devices I may use to do management. It will be a faff. Sigh.
It might be worthwhile to reflect on what https is meant to do. It is meant to secure the communications so that untrusted third parties can't eavesdrop or inject fake data/transactions. If you look at the list of trusted CAs baked into browsers, you are trusting rather a lot of organisations not to leak certificates that enable untrusted people to eavesdrop and inject data.
Personally, I'd prefer to be able to secure the communications link without relying on third parties. SSH can use a 'Trust on First Use' (TOFU) model, so what I do, where possible, is set up the device with an Ethernet cable plugged plugged in between the device and my laptop, enable SSH, and subsequent GUI-based management is HTTP tunnelled over SSH. The SSH provides the secure communications channel, and the http supplies the GUI. No certificate required.
Obviously managing SSH keys gets important, but I can do it all without requiring an Internet connection, or by being tied into someone else's idea of optimal certificate/key expiry times, or becoming dependant on a CA's secure storage and use of root certificates.
So please don't get rid of http entirely. There are other networks than the Internet, and if you use other means of securing the communications channel, http can be used and be useful.
NN
-
Friday 20th November 2020 14:17 GMT Anonymous Coward
What about embedded devices?
I may be being a total ignoramus here, but what about embedded devices - like home routers, printers and some industrial control modules - which are configured via a web browser? Normally they seem to use http only, or at best a self-signed cert which is regenerated at each boot with a long expiry date. Either way they get flagged as insecure.
Managing certificate expiry on a deployed embedded device is often inconvenient or even impossible. Since many of these devices normally exist behind NAT routers, instead of requiring https, would it instead be possible for browsers not to complain about http if the device has a non-routable IP e.g. 192.168.x.x or 10.0.x.x?
-
Friday 20th November 2020 16:33 GMT Smartypantz
GAFAM secrets
At the moment https is primarily a method for GAFAM to ensure that their monopoly on data snooping is intact.
When TLS 1.3 is implemented the circuit is complete.
Maybe we should be promoting full disclosure (http only) and celebrate cleartext data as a means to preserve individual freedom and choice?
-
Saturday 21st November 2020 04:46 GMT W.S.Gosset
No public wifi access in Australia
Bit late to the party here, but :
Https-only mode blocks access to public wifi (eg, libraries, parks, shopping centres) for Australians.
Reason:
For herd-/meme-reasons, all the admin bods for same have decided to use frameworks which all work the same way:
1. Require all users to Accept T&CS before allowing access (entirely valid approach)
2. Via browser only
3. Implemented as:
3.0 On attempting to connect to a website, on receiving server-traffic back, substitute the framework's login/acceptance page rather than the server's page
3.1a But pre-reply, if the site/server demands https, the browser will barf on connection failure first : result = user can never "login" to public wifi
3.1b If it's a http page, get diverted to the "login" page : can login and use public wifi.
The only way to login to public wifi in Australia is if you remember a non-https website or know the particular internal URL for the framework's login page.
Grownups will notice this implies the system was never tested by grownups.
It's actually worse than you think : the frameworks are throwing pages which are doing everything in JavaScript. To be clear, it's a single page of text plus 2 buttons: Accept and Reject (T&Cs). Rather than achingly simplistic html incl. POST attached to 2 buttons, it's all JavaScript.
If you have JavaScript switched off, you can't get access to public wifi