3 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? HTTP ov

> 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.
  - woodruffw 3y ago
    Thanks for bringing up the local network scenario -- I've been skeptical of these kinds of opportunistic encryption schemes, but issuance for LAN devices is indeed a pain and seems like it would be well served by something like tcpcrypt. 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.
    - skissane 3y ago
      > 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.

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.
- woodruffw 3y ago
  Thanks for bringing up the local network scenario -- I've been skeptical of these kinds of opportunistic encryption schemes, but issuance for LAN devices is indeed a pain and seems like it would be well served by something like tcpcrypt. 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.
  - skissane 3y ago
    > 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.