This is cool, I get tripped up every day by accidentally navigating to HTTP sites just because I typed them into the browser, and there's literally no downside—if the site doesn't support HTTPS, the redirect is transparent to the user.
Chrome’s address bar will use https:// by default
221–230 of 463 posts
Re: Chrome’s address bar will use https:// by default
#222I 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,…
There's no such thing as "secure, but not trusted". The security depends on the trust. That isn't just how TLS works; it's how all secure key exchanges work.
Re: Chrome’s address bar will use https:// by default
#223I 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…
Perhaps something like bluetooth pairing would work, where you enter a code into your browser to authenticate?
Re: Chrome’s address bar will use https:// by default
#224I've said it many times, but nobody seems concerned: Certificate authorities are being used as tools of censorship by oppressive regimes. Until a central-authority-free alternative exists, the move to HTTPS is bad for a free world.
I understand that centralised CAs are not ideal, but how is HTTPS by default any worse than plaintext?
Re: Chrome’s address bar will use https:// by default
#225Earlier 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,…
There's no such thing as "secure, but not trusted". The security depends on the trust. That isn't just how TLS works; it's how all secure key exchanges work.
s/secure/encrypted/ ?
Re: Chrome’s address bar will use https:// by default
#226Earlier 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,…
There's no such thing as "secure, but not trusted". The security depends on the trust. That isn't just how TLS works; it's how all secure key exchanges work.
That's exactly how mail works between servers though. Granted, it's about semantics, but virtually all mail servers accept TLS connections without the need to check cert validity of their respective counterparts.
Re: Chrome’s address bar will use https:// by default
#227I 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…
Probably, and I have found myself in the same situation btw, the best solution would be a fork of one of the browsers, that would (for example) only browse to addresses in the user's hosts file. That way, it could still piggyback all of the web interface machinery of a modern browser, but the things like "omg that's a self signed certificate you will die now" warnings can be safely removed, since the browser will only be able/willing to go to addresses in the user's hosts file. Just a thought.
Re: Chrome’s address bar will use https:// by default
#228Earlier quoted context omitted.
I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved. If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
The problem is that there is no way to deal with certs on a local network, but the OP would like to be able to use https anyways; http might be considered too insecure for their usecase
What I do is buy localme.xyz and get a wildcard cert via DNS validation. This way you get SSL for offline devices. But you need to update the cert periodically.
Re: Chrome’s address bar will use https:// by default
#229Earlier 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…
> 1. Create your own root Certificate Authority. 2. Ensure that the security around your new root CA is watertight, so that if your environment ever gets compromised, someone can't generate a new *.google.com or *.yourbank.com certificate signed by your CA and then MITM your connection.
3. use cross signing with name constraints to not have this problem
Re: Chrome’s address bar will use https:// by default
#230Earlier quoted context omitted.
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've literally never seen anybody use a domain name to address my devices, only a simple IPv4. That already makes it a nonstarter, but let's entertain the idea. Maybe I can convince my clients to change the way they work, they generally love that. Just going through the trouble of having the customer mess with their OS's DNS resolver to connect to the device is ludicrous. Can you even do it on Windows without having…
I don't think Let's Encrypt is going to be the right use-case for you then. I think your best bet is to work with another CA to get your company an intermediate cert that you can use to issue longer certs that include ip addresses in the SAN.
Then it's just a matter of the devices connecting to the internet at least once a year and doing a very simple "Hey, I'm $device and using $address. Issue me a cert plz."