Goodbye, ssl stripping attacks, I'll miss you so much! We knew this day would come sooner or later
A protocol downgrade goes to http still, so MITM attacks could still happen :(
Chrome’s address bar will use https:// by default
391–400 of 463 posts
Re: Chrome’s address bar will use https:// by default
#392Earlier quoted context omitted.
You can set up the users' machines so that they trust your certificate.
I have tried to do just that but ran into all kinds of difficulties: 1. Overhead: I have 5 devices that I own 3 of my wife and a smart TV. Setting all this us takes a lot of time, even if it worked fine. 2. What about visitors to my home, that I want to give access? They need the cert as well together with lengthy instructions on how to install it. 3. How do I even install certs on an iPhone? 4. Firefox uses it's own…
I bought a domain For use on my local network. I use letsencrypt for free certs, and I have multiple sub domains hosted under it. It works very well and wasn’t that hard to setup. It’s actually better organized and easier to use than my old system since I had to take the extra step up front to organize it under a domain.
Re: Chrome’s address bar will use https:// by default
#393Earlier quoted context omitted.
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…
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?
HTTP does not solve the problem if you still want your traffic encrypted in transit.
Re: Chrome’s address bar will use https:// by default
#394I 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…
A hypothetical solution would be to stick with the DNS SD / avahi concept and use domains ending in .local.
That would have the benefit to be able to create a CA for that domain that can cross-sign your certificates in order to prevent the snakeoil workflow, which must stick to local IPv4 ranges and the fe80:: IPv6 prefix.
I've been digging through the DNS SD specifications lately (and how airplay, airprint, airscan and others work)...and I'm mindblown on how simple all things IoT could be if everything would support the DNS service discovery RFC.
In a parallel world nobody has IP problems, and nobody has problems connecting to their printers.
The way it's currently going though, I don't see any legacy firmware working in the near future due to CORS. I mean, most of the admin interfaces will break, probably, because of how they use forms to submit configs and settings.
Re: Chrome’s address bar will use https:// by default
#395Earlier quoted context omitted.
I like using http where appropriate and not wasting resources. I publish a blog and there’s no need for https. Adding https just adds a little more effort and provides no benefit to the user. I guess if you count the ISP not knowing, but Google knowing, that you’re visiting my blog, then that’s a reason. But that’s a user issue, not a server issue. Practically, my host does all the cert stuff for me and it’s not hard…
You don't care if your blog's content gets MITM'd?
No. It’s just static content, there’s no registration and all usage is anonymous. I collect no data. Someone can mitm if they wish, although there’s little motivation.
The risk of harm is that someone could try to misrepresent content or something, but again who has motivation and even if they did it would eventually be repaired.
Re: Chrome’s address bar will use https:// by default
#396Earlier quoted context omitted.
You don't care if your blog's content gets MITM'd?
You mean like by someone throwing up a huge warning that this page is made by the devil himself and unless he recites the right combination of holy words there is nothing you can do to access it? Ran into a few pages that were hijacked that way, some of them at least seemed to go to the expected content when I got rid of the https.
There’s certainly risk, but I don’t think converting all traffic to ssl is worth it to mitigate the risk.
I’ve never run into this situation in many years.
Re: Chrome’s address bar will use https:// by default
#397"Chrome will fall back to HTTP ... when there [is] ... DNS resolution failure" makes no sense to me. In what circumstance does DNS resolution succeed for HTTP after failing for HTTPS? DNS doesn't care what you're about to do with the IP address it provides.
Re: Chrome’s address bar will use https:// by default
#398I 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 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 don't know how it could work if you're truly disconnected from the Internet, want to connect arbitrary machines with no setup (not install local CA certs), and don't want any sort of prompt on first use (the TLS-PSK someone else mentioned). We might just be stuck with http in that case. Chrome isn't turning off http support, just changing the default behavior to try https first.
What I can imagine though is home LAN appliances being able to get certificates automatically when you have an Internet connection, have a domain name (they're pretty cheap), and set up your router for it. The router could present a (hypothetical) DHCP option saying "get certificates from me" (maybe via the standard ACME interface) and use the DNS-01 challenge with the upstream ACME server (letsencrypt) behind the scenes on each request.
This is certainly more complicated than just doing the DHCP request for a hostname and being done, and it makes your appliance hostnames public, but you wouldn't have to make appliances accept traffic from the Internet, much less have all your traffic proxied through some cloud service. And I can imagine it being a standard router feature some day with a wizard that walks you through the setup.
Re: Chrome’s address bar will use https:// by default
#399I 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…
Just host a certificate + private key at a well known location and have all the devices download / update it every month. /s (I'd bet someone has done this).
Re: Chrome’s address bar will use https:// by default
#400I 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…
A suggestion would be to treat destinations that do not need to traverse a gateway (ie local network) differently.
Browsers would need to implement this.
Further, they could present an initial dialog to 'trust' the local network. Obviously we don't want to do this in public Wi-Fi networks, but the OS already has a concept of 'private' vs 'public' networks, and the browser can easily know if the destination needs to be routed or it's local.