
TLS 1.3 is going to save us all, and other why IoT is still insecure (2017) - fnord77
https://blog.cloudflare.com/why-iot-is-insecure/
======
rapsey
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
Can we start blocking regular http yet?

~~~
Ajedi32
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.

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

------
nickserv
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
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
Yes, quite right, it's 1.1.1 that supports TLS 1.3

------
adamcharnock
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
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...](https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/)

~~~
adamcharnock
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.

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

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

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

