35C3 - The Rocky Road to TLS 1.3 and better Internet Encryption

35C3 preroll music

Herald-Angel: All right. Now it's my very
big pleasure to introduce Hanno Böck to

you. He's no stranger to the Chaos crowd.
He's been to several Easterheggs and at

several other Chaos events. Today he's
here to talk about TLS 1.3, what it's all

about how it came to be and what the
future of it is gonna look like. Please

give a huge applause and welcome Hanno.
hanno: Yeah. Okay. So today I want to talk

to you about a new version of TLS. TLS is
this protocol, Transport Layer Security,

which I hope everyone knows what it is.
It's a protocol that you can put on top of

other protocols that gives us an encrypted
and authenticated channel through the

generally insecure internet. We have a new
version since August, TLS 1.3. At first

I'd like to go a bit into the history of why we
have this new version, how we got there

and what design decisions were made for
this version. So the very first version of

SSL which it was called back then was
released in 1995 by Netscape and it was

quickly followed up with version 3 which
is still very similar to the TLS 1.2 that

we mostly use today. And then in 1999 it
was kind of taken over from Netscape to

the IETF, which is the Internet
standardization organization, and they

renamed it to TLS. And so that's kind of
the history. We had SSL and I've marked it

in red because these two versions are
broken by design. You cannot really use

them in a way that is secure these days
because we know vulnerabilities that are

part of the protocol. And then we had, in
1999 it was renamed to TLS, and TLS is

kind of still kind of OK if you do
everything right. But that's really

tricky. So it's kind of a dangerous
protocol but maybe not totally broken.

Same with TLS 1.1. TLS 1.2 is what we
still mostly use today and TLS 1.3 is the

new one and what you can see here for
example is that the the biggest gap here

is between 1.2 and 1.3, so it was a very
long time where we had no new development

here. You probably heard that we had
plenty of vulnerabilities in TLS, around

TLS and also these days, a good
vulnerability always has a logo and a nice

name. And I want to go into one
vulnerability which doesn't have a logo.

Not one of the variants. I was very
surprised when I realized that. That's the

so-called Padding Oracles. They are in CBC
mode which is the encryption we use for

the actual data encryption, the symmetric
data encryption. The thing is, when we

encrypt data what we usually use are so-
called block ciphers and they encrypt one

block off a specific size of data. It's
usually sixteen bytes and this CBC mode

was the common way to encrypt in past TLS
versions. And this is roughly how it looks

like. So we have some initialization
vector which should be random, but wasn't

always, but that's another story. And then
we encrypt a block of data and then we XOR

that encryption into the next plain text
and encrypt it again. Now one thing here

is that because these are blocks of data
and our data may not always be in sixteen

byte blocks it may just be five bytes or
whatever, we need to fill up that space.

So we need some kind of padding. In TLS,
what was done was that first of all we had

some data. Then we added a MAC, which is
something that guarantees the correctness

of the data, the authentication of the
data. And then we pad it up to a block

size and then we encrypt it. And this
order of things turned out to be very

problematic. So this padding is a very
simple method. If we have one byte to fill

up we make a 00. If we have two bytes to
fill up well you make 0101, three bytes

020202 and so on. So that's easy to
understand, right? Let's for a moment

assume a situation where an attacker can
manipulate data and can see whether the

server receives a bad padding or whether
it receives bad data, where this MAC check

goes wrong. And here is the decryption
with CBC mode. And what an attacker can do

here: the first thing the attacker does,
it throws one block away at the end, it

just blocks the transmission of that block
and then it changes something here. So

what we assume here is the attacker wants
to know this decrypted byte because it may

contain some interesting data. So what he
can do is he can manipulate this byte with

a guess and a byte is only 256 values a
byte can have. So he can guess enough

times and XOR it with this value. And if
you think about it if we XOR it here with

the plaintext. That means if we end up
with this zero here then the padding is

valid. If we end up with some garbage
value here, then the padding is probably

invalid. So by making enough guesses the
attacker can decrypt a byte here under the

condition that he learns somehow whether
the padding is valid or not. So he could

decrypt one byte but he can't go on. Let's
assume we will learn that one byte we have

decrypted it and then we can go on with
the next byte. So we XOR this byte on the

right with the guess with what we already
know that it is and with the one and. Then

we XOR this next byte with our guess and
also a one. And if this ends up being 0101

then again we have a valid padding. So the
attacker learns the next byte and he can

do this for other bytes. This was
originally discovered in 2002 by Sergey

Vaudenay. But it was kind of only
theoretical. So one thing here is that TLS

has these error messages. There are
different kinds of errors. And if you read

through the TLS 1.0 standard, if the
padding is wrong then you get this

decryption_failed error. And if the MAC is
wrong, so the data has some modification,

then you get this bad_record_mac error. So
you could say this would allow this

Padding Oracle attack because there are
these error messages. But the attacker

cannot see them because they are
encrypted. So this was kind of only a

theoretical attack which didn't really
work on a real TLS connection. But then

there was a later paper which made this
attack practical by measuring the timing

difference from these different kinds of
errors. And this allowed a practical

decryption of TLS traffic. Then in later
versions of TLS this was fixed or kind of

fixed. But there is a warning in the
standard which says.. So this is right

from the standard text. "This leaves a
small timing channel but it is not

believed to be large enough to be
exploitable." If you read something like

that, it sounds maybe suspicious, maybe
dangerous. And actually in 2013 there was

these so-called Lucky Thirteen attack
where a team of researchers actually

managed to exploit that small timing side
channel that the designers of the standard

believed was not large enough to be
exploitable. It is in theory possible to

implement TLS in a way that it is safe
from this timing attacks. But it adds a

lot of complexity to the code. If you just
look at when Lucky Thirteen was fixed, it

just made the code much longer and much
harder to understand. Then there was

another Padding Oracle which was called
POODLE, which was in the old version

SSLv3. This was kind of by design. So the
protocol was built in a way that you could

not avoid this Padding Oracle. Then it
turned out that there was also a kind of

TLS variation of this POODLE attack. And
the reason here was that the only major

change between SSLv3 and TLS 1.0 was that
the padding was fixed to a specific value,

where in the past it could have any value.
It turned out that there were TLS

implementations that were not checking
that, enabling this poodle attack also in

TLS. Then there was the so-called Lucky
Microseconds attack which was basically

the.. one of the people who has found the
Lucky Thirteen attack looked at

implementations and saw if they have fixed
Lucky Thirteen properly. They looked at

s2n, which is an SSL library from Amazon
and they found: "Ok, they tried to make

countermeasures against this attack but
these countermeasures didn't really work

and they had still a timing attack that
they could perform." Then there was a bug

in OpenSSL which was kind of funny because
when OpenSSL tried to fix this Lucky

Thirteen attack, they introduced another
Padding Oracle attack which was actually

much easier to exploit. We had plenty of
Padding Oracles. But if you remember back

what I said, for the very first attack
that this didn't really work in practice

in TLS, because these errors are
encrypted. But theoretically you could

imagine that someone creates an
implementation that sends errors that are

not encrypted. For example you can send a
TCP error or just cut the connection or

have any kind of different behavior
because the whole attack just relies on

the fact that you can distinguish these
two kinds of errors. You can find

implementations out there doing that. So
yeah, Padding Oracle is still an issue.

Then I want to look at another attack
which is a so-called Bleichenbacher

attacks and they target the RSA encryption
and that is kind of the asymmetric

encryption which we use at the beginning
of a connection to establish a shared key.

This attack was found in 1998 by Daniel
Bleichenbacher. If you look at the RSA

encryption before we encrypt something
with RSA, we do some preparations. The way

this is done and in all TLS versions is
these so-called PKCS #1 1.5 standard. How

this looks is: it starts with the 00 02.
Then we have some random data which is

just again a padding to fill up space.
Then we have zero which marks the end of

the pending. Then we have a version number
03 03, which stands for TLS 1.2. It's

totally obvious right. I'll get two
version numbers later. And then we have

the secret data. But the relevant thing
for this attack is mostly this 00 02 at

the beginning. So we know each correct
encrypted block, if we decrypt it, it

starts with 00 02. We may wonder if we
implement a TLS server and it decrypts

some data from the client and then it
doesn't start with 00 02: what shall I do?

And the naive thing would be: yeah of
course we just send an error message

because something is obviously wrong here.
Now this turns out to be not such a good

idea because if we do this we will tell
the attacker something. We will tell him

that the decrypted data does not start
with 00 02. So the attacker learned

something about the interval in which the
decrypted data is. Either it starts with

00 02 or it doesn't. And this turned out
to be enough to.. if you send enough

queries and modify the ciphertext you can
learn enough information to decrypt data.

The whole algorithm is a bit more
complicated but it's not that complicated.

It's relatively straightforward. It's a
bit of math and I didn't want to put in

any formulas but yeah. Now as I said it
was discovered in 1998. So TLS 1.0

introduced some countermeasures. The
general idea here is that if you decrypt

something and it is wrong then you're
supposed to replace it with a random value

and use that random value as your secret
and pretend nothing has happened and then

continue and then the handshake will fail
later on because you don't have the same

key. This prevents the attacker from
learning whether your data is valid or

not. In 2003 a research-team figured out
that the countermeasures how they were

described and TLS 1.0 were incomplete and
also not entirely, it was not entirely

clear how to implement them. Because
there's this version-thing and it was not

exactly described how to handle that. If
only the version is wrong. So they they

were able to make, to create an attack
that still worked despite this

countermeasures. So more countermeasures
were proposed and in 2014 there was a

paper that Java was still vulnerable to
Bleichenbacher-attacks in a special way

because they used some kind of decoding,
then raised an exception. And the

exception was long enough that you could
measure the timing difference. And there

was also still a small issue in OpenSSL
although that was not practically

exploitable. In 2016 there the so-called
drown-attack. And the drown-attack was a

Bleichenbacher-attack in SSL version 2.
Now you may wonder SSL-version 2 is this

very very old version from 1995. Is this a
problem? But it actually is because you

can use encrypted data from a modern TLS-
version, TLS 1.2, and and decrypt it with

a server that still supports SSL version
2. So that was the drown-attack. And then

last year I thought maybe someone should
check if there are still servers

vulvernable to these Bleichenbacher-
attacks. So I wrote a small scan tool and

started scanning, and scanned the Alexa
top-1000000. The first hit was

Facebook.com was vulnerable and it turned
out from the top-100 pages roughly 1/3

were vulnerable. And in the end we found
like 15 different implementations that

were vulnerable. Probably more but these
were the ones we know about. Yeah. And

just I think a month ago there was another
paper, that there also you can use cache-

sidechannels which is mostly interesting
if you have cloud-infrastructure where

multiple servers are running on the same
hardware, which you can also use to

perform these Bleichenbacher-attacks. Now
what I want to show you here: You cannot

read this because it's too small but this
is the chapters in the TLS-standard that

describe the countermeasures to these
Bleichenbacher-attacks. So we knew about

them since before TLS 1.2, so there was a
small chapter what you should do to

prevent these attacks. And then they
figured out: OK that's not enough. We need

to have more countermeasures, and even
more. So, what you can clearly see here is

it's getting more and more complicated to
prevent these attacks. So with every new

TLS-version we had more complexity to
prevent these Bleichenbacher-attacks.

These were just two examples. There were a
lot more attacks on TLS 1.2 and earlier

that were due to poor design choices. I've
named a few here: SLOTH, which was all

against weak caches, FREAK which can
attack issues in the handshake and

compatibility with old versions, SWEET32
which attacks some block-ciphers that have

a small blocksize, Triple-Handshake which
is a very complicated interaction of

different handshakes. The general trend
here was that in TLS 1.2 and earlier, if

there was a security bug, if there was a
vulnerability in the cryptography, what

people did was: We need a workaround for
the security issue. And then if this

workaround doesn't work it's not
sufficient. We need more workarounds. And

also we create more secure modes but we
still keep the old ones. And then people

can choose. We have this algorithm
agility. You can choose, there's the

secure algorithm, there's the less secure
algorithm. Take whatever you want. Which

in practice meant very often still the
insecure modes were used because like for

all of these things there were modes
available in TLS 1.2 that didn't have

these vulnerabilities. But they were
optional. But, and I think that is the

major change that came with TLS 1.3, was a
mindset-change that people said, okay if

something has vulnerabilities, if it's
insecure and if we have something better

then we just remove the thing that is
vulnerable, that is problematic. So the

main change in TLS 1.3 was that a lot of
things were deprecated. So we no longer

have these CBC-modes. We no longer have
our RC4 which is another cipher which was

problematic. We no longer have 3DES, which
has these small blocksizes. We still use

GCM but we no longer use it with an
explicit nonce, which also turned out to

be problematic. We completely remove RSA-
encryption. We still use RSA but only for

signatures. We remove hash-functions that
turned out to be insecure. We remove

Diffie-Hellman with custom parameters,
which was, yeah, which turned out to be

very problematic. And we removed ecliptic-
curves that kind of look not so secure.

But also there was something that some
academics looked at TLS with the more

scientific view. They tried to formally
understand the security protocol,

properties of this protocol and to analyze
them to see if they can proof some kind of

security properties of the protocol. And
many vulnerabilities that I mentioned

earlier were found by these researchers
trying to formally analyze the protocol.

But also these analyses have contributed
to design TLS 1.3 to make it more robust

to attacks. So this is, I think, also a
big change. There was a much better

collaboration between scientists who were
looking at the protocol and the people who

were actually writing the protocol. But
you may see, all the security is nice but

what we really care about or maybe some
people really care about is speech, right.

We want our internet to be fast. We want
to open our browser and immediately get

the page loaded. And TLS 1.3 also brings
improved speed. And I am showing here the

handshake. And this is very simplified. I
have kind of only added the things that

matter to make this point. But, if you
look at on the left, if we do a handshake

with an old TLS-version it starts that
this client sends a client-hello, and some

information, what version it supports,
what encryption modes it's supports. Then

the server sends back which encryption
modes it wants to use and a key

exchange. And then the client sends his
part of the key exchange. And the so-

called finished message and then the
server sends a finished message and then

the client can start sending data. In TLS
1.3 we have compressed this all a bit. The

client sends his client-hello and
immediately sends a key-exchange message.

And then the server answers with his key-
exchange message. And a few more things

that I left out for simplicity. But the
important thing is that with the second

message the client can already send data.
And this is the situation for a fresh

handshake. Like we have not communicated
before. I want to make a new connection to

a server and it goes one time back and
forth. And then I can send data. Which,

and in the earlier version I had two times
back and forth. So I can send data much

faster. So yeah, we remove one round-trip
from a fresh handshake. There's also

security improvements to this handshake.
So this is nice. We have more security and

more speed. And particularly we have
better security on so-called session-

resumption, which means we're reconnecting
using a key from a previous section. And

we also protect more data which may avoid
some attacks where an attacker may fiddle

with the handshake. These were more or
less theoretic attacks. But these are also

prevented in TLS 1.3. Yeah. So TLS has a
more secure and a faster handshake. And if

you want to have more details about this
handshake there was a talk two years ago

at this congress, which goes into this in
much more detail. So if this particularly

interests you you should watch that talk.
I've put a link here and I will put the

slides online. There's also something
called the zero-roundtrip-handshake. And

this is even faster. We can send data
right away. Now, how can we do that? This

is kind of cheating because what we need
here is we need to have a previous

connection. And then we have a key from a
previous connection, can create a new key

from that and use that to send data right
away. So yeah, we need a so-called

preshared-key which we have from previous
connection and then we can send data

without any roundtrips. So, even more
speed. That's nice, right. But this 0-RTT-

mode does not come for free. There is a
problem here with so-called replay-

attacks, which means an attacker could
record the data that we're sending and

then send it again. And the server may
think: Okay, now this request came twice.

So I'm doing twice what this request was
supposed to do. So there are some caveats

with 0-RTT and the standard says you
should only use if it's safe. It says

something like you should only use it if
you have a profile how to use it safely.

Now what does that mean? There, let's look
at https, the protocol we're using

usually. If you look into the HTTP-
standard it says something that a GET-

request has to be idempotent and a POST-
request does not have to be idempotent.

Now what does that mean? It more or less
means if you send a request twice it

shouldn't do anything different from just
sending it once. So in theory we could say

yes a GET-requests are idempotent - that
means they are safe for zero-roundtrip-

connections. The question is, "do web-
developers" ... Sorry.

applause
You can do a little experiment: If you

meet someone who is a web developer, ask
them if they know what idempotent means,

and when they can use idempotent requests
and when they cannot. So, in an ideal

situation where web-developers do know
that, we can use 0-RTT safely with TLS

1.3. 0-RTT also does not have a strong
forward secrecy as a normal handshake. So,

there's kind of a tradeoff here, because
this pre-shared key is encrypted with a

key on the server and if that key gets
compromised that may compromise our

connection even if the key is only leaked
later on. So, this looks a bit problematic

and many speculate that the future attacks
we'll see on TLS 1.3, that at least some

of them will focus on this 0-RTT mode,
because it looks like one of the more

fragile parts of the protocol. But it
gives us more speed., so people wanted to

have it. Maybe the good news is, this is
entirely optional; we don't have to use

it; and if we think this looks too
problematic, we can switch it off. So, if

it turns out that there are too many
attacks involving 0-RTT mode, we could

disable it again and use it without it. It
will still be faster, but not as fast as

it could be with this. Okay. Deployment:
Now, if we have this nice new protocol, we

not only have to make sure it's secure and
fast and everything, but we also have to

deploy it. And we have to deploy it on the
internet - on the real internet - like the

one we have out there, not some
theoretical internet where there are no

bugs and everyone knows how to implement
protocols, but the real internet with lots

of IoT devices and enterprise firewalls
and all these kinds of things. And now I

want to get back to this version number.
This may sound like a trivial thing, but

TLS 1.3 has a new version number for the
protocol version. Here's a Wireshark dump

from a TLS 1.3 handshake. And if you're
trying to look for the version number, you

will find multiple version numbers. And in
case you cannot see it, I have made it a

bit larger. So at the top you see
"Version: TLS 1.0", encoded as 0x0301.

Okay. That looks strange. Then, a few
lines later, you have "Version TLS: 1.2",

0x0303. But we thought this was TLS 1.3...
I mean it says here at the top but somehow

there are these other versions. And then
if you scroll further down, you will see

"Extension: supported_versions". And then
here it lists TLS 1.3, which is encoded as

0x0304. So, what's going on here? This
looks strange. So, the first thing to

realize is why do we encode these versions
in such a strange way; why are we not

using 0x0100 for TLS 1.0? It's TLS 1.0
came after SSL version 3, which kind of

makes it version 3.1; and that's how we
encode it. TLS 1.0 is really just SSL

version 3.1, TLS 1.1 is SSL version 3.2
and so on and for TLS 1.3, it's

complicated. So, the very first version
you saw earlier in this Wireshark dump was

the so-called record layer and this is
kind of a protocol inside the TLS protocol

which has its own version number, which is
totally meaningless but it's just there.

And it turned out, for compatibility
reasons, it's best to just let this on the

version of TLS 1.0 and then, we have the
least problems. And this is kind of...

this record layer protocol is kind of the
encoding of the TLS packages. Now, if we

have a new TLS version, we cannot just
tell everyone "tomorrow we will use TLS

1.3" and everyone has to update, because
we know many people won't. And so, we

somehow need to be able to deploy this new
version and still be compatible with

devices that only speak the old version.
So, let's assume we have a client that

supports TLS 1.2, and we have a server
that only supports TLS 1.0. How does that

work? That's an extremely complicated
mechanism here. So, the client connects

and says "Hello. I speak TLS 1.2". Server
says "Okay, I don't know TLS 1.2, but

what's the highest version I support?"
It's TLS 1.0, so he sents that back. And

then, they can speak TLS 1.0 and - in case
the client still supports that - and we

have a connection. This is very simple. I
would think so. So, to illustrate how you

would program something like that, you
would say "Yeah, if client_max_version is

smaller than than server_max_version, then
we use the client_max_version. Otherwise,

we use the server_max_version. So, you
would think that there's no way anyone

could possibly not get that right, right?
I mean, it's very simple. But I was saying

earlier, we were talking about the real
internet. So... And on the real internet,

we have enterprise products. In case you
don't know that, an enterprise product is

something that's very expensive and it's
buggy.

LaughterApplause
hanno: So, yeah. We will have web pages

that run with firewalls from Cisco or we
will have people using IBM Domino web

server and all these kinds of things. And
this is the TLS version negotiation in the

enterprise edition. So a client says "Yeah
I want to connect with TLS 1.2" and the

server says "Oh I don't support this this
very new version. It's from 2008. I mean

that's 10 years in Enterprise years.
That's very long." So the server just

sends an error if the client connects with
the TLS version that it doesn't know. It

doesn't implement this version negotiation
correctly. And this is called version

intolerance. This has happened every time
there was a new TLS version. Every time we

had devices that had this problem. If we
tried to connect with the new TLS version

they would just fail. They would send an
error or they would just cut the

connection or have a timeout or crash. So
browsers needed to handle this somehow

because the problem here is, when a
browser introduces new TLS version and

everything breaks, then users will blame
the browser and then they will say "Yeah I

will no longer use this browser, I'll now
switch back to Internet Explorer" or

something like that. So browsers needed to
handle this somehow. What the browsers did

was "Okay, we try it with the latest TLS
version we support. And if we get an error

we try it again with one version lower.
And again one version lower and eventually

we may succeed to connect." So here we
have a browser and we have an enterprise

server that supports TLS 1.0 and we will
eventually get a connection. Do you

remember POODLE I mentioned earlier? There
was this padding oracle in SSLv3, which

was discovered in 2014. You may wonder
SSLv3 which is from 1996, that's really

old. Who uses that in 2014? It was
deprecated for 16 years. I mean who uses

that? Windows Phone 7 used it. On this
Nokia phones they also never got an

update. Normal browsers and servers at
least used TLS 1.0. They maybe didn't use

TLS 1.2, but they used TLS 1.0. But we
have these browsers that are trying to

reconnect if there's an error. And so what
an attacker could do is that the attacker

wants to exploit SSLv3. So he just blocks
all connections with the newer TLS version

and therefore forces the client to go into
SSLv3. And then he can exploit this attack

that only works on SSLv3. These downgrades
are causing security issues. What do we do

now? We could add another work workaround.
There was a standard called SCSV which

basically gives the server a way to tell
the client that it's not broken. It says

"hey, I have this kind of special cipher
suite" which tells the client "hey, if you

did these strange downgrades here, please
don't do that. I'm a well behaving

server." So we had a workaround for broken
servers and then we needed another

workaround for the security issues caused
by those workarounds. But at some points

even enterprise servers mostly had fixed
this version intolerance issues and

browsers stopped doing these downgrades.
Attacks like POODLE no longer worked.

However I just said they fixed it. No of
course they have not fixed it. I mean they

fixed it for TLS 1.2. But of course they
did not fix it for future TLS versions

because they were not around yet. This TLS
1.3, we would get version intolerance

again and breaking servers and would have
to introduce downgrades again and all the

nice security would not be very helpful.
The TLS working group realized that and

redesigned the handshake. It was
redesigned in a way that the old version

fields still said that we are connecting
with TLS 1.2 and then we introduce an

extension, supported_versions, which
signals the support for all the TLS

versions we can speak and which signals
support for TLS 1.3 and possibly for

future versions. Now at this point you may
wonder if we'll have version intolerance

with this new extension, once TLS 1.4 gets
out because the server may be implemented

that it sends an error if it sees an
unknown version in this new version

extension. David Benjamin from Google
thought about this and said "Yeah we have

to do something about that. We have to
improve the future compatibility for

future TLS versions." And he invented this
GREASE mechanism. The idea here is, a

server should just ignore unknown versions
in this extension. He gets a list of TLS

versions and if there's one in there that
he doesn't know about, he should just

ignore it and then connect with one of the
versions he knows about. So we could kind

of try to train servers to actually do
that. And the idea here is we're just

sending random bogus TLS versions that are
reserved values that will never be used

for a real TLS version. But we can just
randomly add them to this extension in

order to make sure that if a server
implements this incorrectly, they will

hopefully recognize that early because
there will be connection failures with

normal browsers. The hope here is if
enterprise vendors will implement a broken

version negotiation, they will hopefully
notice that before they ship the product

and then it can no longer be updated
because that's how the Internet works. So

we have this new version negotiation
mechanism we no longer need these

downgrades and we have this GREASE
mechanism to make it future proof. So now

we can ship TLS 1.3, right? Then there was
this middle box issue. Oh sorry, that's a

wrong year. It must be 2016, sorry. In
2016, in summer, TLS 1.3 was almost

finished. But then it took almost another
year till it got out. Oh sorry, I mixed up

the years. It's correct. In 2017, when TLS
1.3 was almost finished, but it took until

2018 until it was actually finished. The
reason for that was that when browser

vendors implemented a draft version of TLS
1.3, they noticed a lot of connection

failures. And the reason for these
connection failures turned out, were

devices that were trying to analyze the
traffic and trying to be smart. And they

thought "OK this is something that looks
very strange. It doesn't look like a TLS

package how we're used to it. So let's
just drop it, yeah?" So "Yeah, this is a

strange TLS package, I don't know what
to do with this, I'll drop it." These were

largely passive middle boxes. So we're not
talking about things like man in the

middle devices that are intercepting a TLS
connection but just something like a

router, where you would expect it just
forwards traffic. But it tries to be

smart, it tries to do advanced security
enterprise. I don't know. And they were

dropping traffic that looked like TLS 1.3
Then the browser vendors proposed some

changes to TLS 1.3 so it looks more like
TLS 1.2. The main thing was, they

introduced some bogus messages from TLS
1.2 that were supposed to be ignored. So

one such message is the so-called
ChangeCipherSpec message in TLS 1.2, which

originally didn't exist in 1.3 due to this
new handshake design. This message in 1.2,

it signals that everything from now on is
encrypted. The idea was "okay, if we sent

a bogus ChangeCipherSpec message early in
the handshake, then maybe this would

confuse those devices, thinking everything
after that is encrypted and they cannot

analyze it." And it turned out this
worked. A lot of this reduced the

connection failures a lot. There are a few
other things. And then eventually the

failure rates got low enough that browsers
thought "Okay, now we can deploy this."

There were a few more issues. This is a
Pixma printer from Canon. These things

have an HTTPS server. They have network
support. And we have to talk about these

people here. If you remember the Snowden
relations, one of the things that got

highlighted there was that there's a
random number generator called Dual EC

DRBG. And that has a backdoor and
basically these days everyone believes

this is a backdoor by the NSA and they
have some secret keys so they can predict

what random values this RNG will output.
Also what was in the Snowden documents was

that at some point the NSA offered 10
million dollars to RSA security, so they

implement this RNG. Then there was a
proposal, a draft, for a TLS extension,

called Extended Random, that adds some
extra random numbers to the TLS handshake.

Why? It wasn't really clear like it was
just "Yeah we can do this." It was just a

proposal. I mean everyone can write a
proposal for a new extension, it was never

finalized, but it was out there. And in
2014, a research team looked closer at

this Dual EC RNG and figured out that if
you use this ER extension then it's much

easier to exploit this backdoor in this
RNG. And coincidentally RSA's TLS library,

BSAFE, also contains support for that
extension. But it was switched off. They

didn't find any implementations that
actually used it. So it was thought of

"okay, this was no big deal, all right".
But actually it seems these these Canon

printers, they had enabled this extension.
They use this RSA BSAFE library and

enabled this ER extension, which was only
a draft. And so as ER was only a draft, it

had no official extension number. So such
a TLS extension has a number so that the

server knows what kind of extension this
is. And for this implementation they just

used the next available number. And it
turned out that this number collided with

one of the mandatory extensions that TLS
1.3 introduced. So these these Canon

printers could not interpret that new
extension. They thought this is this

Extended Random and it didn't make any
sense, and so you had connection failures.

In the TLS protocol they just gave this
extension a new number and then this no

longer happened. There were many more such
issues and they continue to show up. For

example recently, Java, which is like also
very popular in enterprise environments,

it now ships with TLS 1.3 support but it
doesn't really work. So you have

connection failures there. Now with all
these deployment issues, what about future

TLS versions? Will we have all that again?
And we have this GREASE mechanism and it

helps a bit like it prevents this version
intolerance issues but it doesn't prevent

these more complicated middle box issues.
There was a proposal from David Benjamin

from Google who said "Yeah, maybe we
should just, every few months, like every

two or three months, ship a new temporary
TLS version which we will use for three

months and then we will deprecate it again
to just constantly change the protocol so

that the Internet gets used to the fact
that new protocols get introduced."

Laughter
My prediction here is that these

deployment issues are going to get worse.
I mean, we know now that they exist and we

kind of have some ideas how to prevent
them, but if you go to enterprise security

conferences, you will know that the latest
trend in enterprise security is this thing

called artificial intelligence: We use
machine learning and fancy algorithms to

detect bad stuff. And that worries me. And
here's a blog post from Cisco, where they

want to use machine learning to detect bad
TLS traffic, because they see all this

traffic is encrypted and we can no longer
analyze it, we don't know if malware in

there, so let's use some machine learning;
it will detect bad traffic. So, what I'm

very worried that will happen here is that
the next generation of TLS deployment

issues will be AI-supported TLS
intolerance issues and it may be much

harder to fix and analyze. Speaking of
enterprise environments, one of the very

early changes in TLS 1.3 was that it
removed the RSA encryption handshake. One

reason was that it doesn't have forward
secrecy. The other was these, all these

Bleichenbacher attacks that I talked about
earlier. And then, there came an email to

the TLS working group from the banking
industry and I quote: "I recently learned

of a proposed change that would affect
many of my organization's member

institutions: the deprecation of the RSA
key exchange. Deprecation of the RSA key

exchange in TLS 1.3 will cause significant
problems for financial institutions,

almost all of whom are running TLS
internally and have significant, security-

critical investments in out-of-band TLS
decryption." What it basically means is,

they are using TLS for some connection;
they have some device in the middle that

is decrypting the traffic and analyzing it
somehow which - if they do it internally -

it's okay, but this no longer works with
TLS 1.3, because we always negotiate a new

key for each connection and it's no longer
possible to have the static decryption.

There was an answer from Kenny Patterson,
he's a professor from London, he said: "My

view concerning your request: no.
Rationale: We're trying to build a more

secure internet."
Applause

"You're a bit late to the party. We're
metaphorically speaking at the stage of

emptying the ash trays and hunting for the
not quite empty beer cans. More exactly,

we are at draft 15 and RSA key transport
disappeared from the spec about a dozen

drafts ago. I know the banking industry is
usually a bit slow off the mark, but this

takes the biscuit." Okay.
Laughter

There were several proposals then to add a
visibility mode to TLS 1.3, which would in

another way allow these connections that
could be passively observed and decrypted,

but they were all rejected and the general
opinion in the TLS working group was that

the goal of monitoring traffic content is
just fundamentally not the goal of TLS.

The goal of TLS is to have an encrypted
channel that no one else can read. The

industry eventually went to ETSI, which is
the European technology standardization

organization, and they recently published
something called Enterprise TLS...

Laughter
...which modifies TLS 1.3 in a way that it

would allow these decryptions. The IETF
protested against that and primarily

because of the... they used the name TLS,
because it sounds like this is some

addition to TLS or something, and
apparently ETSI has previously promised to

them that they would not use the name TLS
and then they named it Enterprise TLS.

Okay, but yeah... TLS 1.3 is finished. You
can start using it. You should update your

servers so that they use it. Your browser
probably already supports it. So, in

summary: TLS 1.3 deprecates many insecure
constructions. It's faster and deploying

new things on the internet is a mess. So,
yeah. That's it. And I think we have a few

minutes for questions.
Applause

Herald: Alright, yeah. As Hanno mentioned, we
have 6 minutes or so for questions. We

have 5 microphones in the room. So, if you
want to ask a question, hurry up to one of

the microphones and please make sure to
ask a short, concise question, so that we

can get as many in as we can possibly can.
Maybe, you just go ahead over there. Mic

2.
Mic 2: Thank you very much for this

interesting talk. Is there a way to
prevent the uses of this Enterprise TLS?

Hanno: The question is if there is a way
to prevent the use of that Enterprise TLS.

Yes, there is, because the basic idea is
that they will use a static Diffie-Hellman

key exchange and if you just connect twice
and see that they are using the same

again, then you may reject that. Although
the problem is, some servers may also use

that for optimization. So, there are
longer discussions on this question, so...

I cannot fully answer it, but there more
or less... there are options.

Herald: Alright. Before we go to the next
question, a quick request for all the

people leaving the room: Please do so as
quietly as possible, so we can finish this

Q&A in peace and don't have all this noise
going on. Mic 3, please.

Mic 3: Hi. I was wondering about the
replay attacks. Why didn't they implement

something like sequence numbers into the
TLS protocol?

Hanno: Yeah. There is something like that
in there. The problem is, you sometimes

have a situation where you have multiple
TLS termination points - for example, if

you have a CDN network that is
internationally distributed - and you may

not be able to keep state across all of
them.

Herald: Alright. Then, let's take a
question from our viewers in the internet.

The signal angel, please.
Signal angel: Alright. Binarystrike asks:

"With regards to TLS 1.3 in the
enterprise, shouldn't we move away from

perimeter interception devices to also
putting control on the end point, like we

would have in a zero-trust environment?"
Hanno: So, in my opinion, yes. But, there

are many people in the enterise security
industry who think that this is not

feasible. But, I mean, discussion about
network design, that would be a whole

other talk. Yeah.
Herald: Alright. Then, let's take a

question from mic 4.
Mic 4: Yeah. It's also related to the

Enterprise TLS. The browser can connect to
an Enterprise TLS server without any

problems?
Hanno: Yeah. So, it's built that it's

compatible with the existing TLS protocol.
Mic 4: Okay, thanks.

Hanno: And the reason of whether you can
avoid that or not, that's really a more

complicated discussion, that would kind of
be a whole sub-talk, so I cannot answer

this in a minute, but come to me later if
you are interested in details.

Herald: Alright. Then, let's take another
question from the interwebs.

Signal Angel: We have one more question
from IRC: "Would you recommend

inserting bogus values into handshakes to
train implementors?"

Hanno: I mean that what I said what is
done, that's actually what browsers are

doing, and I think this is a good idea. I
just think that this covers only a small

fraction of these deployment issues.
Herald: Okay, we still have plenty of

time, so let's go to mic 2 please.
Mic 2: Yeah, as you said, we have still a

lot of dirty workarounds concerning TLS
1.3 and all the implementatons in the

browers and so on. Is there a way to make,
like, a requirement for the TLS 1.3 or 1.4

compliance to meet some compliance to the
standard? So you have like a test you can

perform, a self-test or something like
that and if you pass that you are allowed

to use the TLS 1.3 logo or 1.4 logo.
Hanno: You can do that in theory. The

problem is you don't really want to have a
certification regime that people like have

to ask for a logo to be able to be allowed
to implement TLS. and I mean that's kind

of one of the downsides of the open
architecture of the Internet, right? We

allow everyone to put devices on the
Internet, so we kind of have to live with

that. And there's no TLS police, so, we
kind of have no way of preventing people

to use broken TLS implementations. And I
mean people won't care if they have a logo

for it or not, right?
Herald: Alright, let's go to mic 5 all the

way in the back there.
Mic 5: Okay. I have a question about

Shor's algorithm and TLS 1.3, because
since quantum computing is getting very

popular lately and there are a lot of
improvements in the industries, so what's

the current situation regarding TLS 1.3
and all those quantum-based algorithms

that break the complexity into polynomial
times?

Hanno: There's no major change here. So,
with TLS 1.3 you still are using

algorithms that can be broken with quantum
computers if you have a quantum computer.

Which currently you don't, but you may
have in the future. There is work done on

standardizing future algorithms that are
safe from quantum attacks, but that's kind

of in an early stage. And there was an
experiment by Google to introduce a

quantum-safe handshake, but they only ran
it for a few months. But, I think we will

see extensions within the next few years
that will introduce quantum-safe

algorithms, but right now there's no
change from TLS 1.2 to 1.3. Both can be

attacked with quantum computers.
Herald: Okay, so I think we are getting to

our last or second to last question, so
let's go to mic 3, I think you've been

waiting the longest.
Mic 3: Okay. In older versions of TLS

there was a problem for small devices such
as IoT and the industrial devices. Has

there been a change in 1.3 to allow them
to participate?

Hanno: I mean I'm not sure what entirely
you mean with the problem, I mean...

Mic 3: Of performance, of performance.
Hanno: ...of course TLS needs some... the

performance issues of TLS have usually
been overstated. So even in a relatively

low-power device you can implement the
crypto. I mean the whole protocol is

relatively complex and you need to
implement it somehow, but I don't think

that's such a big issue anymore because
even IoT devices have relatively powerfull

processors these days.
Herald: Okay, alright, that concludes our

Q&A, unfortunately we are out of time. So
please give a huge round of applause for

this great talk.

applause

35C3 postroll music

subtitles created by c3subtitles.de
in the year 2019. Join, and help us!