Firefox 83 introduces HTTPS-Only Mode
blog.mozilla.org
blog.mozilla.org
This doesn’t guarantee the transport is end-to-end secure; I’m sure plenty will strip the encryption at an LB and then possibly send it back over the internet. But, I think it’s a good addition nevertheless. Here’s to hoping for more DoH and encrypted SNI adoption as well. No good reason to leave anything unencrypted if it doesn't have to be.
(I’m less happy with Firefox’s approach to DoH rollout, but I’m still glad to see DoH gaining some traction. Let’s hope the end result is worth it...)
HTTPS upgrade feature has always been there in Brave.
Edit: I'm using system-wide DoT at the moment with CoreDNS but it doesn't work that well. Not sure why.
I work for a firewall co and we had taken a strategic decision to not allow plaintext traffic onto the internet (from cloud deployments). It's just lazy on the client or server operator's part to not have it so.
Our market is more backend API traffic so doesn't impact as much.
Someone did, almost two and a half decades ago. It's called the Internet Cache Protocol.
- Internet Cache Protocol (ICP), version 2 [0]
- Application of Internet Cache Protocol (ICP), version 2 [1]
--
As an end user, I don't want the possibility of anything being tampered with along the route. As a content owner / webmaster, I want the same. So publisher and consumer are both aligned in their desire, making HTTPS ideal for everyone except for people reading/manipulating traffic along the way.
There is nothing about DoH that forces you to use a single company.
If a domain owner gets a certificate and gives it, and a private key, to a third party, then that's their business.
Just for completeness, HTTPs does not necessarily guarantee you are connected to the right server. This depends on the CAs you trust.
For example, larger enterprises commonly inject their own CA into their workstations in order to prevent loss of sensitive data. This allows SSL inspection proxies to terminate all SSL connections with a valid, trusted certificate from the perspective of that workstation. .
Only Chrome is allowed to break stuff on the web, remember?
I want my network to tell me a DNS server to use. As I own my computer I can override that, but much of the time I want to use the network provided DNS server.
Many sysadmins will hate this.
> Full of spyware, and tracking.
What do you use? Google?...
If I were on a hostile network (say a hotel), then sure, I'll ignore their DNS server and use my own (or indeed just punch my way out via a VPN), but most of the time I use friendly networks, and I don't want to have to configure 20 different applications on a dozen different boxes to use a DNS provider of my choice. There's a reason I use DHCP in the first place.
Given your knowledge you can disable or even build firefox with DoH disabled , it is a sensible default for vast majority of users who do not know what DHCP is, or control their network. It cannotis trivial configuration for people who can control and do not want the DoH service provider given by Firefox.
Also many places do not allow VPN traffic either. It is not as easy to bypass monitoring in a locked down environment like typical corporate firewalls, college campuses etc. Yes for every block in place like deep packet inspection etc there is usually some workaround but these become increasingly difficult as more stringent the blocking becomes, and having options like DoH helps users who cannot or do not know how to run VPNs.
Now port 53 can and often is intercepted (but sometimes it gets through when 443 doesnt)
It is not possible to sniff out DoH traffic via DPI as looks exactly the same as regular traffic
While running flash servers for media use in corporate environment (when flash was still a thing) back I used to run into similar problems with RTMP/ RTMPS constantly.
I have mixed feelings about the issue, but it's not that simple.
I run a variety of services on my LAN for my users and guests. That includes Unbound, so even though their browser doesn't know it, their queries are secure from my ISP. But more importantly I have other stuff behind hostnames (which are resolved by Unbound). For example, my guests can navigate to music/ and use a web interface to play any of the music in my library over the stereo.
Hopefully it's obvious why this is something useful to have.
Now that Firefox is intercepting DNS requests, a conversation with someone might go like this: "Oh, it's not working? Are you using Firefox? Yeah, Firefox broke this recently, let me get the IP address for you." And then I have to log in to a computer, ssh into the relevant system, and get its IP address on the LAN.
And that's just the beginning. Last I checked Cloudflare still can't resolve the archive.is / archive.today domains. Even though I use Cloudflare over TLS in Unbound, I fix this for myself and my users by sending these domains to Google instead. Anything as convenient and simplistic as Firefox just sending everything directly to Cloudflare can't do that.
From Mozilla documentation.
"localhost" and names in the ".local" TLD will never be resolved via DOH. [1]
The Cloudflare / Archive.is point is esoteric debate and not a common occurence, DoH does support other providers than Cloudflare so not sure if this really a major concern
I don't think PFsense + Unbound supports appending .local to every hostname automatically, so I'd have to change every last one of my hostnames to whatever.local and that seems like a real pain. (Surely most people are not using whatever.local in their /etc/hostname, right?)
> The Cloudflare / Archive.is point is esoteric debate and not a common occurence, DoH does support other providers than Cloudflare so not sure if this really a major concern
Sure, but my general point is that there's all sorts of different reasons why it can be useful for a LAN administrator to override the remote DNS response in certain specific cases. Given that Firefox is using Cloudflare by default, the fact that you can change it also doesn't really help anything, since after all the thing I'm specifically complaining about is that stuff randomly breaks for any of your guests using Firefox.
Cloudflare broke a lot of traffic when the 1.1.1.1 dns server came up, google broke lot of dev setups when they got the . dev TLD, however it is not theit fault though.
Then it will automatically register them in DNS with that name: https://docs.netgate.com/pfsense/en/latest/services/dns/reso...
> The domain name from System > General Setup is used as the domain name on the hosts.
Then in the DHCP configuration, you set the domain name as well (defaults to using the general setting): https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv...
> Specifies the domain name passed to the client to form its fully qualified hostname. If the Domain Name is left blank, then the domain name of the firewall it sent to the client.
The client will automatically try adding the domain when looking up hostnames. Normally on Linux the FQDN is not specified in /etc/hostname but only in /etc/hosts.
archive.is didn't work for Cloudflare users because they purposely sabotaged the results for Cloudflare (they did actually return valid, but wrong, results).
EDIT: Although you might have a problem if the owners of the ".music" TLD decide to put something else there.
But anyway, it is your decision to use them - you can use 1.1.1.1 (CloudFlare), 8.8.8.8 (Google - if you don't mind the tracking) or any other DNS provider.
Your comment was obviously trying to strike a blow for one side of a well-known argument that's going on right now. There are a few problems with that. First, blow-striking is not curious conversation; we can't have both, and HN exists for the latter [2]. Second, these arguments are so well known that the threads they lead to get increasingly predictable as they get more intense [3]. I'm sure you can see how that's bad for curious conversation too.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://news.ycombinator.com/newsguidelines.html
[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor...
The cat is out the bag, so to speak. I foresee a lot of adware, spyware, and malware leveraging DoH now to evade just about every DNS-based monitoring/blocking/provisioning solutions.
Anyway, the right layer to monitor for Internet traffic has always been the IP layer (VPNs notwithstanding).
Of course you can just drop a rule blocking the IP address on your firewall, which will probably work for a while.
You could make the exact same kind of argument about widespread use of HTTPS for example. Do we want to allow encryption technology if it means the enemy can use it too? As a society we have agreed that encryption is a net positive even though terrorists and criminals benefit from it, but when malware uses it then that's too far?
That doesn't hold up under scrutiny. My pihole blocks ~11% of domain lookups (blocking 1000 queries per day for our household), turning it off vastly increases the unwanted content. It might seem is logical a ready hurdle, but it's a hurdle that practically works.
I don't follow the reasoning that says this is a small barrier to malware so we'll remove it.
What are we, end users, getting out of routing all our domain lookups to Cloudflare and ceding control of filtering?
It does feel the world is moving away from a multi-level network to run everything over TLS/TCP (and probably eventually mainly TLS/UDP), taking away the power from me as a network and device owner, and giving it to the developers
I guess this Mozilla Firefox change deprecates HTTPS Everywhere.
Either way, we've come a long way. For people in the Dutch security world, DigiNotar was a known joke. I knew about their terrible security (and the implications) back around 2000-2004. Although there have been more vulnerabilities too, such as Hearthbleed and POODLE.
I'm not familiar with HTST so I went looking but didn't find anything related to the web and HTTP, so I'm guessing you meant HSTS?
On a side note, I would love to see a system that adds out-of-band validation of an entity. e.g. My bank should have a QR code behind glass on the wall that I can scan, import a key and further validate their site at the application layer, above and beyond HTTPS and CA certs.
1) The ISP says what should be used
2) the lan either accepts that, or the operator puts their own values
3) the device either accepts that, or the operator puts their own values
Same as object inheritence. An ISP says "use this DNS server it's nearer", the network operator says "no thanks, I'll run my own with an upstream of google as I don't like your NXDOMAIN injects", the user says "actually I'll use cloudflare because I don't trust any of you"
That's all fine, and gives the power to the user.
Exceptionally if a device doesn't allow the network settings to be overwritten for some technical reason, it should simply accept what the lan sends it.
And so browsers are saying that the path should be.
1) The browser developers say what should be used.
2) The user either accepts that or puts their own values.
Ideally I think it should actually be something like
1) The OS vendor say what should be used.
2) The user either accepts that or puts their own values.
2.1) Lan operators can offer DNS servers which the user can (always) accept or (always) reject with reject being the default.
But this whole mess with browser DoH is because OS vendors are slow to move on this. Google Android does it kinda, Windows has it in beta, Linux works but it's a little DIY.
In some parallel universe, TLS would have been part of TCP not a separate protocol and the Berkeley sockets implementation in the OS kernel would handle all encryption, certificate validation, etc, on behalf of applications. AT-TLS is a bit like visiting that parallel universe
(Strictly speaking, I'm not sure if AT-TLS actually is implemented in the OS kernel – or "nucleus" to use the z/OS terminology – it may actually be implemented somewhere else, say in the C library. I know some of it is actually implemented by a daemon called PAGENT. But, from the application programmers viewpoint, it is provided by the OS, however exactly the OS provides it.)
But tunnelling X in Y is not new at all and has a long tradition (even in regular protocol design). Is this really a shift waiting to happen in malware? As I would think, this has been available all along. Except for browser-based malware.
Adware, spyware, and malware has always had the ability to avoid system DNS. At its most basic, they could hardcode lists of IPs into their malicious code. At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system. Drop a list of hostnames into a pastebin post, tell your malware to check the list for updates, profit.
DoH in Firefox simply makes the above issue harder to ignore. Before this, an enterprise or individual sysadmin could implement DNS inspection at the border, see logs showing their users browsing naughty websites, and feel like they’d made progress. But they’d always be blind to attackers (or nefarious users) who just didn’t bother using the stock DNS offering to bootstrap their hijinks. Detecting that has always required device-level monitoring or further MITM of traffic; learning about DoH makes that more obvious to sysadmins, but it doesn’t materially change what adversaries were able to do already.
> DoH in Firefox simply makes the above issue harder to ignore.
That's exactly what I mean [0]. The cat's always been there so to speak but now it is out there roaming around harder to ignore.
[0] https://news.ycombinator.com/item?id=25123487 and https://en.wikipedia.org/wiki/Script_kiddie
Which makes the malware more fragile, because the hosts are often compromised machines themselves, or are the targets of takedowns. If they include only one IP at a time (as they can do with DNS) then when that machine gets cleaned by the owners, they have no way to switch to another one. If they list several machines then anyone analyzing the malware has a list of multiple compromised machines to go have them all cleaned at once. Also, then you can add the IP address to a block list and they can't update it like they can with DNS.
> At its most complex, the same building blocks that DoH/DoT use were available to them: they could build similar tools that tunnel over HTTPS/SSH/etc, whichever protocol they felt was least conspicuous on their target system.
Malicious javascript in a browser doesn't have access to SSH or similar. And that's assuming their code can even reach your machine if your Pi-hole is blocking the DNS name of the server hosting it.
> DoH in Firefox simply makes the above issue harder to ignore.
It makes it harder to prevent. Someone sends the user an email link to a URL containing an unpatched browser exploit or a link to a malicious binary. If the Pi-hole blocks the domain and/or the IP address in the email, the attack is prevented. If the browser bypasses the Pi-hole, you have malicious code actually running on the user's machine, and that's a much bigger problem.
> Also, if they use an IP address then they can't be using SNI to host it on the same IP address as several other domains
Sure they can, just hardcode the "Host" header value as well
> Malicious javascript in a browser doesn't have access to SSH or similar.
They can access HTTP though, which is more than enough.
Over HTTP from what? You would need name resolution or a hard-coded IP address to make an HTTP request.
And the thing this is preventing isn't just what the malware does after you're already infected, it's the path to receiving malware to begin with.
And in many cases the user is the network operator. What the browser is doing is taking away the mechanism to set local policy. Ordinarily you hand out the DNS you want your devices to use via DHCP, and they use it. If you move that from the OS to the application and the application ignores the DHCP setting by default, now you've lost the ability to set a uniform policy for all your devices and applications. It becomes an arduous manual process to change the setting in every application on every device, and then you probably miss half of them.
DNS has historically been set by network policy so that it's easy for network operators to map hostnames to their local network resources. The point of the design wasn't to enable traffic monitoring or content blocking by altering the results for hosts that aren't under your control.
For most people, their local DNS is someone like Comcast or Verizon, way less trustworthy than CloudFlare. We shouldn't reduce the privacy of the majority of people just to increase it for a small minority of people by default.
Are you referring to the whole CA system being an untrustworthy racket?
What is the burden for using HTTPS assuming you DO want to be able to inspect and block HTTPS resources at a network level? Very extensive compared to plain HTTP.
The other half of the problems are around defaulting to allowing cloudflare to inspect your traffic, instead of comcast. And the lack of integrity and encryption for the rest of the DNS infrastructure. And the expansion of the complex and difficult to secure x509 certificate regime which we should be moving away from. (Something like gossamer seems to be a big step in the right direction)
I want encrypted dns, just not a half-assed hack of an implementation that is going to be impossible to fix once deployed.
Regarding the rest of the DNS infrastructure, I agree there is more work to be done. But I see DoH/DoT/etc as a necessary step and not a "half-assed implementation" that needs to be "fixed".
Who doesn't want that? I have a pihole (and use OpenDNS). Bypassed it all yesterday, as an experiment, to look at an anime site my eldest started using and immediately was hit with a pretty impressive and convincing phishing attempt (mimicking my ISP).
Pretty much all of us on HN seem to use some form of 'DNS' based filtering (pihole, or even just hosts file). UK ISPs offer DNS based filtering as a default (and have to filter some pages by law, and are encouraged to filter others [through threat of law]) ... but a lot of people want that, many many families, schools, businesses.
Certainly I don't want it to be easier for advertising and malware to bypass my chosen DNS-style filtering.
UK ISPs having mandatory DNS blocking is a great example of why DoH is important. The user should decide what they want, not the network operator.
Perhaps widespread use of encryption technologies means I can't do content blocking on proprietary appliances like the Chromecast for example. I think that's a necessary evil and I just won't buy such an appliance if it's that big of a problem. Only legislation can really fix that kind of problem anyway, it doesn't really matter whether Firefox implements DoH or not.
https://support.mozilla.org/en-US/kb/configuring-networks-di...
Someone previously mentioned Pi-Hole. Pi-Hole provides the DoH canary domain in it's default configuration, therefore if you run an up to date Pi-Hole on your network you will have DoH disabled. It is recommended (and there are good instructions on the Pi-Hole website) to set up cloudflared or a similar DNS resolver which implements DoH as the backend to Pi-Hole, allowing it to use DoH when leaving your network but still act as the local network's authoritative name server.
If you choose to be a network operator, there are some additional complexities you must think about. For those (majority of) users that choose not to be network operators, DoH is nearly transparent for them and provides significantly improved security and privacy by preventing local cache poisoning, DNS injection, and DNS snooping attacks on their browsing.
Additionally, while the default in Firefox is a non-filtering endpoint currently, you can manually configure the use of a filtering DoH endpoint like those provided by CloudFlare 1.1.1.1 for Families if you wanted to do so. Nothing prevents this, and it can be configured via policies network-wide in Firefox using the enterprise policy mechanisms.
I still don't really understand this. Yes, it solves that problem, but how is it not also defeating the entire premise? If you had a DNS server from an adversarial network operator, they could just resolve the canary. So it means the browser's DoH is only secure if you can trust your network operator's DNS, at which point, what was its purpose supposed to be?
And the fear is that at some point someone is going to try to "correct" that by removing the check for the canary.
There's still some specific cases where DoH is problematic, but these are being eliminated over time as the technology matures. As an example of this, split horizon DNS in corporate environments is a good choice. Right now, the only realistic way to provide this is with Do53, so DoH must be disabled, but with Microsoft adding DoH support into the Windows 10 DNS Client, they are likely soon going to also support it on Windows DNS Server, which would enable businesses to make use of DoH internally and to simply set the endpoint by enterprise policies.
DoH is a few different things, but at it's most basic it's transport security for DNS, which is a fundamentally good idea any way you slice it. At some point in the future, plaintext DNS will effectively cease to exist and that's a /good thing/. There are several different implementations of encrypted DNS in the wild besides DoH (DoT and DNScrypt as examples), whichever you choose, any option that encrypts DNS both on your local network and across external networks improves privacy and security.
It takes a pretty long time to transition fundamental protocols like this, but a future where more things are sent across encrypted transports is a good future. Plaintext DNS is incredibly vulnerable, and it's also in an area which isn't heavily visible to most users, which is not a recipe for success.
https://wiki.mozilla.org/Security/DOH-resolver-policy
This is all publicly documented. As Mozilla rolls DoH out to other regions they will add additional TRR partners and CloudFlare won't be the only choice.
For non-tech companies, replace with any relatively popular wiki.
The goal is “make a connection over HTTPS or other normal-looking protocol, to a destination that is both justifiability relevant for normal user traffic and allows the attacker to seed the next-step”. And it turns out there are lots of sites that fit that bill.
They're not going to leave malware payloads sitting there. Pastebins etc. get abused as malware command-and-control systems all the time, and of course some gets through, but countermeasures happen. Whereas for a DoH server it would be operating as designed.
A simple GET request to https://github.com/adkafdjsh20/cool_repo/blob/master/dns.txt would work for DNS purposes.
Also, there are countermeasures for malware domains themselves, as you can report them to registrars.
The issue is “how do I tell my bootstrapper where to get a payload from in an inconspicuous way”. To solve that, you find a benign site with existing business purpose (like GitHub or a wiki or a pastebin), and you insert your desired IP address. So maybe you add it as new file in a repo under your cool new fake GitHub account, and the file just says “1.2.3.4”. Now you can tell your bootstrapper to make an HTTPS request for that file, which looks boring to any introspection because outbound requests to GitHub are normal, and to use the resulting IP to request the payload.
Your compromised payload host gets shut down? Spin up a new one, and update the file on GitHub with the new IP.
Oh joy.
I run DHCP for a reason. That reason is telling devices on my network what their settings should be. I expect those settings to be honored, not them doing the electronic equivalent of "okay boomer" and using whatever arbitrary settings they were told to by a corporation.
The key is that if it's really your traffic, then you can easily reconfigure Firefox so that you can monitor it. The benefit of DoH is that if someone else is using Firefox on their own computer, you can't snoop on or hijack their DNS just because they're on your network.
If you work in a setting in which web surfing is intercepted, and outright breaks pages, the in-browser DNS can be a godsend.
Also, it is only a matter of time before ads (and websites) start using it to bypass browser DNS:
I'll go further and say I want my router to handle this. It is unrealistic to expect every device on my network to natively support the standard, but it's pretty easy to have your local DNS endpoint reroute the traffic through DoH on it's way out of your network. Right now I accomplish this by running cloudflared upstream of my Pihole.
I don't like applications that do their own DNS resolution. I use a text-only browser that relies on the OS to do DNS resolution.
But imagine your DNS is filtered. Would you still want only a single source, e.g., your ISP? In that case, wouldn't you want multiple sources?
When in a DNS-filtered environment, e.g., a hotel, DOH outside the browser can actually be useful. For example, I can retrieve all the DNS data for all the domains on HN in a matter of minutes using HTTP/1.1 pipelining from a variety of DOH providers. The data goes into a custom zone file served from an authoritative nameserver on the local network. Browsing HN is much faster and more reliable when I do not need to do recursive DNS queries to remote servers. The third party resolver cache concept is still really popular, but IME most IP addresses are long-lived/static and "TTL" is irrelevant. I rarely need to update the existing RRs in the zone files I create and the number that need to be updated is very small.
DOH servers are not the only alternative source of DNS data.
Ideally, I prefer to avoid third party DNS altogether. Nor do I even need to run a local cache. I wrote some utilities that gather DNS data "non-recursively", querying only authoritative nameservers and never setting the RD bit. It is very fast. The only true "single source" of DNS data is the zone file for the particular RR at the designated authoritative nameserver(s). Everone else is a middleman.
I am not a fan of applications doing their own DNS resolution, even if they use DOH. But I have found the existance of DOH servers, i.e., third party DNS caches served over HTTP, can be useful.
But agreed, it is a good idea. The only disadvantage I see is that some sites might not want to pay for a certificate and don't know how to easily obtain free ones. So it might kill some sites.
https://www.privateinternetaccess.com/blog/kazakhstan-tries-...
Hijacking this a bit - If plenty are stripping the encryption at an LB (like Cloudflare for example), how can you be sure that NSA is not wiretapping in Cloudflare's infrastructure where it is not encrypted? Seems like a really easy way to get unencrypted data and not care about if everything is HTTPS or not.
Are there any counterexamples to this? Do we know that Cloudflare or AWS is not doing this?
100% with you that by itself, browser HTTPS-only mode (even by default) is A Good Thing. In isolation, this is a no-brainer and Mozilla's doing the right call.
I'm not happy with DoH though, at all. I fall in the crowd who wants to control my own DNS on my own devices (and I do realize that for those less technically knowledgeable, the status quo is putting that in the hands of the network admin or even ISP, but at least in principle they have the means to do so if they just figure out how, which is relatively trivial). DoH effectively completely cripples things like pihole. I'd have to start whitelisting IPs/hostnames for port 443 :/
Another practical negative consequence is the further centralization of TLS termination in (most notably) Cloudflare and Akamai, as I am sure this will de the default for those who are now rushed to TLS-enable currently uncompliant endpoints. Great sieves for XEyes and private tracking industry.
You can easily set it up to contact that, but enable some exclusions for specific domains if you wish to fallback to pihole.
It's probably not that efficient anyway to be using pihole's filtering in Firefox compared with just ublock origin anyway.
In a broader sense, I guess the larger concerns is malware and trackware on various devices where DoH is used maliciously. Especially smartphones. Granted there is nothing stopping them today, but the normalization of DoH will put it in arms reach for everyone.
Pihole operates at the network level. It can block Windows Telemetry, ads on your Roku, smart devices trying to phone home, etc. Any guest devices that connect to your network also benefit without you having to install blockers on them.
It's not a replacement for ublock, it's used in conjunction with it.
No, it isn't. Never mind the fact that that isn't how PiHole works, I'm perfectly within my right to control how my home network functions.
My argument though is in the context of Firefox, in which case the benefit of the pihole bit is dubious when you can install ublock origins. Pihole doesn't provide much additional benefits that can't be achieved with ublock origin advanced filters.
Granted someone could argue what would be the benefit of using the dnscrypt-proxy at that point. In that context, you benefit from better privacy (DNS requests aggregated) and caching benefits.
None of this - DoH, nor HTTPS-only - is required. It's not even on by default (yet). If you have some specific wishes; it's trivial to pick a different DNS system, or leave https-only off.
Additionally, DoH and https-only aren't really closed or locked in in any way. There's a cloudflare-base DoH option that's used by default, but just as you can pick your own DNS servers, you can also pick your own DoH servers. Sure, it's new (and thus not on by default), so selection is still fairly limited. But even ISPs are starting to offer DoH, and surely others will too. There's no reason to assume that you won't soon be able to pick from several choices for your DoH setup, including local or LAN options.
You mention pihole; and though I've never used it, they do have a page on DoH, and a superficial skim doesn't have any huge issues: https://docs.pi-hole.net/guides/dns-over-https/ - and looks like it's based on code described here https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo... - and that supports upstream and downstream DoH, by the looks of it.
In other words: all change has some friction, but if you want local control: you still have it. The only thing you really lose is the ability for networks to hijack DNS of devices that don't trust it. And that's a feature, right? If you trust the network; sure, use that DNS if you want. But if you don't: better that its easier to avoid control by that network.
What downsides does DoH have?
For me at least, the biggest criticism of DoH is that it's not necessarily a centralized config at the OS level and seems to be a step in the direction of the general theme "Browser As Your OS".
I had to disable DoH on all 5 of my machines because it was enabled automatically.
> You mention pihole; and though I've never used it, they do have a page on DoH
pihole supports using Cloudflare as an upstream DoH provider, not acting as a DoH provider.
Some googling: it's on by default in the US now, not yet globally.
> pihole supports using Cloudflare as an upstream DoH provider, not acting as a DoH provider.
That's unfortunate; are you sure it's not just a little poorly documentend? At least the underlying software they link to https://developers.cloudflare.com/1.1.1.1/dns-over-https/clo... clearly mentions a proxy functionality, but maybe that's not on yet?
In any case: the point is that just as DNS proxying became easier over time, so will DoH proxying. There's nothing wrong with sticking to old tech as you chose to if it's not yet convenient for you to switch; especially if pihole supports upstream DoH, since presumably you trust the network between your device and your pihole ;-) - rendering the rest of the DoH benefits moot.
I'm sure time will resolve issues like that, but in the meantime, the vast majority of people that didn't customize their DNS and don't choose at all, or choose based on privacy or performance get a more private & secure option by default. I mean, it's transition pains are annoying, but it sounds like a good idea in general, so I suppose the transition costs are worth it in the long run, especially since the vast majority of users won't even notice. It's annoying to be in the camp that gets to bear the burden, for sure.
I've often daydreamed of a new HN freature where non-HTTPS links have a preceeding red marker "[HTTP only]" (or similar) but never could find the correct place to write it down. Considering that Firefox is now a minority browser :( perhaps there is still usefulness in this idea?
Increased corporate/government control and centralisation. That is a huge "do not want" for many of the HN crowd, including me.
I think people are just totally off-base on this. The instances of government/corporation reactions to DOH that we have seen suggest that untrustworthy organizations and governments largely oppose the change. They would not oppose the change if it was in their best interest.
Worth noting that anyone can set up a DOH server. You can even set up your own server in your own house and use it the same way that you would a Pi-hole. To the extent that malware providers or IoT providers will use this to circumvent blocks, they already had the ability to do that -- and IoT services like Chromecasts have already experimented in the past with setting their own DNS providers and ignoring network settings.
We do not need to open up our networks to MiTM attacks to avoid centralization. Unencrypted DNS is a bad idea, it isn't complicated.
This is not responsive to my argument that it will impact most Firefox users. Most people won't change their defaults. Defaults matter. And that goes double when you need to dink with your own DNS server to override this crap.
a) the best provider available
b) more importantly, the most private provider available
But there's nothing about the technology locking Mozilla into keeping Cloudflare the default in perpetuity, and in any case, the solution to your concern is to adjust the defaults, not to throw out DoH entirely.
There's nothing about DoH in specific that's causing the concerns you have. Mozilla could have set Cloudlfare DNS to be the default even for regular, unencrypted DNS traffic. There's nothing inherent in DNS technology that would force them to respect your OS settings. If your concerned about Cloudflare taking over, rejecting DoH isn't the solution to that problem.
It's not an underhanded centralization push, it just so happens that when DoH was still new, there was effectively one provider that was widely available, that could confidently handle a large upsurge in traffic, and that made extremely strong privacy guarantees compared to the rest of the industry. At the time Mozilla started pushing DoH, most ISPs in the US didn't even offer it as an option at all. As that changes, I expect that browser defaults will change as well.
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
I get your concern about cloudflare, but I can tell you right now which of the two options I would trust more with this data, and it's not Comcast/AT&T/Cox/<insert shady ISP here>
For most users on the planet Cloudflare is a hell of a lot better than your ISP
What particularly annoyed me was using http to sites which supported https.
So if a site isn't in the whitelist, it won't modify the request in any way.
To be honest, it's about time that cert enablement is built into all web server configs (on all OSs) as a native feature instead of having to manually roll the config using this-weeks-currently-preferred letsencrypt script.
---
[1] Yes, yes, I know everyone on HN prefers everything to be https, but out in the real world, most people don't care if all they are doing is browsing for information.
This satisfies the need to be on HTTPS, without actually having to change anything in your server.
Not saying this is ideal, but for websites that don't _need_ it it could be the best/easiest approach.
If you are concerned about the power-users who enable this being aware of these facts then maybe you do need https after all.
(Of course I suspect this mode will be made the default at some point, but that is probably at least a couple of years off.)
It feels like we're slowly getting there! +1 for Caddy for making HTTPS a surprisingly pleasant process. My home router and NAS also support (and enable) Letsencrypt out of the box, which was a nice surprise.
Therefore I believe it should be a social duty to make everything https so as to ensure that we don’t create something that can be used to harm others.
I didn’t use to think like this until I actually tried it out by going to a mall and doing it myself. Whoever was accessing simple http websites for the very short end of a stick (metaphorically speaking)
I keep hearing this as a plausible excuse, yet I've never seen any proof of such.
non-https does make it possible but has anyone got any source where someone has been victim of such attacks?
[1]https://www.privateinternetaccess.com/blog/kazakhstan-tries-...
[2]https://security.stackexchange.com/questions/157828/my-isp-b...
Yes, the most well-known victim was GitHub. A malicious MITM injected JavaScript code into an unrelated non-HTTPS page, making browsers which visited that page do a DDoS attack against GitHub. Quoting https://arstechnica.com/information-technology/2015/04/meet-... "[...] The junk traffic came from computers of everyday people who browsed to websites that use analytics software from Chinese search engine Baidu to track visitor statistics. About one or two percent of the visits from people outside China had malicious code inserted into their traffic that caused their computers to repeatedly load the two targeted GitHub pages. [...]"
Just need to be on the same network as the victim and do some ARP spoofing to make your computer the gateway for that network.
As for attacks, others have pointed out examples as well, and I can assure you you can go far with them (and often with some simple social engineering).
HTTP is just a no-no for me as a developer.
Also it's really different from DKIM: the problem with DKIM is that since the signature is part of the email itself, so unless the receiver bothers to strip it (why would they?) then it's stored forever in the metadata, even though arguably its use as an anti-spam feature stops being relevant once it's been delivered to the MUA. So basically every time you send an email through gmail you effectively also send a signature saying "I, Google, vouch that h4x0r@gmail.com did send this email" and the receiving end will keep this signature for as long as they keep the email.
HTTPS session keys however are not typically saved unless somebody goes out of their way to do it. As such it's a lot less likely to be used for blackmail in hindsight. In general people use archive.org to prove that some content used to exist in this scenario, not old HTTPS session dumps.
And like for DKIM the solution is fairly trivial if it's really an issue: every time you rotate your keys (which should be fairly frequent if you use something like letsencrypt) be sure to make the expired private keys available publicly to give you plausible deniability.
I have yet to hear a good argument against HTTPS everywhere honestly, it generally boils down to "but I don't want to do it" with some weak post-hoc justification for why it's bad.
A standardized overkill solution that covers most use cases is probably better than n+1 standards with different tradeoffs.
DNS-over-HTTPS is one in a long series of decisions that contradict the assumption that network operators deserve cleartext access to your traffic. I suppose we can thank the NSA’s Room 641A for inspiring the tech world to pivot to this view all those years ago. It’s finally reaching critical mass, and endpoint network operators are furious at having their sniffing/spying capabilities hindered.
Captive WiFi portals are next on that list of institutions that are at risk of failing. I can’t wait, personally.
I'm merely pointing out what is in my humble opinion, even when no sensitive data is traveling, the main reason why HTTPS should be everywhere. If you believe there are other easy to deploy and maintain solutions with the same amount of relevant user outreach, then by all means suggest them.
(I could of course point other reasons, like the fact that even if your website has no sensitive data it can still be scraped to build a profile of the visitor by a third party, etc).
Those who give up freedom for security deserve neither.
You can make an act compulsory on the whole population but you can't legislate duty-of-care upon the whole population.
Benjamin Franklin, to the legislature of Pennsylvania, on the topic of basically letting the Penn family buy their way out of paying taxes indefinitely by providing enough hired mercenaries to protect the colony's frontier during the French and Indian war.
The freedom he was talking about was a legislature's freedom to govern.
The temporary security he was talking about was hired guns.
And none of it applies to the question of the tragedy of the commons that is "HTTP protocol is default embarrassingly insecure."
Indeed, if I were to torture the quote enough to make it fit, it looks more like "Those who would give up essential Liberty (Mozilla, in this case, to design the user agent the way they think best benefits their users and the World Wide Web as a whole) to purchase a little temporary Safety (... of their user count by delaying inconveniencing users in the corner cases where HTTPS can't be used), deserve neither Liberty nor Safety." But it barely fits.
I've been getting certs for all of my side projects and it takes about ~10 minutes each. Highly recommend.
I was wondering. If I run a simple http page on my home network, how can I, from another device, change it or make another client get a modified page with the same address?
Or maybe Wi-Fi promiscuous mode packet sniffing, but that's a read-only attack.
Everyone being forced to get permission from a centralized cert authority that is easily influenced, pressured, etc in order to host a visitable website is the end of the web as we know it. This is a slide into a total loss of autonomy.
I give it about 3 years before all commercial browsers stop allowing you to visit HTTP sites at all and Firefox only allows if you use their unstable beta build.
At that point you won't be able to host a visitable website without getting permission from someone else. And that's the end of the personal web.
In fact, your browser trusts a few dozens of different ones, and companies routinely manage their own.
If you visit an HTTP site and get MITM'd, it's not just that the attacker can put you at risk by spoofing a credential input box; it's that the attacker can put third parties at risk by having your browser XMLHttpRequest as fast as it can at at someone else's site to try and DDOS them.
At that point, the calculus shifts and we see a world where user-agent engineers have to make decisions like Microsoft did (to start forcing people to install security patches to the most popular OS on the planet, because we have enough evidence from human behavior to know that at some point, forcing-via-inconvenience becomes necessary).
HTTP is fundamentally broken in that it can be abused to damage the network itself, and even though it's a deeply entrenched protocol, it's one that people have to be backing towards the exits on for that reason.
DNSSEC works I don’t really get that point.
The “root of trust” problem is hard to solve. I kinda hear the DANE guys’ argument, I’d rather trust one authority than a thousand.
Right, so the question is why we should put a huge amount of effort into implementing and operating a system which doesn't make significant improvements.
> DNSSEC works I don’t really get that point.
It's mostly a layering question: if a new cryptographic algorithm is released or a problem with an old one comes out, browsers can update very quickly. Updating the operating systems and network hardware which implement DNSSEC takes considerably longer. DNSSEC lingered on 90s crypto for ages, key rotations were put off for years, etc. because everyone in this space has to be extremely conservative. That has security implications as well as delaying most attempts to improve performance or usability.
Similarly, browsers can have extensive UI and custom validation logic for HTTPS. A lot of that information isn't present if you use DNSSEC without implementing your own resolver, so you get generic error messages and you don't get control over the policies set by your network administrator. This is especially interesting both as a risk if you don't trust your ISP or for dealing with compromises — if I compromise your DNS server and publish DNSSEC records with a long TTL, your users are at risk until you can get every ISP with a copy to purge the cached records ahead of schedule.
All of those issues can be improved but it's not clear that there's enough benefit to be worthwhile.
> The “root of trust” problem is hard to solve. I kinda hear the DANE guys’ argument, I’d rather trust one authority than a thousand.
This is the best argument for DNSSEC but it's not clear to me how much difference it makes in practice when you're comparing the still nascent DNSSEC adoption to modern TLS + certificate transparency which also catches spoofing and is far more widely implemented.
- An error is presented only if the host offers HTTP _and_ HTTPS. - There's a nice button to just skip it and view the plain HTTP page.
However, I'm not sure whether it'd be best to make this the mode the default for everyone. I imagine regular users would be quite scared/confused when encountering such a message, and that might lead to lots of valuable (mostly older) websites still running plain HTTP to be effectively cut off.
Going through multiple prompts, each and every time someone wants to do what they want, is problematic.
I have gear on my LAN. No SSL, or self-signed, expired certs. I don't care. Ever. Why would I spent 10 seconds setting such things up? They're locked behind a firewall, (a secondary firewall), have no direct network access, and can't even be reached without port forwarding via SSH.
Yet, do you think I can tell my browser "never ever prompt for this again"? Nope. Nada.
I have zero issues with safer defaults, prompting when required. However, the idea that "Firefox knows best" is the sort of asinine behaviour that causes big tech issues all the time.
My point is, this is going to be annoying... not because of the feature, but instead, if I enable it, I'll be cut off from legacy sites by a wall of forever "Do you want to really do this?" with likely 10 clicks of 'yes' and 'ok' and 'i understand', combined with never storing this as a default.
It’s crazy, because somebody must have had to configure something to explicitly let that through (not understanding the purpose of it?) and it just completely breaks it! I’ve tried to leave feedback (there is a link from the portal page) that they’ve screwed it up but it hadn't been fixed the last flight I went on..
With http, a captive portal system will intercept your connection and redirect you to the portal authentication page. Most modern devices deal with it automatically by checking those plain http urls when the network comes up. For example, I think the way it works on iOS is that when you connect to a WiFi network the OS tries to hit http://captive.apple.com which triggers the redirect and prompts you for authentication.
With https, there's no way to have a valid TLS certificate for a random site the user is connecting to (ex: captive.apple.com), so you get a TLS error if you're attempting to connect to an https site while the portal is trying to redirect you for authentication.
Last time I pointed them at one of my sub-domains that still serves plain HTTP to bring up the captive portal (which wasn't trying to charge, or apparently even advertise, the network just insisted you hit it at least once to be told "Hello!" and presumably have your MAC added to the whitelist for a time).
The name "neverssl" might confuse non-techies though. Maybe I'll register something like iswirelessbroken.com for doing the same thing.
If I go to https://neverssl.com/ I get a warning explaining that this site doesn't have a certificate for neverssl.com but only for Cloudfront (presumably where it's hosted)
But if I try to go to http://neverssl.com/ then I get the message explaining that the HTTPS site doesn't work, do I want the insecure HTTP one instead?
If I type "whatever.com", I'm happy with it to try port 443 first
I'm not sure if a http/80 page should be at least HEADed to see if there's a redirect to https/443 before throwing up the "this is not secure"
For those people, it makes sense that typing "http://" would take them to the "https://" site if available. Although they did specify HTTP, it isn't necessarily what they actually wanted.
I think the use case you describe (whilst valid) only applies to a relatively small pool of people. Most people don't really understand HTTP or HTTPS very well. They know it's part of the web address, and some know that "https://" is "secure", but that's about it.
I think it makes sense to direct people to the secure version of the site as much as possible, whilst of course providing a mechanism to switch to the HTTP version if necessary.
If the server says that the thing on port 80 is better served from port 443, then it can issue a 302 permanently move (and a HSTS header to make it stick). If the server offers different content on port 80 and port 443 then the server can do so just fine.
The browser should not try to second guess my explicit instructions.
Having to tell them to click through a non-https warning is almost as bad as having to tell them to click through a TLS warning.
If you offer "free" WiFi behind an annoying Captive Portal chances are I'll just use my 3G service if it works. Now, in my mind do you think I consider you offered me "free" WiFi? No, it was too annoying to use. So your competitor that didn't bother with a Captive Portal site and just posted their WiFi password on a chalkboard - they have free WiFi and you don't.
It's not even hard, all that's needed is to add an "authentication URL" field to DHCP and IPv6 router advertisements.
It certainly solves the login part, it might also solve the register part?
Actually the future is ambient network access. But on the way there, the likely pathway is larger and larger federated network authentication. Most of the world's higher education students/ staff are enrolled into EduROAM, so that it doesn't matter if they're in a classroom in Tokyo or London, the federated system concludes they are a legitimate user somewhere and so they can connect here. In these federated systems there's no use for a "Captive portal" since it could not safely achieve federated authentication, so there isn't one.
To enable it, make sure you have Firefox 83 installed. Then go to about:preferences#privacy and scroll down to the section "HTTPS-Only Mode" and make your selection.
HTTP over VPN is still weaker than HTTPS over VPN. For example HTTPS also handles authentication which HTTP doesn't. If you're outside of your VPN, a MitM could redirect you to http://my-internal-domain.example and resolve its DNS to an attacker's website. Your browser would not understand the difference between this and your actual website in your VPN. It would send all the site's cookies to the evil website, and if Service Workers[1] worked over HTTP, this would actually be a way to completely compromise an internal HTTP website. So it's important not to whitelist such HTTP sites as if they're secure.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...
Of course it's still unsecure from your proxy to the device, but that's a more managable risk
As a developer, should you not work against an environment closer to production behaviours? Otherwise you might miss performance issues (due to different caching behaviours between http/https) or other problems until your code is released.
We serve strongly regulated industries and are subject to in-depth audits by clients on occasion, so perhaps my level of paranoia would be less warranted elsewhere. I'd still HTTPS everything though, even if the potential payoff is small because the required effort is too.
Of course only a trusted few have access to the private parts of the certificate that covers centrally managed things. For local dev instances I suggest having a local only meaningless domain and a wildcard off that,
If we were using per name certs and name leaking were a significant issue we could instead sign with a local CA and push the signing cert out as trusted to all machines we manage.
dom.security.https_only_mode = true
For example: Twitter would periodically refuse to load. You'd have to force refresh Twitter for it to load once again.
I'll try to keep my tin hat stored.
https://www.buypass.com/ssl/products/acme This one appears fully drop in compatible with LE, except that it does not offer wildcards.
https://zerossl.com/ Does offer wildcards, but slightly less compatible, because you need to sign up with a web form, and provide your credentials via the optional ACME EAB feature (External Account Binding), so not all tooling will support it.
What it doesn't do, is force good TLS - there's nothing to stop a site using a weak algorithm, SSLv2/3, or old TLS versions.
It also wrecks network-level caching using appliances like Squid.
TLS 1.0 and 1.1 were disabled in Firefox 78 in June.
It's a very exciting development. It's managed to use the geek "Everything has to be like this!" fanaticism to drag in a mechanism of control.
I wonder which of the Four Horsemen it will be used against first.
This is what I've been missing from chrome!
HTTP is insecure, but will run forever.
This move will literally kill the old web.
HTTPS is not secure because it is centralized and it does not protect against MITM.
HTTP is the foundation of our civilization, it will never go away how much certificate sellers try.
But I would go one step further and point out that HTTP can be made secure manually selectively so that you only secure the things that need security!
HTTPS wastes energy by encrypting cat pictures, and we don't have that much cheap energy left!
But don't worry this will not kill HTTP only Mozilla/Chrome. Chromium will always allow adblockers for free and HTTP, because if they remove it, I'll fork it and add it back in, even if it takes 1 day to compile!
If you IP is a cryptographic identifier:
* It cannot be forged
* Anyone can generate a new one on-demand
* Every packet is authenticated, every packet can be encrypted
* TLS becomes redundant
However, the DNS part remains a hard one. How to securely link to websites you have never seen? Pet names seem like a way to do so. Asking users to type IP addresses isn't really an answer, I think, but I don't know if there's a lot of "basic" users who type URLs in nowadays, they all seem to rely on google providing the right website anyway, or the web browser itself.
It's not like DNS is also our single source of trust nowadays, but at least certificate providers are competent enough to make sure names are resolved correctly.
One option would be to make signed DNS records over a DHT: the root authority "." signs "com", "net", etc, that sign "ycombinator", etc. Publish to DHT, hash-indexed.
Of course, point-to-point connections have their weaknesses as well, it might be interesting to migrate to something like beaker browser (html on top of hypercore, formerly DAT, kind of like mutable torrents in a DHT). At the end of the day, the core issue is: migrating users is difficult if the benefits are not immediately obvious.
And yes, massively adopting anything else would litterally "kill the old web", in the protocol sense. In the community or content sense? Not so sure.
https://yggdrasil-network.github.io/
I built a realtime MMO stack using only HTTP/1.1 for network.
Then build some links without it, and have the compatibility layer the other way. If there are compelling reasons to use the new protocol, it might gain some traction. Maybe we'll turn off IP, but probably not within a century, unless some organization acquires a tremendous amount of control over the Internet.
* Access browser tabs
* Access browser activity during navigation
* Access your data for all websites
So can be pretty devastating if it went rogue, which I doubt.
The nice thing about the new Firefox feature is that the browser won't make any insecure connections unless I explicitly allow it.
It has certainly seemed like HTTPS is the future of the web for the last few years. I love this HTTPS-Only mode and wish it would become the default (with better downgrades and messages for users who may not understand what it means). With the number of HTTP-only sites dwindling, this could result in a faster experience for sites that do not want to (or haven’t figured out how to) use HSTS or HSTS Preload (no redirects from HTTP to HTTPS) and for users who haven’t heard of the HTTPS Everywhere [1] extension.
Also man in the middle attacks seem massively overblown. If you are sitting at home on your private network, the likelihood of a man in the middle attack is stunningly small, such that it's completely irrelevant - especially in regards to the likely trivial content being viewed over http.
I remember seeing this in the mid-2000s when HTML tables were shunned in favour of "divs". I saw people reinventing tables using divs and CSS to display tabular data. Completely missing the point, of course.
This is an example of that for me. How can I possibly trust every single website I visit? It means nothing to connect to a news website, say, and see the "green padlock". Who am I trusting exactly? That I've successfully connected to some load balancer that is operated by "super-trustworthy-tech-news.com"? What's the use in that? Am I supposed to trust them more than some man-in-the-middle just because they own a domain name?
But maybe it's for privacy? If you want privacy you use tor. HTTPS does nothing for privacy when it's the same tech giant on the other end that is collecting all the data. It just means that said tech giant gets exclusive access to that data. Great.
All this does is train people to not care about security and to just trust us to do the right thing because they are too stupid to get it. Sooner or later there will be an event where a government compromises a CA. Bad luck. Some Americans already decided this was a solved problem and that this could never happen.
It's sad to see Firefox continuing to bother itself with solving non-problems while serious bugs go uncorrected for years.
To my understanding CSS Grid is meant to solve this
The green padlock will not turn any unreliable fake news site of your choise in a trustworthy outlet but it does make some guarantees about it being the same site as yesterday (barring security leaks or missed DNS renewal)
AFAIU the elefant in the room is that if your DNS resolver is malicious and points all domains to a malicious IP then https is completely useless.
No it doesn't. Are you thinking of TOFU via public key pinning?
1. managed to obtain a valid certificate from some recognized autority
2. managed to steal a valid certificate for the domain in question from another server
3. managed to convince enough DNS resolvers to point to their IP for a given domain (so to get your traffic and/or pass LE challenges)
and/or other conditions. From an operational perspective it says very little, especially considering the third case where any public wifi network has in most cases total initial control over your DNS traffic.
100% false. HTTPS absolutely protects against that.
1. You are talking to the domain that you think you are. 2. No one else can see the traffic in transit. 3. No one has modified the traffic.
It does not provide any guarantee around the trustworthiness of the domain itself. (Well EV Certs try but as far as I am concerned that is worthless.)
1 and 3 are not helpful in your example of "Am I supposed to trust them more than some man-in-the-middle" but it does help once you establish other trust in that domain. For example a friend sent you the link, or you start using the site regularly.
However personally even just 2 is a tangible benefit when I am using public connections. I very much like the idea that my browser will not send out an unencrypted data without my explicit approval.
You can be assured that you are actually talking to them. That's a big step up from not being able to do that.
In the browser bar, to the left the address, you get an icon of a padlock, with a red slashed circle across it, and the word "Not secure".
Why can't you click on this to get a popup to switch to trying the HTTPS version of the URL?
You can click on it, you get to a read-only tree of information providing info about the site.
If you right click on it, you get a context menu popup about customizing the toolbar.
There is UI for printing a page; I'm pretty sure I've adjusted a HTTP to HTTPS more times than I've printed a web page.
> still do relatively easily by typing ”s”.
You have to position the cursor first; it's annoying.
The idea was to allow http if needed, and alternately allow strict https if needed, in a backwards compatible way (visiting a https:// url would work as before, but visiting secure:// would trigger the strict security for the rest of the session). This way you have the best of both worlds and the user (and server) get choice/agency.
The purpose was to stop MITM. The ability to MITM only requires blocking port 443 and letting the browser fall back to 80; this works even against HSTS because most people will just try other URLs until one works. So you need a way to avoid MITM at least for some specific requests. Banks, e-mail providers, etc would say "type in secure://mybank.com in your browser for strong security".
Another option was a "secure only" button on the browser. It seems they're moving towards this. They've buried it in preferences, which hopefully they'll change to the front UI. But I still think the secure:// links are easier for laypeople.
As always, the issue is adoption. What good is a solution if no browsers implement it? Catch-22, which is usually broken when a giant (google nowadays) decides to break it. And they need incentives to do so. Which is why we need the non-profit Mozilla giant. badly.
https://en.wikipedia.org/wiki/Password-authenticated_key_agr...
Let's say governments ban youtube-dl. The prosecution gets a court order to order CAs to not renew youtube-dl.org. If they're using a Let's Encrypt style 30 day certificate, youtube-dl has 30 days to comply or be soft-banned from the internet.
In conclusion, deprecating HTTP makes it harder for people to get started on the web. How are you going to get certificates for IP address' control dashboard, after all?
But I'd say that anyone that has an operation so big that it dynamically creates and destroys servers to balance load should probably already be paying for their own wildcard cert anyhow.
The game has no log-in or sign-up; no account system. The only potentially sensitive data sent is the nickname the user enters.
> But I'd say that anyone that has an operation so big that it dynamically creates and destroys servers to balance load should probably already be paying for their own wildcard cert anyhow.
The game is free and ad-supported. Dynamically creating and destroying servers is a basic requirement.
Just give each server a separate domain and certificate as you create them. The matchmaking algorithm returns a url pointing to the server.
>How are you going to get certificates for IP address' control dashboard, after all?
By clicking the damn button?
Do you mean a separate subdomain? (A separate domain would be very expensive.) I would need to figure out how to generate and provision certificates, in that case.
I have a side project that plays webradio streams. A lot of them don't have https, some links even are ip addresses and Chrome won't allow to request them on my https site. In the end it forced me to create a stream proxy that I have to host...
I hope it does not get too annoying for backend developers for running things locally because locally you typically don't set up https.
- Links2 (in graphics mode) — main, for fully no-JS browsing;
- Pale Moon* (in Private mode) — main, for browsing w/ & w/o JS;
- Firefox — for curious reasons if target website is not working in Links2 & Pale Moon.
In last year I used Firefox maybe twice, as Links2 & Pale Moon.
As for Android mobile:
- Termux app + Links2 (in non-graphics mode) — main for fully no-JS browsing;
- Prvacy Browser — main, for browsing w/ & w/o JS;
- DuckDuckGo Browser — for curious reasons if target website is not working in Termux/Links2 & Privacy Browser.
P.S. In conclusion, happy to see Firefox is still growing, but every release just brings many "hardcoded" features that, as for me, should not be "hardcoded" in free & open-source browser.
On a personal level, as a developer, I actually find the ban on mixed connections on a web page much more frustrating. It's easy for me to get a cert for nginx for my side project. It's another thing entirely to figure out how to give my application server access to the certs in the "right" way so that the application can terminate wss:// connections. I have to figure it out, of course, because firefox will refuse to connect a ws:// connection on a https page.
The point I'm trying to express is that giving a cert to your webserver is often only the first step in a relatively complicated process of securing all you assets. I wish browser makers would ask about blocking insecure connections instead of doing it by default.
If you're interested in the kind of thing I mean see below:
------------------------------------------------------------------------------------------
So, for example - I'm running a quart server on hypercorn for a side project. Just giving nginx the certs will not, for reasons I don't understand, allow a wss:// connection to successfully connect (returns a 400). The developer conversation around this[1] suggests giving the certs to the application server. I can confirm that this works, but again I don't understand why.
I’m not sure where the auto-switch from "foobar.com" to "www.foobar.com" occurs; if it’s in the browser, ideally Firefox would attempt this auto-correct first and try the HTTPS connection to the corrected location, to minimize the chance of triggering a warning.
I wonder if that will get an update next January. I'd also be more interested in a list of popular sites that don't support HTTPS at all, i.e. the sites that will trigger a warning prompt under this new HTTPS-Only Mode.
Thinks about the implications of this. It will be impossible to host any web content unless you get blessed by a well-known CA (packaged in the platform/browser CA store).
That's why we have Let's Encrypt, right? Yes, thanks to them.
Now imagine a future where Let's Encrypt goes away, for whatever reason.
Now it's impossible to host any web content without getting approved by a commercial CA.
On Windows 10, I use Cold Turkey to block distracting websites. I often have issues with Firefox bypassing the blocks on Windows, ignoring the Hosts settings.
On Android, Block Site addons are not compatible with the new Firefox for Android.
I love Firefox, but some recent changes make me feel that I have less control over my browsing experience.
I hope they don't make things 'default' for our 'protection', rather leave some things to the user to decide as per their preferences.
The most prominent example is ISPs inject ads or messages. Search for "comcast injecting ads" to see some examples.
Edit: and, as others have said, the content can be modified by a man-in-the-middle attacker, which can inject fake content or malware.
What prevents LetsEncrypt from censoring entire domains by refusing to renew their short-lived certificate?
> The majority of websites already support HTTPS
When I run a webserver on a machine I just set up, it has no certificate, certainly not one signed by anybody else, and there's no reason I need to be forced to use encryption with it.
> and those that don’t are increasingly uncommon.
False. Although - for fashionable Silicon Valley companies, "most websites" probably means something like Facebook, Google, Amazon, Wikipedia and a few others.
> Regrettably, websites often fall back to using the insecure and outdated HTTP protocol.
HTTP is "outdated"? "Fall back"? ... Seriously?
I guess we're just lucky FF's share has dropped so far that we shouldn't worry about this stuff. I just hope other browsers don't do this (although - who knows, right?)
And that is the problem.
HTTPS messages need to reform. How about “the website and its data is observable and can be spied on by a third party along the network. Please be careful when entering data.”
Web browsers have no business using DNS over HTTPS, none; nada. zip.
We've opened a can-of-worms ... for malwares to evade further network detection ... effectively with DNS-over-HTTPS.
And, as wonderful as LetsEncrypt is, it's not forever. At some point, they're gonna' get tired of messing with it or it will get taken over by private equity (see .org) and for whatever reason, it won't work any more.
And sure, that's always been true, new stuff obsoletes old and things fall by the wayside. But my current browser can access modern websites as well as sites from the dawn of the Web. But FireFox 85, 87 or 90 will probably make https mandatory -- and that amazing continuity is gone.
• https://news.ycombinator.com/item?id=21912817
Some websites are the equivalents of billboards.
The cost is dependence on a central authority that can make your site inaccessible in a whim.
It's now practically impossible to write a new web browser from scratch, unless you're a mega corp with endless resources and a grudge against Google, and they're still adding more complexity every day.
Of course a perfect protocol where nothing needs to be added later would be great, but that's not very realistic.
The amount of APIs that need to be implemented to be considered even a basic web browser is so huge that it's not an approachable project for just about any organization, and as an individual it's just not possible.
Then there is the case of all the old computers that either lack the processing power or support for modern algorithms.
JS HTML CSS WASM etc ...all need to be tamper-resistant.
Processing power, meh. More of an issue is older devices not getting the updates to software for the newer algorithms, and not getting the updated certificates. I got rid of a perfectly good tablet for just this reason. A bit slow perhaps but workable.
Because all images are of cats or it's easy to tell when it's sensitive and when not.
Every page needs HTTPS because you can't trust any content sent to you over HTTP. You don't know if it's "just a cat picture."
Also I'm starting to suspect the downvoting feature is used a sadistic tool, just keeping karma up so you can punish people.
If you're not familiar with this omnipresent class of exploit, I wouldn't hope for many people on HN to take your advice on whether a security measure is needed or not seriously. Even if your comments were underlined and flashing on the page instead of grayed out.
> 2.5 Why not just use a subset of HTTP and HTML?
> [...] The problem is that deciding upon a strictly limited subset of HTTP and HTML, slapping a label on it and calling it a day would do almost nothing to create a clearly demarcated space where people can go to consume only that kind of content in only that kind of way. [...]
The protocol itself has very strong opinions on what is allowed and what is not. It is simple but mandates TLS (so, not simple), because authors think encryption is important but other things are not. It is also deliberately non-extensible.
Not saying it is a bad thing, I mean, they didn't hurt anyone. But that protocol is clearly intended as a rallying point for like-minded individuals rather than something for everyone to use.
I have no idea of the importance between 83 vs 80.
Therefore version 83 is 3 versions ahead of version 80. Note that "version" in this context is shorthand for "major version". It does not include minor patches that only fix a bug or security issue.
Each new major version of Firefox comes with new features and may occasionally deprecate or remove old features. They are currently released roughly every 4 weeks.
> For the small number of websites that don’t yet support HTTPS, Firefox will display an error message that explains the security risk and asks you whether or not you want to connect to the website using HTTP. Here’s what the error message looks like: ..
That suggests it will ask you for permission, presumably with a "always remember this choice" option.
> Firefox asks for your permission before connecting to a website that doesn’t support secure connections.
"browsers generally treat localhost and/or 127.0.0.1 as secure origins in themselves anyway"
> Locally-delivered resources such as those with http://127.0.0.1 URLs, http://localhost and http://*.localhost URLs (e.g. http://dev.whatever.localhost/), and file:// URLs are also considered to have been delivered securely.
So all kinds of significant enhancements in 83, including HTTPS mode, might essentially be missed by most users. (Heck, I only knew because of this HN post.)
Why do programs insist on “hijacking” things? Release notes seem particularly vulnerable to this, e.g. iPhone apps love to have “notes” that don’t actually tell you anything at all, just marketing-speak.
Perhaps one of the downvoters can explain why the implied opinion "Nobody should be able to access your site without clearance from a third-party gatekeeper" belongs on a site called "Hacker News."
And no, it won't be opt-in for long. Read the rest of the page: "Once HTTPS becomes even more widely supported by websites than it is today, we expect it will be possible for web browsers to deprecate HTTP connections and require HTTPS for all websites. In summary, HTTPS-Only Mode is the future of web browsing!"
This is something you should be speaking up against.
HTTPS-only is about forcing all traffic to be encrypted by banning clear-text traffic. I've been using the "HTTPS everywhere" extension for years and it's great.
lets say a simple website which someone uses to display some holiday pictures. why would we need https here, if there is no login or anything like that?
it just adds an extra hurdle for not so tech-savvy users and increases the trend to abolish small private websites.
Imagine if those pictures have been replaced by something else. If you can't think of a long list of replacement images that could be very useful for a spearphishing attack, then you're not having enough imagination.
This attack could also be used to get the poster of the photos in trouble.
The day where certs are no longer freely obtainable is the day another self governed free TLS provider will appear and force their way into the market by providing installers to inject CAs into system cert stores.
There’s always TOR if you disagree.
Both leading to further centralisation of the Internet.
> by providing installers to inject CAs into system cert stores
That's already pointless on Android, user-installed CAs are ignored by default unless an app developer opts in to using them.
Once we go down this path there's no turning back to the user-centric Web of the 1990s / 2000s
And? App developers should opt in to ignoring transport security. I’m sure a bunch of Android shitware attempts to install CAs either via user interaction or exploitation.
> Once we go down this path there's no turning back to the user-centric Web of the 1990s / 2000s
The landscape we live in now is very different to then. I’m all for a free web, but not at the cost of security. The web is now a multi billion trillion dollar industry. Weakening security just so Bob can see Alices’ holiday pics in situation where Alice can’t figure out letsencrypt, is frankly unhinged.
If you want a ‘free web’ you’re welcome to disable any HTTPS enforcement and disable TLS cert checking entirely. Hell, fork a browser, be very clear about the security weaknesses and publish on github if you feel that strongly, I’ll even star it for you.
Maybe your web service is, but mine isn't. Mine is a specialized embedded device server that now has an expiration date for no reason on God's green earth.
Static content does not need https unless there are reasons for privacy or MiTM concerns related to the nature of the content itself.
This is not how this was supposed to work. This is not how any of this was supposed to work. But it's hard to voice any objections over the proverbial thunderous applause.
Banning clear text might work for browsers but it would disable ACME clients that rely on plain http to initiate a certificate request from Let's Encrypt.
I didn't vote down, but ironically this is news to real hackers who will have a harder time doing mitm downgrade attacks once this is widespread.
I believe that web browsers should alert users if a website uses a less secure protocol than "nearly all" of the rest of the websites they visit, for some value of "nearly all".
It's not preventing the user from visiting, just saying "heads up, the assumptions you make about the websites you visit don't hold for this one."