Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chrome’s address bar will use https:// by default

blog.chromium.org

Post reply on HN
Print view View original

171–180 of 463 posts

Re: Chrome’s address bar will use https:// by default

#171

Post by terramex »

fluidcruft wrote: post #51
pornel wrote: post #13

That makes a lot of sense. HTTPS adoption is now very high[1], and this might push it a little bit further for sites that don't redirect to HTTPS automatically. I've been using Firefox in the experimental HTTPS-only mode, and the web is quite usable without cleartext HTTP. [1] https://transparencyreport.google.com/https/overview It's not a big change from security perspective though. HTTP requests shouldn't be gettin…

The biggest problem I'm having is that our edge firewall doesn't play nicely with it for some reason. I get these random websites that refuse to work in Firefox, but they always work fine in Chrome. And it's not certificate errors, it's just "connection reset by peer". I'm not entirely sure how it's working, but I've seen a few other people with these issues at the mozilla bug tracker and it's always just sort of eit…

I've had exactly the same issue for 2 years and I have narrowed it to dropped packets on the network.

I'm connected to internet through WiFi bridge that periodically has transmission issues (over 200 meters distance) and if average amount of transmitted packets (I can see it in antenna panel) is anything else then 100% and negotiated speed is anything lower than maximum 54 Mbps then neither Safari nor Firefox will be reliable and I will get "connection reset by peer" error that will go away after refresh. Chromium-based browsers work fine, I'm using Vivaldi with no issues. On Windows tools like curl and wget work with no issues but not on macOS - it looks like a deeper problem with its network stack that Chromium browsers somehow avoid.

It might be a correlation without casualization, but I also was unable to find a good way to debug this issue.

Re: Chrome’s address bar will use https:// by default

#172

Post by jiri »

simias wrote: post #111

I 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…

I agree. Am I right - would it be solved by prefering https for all ip addresses except 10.0.0.0/8, 192.168.0.0/24 and 172.16.0.0/16?

Re: Chrome’s address bar will use https:// by default

#173

Post by [deleted] »

squaresmile wrote: post #52
bmicraft wrote: post #47

Earlier quoted context omitted.

What's the point in having the protocol spelled out when you have the lock icon anyways? I don't think this would be a useful default.

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.

[deleted]

Re: Chrome’s address bar will use https:// by default

#174

Post by cblconfederate »

squaresmile wrote: post #52
bmicraft wrote: post #47

Earlier quoted context omitted.

What's the point in having the protocol spelled out when you have the lock icon anyways? I don't think this would be a useful default.

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 don't think it's niche at all. Why else would the address field be editable then

Re: Chrome’s address bar will use https:// by default

#175

Post by tobobo »

Spivak wrote: post #154
simias wrote: post #127

Earlier quoted context omitted.

I develop broadcast TV equipments which are often rented all over the place for short amounts of time, often don't have any direct internet access etc... I simply cannot make any assumption about the network these devices will run, and can certainly not rely on any sort of DNS validation. Virtually 100% of the time the devices are addressed directly by IPv4. I really can't think of a solution for this situation. For…

I think you would like how Plex did it. https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Interesting. I’m currently working on an “IoT” device and this seems like it could theoretically work. One concern I have is that there’s an initial step where the device creates an access point so that you can enter wifi credentials that it will use to connect to your home network. In this case, the device connecting to the local server will not have internet access, and would not be able to resolve the plex.direct domain. Maybe I can rely on the browser dns cache, but that seems pretty sketchy...

Re: Chrome’s address bar will use https:// by default

#176

Post by tony101 »

simias wrote: post #111

I 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…

> "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 decide to proceed, or just go with good old HTTP but then you hit all sorts of limitations, and obviously zero security."

How about what Plex did for its self-hosted media servers?

"First they solved the problem of servers not having a domain name or a stable IP (they are mostly reached via bare dynamic IPs or even local IPs) by setting up a dynamic DNS space under plex.direct"

"Then they partnered with Digicert to issue a wildcard certificate for *.HASH.plex.direct to each user, where HASH is - I guess - a hash of the user or server name/id."

"This way when a server first starts it asks for its wildcard certificate to be issued (which happened almost instantly for me) and then the client, instead of connecting to http://1.2.3.4:32400, connects to https://1-2-3-4.625d406a00ac415b978ddb368c0d1289.plex.direct... which resolves to the same IP, but with a domain name that matches the certificate that the server (and only that server, because of the hash) holds."

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

Re: Chrome’s address bar will use https:// by default

#177

Post by capableweb »

fluidcruft wrote: post #170
capableweb wrote: post #126

Earlier quoted context omitted.

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 'm pretty confident that shows up as a certificate error with it's own scare page, not connection reset. Usually on cert errors you can click through all the warnings and accept the risks to connect anyway. Connection reset is just a complete dead end. 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 site…

> I 'm pretty confident

Sounds like a engineers way of saying "I think it is like this, but I should double-check just in case" because who knows what the browser can show when something different happens?

I don't know, I would check it at least.

Re: Chrome’s address bar will use https:// by default

#178

Post by MaxBarraclough »

franga2000 wrote: post #169
simias wrote: post #111

I 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…

Yeah, there really needs to be a "secure, but not trusted" mode. My suggestion would be add a "trusted-only" TXT DNS entry that a browser could check when presented with an untrusted connection. 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,…

On the face of it, it sounds simple enough: special treatment when the IP address is an IETF-designated private IPv4 address (e.g. 192.168.x.y).

Is there some reason this wouldn't work, that I haven't thought of?

Re: Chrome’s address bar will use https:// by default

#179

Post by flotzam »

marcosdumay wrote: post #98
flotzam wrote: post #28

Is there a way to get exactly this new Chrome address bar behavior in Firefox? I.e. I want Firefox to follow plain http links same as before, but if I type in example.com it should expand to https://example.com

AFAIK, Firefox has worked exactly like this for a long time. There is probably some way to disable that behavior, and when you type a site, it offers an http suggestion for you to reach easily, but the default is https.

Firefox 86 falls back on HTTP transparently (e.g. try it with sane-project.org). I'd like to disable that, but without also adding a (stateful, fingerprintable) confirmation step to follow HTTP links.

Re: Chrome’s address bar will use https:// by default

#180

Post by topkeks »

OskarS wrote: post #49
melomal wrote: post #25

Earlier quoted context omitted.

> HTTPS adoption is now very high[1] This is simply because they told SEO's that HTTPs takes precedent and effects ranking - if you want mass adoption of anything then just tell a bunch of SEOs that rankings will be effected (AMP is one that has thankfully not won the fight). Google passed it off as security but I cannot believe this to be the case when you see the shit that litters the Play Store.

What are you even saying? Are you implying that HTTPS is a bad thing because of... SEO? The Play Store? AMP? What is your point exactly?

Anti-google neckbeards are ready to throw TLS away in their blind rage. What's new?
Post reply on HN