The constant churn of protocol deprecations, certificate expirations, rotations, etc. is like planned obsolescence on steroids.
BGP and us-east-1 fair :D
I think this is a very different definition of brittle than the original poster meant
Facebook doesn't count, as it was limited to their network.
> Space Cadet Pinball was not originally written by Microsoft, but was rather obtained via licensing from a company then-known as Cinematronics. This means that there are restrictions on what can be done with the program, as spelled out by the license agreement.
https://devblogs.microsoft.com/oldnewthing/20181221-00/?p=10...
The change would be you can’t ship software like this… I would say that is a net positive.
Free software centers around the user. Everything else is a means to that end. Open source centers around the authors. This is fundamentally misguided.
I couldn’t give two [deleted] about authors and what they want.
Firstly, the obvious, laws are local not global. Your proposed law would need to be ratified by 200 odd governments. This seems unlikely (Not least in the US which perfers not to ratify international laws). Given that China is least likely to care, and given that most really cheap phones originate there, I'm not sure your proposed law will work there.
So, to summarise, suggesting global laws, while not necessarily wrong, is as fruitless as suggesting that we use magic pixie dust to solve the problem. Both have exactly the same liklihood of being adopted.
Plus, given that the proposed law dictates -future- behaviour I'm not sure who, how or where an affected person (one who only has money for an ultra cheap phone they haven't updated in 7 years) would get relief from.
> either need to open-source everything
That'd be problematic, as in many cases the vendor doesn't even have the full source code (think: all of the embedded chips that run their own RTOS), let alone the legal right of relicensing it. Another thing is build reproducibility, the ability to actually flash/install the code, etc. It would be desirable to have all that, but it's far from simple.
> allow everyone who ever bought one to return it for a full refund.
Regardless of the actual physical condition of the item? I would say something like a trade-in program, where you get a % of the original value depending on overall condition. But then it gets tricky as it's difficult to write into law, what "good condition" does actually mean. What if the device has two screens, but only one is broken? What about components that tend to wear out or break during normal use (batteries, straps, hinges)?
But having that process in place could also actually help us recycle more stuff.
Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product. That'd just get the bigger corps even more entrenched (while they figure out the "legitimate interest cookie" equivalent of still screwing you over).
I consider making closed-source more legally difficult to be an additional benefit, not a downside.
> Regardless of the actual physical condition of the item?
Yes. The idea is that it'd be better for things to continue to be safely usable rather than to have to become e-waste, so if the manufacturer chooses the option that requires the latter, the deal should be as one-sided as possible against them.
> Also, consider the smaller companies, that don't have the resources to effectively give you a 10-year warranty on their product.
Software updates are a lot cheaper than full warranties, and if they make all of their stuff open-source then there'd be nothing else they have to do at all.
Then perhaps start with a copyright reform, otherwise I think you're trying to "solve" too many problems all at once.
> so if the manufacturer chooses the option that requires the latter, the deal should be as one-sided as possible against them.
Meaning only the already wealthy companies can afford to take the risk. You're further empowering the rich.
This is cold comfort, of course (though: the post-ACME world of short-lived certs has better DX than the nightmare world of long-lived Verisign certs), but it's worth noting that any alternative to TLS would face similar problems.
It would be nice to have a centralized push-based solution or something. I dunno, hard problem.
I suspect that protocol churn will settle down now. TLS 1.2 was introduced in 2008 and still considered ok, so its hardly that new now. Lots of people looking carefully hopefully means most of the issues have been flushed out.
IMO, you could argue what Let's Encrypt does is basically DANE so why not just support it, but there may be use cases where DANE isn't appropriate. I don't see why perfect has to be the enemy of good though, let folks use DANE if they want.
HTTP over tcpcrypt AKA TCP-ENO?
https://www.rfc-editor.org/rfc/rfc8547.html and https://www.rfc-editor.org/rfc/rfc8548.html
Unlike HTTPS/TLS, it doesn't provide protection against active attacks, but at least prevents passive ones. So it couldn't be used for https:// URLs, but would be a security improvement for http:// ones. And no certificates to manage
E.g. you could try to randomly record both ends of a TCP connection and then compare them out-of-band to see if someone in between tampered with the contents. (Although my late former colleague was working on a tool to do that and it turns out that there's a lot of noise and complexity to contend with in trying to make it practical, e.g. because of packet loss, retransmission, fragmentation, and changes like NAT by middleboxes that consider themselves benign.)
Random example of a passive communications interception attacker:
https://en.wikipedia.org/wiki/RAF_Menwith_Hill#/media/File:M...
Another example:
https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:...
There are lots more where those came from!
I think a lot of stuff on local LANs is still HTTP-only because trying to do TLS for local devices – even with LetsEncrypt – is a pain. Not impossible – you can't get a TLS certificate for 192.168.12.34, but you can create a public DNS entry pointing to that and then use a DNS-01 challenge to get a certificate for it. But that's enough work that heaps of people don't do it.
It also makes local LAN reliant connectivity reliant on public DNS – since you can't do https://192.168.12.34 you have to do https://device-12-34.example.com, if your Internet connection is down you might not be able to resolve device-12-34.example.com even though the device is up and accessible on your local network. Adding a local DNS server will fix that – but now that's another thing you need to make it all work.
Whereas if we had opportunistic encryption for http://, that would make local LAN passive attacks a lot harder. Yes it wouldn't stop against local LAN active attacks, but security against passive but not active attacks is still better than no security against either.
At the same time: how do you foresee this interoperating securely with TLS? My first intuition is, without something even stronger than HSTS, that this would open up additional downgrade attacks against HTTPS: an attacker could do a normal HTTP downgrade and then present a TCP-ENO session that they control the key for. That's perhaps no worse than the downgrade itself, but I could see it being a source of user confusion if browsers choose to present this kind of scheme as "secure" in the UI.
The obvious solution to that problem is - don’t show it in the UI by default.
For sophisticated users, have a config setting they can turn on which will show some kind of icon (not the padlock, a different one). For unsophisticated users, make it invisible.
Invisible protection against passive attacks is still better than no protection against passive attacks. But passive-vs-active is beyond the understanding of non-technical users, so for them keep it invisible.
I agree that perfect can be the enemy of good, but i also think its important to do things that stop actual attacks. Things that make attacks just mildly more difficult are pointless since the attacks are going to be scripted anyways.
How do you distinguish between a host you have seen before that has a mismatched key vs a totally new host which you have never seen before.
I guess it depends on how you are discovering these resources in the first place, but traditional answers like IP address are much less workable on the local network.
You wouldn't even have to expose the private network to the outside world. It could still be firewalled off.
Say if your prefix is 2a09:1337:8888:aa::/56 and your private prefix is 2a09:1337:8888:aaff::/64, just make sure that the router redirects all traffic from outside to the /64 to a box that listens for connections so a certificate can be issued. Of course you'd also need to be able to reach the said box from boxes within the private network (for .well_known cert requests), but it's trivial. No BGP required. Simple HTTP challenge.