This is the kind of sunset you love to see. Retirement because they succeeded and therefore became redundant, rather than due to failure. If there's one organization I love to see succeed, it's the EFF.
There's still a real issue with infrastructre that has web configuration. Everything from home routers to video cameras and so on. Not being able to ship with a certificate that passes browser security checks is a problem that essentially nobody has addressed.
When people connect to an IOT device, they need to be able to connect with a web browser and not jump through hoops to say, "No, really I know that this is a secure connection." Because we can't keep teaching people to dodge secure connections when they should care about having secure connectinos. As much as I don't like IOT, but this is an issue that needs to be easier than "understand cyrptography configuration, generate your own keys, and install them wherever you need them".
That's all besides the vendor "solution" of "install this phone app that will maybe barely work except for the parts that track your data forever LOL thx sucker".
It's also something that can be done with a level of reliability that will impress incredulous people. But that there will always be somebody to complain that is not following the standard recommendations.
1. Look up all local interfaces' networks (IP & subnet mask)
2. Determine if .local IP is within subnet range of one of the interfaces
3. If .local IP is not on a subnet of a local interface, drop the connection
What certs prove is "this host currently has a private key and cert, and at one time this private key was used to generate a CSR for this cert, and at one time it was validated that an IP resolvable by the domain name in the CSR was also controlled by whoever issued the CSR". It's a very awkward thing that doesn't really match up to local consumer devices.
We need a vendor key registry, the way MAC address prefixes are mapped to vendors, so at least we could say "the key on this host came from vendor XYZ". The browser would need to pop up a warning saying "WARNING: You are now connected to a local device from Vendor XYZ! If you did not intend to connect to a local device, close this window!" Updates to the vendor registry could also invalidate previous entries if old keys got compromised. But this would be in combination with the aforementioned "is the site on a local network?" logic. Anyone using a .local would have to both compromise a local network and steal a key from a vendor, or be registered as a vendor, and then the user would have to be dumb enough to click through a big warning about a local device.
It's probably better if we terminate the trust at a TLS certificate or something similar to DANE. So there isn't any specialized registry to maintain.
I'd personally classify 192.168/16, 172.16/12, 10/8, 127/8, fe80/10, and ::1 as local networks, but that's simply not always the case. There are tons of universities and even business out there that use publicly routable addresses for clients and that approach is even the default for IPv6. You could be tempted to use the local network range as a "local" network but there are plenty of networks out there where that would mark foreign networks as "local". Then there are those who use 1.0.0.0/8 for local addresses because that subnet was previously unused and the 10 range already had a separate meaning.
Just verifying that .something (.local is already reserved, you shouldn't use it for internal device names even though it'll probably work) matches an internal IP doesn't add any security. You might as well mark HTTP to local IP addresses as a secure origin and not mess with certificates at all. I don't th9nk that's a very good idea.
With IPv6, there's a solution to this problem. You can provision certificates to globally unique IP addresses and possibly their hostname. I don't think there's a solution for IPv4 on most local networks, though.
However precisely because .home.arpa domains are non-unique is is forbidden by the relevant RFC to treat it specially for security. Because with a roaming device, when out on say an public attacker controlled wifi, the name might resolve to something malicious under attacker control, and doing something automatically trusting self signed certs would make it more likely that attacks using such devices could succeed.
If a mechanism for securely identify exactly which home network you are connected to is eventually discovered, then this limitation can be lifted, with the user specifically whitelisting trusted home networks.
HTTPS Everywhere was "this site already has HTTPS, and really should only use that, but doesn't, so we'll redirect you to the HTTPS version". Now sites that have HTTPS default to it, and browsers have options to basically try https first and see if it works.
"HTTPS Everywhere" is pretty suggestive. And the English meaning of the words might be a worthwhile goal too.
If so, that's a 2017 flamewar.
[0] http://n-gate.com/software/2017/07/12/0/ (NOTE: this site tracks if you come from HN and sets a cookie. You'll probably need to open it in incognito)
They don't provide an alternative to "HTTPS Everywhere User Rules" as well as adding exceptions to HTTPS only sites (under "HTTPS Everywhere Sites Disabled"), which can be found in HTTPS Everywhere options.
In Chromium I can only turn HTTPS on all sites, without exception. It also doesn't allow me to have mixed content (on certain sites)
* Long sunset period
* Instructions to make sure you can enjoy the same security after they sunset
I’m just some guy on the Internet but IMHO their being OK with massive conflicts of interest means I no longer trust them.
1. Achieve its mission with no money, or 2. Find money from sources deemed acceptable, or 3. Take money from sources deemed unacceptable
I'm OK with option 3, so long as its transparent, because I agree with the agenda the EFF are pushing. If they start pushing an agenda I disagree with, I'll stop supporting them, whether or not they receive money from Google et al.
EFF works on a wide range of issues, ranging from anti-censorship, software patent reform, online free speech, just to name a few. Many of those areas are where their values align with those of the Facebook/Google executives which donate to them. That they are able to receive those donations in spite of the areas where they disagree speaks more to EFF's track record of being an effective and powerful force for good in tech.
I'm not a fan of Google or Facebook, but I also don't outright boycott everything that they've ever touched. They donate money and developer time to tons of projects that I use regularly (including Linux), and it would be hypocritical of me to look down on the EFF for benefiting from the companies that I also benefit from.
I don't like the bad behavior from Google or Facebook, but I don't think donating millions to the EFF is bad behavior, nor do I think getting tens of thousands of pull requests merged into public FOSS projects from Google and Facebook employees is bad behavior. Black and white guilt-by-association doesn't work when you have companies of this size, with hundreds of thousands of employees, and tons of varying internal cultures.