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

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

blog.cloudflare.com

94 pointsfnord7726 comments

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.

Can we start blocking regular http yet?

Not quite. That'd still result in blocking ~20% of requests on Windows (~30% on Linux). https://transparencyreport.google.com/https/overview

Slowly making progress though. Apparently in the US 95% of users' browsing time is spent on HTTPS sites.

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.

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.

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.

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.

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)

Yes, quite right, it's 1.1.1 that supports TLS 1.3

TLS 1.3 adoption has been growing significantly, though largely by CDNs as expected:

https://www.shodan.io/report/Zwg7ScFM

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.

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-pro...

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.

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

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/ for the securing-MQTT part.)

Look at something like wolfmqtt or equivalent - this is like 3-4kb, if you are targeting mqtt.

If you didn't need many features, you could theoretically wrap mqtt in dnscurve payloads; lighter weight than tls and still very secure.

Public key crypto (required for SSL/TLS) is difficult to fit in that RAM footprint. You don't have enough RAM to hold an RSA or DSA key, let alone a certificate chain!

Usually devices of that size will use a dedicated crypto chip to store and manipulate the keys.

Elliptic curve algorithms fit better into that RAM footprint, if you can afford to sacrifice protocol compatibility.

If you can drop the SSL/TLS requirement and fall back to authenticating and encrypting your payloads over HTTP, RC5/SHA might suffice. Hash some unique serial number on your device and use that as a key. Auth is provided with a secret key burned into your device -- but this opens up big risks if your physical device or its firmware are compromised.

Sorry, but TLS has PSK cyphers that do not use asymmetric cryptography. They are not used often, as you normally want the benefits of asymmetric cryptography, but they are useful if you can pair devices out-of-band and can store a unique secret key for each communication partner.

Based on my experience on releasing a secure IoT device on a microcontroller: You will need to spend a lot of time optimizing that. The most used TLS library (mbedTls) requires 20kB send and receive buffers for each connection. That doesn't involve buffers for the TCP/IP stack yet, and also not anything for an application. You can reduce the buffer sizes, but then you are no longer standard compliant (at least on the receiving side) and if the server sends longer TLS frames the device might close the connection or exhibit undefined behavior.

You can either experiment with other TLS libraries or investigate whether a more powerful device wouldn't make your life easier.

Consider PSK TLS. I.e., fixed AES key and something like GCM or similar for integrity. No certificates. Libraries exist, also it's a lot faster on both ends to handle than RSA crypto.

Is there really no estabilished open-source solution to this problem? It seems very sad since rolling your own crypto protocol even from knwon good primitives is such an infamous minefield.

Also apparently many "IoT" labeled devices are not actually on the internet, but are using some kindof gateway to the net. In this case you would lose end-to-end security by just using TLS to the gateway.

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)

TLS 1.3 is still better in a bunch of ways, but there's no need to be misleading.

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

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.

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.

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

Reply on news.ycombinator.com