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

131–140 of 463 posts

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

#131

Post by wjrtyjw »

boardwaalk wrote: post #118
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…

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.

Isn't this the default behavior of most browsers? Access an https service with an untrusted tls certificate, the browser throws a warning and offers a way to permanently trust the certificate.

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

#132

Post by freeone3000 »

boardwaalk wrote: post #118
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…

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.

Known_hosts works by having a list of trusted public keys. The TLS equivalent is adding the endpoint's TLS cert to your local trust store.

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

#133

Post by GekkePrutser »

capableweb wrote: post #126
nitrogen wrote: post #73

Earlier 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.

This is most likely exactly what's happening.

On Windows you can choose to use the system store though. On other platforms you can only use the internal one

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

#134

Post by londons_explore »

simias wrote: post #127
liveoneggs wrote: post #117

Earlier quoted context omitted.

let's encrypt with *.lan.mydomain.com via DNS validation, installed all over where needed, and annoying to update every 90 days because it's in weird/internal/non-standard places :)

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…

DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device.

All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.

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

#135

Post by superkuh »

patrickmcnamara wrote: post #22

I'm surprised this took so long. I tried to find an extension recently that could completely block HTTP but I couldn't find anything.

What you've described is, of course, what Google wants in the long run. For corporations making money on the web HTTPS is required and it makes a lot of sense.

The problem is the web isn't just corporate sites involving money or private information. But if a browswer, or individual, begins blocking HTTP sites what they're effectively doing is saying, "Only sites approved by corporations should be visitable." This is a result of only corporations (no matter how non-profit or currently benevolent they are) being certificate authorities. A human person can't be a certificate authority. And that is a terrible blow to freedom on the web.

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

#136

Post by j1elo »

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…

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 offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all!

It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow.

EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host.

[0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

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

#137

Post by throwaway287391 »

Symbiote wrote: post #105
throwaway287391 wrote: post #76

Earlier quoted context omitted.

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…

Are there ways to get the keyboard to have cursor keys, or something similar? I use the Microsoft Swiftkey keyboard on Android, and there's a setting which makes holding the space button activate gestures for up/down/left/right. (i.e. hold space and move small amounts left/right.) If you have enough screen space, I think you can add real arrow keys. But I'm not sure you can change the keyboard on iOS.

Wow -- life-changing, thanks! On the native iOS keyboard, hold down spacebar and (without lifting your thumb) swipe left/right to "scroll around" within a text field (at least in the Chrome address bar, but presumably anywhere). Amazing that after 5+ years using iOS I'm still discovering these hidden but basic features...

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

#138

Post by heavyset_go »

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…

> 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.

If you go the self-signed route, you'll encounter devices that simply won't work with them, especially IoT devices. If you got the HTTP route, you'll still encounter devices that simply won't work with them. For example, you can't cast an HTTP resource from Chrome or Chromium to a Chromecast, even if it exists on your LAN.

As long as there are devices that you can't insert your own certificates into their certificate stores, this will be an issue.

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

#139

Post by sumtechguy »

danShumway wrote: post #80
colllectorof wrote: post #32

Earlier quoted context omitted.

>HTTPS adoption is now very high[1] I posted this in a separate comment and I will post it again. https://certbot.eff.org/hosting_providers HTTPS adoption is hard enough that the wast majority of shared hosting providers haven't automated cert provisioning and are delegating this process to their users. The push towards forced HTTPS has significant costs, which most people in this filter bubble don't want to honestly…

> The push towards forced HTTPS has significant costs, which most people in this filter bubble don't want to honestly discuss. I agree, but I'll push back by saying that delaying HTTPS adoption and getting lax about it has a much higher cost -- and that is similarly a cost that most people pushing back against HTTPS either downplay or refuse to acknowledge. And more than that, those critics have shown that they're no…

To add to that https I think is one part of the puzzle.

This weekend I watched a bunch of scam bait calls. Very amusing to watch them get taken down. But there are people out there mailing 20k in fedex boxes to scammers. All because their browser said 'your balance is 20000 and I transferred too much to the account, could you mail that back to me so I do not get in trouble?'. It is a very human attack using a combination manipulation, fear and compassion. The bottom line is these people unknowingly allowed people to open the debug console in their browser to change things.

What I have been trying to figure out in my head is how do we do a digital watermark on data presented to the user? How do we at a minimum tell the user their data has been manipulated? You can have all the TLS on every level but at one of the most important ones there is nothing. A scammer can open a debug console on a https presented page just as much as a http page.

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

#140

Post by scruple »

londons_explore wrote: post #134
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…

DNS validation can entirely be done by a server on the internet, which does all the stuff necessary to get the certificate, and then gives the certificate to your end user device. All the end user device needs is a connection to the internet once per 90 days. The vast majority of networks have sufficient network connectivity for this.

I worked in embedded radios for the broadcast industry and SCADA applications for a spell and dealt with the same problems that the GP is describing. Many of these systems are composed of networks built on top of radio modems. It is very common that these devices can't reach the Internet...
Post reply on HN