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

271–280 of 463 posts

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

#271

Post by j1elo »

shadowgovt wrote: post #212
j1elo wrote: post #136

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…

Is it the case that self-signed certs don't work in iOS at all? I'm looking around, and I appear to see tutorials for how to properly configure one in iOS. https://medium.com/collaborne-engineering/self-signed-certif...

I'm talking about user access. At least other browsers still allow it (but that's also prone to change at the whims of the developers), but in Safari for iOS the page will fail silently and won't load, with absolutely no feedback as to why.

Having to install custom-made Root CAs into all and every client device doesn't sound to me like an ideal solution...

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

#272

Post by jeroenhd »

canadaduane wrote: post #246

The devcert tool (and its corresponding devcert-cli command-line interface) is very handy for creating a local root certificate authority that you control & your device trusts: https://github.com/davewasmer/devcert https://github.com/davewasmer/devcert-cli Benefits include no scare-screen, and being able to switch off all of your personally-generated certs at once by revoking the root auth.

IP addresses and localhost are still exempt from these changes. For development purposes, nothing serious should change; localhost is already a secure context.

I'd very much watch out for using automated tools like these. Many browsers do not check certificate revocation and this leaves your browser open to some extensive MitM attacks. If you use this, you should probably create a second profile (firefox /p to create and pick one) so your normal browsing won't be affected.

In my opinion, it's easier to just type "thisisunsafe" into the warning page once if you use it for developing. If you're demoing your application, putting it on a server with a Let's Encrypt cert shouldn't be too hard either.

I'm sure this has its uses, but I just can't figure out what they would be if you do not wish to take huge security risks.

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

#273

Post by kazen44 »

MaxBarraclough wrote: post #178
franga2000 wrote: post #169

Earlier quoted context omitted.

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?

well, rfc1918 addresses just specify which ranges should not be advertised into the default free zone. (aka, the internet routing table). It says nothing about if a network is LAN or not.

One could totally build a network with globally routed addresses, and not announce those addresses to the rest of the world.

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

#274

Post by varispeed »

mikeiz404 wrote: post #218
davidkhess wrote: post #184

Earlier quoted context omitted.

Here's an approach I've used before successfully. It's not perfect but it's better than nothing. 1. Create your own root Certificate Authority. 2. Create a script using your favorite language and libraries that will create a new certificate for each device something along the lines of "myiotdevice-AABBCCDD.local". The AABBCCDD needs to be some sort of serialized number that's assigned during manufacturing and won't b…

That should work but trusting a root cert from a third party makes be a bit wary depending on how it is done. If the certificate is scoped to only that domain or to only domains used by that user then I suppose it's OK but there is currently no way to enforce this, that I am aware of, without the user understanding and inspecting the certificate. Thinking out loud here: It would be neat if browsers supported some for…

I think there is the solution - to support scopes for certificates, but I am afraid big companies won't be keen on donating resources to implement that.

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

#275

Post by shadowgovt »

j1elo wrote: post #265
easton wrote: post #236

Earlier quoted context omitted.

Yeah, I don't know what OP is talking about, I'm using one on my iPhone right now. Enterprises deploy them all the time. It is true, that in recent versions of iOS (in the past five years or so), you have to install the certificate in Safari, then go to Settings->General->About, scroll all the way down, and manually trust the certificate (to ensure you really know what you're doing by enabling it). And iOS doesn't ma…

If you are talking about installing the Root CA in the iPhone, yeah. That's how I do it in my development devices. But for a user, iOS Safari (not Safari for MacOS) doesn't show any certificate warning that the user can accept, like other browsers. In fact, it just fails absolutely silently. You'd have to connect it to a Mac and open up the developer tools on the desktop's Safari, to see the errors that are being pri…

Unfortunately, user behavior testing shows those certificate warnings are a threat vector. There's a reason the browsers have been moving towards the exits on trusting the user to understand the security model enough to override the trust breakage.

Chrome pops a warning, but (with a few exceptions) doesn't let you just navigate through it (there's a secret key sequence you can type to override it, but it's both purposefully undocumented and periodically rotated to make it something that you can only know if you have the chops to read the source code or consult the relevant developers' forums).

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

#276

Post by jessriedel »

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…

As someone with a WordPress blog and static personal site with zero security threats, these changes don't help me at all. They just force me to pay an $150 additional per year to my hosting provider or spend at least a full day figuring out how to reconfigure my SSH certificate to one of the cheap options.

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

#277

Post by shadowgovt »

j1elo wrote: post #271
shadowgovt wrote: post #212

Earlier quoted context omitted.

Is it the case that self-signed certs don't work in iOS at all? I'm looking around, and I appear to see tutorials for how to properly configure one in iOS. https://medium.com/collaborne-engineering/self-signed-certif...

I'm talking about user access. At least other browsers still allow it (but that's also prone to change at the whims of the developers), but in Safari for iOS the page will fail silently and won't load, with absolutely no feedback as to why. Having to install custom-made Root CAs into all and every client device doesn't sound to me like an ideal solution...

Unfortunately, since one is breaking the SSL trust model, that's probably the right solution. Not unlike having to explicitly enable "Developer mode" before a whole host of security-breaking options are available.

Actually, that's one solution Apple could consider: if a user has enabled Developer Mode on a given iOS device, allow the trust model to be broken with an "Are you sure you know what you're doing?" button instead of a silent failure.

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

#278

Post by qwertox »

j1elo wrote: post #136
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 offlin…

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

I constantly have issues with this address bar hiding the scheme and even the www.

One issue is when I quickly want to select some parameters or delete parts of the url in order to "up" one level.

What drives me absolutely insane is their inconsitent autocomplete functionality. Sometimes I end up at googling "examp" instead of navigating www.example.com, which was a page I already had visited and therefore showed up as the domain which was autocompleted inside the address bar. Sometimes pressing enter autofills the address, sometimes it googles the halfway typed domain. If I tab the halfway typed domain, it always completes it and an enter will navigate to it.

There is some strange difference in entering a domain and performing a search, something feels off. I can't exactly tell what it is, but sometimes I end up with submissions which I did not intend.

Also something with pressing the down-key in order to select the topmost entry, the one which gets selected with tab, it just gets skipped when I use the down-key.

Another thing is if I want to query "Raspberry Pi disable wifi" or something which begins with "Raspberry Pi", that I then get suggested the URL raspberry.org, a domain which I have often visited, and am forced to type through the entire word Raspberry in order for the URL-functionality to get aborted and have it switch over to googling mode. Maybe there is a keyboard shortcut or something which would help me out, but it simply isn't intuitive.

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

#279

Post by superkuh »

Ajedi32 wrote: post #182
superkuh wrote: post #135

Earlier quoted context omitted.

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 human person can't be a DNS registrar either. TLS certs aren't a stamp of approval; they're just a statement saying "we've verified that this public key belongs to the owner of this domain".

That's true, but I can still type in an IP address and communicate with any webserver I want on the entire internet.

I guess you don't remember in 2018 when Comodo revoked sci-hub's TLS certs under corporate political pressure. This style of revocation combined with HTTPS only browsers is effectively a block that can't be bypassed. I am not saying that the DNS system cannot be used for political attack. It obviously can. It was used as such against sci-hub before they started attacking via the cert provider. What I am saying is that blocking HTTP in the browser makes the consequences much, much worse.

It greatly increases the incentives for revoking TLS certs for political reasons due to increased effectiveness. The cert authority doesn't even have to be malicious. All they have to do is be "law abiding" relative to some country with a bad set of laws.

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

#280

Post by alexchamberlain »

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…

Would something like an electron app allow you to embed an alternative root/public certificate?
Post reply on HN