Earlier quoted context omitted.
It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offlin…
> IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. According to the post this shouldn't be an issue.
Chrome’s address bar will use https:// by default
161–170 of 463 posts
Re: Chrome’s address bar will use https:// by default
#162Earlier quoted context omitted.
One thing that was quite annoying to me is the URL changing under my cursor on double-click if the protocol is hidden. However, I can see that editing the URL is a niche use case. Fair enough.
I hate that editing URLs is practically impossible in Chrome on iOS (not sure about Android or other iOS browsers). There seems to be no equivalent of arrow keys to navigate around inside the address bar. If I screeenmash enough I think I can sometimes get it to go to the very start or end of the URL, but anything in between is hopeless. (Posting this partially in hopes that someone tells me how to do it to prove me…
Re: Chrome’s address bar will use https:// by default
#163Earlier quoted context omitted.
It seems like we should have something like known_hosts for ssh, yeah. As long as it’s trusting one domain at a time (not a root CA), would it really be /that/ bad? This and browser vendors being overbearing about extensions (I know they’re powerful) gets me down.
You used to be able to add your own certificates to a device's certificate store. Nonadjustable certificate stores complement planned obsolescence, and help split the market into consumer and enterprise devices, that latter of which you can charge a premium for.
Chrome uses the OS store (for now: https://www.chromium.org/Home/chromium-security/root-ca-poli...) which you can also add certs to.
Re: Chrome’s address bar will use https:// by default
#164Re: Chrome’s address bar will use https:// by default
#165I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…
The actual problem though is fascinating and there is a ton to unpack. For one, the internet was always supposed to be zero-trust. Security-by-NAT was an accident not a feature. And IPv6 enshrines this reality (and it breaks my heart when I see tech companies trying to make IPv6 work like IPv4 in the home). The privacy problem is not really an issue if everything is appropriately firewalled and communicating securely. And as you mention, half the IoT things out there only use a central server to get around what is ultimately a problem NAT introduced: devices don't have public IPs and aren't 1st class internet citizens.
Here's how it's supposed to work:
Your ISP delegates you an IPv6 prefix. As the gateway to your home site, your router advertises the public prefix, as well as a ULA prefix to your home devices. Devices construct both permanent and temporary IP addresses from the public and universal local prefixes (at this point a device that needs public internet access has 4 IP addresses). That's just IPv6 so far but the point is that devices have multiple addresses, ones for public communication and ones for local communication.
Once you have the setup above you can do this:
Your ISP provides you a domain (optionally you purchase your own vanity domain, of course) and their nameservers delegate to your gateway device (or possibly some other one, but conveniently your gateway) as the nameserver for your home site. After a device comes online it dynamically registers its desired hostname with gateway, which will now respond to DNS queries with its address. The gateway should also serve PTR and SRV records for your site unicast DNS-SD style. Your nameserver can serve the public record if the request comes from a public IP and the ULA record if the request comes from that prefix. All public traffic stays public and all local traffic stays local.
Since your devices now are publicly routable, they get certs using ACME. If you want to run local ACME on your ULA network, go for it, but you'll continue to run into the original problem that browsers aren't configured to use your local CA by default and getting users to bootstrap that is essentially impossible. In that vein I do wish there was a way to start a browser window for "local" browsing where it only trust one CA (your local one) and thus isn't mixing public and local security domain concerns.
If devices don't want to communicate on the public internet because that's a privacy or security concern, then they simply don't provision themselves a public-prefixed address or add a public DNS entry, etc.
In short, NAT killed the internet and we're still recovering from it.
Re: Chrome’s address bar will use https:// by default
#166Earlier quoted context omitted.
> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower…
I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context , you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing…
Re: Chrome’s address bar will use https:// by default
#167Earlier quoted context omitted.
It's a huge security improvement. The HTTP->HTTPS redirection is not secured in any way. [edit: it's not really because it falls back]
The info "is https available" is not secured either. The ISP can just block any packet on port 443 and force http that way. It would break links but wouldn't break people entering the address via the URL bar. A real improvement in security would be Google caching the data, and either offering it via a custom API or just signing it and appending it to their 8.8.8.8 DNS responses. Per default, Chrome already sends the…
Re: Chrome’s address bar will use https:// by default
#168example.com
We're finally getting there! Now just a decades to go and we'll reverse the order to get
com.example
After which we'll wait a couple of decades to decide we don't need TLDs as ICANN is instead just given a free pass to print any amount of money they want without that silly distraction. Then we'll be at just:
example
which is just one step from the final solution which is that no URLs will be needed because the browser will just open up to Amazon who after final approval of their purchase of Google will at that point own not just the internet but the entire world.
Re: Chrome’s address bar will use https:// by default
#169I wish there was a solution for those of us who develop web interfaces for embedded products designed to live on LAN, often without any internet access and no well defined domain name. I'm all for HTTPS everywhere but right now for my products it's either: https with self-signed certificate, which basically makes any modern browser tell its user that they're in a very imminent danger of violent death should they deci…
HTTP: gray broken padlock HTTPS+Cert: green padlock HTTPS+no cert: gray padlock HTTPS+no cert+trusted-only: red broken padlock
Any complaints? No? Ok, let's make it a standard! Oh wait... we're not in control of the standard, it's the world's largest cloud hosting, service and product providers. Intranets and locally-accessible embedded devices are a threat to their business model. Fuck.....
Re: Chrome’s address bar will use https:// by default
#170Earlier quoted context omitted.
Try comparing the packet conversation using Wireshark to see if Firefox is doing something different from Chrome.
Someone please correct me if I'm wrong, but I do think Firefox ships their own root certificates with their browser, while Chrome uses the system ones. It's possible fluidcruft's employer has installed new root certificates so they can analyze/inspect the traffic through their network and Chrome is happily rolling along, while Firefox does not like it because now the connection effectively has been broken.
I have pondered whether there's some way for the firewall to have a whitelist of sites that it allows without SSL MITM and otherwise sends reset for unknown SSL sites unless the firewall's MITM certificates are used. Our IT might be paranoid enough to do that.
I don't have any evidence that the firewall does any MITM other than I found it listed as a feature that can be configured on the firewall's website when I've been googling. But even then the error people complain about is bad cert not connection resets. I have tested with Chrome on systems that IT cannot have injected certificates into and they do work. I do know that I can access my home server's let's encrypt site using firefox and chrome without problems and the keys are correct. So it's not really high in my suspicion list.
Anyway it looks like I need to learn how to packet sniff.