7 ms·

Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web? The const

Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web? The constant churn of protocol deprecations, certificate expirations, rotations, etc. is like planned obsolescence on steroids.

woodruffw 3y ago
I don’t think TLS is the most brittle component of the web. That award probably goes to DNS, BGP, or (depending on how you qualify it) us-east-1.
- lbotos 3y ago
  Whats brittle about DNS? Caching? BGP and us-east-1 fair :D
  - bawolff 3y ago
    DNSSec is pretty brittle. I think this is a very different definition of brittle than the original poster meant
    - tptacek 3y ago
      Yeah, but almost nobody uses it (it's got low single digits uptake in the US, and has actually decline in some years), so that's not the part of DNS that's making it brittle for deployments.
    - talideon 3y ago
      Describing DNSSEC as brittle is the height of understatement.
      - AdamJacobMuller 3y ago
        Brittle, painful and with a tiny minority who scream at you for being stupid because you're not using it and complain about these problems.
  - woodruffw 3y ago
    Caching, people misunderstanding (and misusing) TTLs, bespoke service discovery on top of DNS without understanding the aforementioned, bespoke stringly-typed configuration languages in various DNS records, etc.
- sgjohnson 3y ago
  What's brittle about BGP? There hasn't been a wide-scale BGP outage since 2019 when verizon did `import all; export all;`. Facebook doesn't count, as it was limited to their network.
- account42 3y ago
  A DNS client from the 90s will have no trouble communicating with current DNS servers and BGP only matters to internet backbone routers. Neither of them cause any problems for old devices.
bawolff 3y ago
I think fundamentally, it is impossible to trust any entity forever. The best solution would be certificate updates outside of normal update paths. Its not like the format of x509 certs have changed in basically ever. 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.
- nyanpasu64 3y ago
  It's true that TLS 1.2 is still considered OK, but cacert now only serves on TLS 1.3, Windows 7's integrated HTTP stack only supports TLS 1.2 and below, and Scoop relies on using PowerShell or similar to download cacert before it can install curl, meaning I can no longer install curl that way on Windows 7 (still an OS nearly as usable as Windows 10 and Linux, though apps are sadly starting to drop support for it).
skissane 3y ago
> Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web? HTTP over tcpcrypt AKA TCP-ENO? https://www.rfc-editor.org/rfc/rfc8547.html https://www.rfc-editor.org/rfc/rfc8547.html and https://www.rfc-editor.org/rfc/rfc8548.html 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:// https:// URLs, but would be a security improvement for http:// http:// ones. And no certificates to manage
- bawolff 3y ago
  Not a whole lot of point if you dont care about active attacks. Active attacks aren't that hard. With the exception of mass survelience in the usa almost all attacks you actually care about can easily be active.
  - schoen 3y ago
    Historically there are lots of passive attackers (and we don't know or think about them because they're passive), while a lot of them have been reluctant to become active attackers (because we might notice them!). 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:Menwith_Hill_radomes_x_26.jpg https://en.wikipedia.org/wiki/RAF_Menwith_Hill#/media/File:M... Another example: https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:Orion_MENTOR4_(USA-202).jpg https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:... There are lots more where those came from!
  - skissane 3y ago
    I don't agree with this logic that "either you have perfect security or there's no point". 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 https://192.168.12.34 you have to do https://device-12-34.example.com 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:// 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.
candiddevmike 3y ago
DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://wikipedia.org/wiki/DNS-based_Authentication_of_Named... 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.
tptacek 3y ago
It seems like most of what's bugging you about TLS is having to keep up with certificate reissuance. The reason you have to deal with that is that global-scale distributed revocation is a ludicrously hard problem. To mitigate the fact that some bindings of users-to-certificates are effectively irrevocable, you shorten the lifespan of certificates, so their blast radius is smaller. 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.
- TillE 3y ago
  Certificate revocation is a really interesting problem, because it's obviously vital but also pretty rare. Currently, to validate a certificate, every client has to walk through every certificate in the chain and ask for the CRL or make an OCSP query, just in case. It's incredibly wasteful and subject to all sorts of problems. It's really fun verifying file signatures on a machine with no direct internet access. It would be nice to have a centralized push-based solution or something. I dunno, hard problem.
  - BenjiWiebe 3y ago
    Doesn't OCSP stapling help / solve most of that?
josephcsible 3y ago
The issue isn't that TLS keeps changing. It needs to for security. The bad thing that leads to planned obsolescence is that devices stop receiving manufacturer updates so soon and can't be updated by third parties. My preferred solution would be a law that if a manufacturer needs or wants to stop producing security updates sooner than 10 years after sales ended, it'd either need to open-source everything or allow everyone who ever bought one to return it for a full refund.
- baggy_trough 3y ago
  That would be a terrible law. It would dramatically raise prices and reduce choice.
  - thanksgiving 3y ago
    Not really. You’d have to make sure you either own the software you ship or that software is already available freely so you don’t get into the space cadet situation like Microsoft Windows. > 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=100535 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.
    - baggy_trough 3y ago
      Why should your preferred software licensing policies be legally mandated and binding on others such as myself?
      - josephcsible 3y ago
        If you don't want others' preferred software licensing policies to be legally mandated and binding on you, are you in favor of abolishing copyright for software?
bombcar 3y ago
The onion protocol contains its own certification in the domain.

woodruffw 3y ago

I don’t think TLS is the most brittle component of the web. That award probably goes to DNS, BGP, or (depending on how you qualify it) us-east-1.

lbotos 3y ago
Whats brittle about DNS? Caching? BGP and us-east-1 fair :D
- bawolff 3y ago
  DNSSec is pretty brittle. I think this is a very different definition of brittle than the original poster meant
  - tptacek 3y ago
    Yeah, but almost nobody uses it (it's got low single digits uptake in the US, and has actually decline in some years), so that's not the part of DNS that's making it brittle for deployments.
  - talideon 3y ago
    Describing DNSSEC as brittle is the height of understatement.
    - AdamJacobMuller 3y ago
      Brittle, painful and with a tiny minority who scream at you for being stupid because you're not using it and complain about these problems.
- woodruffw 3y ago
  Caching, people misunderstanding (and misusing) TTLs, bespoke service discovery on top of DNS without understanding the aforementioned, bespoke stringly-typed configuration languages in various DNS records, etc.
sgjohnson 3y ago
What's brittle about BGP? There hasn't been a wide-scale BGP outage since 2019 when verizon did `import all; export all;`. Facebook doesn't count, as it was limited to their network.
account42 3y ago
A DNS client from the 90s will have no trouble communicating with current DNS servers and BGP only matters to internet backbone routers. Neither of them cause any problems for old devices.

bawolff 3y ago

I think fundamentally, it is impossible to trust any entity forever. The best solution would be certificate updates outside of normal update paths. Its not like the format of x509 certs have changed in basically ever. 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.

nyanpasu64 3y ago
It's true that TLS 1.2 is still considered OK, but cacert now only serves on TLS 1.3, Windows 7's integrated HTTP stack only supports TLS 1.2 and below, and Scoop relies on using PowerShell or similar to download cacert before it can install curl, meaning I can no longer install curl that way on Windows 7 (still an OS nearly as usable as Windows 10 and Linux, though apps are sadly starting to drop support for it).

skissane 3y ago

> Is there any proposed solution (other than just using unencrypted HTTP) that would make it so TLS is no longer the most brittle component of the web? HTTP over tcpcrypt AKA TCP-ENO? https://www.rfc-editor.org/rfc/rfc8547.html https://www.rfc-editor.org/rfc/rfc8547.html and https://www.rfc-editor.org/rfc/rfc8548.html 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:// https:// URLs, but would be a security improvement for http:// http:// ones. And no certificates to manage

bawolff 3y ago
Not a whole lot of point if you dont care about active attacks. Active attacks aren't that hard. With the exception of mass survelience in the usa almost all attacks you actually care about can easily be active.
- schoen 3y ago
  Historically there are lots of passive attackers (and we don't know or think about them because they're passive), while a lot of them have been reluctant to become active attackers (because we might notice them!). 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:Menwith_Hill_radomes_x_26.jpg https://en.wikipedia.org/wiki/RAF_Menwith_Hill#/media/File:M... Another example: https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:Orion_MENTOR4_(USA-202).jpg https://en.wikipedia.org/wiki/Orion_(satellite)#/media/File:... There are lots more where those came from!
- skissane 3y ago
  I don't agree with this logic that "either you have perfect security or there's no point". 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 https://192.168.12.34 you have to do https://device-12-34.example.com 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:// 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.

candiddevmike 3y ago

DANE: https://wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://wikipedia.org/wiki/DNS-based_Authentication_of_Named... 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.

tptacek 3y ago

It seems like most of what's bugging you about TLS is having to keep up with certificate reissuance. The reason you have to deal with that is that global-scale distributed revocation is a ludicrously hard problem. To mitigate the fact that some bindings of users-to-certificates are effectively irrevocable, you shorten the lifespan of certificates, so their blast radius is smaller. 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.

TillE 3y ago
Certificate revocation is a really interesting problem, because it's obviously vital but also pretty rare. Currently, to validate a certificate, every client has to walk through every certificate in the chain and ask for the CRL or make an OCSP query, just in case. It's incredibly wasteful and subject to all sorts of problems. It's really fun verifying file signatures on a machine with no direct internet access. It would be nice to have a centralized push-based solution or something. I dunno, hard problem.
- BenjiWiebe 3y ago
  Doesn't OCSP stapling help / solve most of that?

josephcsible 3y ago

The issue isn't that TLS keeps changing. It needs to for security. The bad thing that leads to planned obsolescence is that devices stop receiving manufacturer updates so soon and can't be updated by third parties. My preferred solution would be a law that if a manufacturer needs or wants to stop producing security updates sooner than 10 years after sales ended, it'd either need to open-source everything or allow everyone who ever bought one to return it for a full refund.

baggy_trough 3y ago
That would be a terrible law. It would dramatically raise prices and reduce choice.
- thanksgiving 3y ago
  Not really. You’d have to make sure you either own the software you ship or that software is already available freely so you don’t get into the space cadet situation like Microsoft Windows. > 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=100535 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.
  - baggy_trough 3y ago
    Why should your preferred software licensing policies be legally mandated and binding on others such as myself?
    - josephcsible 3y ago
      If you don't want others' preferred software licensing policies to be legally mandated and binding on you, are you in favor of abolishing copyright for software?

bombcar 3y ago

The onion protocol contains its own certification in the domain.