6 ms·

TLS 1.3 is going to save us all, and other why IoT is still insecure (2017)

94 points by fnord77 8y ago

deathanatos 8y ago
The word "reasons" appears to have gotten dropped from the submitted title. The article's title is, > TLS 1.3 is going to save us all, and other reasons why IoT is still insecure …which is grammatically correct.
rapsey 8y ago
This article is strange. Low power devices that need to conserve batteries are not ddos origins. Cctv cameras are. They are not that underpowered (they need to be streaming servers), can run tls just fine and 1.3 optimizations don’t make that much of a difference. Cameras generaly run linaro and they absolutely can update themselves over the network. The problem is that their manufacturers (at least the chinese giants) care very little about this problem. To them running ssl and having an auto update mechanism is a risk and a cost with no return. What we actually have is an influx of electronics engineers and programmers stepping into a networked world without knowing or caring about security. I’ve worked with them enough to see this attitude is pervasive. IT sevurity is far from their area of expertise.
- lallysingh 8y ago
  Can we start blocking regular http yet?
  - Ajedi32 8y ago
    Not quite. That'd still result in blocking ~20% of requests on Windows (~30% on Linux). https://transparencyreport.google.com/https/overview https://transparencyreport.google.com/https/overview Slowly making progress though. Apparently in the US 95% of users' browsing time is spent on HTTPS sites.
  - mlindner 8y ago
    ArchLinux's package servers are http by default and include no https servers by default. We're a long way from disabling http. It's "not a problem" because packages are signed, but it's still http.
  - emilfihlman 8y ago
    Blocking http means forcing others to subscribe to the PKI model (unless of course self signed certificates become much easier to add and use and not scary, in which case HTTPS is fine), which is neither foolproof nor end-all-solution.
adamcharnock 8y ago
This is precisely the problem I’m having right now. I’m working on the server side of an IoT project and trying to figure out a tenable way to secure an MQTT connection on devices with somewhere between 4-32kb of RAM. If anyone has any suggestions I’d love to hear it.
- becauseiam 8y ago
  The ace working group within the IETF has a fairly recent draft[1] standard on this. [1]: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...
  - adamcharnock 8y ago
    Thank you for this, I’ve just taken an initial look. I had understood that TLS would be a no-go in such a constrained environment, but perhaps I am mistaken.
- out_of_protocol 8y ago
  If you can share a secret then some hmac + e.g. aes128 will make communication virtually impenetrable and protected aganst all or almost all possible attacks. aes needed for hiding data inside, hmac for data integrity (protection against resending etc). If you don't have any crypto built into hardware it will be tough
- ctz 8y ago
  You're not going to have much RAM left after running a TCP/IP stack and the layers below it -- are these actually IP devices, or do you have a gateway? (Perhaps consider https://teserakt.io/ https://teserakt.io/ for the securing-MQTT part.)
- spydum 8y ago
  Look at something like wolfmqtt or equivalent - this is like 3-4kb, if you are targeting mqtt.
- peterwwillis 8y ago
devy 8y ago
This post was from 2017. The TLS landscape might have changed significantly. Can someone add a [2017] tag on this post's title?
nickserv 8y ago
Switching to TLS 1.3 will probably not really start in earnest until libssl 1.1.1 is installed by default on all major Linux distros. I'm running on Debian 9 and getting nginx to run TLS 1.3 took some work, nothing difficult, but when you see that many (most?) admins don't even bother to change SSH settings from the default, adding extra source lists seems impossible. Also, we're unable to kill off TLS 1.0/1.1 because of all these people running IE... edit: fix libssl version number as mentioned in comment below.
- yegle 8y ago
  I think you are referring to OpenSSL 1.1.1. OpenSSL 1.1.0 doesn't support TLS 1.3 (Debian Stretch ships with OpenSSL 1.1.0)
  - nickserv 8y ago
    Yes, quite right, it's 1.1.1 that supports TLS 1.3
- achillean 8y ago
  TLS 1.3 adoption has been growing significantly, though largely by CDNs as expected: https://www.shodan.io/report/Zwg7ScFM https://www.shodan.io/report/Zwg7ScFM
deleted 8y ago
[deleted]
blueline 8y ago
just in case anyone cares, the article sort of implies (by not mentioning it) that TLS and MQTT are incompatible. this is not the case, at my last job i used the EMQ broker with paho MQTT c++ on the devices using TLS.
cakoose 8y ago
This article exaggerates the deficiencies of TLS 1.2. - Because of the TCP handshake, the difference between plain HTTP and TLS 1.2 is 2 RTTs vs 4 RTTs, not 1 vs 3. - TLS 1.2 supports session resumption, which can bring it down from 4 RTTs to 3. - The article's "TLS 1.3 Session Resumption" diagram is actually describing "0-RTT" resumption, which is vulnerable to replay attacks and can't be used without carefully considering semantics of the HTTP POST request. (https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch) TLS 1.3 is still better in a bunch of ways, but there's no need to be misleading.
- tialaramex 8y ago
  You're correct that people MUST NOT use 0-RTT without actually understanding its semantics and designing their systems accordingly (e.g. if you think "But HTTP defines GET as idempotent so that's enough" then you already lost) But you can get rid of the extra RTT for a resumption on TCP in two ways. Firstly Systems can agree to do "Fast open". https://en.wikipedia.org/wiki/TCP_Fast_Open https://en.wikipedia.org/wiki/TCP_Fast_Open Secondly you can get rid of TCP from your TLS stack, by integrating the TLS layer into your connection-oriented protocol, which is what the IETF QUIC does/ will do. Then your connection setup can (again pending DDOS mitigation if appropriate) be zero round trip. So the end result is that in practice TLS 1.2 can be brought down to 1-RTT for second and subsequent connections (TCP Fast Open + TLS resumption + TLS False Start) and TLS 1.3 can match that for all connections, and beat it with 0-RTT for resumptions that meet extra security criteria. TLS session resumption does have a bunch of privacy implications, which are worse in TLS 1.2 and earlier but still present in TLS 1.3, and so privacy-focused clients might choose either to sharply limit resumption (e.g. only use it for connections that happen in the 15 seconds after the original connection) or get rid of it altogether. If you don't do resumption for this reason, TLS 1.3 beats TLS 1.2 because the no-resumption case is less round trips.

94 points by fnord77 8y ago

The word "reasons" appears to have gotten dropped from the submitted title. The article's title is, > TLS 1.3 is going to save us all, and other reasons why IoT is still insecure …which is grammatically correct.

rapsey 8y ago

This article is strange. Low power devices that need to conserve batteries are not ddos origins. Cctv cameras are. They are not that underpowered (they need to be streaming servers), can run tls just fine and 1.3 optimizations don’t make that much of a difference. Cameras generaly run linaro and they absolutely can update themselves over the network. The problem is that their manufacturers (at least the chinese giants) care very little about this problem. To them running ssl and having an auto update mechanism is a risk and a cost with no return. What we actually have is an influx of electronics engineers and programmers stepping into a networked world without knowing or caring about security. I’ve worked with them enough to see this attitude is pervasive. IT sevurity is far from their area of expertise.

lallysingh 8y ago
Can we start blocking regular http yet?
- Ajedi32 8y ago
  Not quite. That'd still result in blocking ~20% of requests on Windows (~30% on Linux). https://transparencyreport.google.com/https/overview https://transparencyreport.google.com/https/overview Slowly making progress though. Apparently in the US 95% of users' browsing time is spent on HTTPS sites.
- mlindner 8y ago
  ArchLinux's package servers are http by default and include no https servers by default. We're a long way from disabling http. It's "not a problem" because packages are signed, but it's still http.
- emilfihlman 8y ago
  Blocking http means forcing others to subscribe to the PKI model (unless of course self signed certificates become much easier to add and use and not scary, in which case HTTPS is fine), which is neither foolproof nor end-all-solution.

adamcharnock 8y ago

This is precisely the problem I’m having right now. I’m working on the server side of an IoT project and trying to figure out a tenable way to secure an MQTT connection on devices with somewhere between 4-32kb of RAM. If anyone has any suggestions I’d love to hear it.

becauseiam 8y ago
The ace working group within the IETF has a fairly recent draft[1] standard on this. [1]: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-pro...
- adamcharnock 8y ago
  Thank you for this, I’ve just taken an initial look. I had understood that TLS would be a no-go in such a constrained environment, but perhaps I am mistaken.
out_of_protocol 8y ago
If you can share a secret then some hmac + e.g. aes128 will make communication virtually impenetrable and protected aganst all or almost all possible attacks. aes needed for hiding data inside, hmac for data integrity (protection against resending etc). If you don't have any crypto built into hardware it will be tough
ctz 8y ago
You're not going to have much RAM left after running a TCP/IP stack and the layers below it -- are these actually IP devices, or do you have a gateway? (Perhaps consider https://teserakt.io/ https://teserakt.io/ for the securing-MQTT part.)
spydum 8y ago
Look at something like wolfmqtt or equivalent - this is like 3-4kb, if you are targeting mqtt.
peterwwillis 8y ago

devy 8y ago

This post was from 2017. The TLS landscape might have changed significantly. Can someone add a [2017] tag on this post's title?

nickserv 8y ago

Switching to TLS 1.3 will probably not really start in earnest until libssl 1.1.1 is installed by default on all major Linux distros. I'm running on Debian 9 and getting nginx to run TLS 1.3 took some work, nothing difficult, but when you see that many (most?) admins don't even bother to change SSH settings from the default, adding extra source lists seems impossible. Also, we're unable to kill off TLS 1.0/1.1 because of all these people running IE... edit: fix libssl version number as mentioned in comment below.

yegle 8y ago
I think you are referring to OpenSSL 1.1.1. OpenSSL 1.1.0 doesn't support TLS 1.3 (Debian Stretch ships with OpenSSL 1.1.0)
- nickserv 8y ago
  Yes, quite right, it's 1.1.1 that supports TLS 1.3
achillean 8y ago
TLS 1.3 adoption has been growing significantly, though largely by CDNs as expected: https://www.shodan.io/report/Zwg7ScFM https://www.shodan.io/report/Zwg7ScFM

deleted 8y ago

[deleted]

blueline 8y ago

just in case anyone cares, the article sort of implies (by not mentioning it) that TLS and MQTT are incompatible. this is not the case, at my last job i used the EMQ broker with paho MQTT c++ on the devices using TLS.

cakoose 8y ago

This article exaggerates the deficiencies of TLS 1.2. - Because of the TCP handshake, the difference between plain HTTP and TLS 1.2 is 2 RTTs vs 4 RTTs, not 1 vs 3. - TLS 1.2 supports session resumption, which can bring it down from 4 RTTs to 3. - The article's "TLS 1.3 Session Resumption" diagram is actually describing "0-RTT" resumption, which is vulnerable to replay attacks and can't be used without carefully considering semantics of the HTTP POST request. (https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch https://blog.cloudflare.com/introducing-0-rtt/#whatsthecatch) TLS 1.3 is still better in a bunch of ways, but there's no need to be misleading.

tialaramex 8y ago
You're correct that people MUST NOT use 0-RTT without actually understanding its semantics and designing their systems accordingly (e.g. if you think "But HTTP defines GET as idempotent so that's enough" then you already lost) But you can get rid of the extra RTT for a resumption on TCP in two ways. Firstly Systems can agree to do "Fast open". https://en.wikipedia.org/wiki/TCP_Fast_Open https://en.wikipedia.org/wiki/TCP_Fast_Open Secondly you can get rid of TCP from your TLS stack, by integrating the TLS layer into your connection-oriented protocol, which is what the IETF QUIC does/ will do. Then your connection setup can (again pending DDOS mitigation if appropriate) be zero round trip. So the end result is that in practice TLS 1.2 can be brought down to 1-RTT for second and subsequent connections (TCP Fast Open + TLS resumption + TLS False Start) and TLS 1.3 can match that for all connections, and beat it with 0-RTT for resumptions that meet extra security criteria. TLS session resumption does have a bunch of privacy implications, which are worse in TLS 1.2 and earlier but still present in TLS 1.3, and so privacy-focused clients might choose either to sharply limit resumption (e.g. only use it for connections that happen in the 15 seconds after the original connection) or get rid of it altogether. If you don't do resumption for this reason, TLS 1.3 beats TLS 1.2 because the no-resumption case is less round trips.