< Return to Video

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

  • 0:00 - 0:18
    35C3 preroll music
  • 0:18 - 0:24
    Herald-Angel: All right. Now it's my very
    big pleasure to introduce Hanno Böck to
  • 0:24 - 0:32
    you. He's no stranger to the Chaos crowd.
    He's been to several Easterheggs and at
  • 0:32 - 0:38
    several other Chaos events. Today he's
    here to talk about TLS 1.3, what it's all
  • 0:38 - 0:44
    about how it came to be and what the
    future of it is gonna look like. Please
  • 0:44 - 0:58
    give a huge applause and welcome Hanno.
    hanno: Yeah. Okay. So today I want to talk
  • 0:58 - 1:04
    to you about a new version of TLS. TLS is
    this protocol, Transport Layer Security,
  • 1:04 - 1:10
    which I hope everyone knows what it is.
    It's a protocol that you can put on top of
  • 1:10 - 1:16
    other protocols that gives us an encrypted
    and authenticated channel through the
  • 1:16 - 1:26
    generally insecure internet. We have a new
    version since August, TLS 1.3. At first
  • 1:26 - 1:31
    I'd like to go a bit into the history of why we
    have this new version, how we got there
  • 1:31 - 1:41
    and what design decisions were made for
    this version. So the very first version of
  • 1:41 - 1:47
    SSL which it was called back then was
    released in 1995 by Netscape and it was
  • 1:47 - 1:55
    quickly followed up with version 3 which
    is still very similar to the TLS 1.2 that
  • 1:55 - 2:01
    we mostly use today. And then in 1999 it
    was kind of taken over from Netscape to
  • 2:01 - 2:06
    the IETF, which is the Internet
    standardization organization, and they
  • 2:06 - 2:12
    renamed it to TLS. And so that's kind of
    the history. We had SSL and I've marked it
  • 2:12 - 2:18
    in red because these two versions are
    broken by design. You cannot really use
  • 2:18 - 2:23
    them in a way that is secure these days
    because we know vulnerabilities that are
  • 2:23 - 2:31
    part of the protocol. And then we had, in
    1999 it was renamed to TLS, and TLS is
  • 2:31 - 2:36
    kind of still kind of OK if you do
    everything right. But that's really
  • 2:36 - 2:41
    tricky. So it's kind of a dangerous
    protocol but maybe not totally broken.
  • 2:41 - 2:47
    Same with TLS 1.1. TLS 1.2 is what we
    still mostly use today and TLS 1.3 is the
  • 2:47 - 2:52
    new one and what you can see here for
    example is that the the biggest gap here
  • 2:52 - 3:00
    is between 1.2 and 1.3, so it was a very
    long time where we had no new development
  • 3:00 - 3:09
    here. You probably heard that we had
    plenty of vulnerabilities in TLS, around
  • 3:09 - 3:16
    TLS and also these days, a good
    vulnerability always has a logo and a nice
  • 3:16 - 3:23
    name. And I want to go into one
    vulnerability which doesn't have a logo.
  • 3:23 - 3:29
    Not one of the variants. I was very
    surprised when I realized that. That's the
  • 3:29 - 3:35
    so-called Padding Oracles. They are in CBC
    mode which is the encryption we use for
  • 3:35 - 3:44
    the actual data encryption, the symmetric
    data encryption. The thing is, when we
  • 3:44 - 3:51
    encrypt data what we usually use are so-
    called block ciphers and they encrypt one
  • 3:51 - 4:00
    block off a specific size of data. It's
    usually sixteen bytes and this CBC mode
  • 4:00 - 4:07
    was the common way to encrypt in past TLS
    versions. And this is roughly how it looks
  • 4:07 - 4:11
    like. So we have some initialization
    vector which should be random, but wasn't
  • 4:11 - 4:19
    always, but that's another story. And then
    we encrypt a block of data and then we XOR
  • 4:19 - 4:27
    that encryption into the next plain text
    and encrypt it again. Now one thing here
  • 4:27 - 4:32
    is that because these are blocks of data
    and our data may not always be in sixteen
  • 4:32 - 4:38
    byte blocks it may just be five bytes or
    whatever, we need to fill up that space.
  • 4:38 - 4:47
    So we need some kind of padding. In TLS,
    what was done was that first of all we had
  • 4:47 - 4:53
    some data. Then we added a MAC, which is
    something that guarantees the correctness
  • 4:53 - 4:58
    of the data, the authentication of the
    data. And then we pad it up to a block
  • 4:58 - 5:03
    size and then we encrypt it. And this
    order of things turned out to be very
  • 5:03 - 5:11
    problematic. So this padding is a very
    simple method. If we have one byte to fill
  • 5:11 - 5:17
    up we make a 00. If we have two bytes to
    fill up well you make 0101, three bytes
  • 5:17 - 5:28
    020202 and so on. So that's easy to
    understand, right? Let's for a moment
  • 5:28 - 5:35
    assume a situation where an attacker can
    manipulate data and can see whether the
  • 5:35 - 5:42
    server receives a bad padding or whether
    it receives bad data, where this MAC check
  • 5:42 - 5:52
    goes wrong. And here is the decryption
    with CBC mode. And what an attacker can do
  • 5:52 - 5:57
    here: the first thing the attacker does,
    it throws one block away at the end, it
  • 5:57 - 6:04
    just blocks the transmission of that block
    and then it changes something here. So
  • 6:04 - 6:11
    what we assume here is the attacker wants
    to know this decrypted byte because it may
  • 6:11 - 6:18
    contain some interesting data. So what he
    can do is he can manipulate this byte with
  • 6:18 - 6:27
    a guess and a byte is only 256 values a
    byte can have. So he can guess enough
  • 6:27 - 6:36
    times and XOR it with this value. And if
    you think about it if we XOR it here with
  • 6:36 - 6:41
    the plaintext. That means if we end up
    with this zero here then the padding is
  • 6:41 - 6:46
    valid. If we end up with some garbage
    value here, then the padding is probably
  • 6:46 - 6:55
    invalid. So by making enough guesses the
    attacker can decrypt a byte here under the
  • 6:55 - 7:01
    condition that he learns somehow whether
    the padding is valid or not. So he could
  • 7:01 - 7:07
    decrypt one byte but he can't go on. Let's
    assume we will learn that one byte we have
  • 7:07 - 7:15
    decrypted it and then we can go on with
    the next byte. So we XOR this byte on the
  • 7:15 - 7:23
    right with the guess with what we already
    know that it is and with the one and. Then
  • 7:23 - 7:31
    we XOR this next byte with our guess and
    also a one. And if this ends up being 0101
  • 7:31 - 7:36
    then again we have a valid padding. So the
    attacker learns the next byte and he can
  • 7:36 - 7:44
    do this for other bytes. This was
    originally discovered in 2002 by Sergey
  • 7:44 - 7:51
    Vaudenay. But it was kind of only
    theoretical. So one thing here is that TLS
  • 7:51 - 7:58
    has these error messages. There are
    different kinds of errors. And if you read
  • 7:58 - 8:06
    through the TLS 1.0 standard, if the
    padding is wrong then you get this
  • 8:06 - 8:11
    decryption_failed error. And if the MAC is
    wrong, so the data has some modification,
  • 8:11 - 8:16
    then you get this bad_record_mac error. So
    you could say this would allow this
  • 8:16 - 8:22
    Padding Oracle attack because there are
    these error messages. But the attacker
  • 8:22 - 8:26
    cannot see them because they are
    encrypted. So this was kind of only a
  • 8:26 - 8:33
    theoretical attack which didn't really
    work on a real TLS connection. But then
  • 8:33 - 8:38
    there was a later paper which made this
    attack practical by measuring the timing
  • 8:38 - 8:43
    difference from these different kinds of
    errors. And this allowed a practical
  • 8:43 - 8:52
    decryption of TLS traffic. Then in later
    versions of TLS this was fixed or kind of
  • 8:52 - 8:57
    fixed. But there is a warning in the
    standard which says.. So this is right
  • 8:57 - 9:02
    from the standard text. "This leaves a
    small timing channel but it is not
  • 9:02 - 9:07
    believed to be large enough to be
    exploitable." If you read something like
  • 9:07 - 9:16
    that, it sounds maybe suspicious, maybe
    dangerous. And actually in 2013 there was
  • 9:16 - 9:20
    these so-called Lucky Thirteen attack
    where a team of researchers actually
  • 9:20 - 9:26
    managed to exploit that small timing side
    channel that the designers of the standard
  • 9:26 - 9:35
    believed was not large enough to be
    exploitable. It is in theory possible to
  • 9:35 - 9:40
    implement TLS in a way that it is safe
    from this timing attacks. But it adds a
  • 9:40 - 9:45
    lot of complexity to the code. If you just
    look at when Lucky Thirteen was fixed, it
  • 9:45 - 9:52
    just made the code much longer and much
    harder to understand. Then there was
  • 9:52 - 9:57
    another Padding Oracle which was called
    POODLE, which was in the old version
  • 9:57 - 10:04
    SSLv3. This was kind of by design. So the
    protocol was built in a way that you could
  • 10:04 - 10:11
    not avoid this Padding Oracle. Then it
    turned out that there was also a kind of
  • 10:11 - 10:18
    TLS variation of this POODLE attack. And
    the reason here was that the only major
  • 10:18 - 10:27
    change between SSLv3 and TLS 1.0 was that
    the padding was fixed to a specific value,
  • 10:27 - 10:31
    where in the past it could have any value.
    It turned out that there were TLS
  • 10:31 - 10:36
    implementations that were not checking
    that, enabling this poodle attack also in
  • 10:36 - 10:45
    TLS. Then there was the so-called Lucky
    Microseconds attack which was basically
  • 10:45 - 10:50
    the.. one of the people who has found the
    Lucky Thirteen attack looked at
  • 10:50 - 10:56
    implementations and saw if they have fixed
    Lucky Thirteen properly. They looked at
  • 10:56 - 11:01
    s2n, which is an SSL library from Amazon
    and they found: "Ok, they tried to make
  • 11:01 - 11:05
    countermeasures against this attack but
    these countermeasures didn't really work
  • 11:05 - 11:13
    and they had still a timing attack that
    they could perform." Then there was a bug
  • 11:13 - 11:20
    in OpenSSL which was kind of funny because
    when OpenSSL tried to fix this Lucky
  • 11:20 - 11:25
    Thirteen attack, they introduced another
    Padding Oracle attack which was actually
  • 11:25 - 11:34
    much easier to exploit. We had plenty of
    Padding Oracles. But if you remember back
  • 11:34 - 11:39
    what I said, for the very first attack
    that this didn't really work in practice
  • 11:39 - 11:47
    in TLS, because these errors are
    encrypted. But theoretically you could
  • 11:47 - 11:52
    imagine that someone creates an
    implementation that sends errors that are
  • 11:52 - 12:02
    not encrypted. For example you can send a
    TCP error or just cut the connection or
  • 12:02 - 12:06
    have any kind of different behavior
    because the whole attack just relies on
  • 12:06 - 12:13
    the fact that you can distinguish these
    two kinds of errors. You can find
  • 12:13 - 12:24
    implementations out there doing that. So
    yeah, Padding Oracle is still an issue.
  • 12:24 - 12:28
    Then I want to look at another attack
    which is a so-called Bleichenbacher
  • 12:28 - 12:33
    attacks and they target the RSA encryption
    and that is kind of the asymmetric
  • 12:33 - 12:41
    encryption which we use at the beginning
    of a connection to establish a shared key.
  • 12:41 - 12:52
    This attack was found in 1998 by Daniel
    Bleichenbacher. If you look at the RSA
  • 12:52 - 13:02
    encryption before we encrypt something
    with RSA, we do some preparations. The way
  • 13:02 - 13:10
    this is done and in all TLS versions is
    these so-called PKCS #1 1.5 standard. How
  • 13:10 - 13:16
    this looks is: it starts with the 00 02.
    Then we have some random data which is
  • 13:16 - 13:21
    just again a padding to fill up space.
    Then we have zero which marks the end of
  • 13:21 - 13:28
    the pending. Then we have a version number
    03 03, which stands for TLS 1.2. It's
  • 13:28 - 13:33
    totally obvious right. I'll get two
    version numbers later. And then we have
  • 13:33 - 13:39
    the secret data. But the relevant thing
    for this attack is mostly this 00 02 at
  • 13:39 - 13:45
    the beginning. So we know each correct
    encrypted block, if we decrypt it, it
  • 13:45 - 13:56
    starts with 00 02. We may wonder if we
    implement a TLS server and it decrypts
  • 13:56 - 14:04
    some data from the client and then it
    doesn't start with 00 02: what shall I do?
  • 14:04 - 14:08
    And the naive thing would be: yeah of
    course we just send an error message
  • 14:08 - 14:14
    because something is obviously wrong here.
    Now this turns out to be not such a good
  • 14:14 - 14:20
    idea because if we do this we will tell
    the attacker something. We will tell him
  • 14:20 - 14:25
    that the decrypted data does not start
    with 00 02. So the attacker learned
  • 14:25 - 14:30
    something about the interval in which the
    decrypted data is. Either it starts with
  • 14:30 - 14:38
    00 02 or it doesn't. And this turned out
    to be enough to.. if you send enough
  • 14:38 - 14:45
    queries and modify the ciphertext you can
    learn enough information to decrypt data.
  • 14:45 - 14:49
    The whole algorithm is a bit more
    complicated but it's not that complicated.
  • 14:49 - 14:53
    It's relatively straightforward. It's a
    bit of math and I didn't want to put in
  • 14:53 - 15:01
    any formulas but yeah. Now as I said it
    was discovered in 1998. So TLS 1.0
  • 15:01 - 15:07
    introduced some countermeasures. The
    general idea here is that if you decrypt
  • 15:07 - 15:13
    something and it is wrong then you're
    supposed to replace it with a random value
  • 15:13 - 15:19
    and use that random value as your secret
    and pretend nothing has happened and then
  • 15:19 - 15:23
    continue and then the handshake will fail
    later on because you don't have the same
  • 15:23 - 15:28
    key. This prevents the attacker from
    learning whether your data is valid or
  • 15:28 - 15:35
    not. In 2003 a research-team figured out
    that the countermeasures how they were
  • 15:35 - 15:40
    described and TLS 1.0 were incomplete and
    also not entirely, it was not entirely
  • 15:40 - 15:45
    clear how to implement them. Because
    there's this version-thing and it was not
  • 15:45 - 15:50
    exactly described how to handle that. If
    only the version is wrong. So they they
  • 15:50 - 15:56
    were able to make, to create an attack
    that still worked despite this
  • 15:56 - 16:04
    countermeasures. So more countermeasures
    were proposed and in 2014 there was a
  • 16:04 - 16:10
    paper that Java was still vulnerable to
    Bleichenbacher-attacks in a special way
  • 16:10 - 16:14
    because they used some kind of decoding,
    then raised an exception. And the
  • 16:14 - 16:18
    exception was long enough that you could
    measure the timing difference. And there
  • 16:18 - 16:24
    was also still a small issue in OpenSSL
    although that was not practically
  • 16:24 - 16:33
    exploitable. In 2016 there the so-called
    drown-attack. And the drown-attack was a
  • 16:33 - 16:38
    Bleichenbacher-attack in SSL version 2.
    Now you may wonder SSL-version 2 is this
  • 16:38 - 16:44
    very very old version from 1995. Is this a
    problem? But it actually is because you
  • 16:44 - 16:50
    can use encrypted data from a modern TLS-
    version, TLS 1.2, and and decrypt it with
  • 16:50 - 16:59
    a server that still supports SSL version
    2. So that was the drown-attack. And then
  • 16:59 - 17:04
    last year I thought maybe someone should
    check if there are still servers
  • 17:04 - 17:08
    vulvernable to these Bleichenbacher-
    attacks. So I wrote a small scan tool and
  • 17:08 - 17:14
    started scanning, and scanned the Alexa
    top-1000000. The first hit was
  • 17:14 - 17:21
    Facebook.com was vulnerable and it turned
    out from the top-100 pages roughly 1/3
  • 17:21 - 17:26
    were vulnerable. And in the end we found
    like 15 different implementations that
  • 17:26 - 17:37
    were vulnerable. Probably more but these
    were the ones we know about. Yeah. And
  • 17:37 - 17:42
    just I think a month ago there was another
    paper, that there also you can use cache-
  • 17:42 - 17:48
    sidechannels which is mostly interesting
    if you have cloud-infrastructure where
  • 17:48 - 17:52
    multiple servers are running on the same
    hardware, which you can also use to
  • 17:52 - 18:00
    perform these Bleichenbacher-attacks. Now
    what I want to show you here: You cannot
  • 18:00 - 18:05
    read this because it's too small but this
    is the chapters in the TLS-standard that
  • 18:05 - 18:10
    describe the countermeasures to these
    Bleichenbacher-attacks. So we knew about
  • 18:10 - 18:15
    them since before TLS 1.2, so there was a
    small chapter what you should do to
  • 18:15 - 18:18
    prevent these attacks. And then they
    figured out: OK that's not enough. We need
  • 18:18 - 18:25
    to have more countermeasures, and even
    more. So, what you can clearly see here is
  • 18:25 - 18:32
    it's getting more and more complicated to
    prevent these attacks. So with every new
  • 18:32 - 18:41
    TLS-version we had more complexity to
    prevent these Bleichenbacher-attacks.
  • 18:41 - 18:45
    These were just two examples. There were a
    lot more attacks on TLS 1.2 and earlier
  • 18:45 - 18:51
    that were due to poor design choices. I've
    named a few here: SLOTH, which was all
  • 18:51 - 18:57
    against weak caches, FREAK which can
    attack issues in the handshake and
  • 18:57 - 19:04
    compatibility with old versions, SWEET32
    which attacks some block-ciphers that have
  • 19:04 - 19:09
    a small blocksize, Triple-Handshake which
    is a very complicated interaction of
  • 19:09 - 19:18
    different handshakes. The general trend
    here was that in TLS 1.2 and earlier, if
  • 19:18 - 19:23
    there was a security bug, if there was a
    vulnerability in the cryptography, what
  • 19:23 - 19:29
    people did was: We need a workaround for
    the security issue. And then if this
  • 19:29 - 19:35
    workaround doesn't work it's not
    sufficient. We need more workarounds. And
  • 19:35 - 19:42
    also we create more secure modes but we
    still keep the old ones. And then people
  • 19:42 - 19:46
    can choose. We have this algorithm
    agility. You can choose, there's the
  • 19:46 - 19:52
    secure algorithm, there's the less secure
    algorithm. Take whatever you want. Which
  • 19:52 - 19:56
    in practice meant very often still the
    insecure modes were used because like for
  • 19:56 - 20:01
    all of these things there were modes
    available in TLS 1.2 that didn't have
  • 20:01 - 20:10
    these vulnerabilities. But they were
    optional. But, and I think that is the
  • 20:10 - 20:18
    major change that came with TLS 1.3, was a
    mindset-change that people said, okay if
  • 20:18 - 20:22
    something has vulnerabilities, if it's
    insecure and if we have something better
  • 20:22 - 20:30
    then we just remove the thing that is
    vulnerable, that is problematic. So the
  • 20:30 - 20:35
    main change in TLS 1.3 was that a lot of
    things were deprecated. So we no longer
  • 20:35 - 20:41
    have these CBC-modes. We no longer have
    our RC4 which is another cipher which was
  • 20:41 - 20:49
    problematic. We no longer have 3DES, which
    has these small blocksizes. We still use
  • 20:49 - 20:54
    GCM but we no longer use it with an
    explicit nonce, which also turned out to
  • 20:54 - 21:00
    be problematic. We completely remove RSA-
    encryption. We still use RSA but only for
  • 21:00 - 21:07
    signatures. We remove hash-functions that
    turned out to be insecure. We remove
  • 21:07 - 21:13
    Diffie-Hellman with custom parameters,
    which was, yeah, which turned out to be
  • 21:13 - 21:24
    very problematic. And we removed ecliptic-
    curves that kind of look not so secure.
  • 21:24 - 21:31
    But also there was something that some
    academics looked at TLS with the more
  • 21:31 - 21:36
    scientific view. They tried to formally
    understand the security protocol,
  • 21:36 - 21:41
    properties of this protocol and to analyze
    them to see if they can proof some kind of
  • 21:41 - 21:48
    security properties of the protocol. And
    many vulnerabilities that I mentioned
  • 21:48 - 21:53
    earlier were found by these researchers
    trying to formally analyze the protocol.
  • 21:53 - 22:01
    But also these analyses have contributed
    to design TLS 1.3 to make it more robust
  • 22:01 - 22:07
    to attacks. So this is, I think, also a
    big change. There was a much better
  • 22:07 - 22:12
    collaboration between scientists who were
    looking at the protocol and the people who
  • 22:12 - 22:21
    were actually writing the protocol. But
    you may see, all the security is nice but
  • 22:21 - 22:26
    what we really care about or maybe some
    people really care about is speech, right.
  • 22:26 - 22:31
    We want our internet to be fast. We want
    to open our browser and immediately get
  • 22:31 - 22:43
    the page loaded. And TLS 1.3 also brings
    improved speed. And I am showing here the
  • 22:43 - 22:50
    handshake. And this is very simplified. I
    have kind of only added the things that
  • 22:50 - 22:55
    matter to make this point. But, if you
    look at on the left, if we do a handshake
  • 22:55 - 23:00
    with an old TLS-version it starts that
    this client sends a client-hello, and some
  • 23:00 - 23:05
    information, what version it supports,
    what encryption modes it's supports. Then
  • 23:05 - 23:10
    the server sends back which encryption
    modes it wants to use and a key
  • 23:10 - 23:16
    exchange. And then the client sends his
    part of the key exchange. And the so-
  • 23:16 - 23:19
    called finished message and then the
    server sends a finished message and then
  • 23:19 - 23:27
    the client can start sending data. In TLS
    1.3 we have compressed this all a bit. The
  • 23:27 - 23:33
    client sends his client-hello and
    immediately sends a key-exchange message.
  • 23:33 - 23:38
    And then the server answers with his key-
    exchange message. And a few more things
  • 23:38 - 23:43
    that I left out for simplicity. But the
    important thing is that with the second
  • 23:43 - 23:50
    message the client can already send data.
    And this is the situation for a fresh
  • 23:50 - 23:55
    handshake. Like we have not communicated
    before. I want to make a new connection to
  • 23:55 - 24:02
    a server and it goes one time back and
    forth. And then I can send data. Which,
  • 24:02 - 24:07
    and in the earlier version I had two times
    back and forth. So I can send data much
  • 24:07 - 24:18
    faster. So yeah, we remove one round-trip
    from a fresh handshake. There's also
  • 24:18 - 24:24
    security improvements to this handshake.
    So this is nice. We have more security and
  • 24:24 - 24:30
    more speed. And particularly we have
    better security on so-called session-
  • 24:30 - 24:38
    resumption, which means we're reconnecting
    using a key from a previous section. And
  • 24:38 - 24:43
    we also protect more data which may avoid
    some attacks where an attacker may fiddle
  • 24:43 - 24:48
    with the handshake. These were more or
    less theoretic attacks. But these are also
  • 24:48 - 24:57
    prevented in TLS 1.3. Yeah. So TLS has a
    more secure and a faster handshake. And if
  • 24:57 - 25:01
    you want to have more details about this
    handshake there was a talk two years ago
  • 25:01 - 25:06
    at this congress, which goes into this in
    much more detail. So if this particularly
  • 25:06 - 25:10
    interests you you should watch that talk.
    I've put a link here and I will put the
  • 25:10 - 25:20
    slides online. There's also something
    called the zero-roundtrip-handshake. And
  • 25:20 - 25:26
    this is even faster. We can send data
    right away. Now, how can we do that? This
  • 25:26 - 25:31
    is kind of cheating because what we need
    here is we need to have a previous
  • 25:31 - 25:35
    connection. And then we have a key from a
    previous connection, can create a new key
  • 25:35 - 25:42
    from that and use that to send data right
    away. So yeah, we need a so-called
  • 25:42 - 25:47
    preshared-key which we have from previous
    connection and then we can send data
  • 25:47 - 25:58
    without any roundtrips. So, even more
    speed. That's nice, right. But this 0-RTT-
  • 25:58 - 26:05
    mode does not come for free. There is a
    problem here with so-called replay-
  • 26:05 - 26:11
    attacks, which means an attacker could
    record the data that we're sending and
  • 26:11 - 26:17
    then send it again. And the server may
    think: Okay, now this request came twice.
  • 26:17 - 26:24
    So I'm doing twice what this request was
    supposed to do. So there are some caveats
  • 26:24 - 26:29
    with 0-RTT and the standard says you
    should only use if it's safe. It says
  • 26:29 - 26:37
    something like you should only use it if
    you have a profile how to use it safely.
  • 26:37 - 26:44
    Now what does that mean? There, let's look
    at https, the protocol we're using
  • 26:44 - 26:49
    usually. If you look into the HTTP-
    standard it says something that a GET-
  • 26:49 - 26:55
    request has to be idempotent and a POST-
    request does not have to be idempotent.
  • 26:55 - 27:00
    Now what does that mean? It more or less
    means if you send a request twice it
  • 27:00 - 27:07
    shouldn't do anything different from just
    sending it once. So in theory we could say
  • 27:07 - 27:13
    yes a GET-requests are idempotent - that
    means they are safe for zero-roundtrip-
  • 27:13 - 27:23
    connections. The question is, "do web-
    developers" ... Sorry.
  • 27:23 - 27:31
    applause
    You can do a little experiment: If you
  • 27:31 - 27:35
    meet someone who is a web developer, ask
    them if they know what idempotent means,
  • 27:35 - 27:43
    and when they can use idempotent requests
    and when they cannot. So, in an ideal
  • 27:43 - 27:48
    situation where web-developers do know
    that, we can use 0-RTT safely with TLS
  • 27:48 - 27:57
    1.3. 0-RTT also does not have a strong
    forward secrecy as a normal handshake. So,
  • 27:57 - 28:02
    there's kind of a tradeoff here, because
    this pre-shared key is encrypted with a
  • 28:02 - 28:06
    key on the server and if that key gets
    compromised that may compromise our
  • 28:06 - 28:15
    connection even if the key is only leaked
    later on. So, this looks a bit problematic
  • 28:15 - 28:20
    and many speculate that the future attacks
    we'll see on TLS 1.3, that at least some
  • 28:20 - 28:24
    of them will focus on this 0-RTT mode,
    because it looks like one of the more
  • 28:24 - 28:29
    fragile parts of the protocol. But it
    gives us more speed., so people wanted to
  • 28:29 - 28:37
    have it. Maybe the good news is, this is
    entirely optional; we don't have to use
  • 28:37 - 28:43
    it; and if we think this looks too
    problematic, we can switch it off. So, if
  • 28:43 - 28:47
    it turns out that there are too many
    attacks involving 0-RTT mode, we could
  • 28:47 - 28:52
    disable it again and use it without it. It
    will still be faster, but not as fast as
  • 28:52 - 29:03
    it could be with this. Okay. Deployment:
    Now, if we have this nice new protocol, we
  • 29:03 - 29:07
    not only have to make sure it's secure and
    fast and everything, but we also have to
  • 29:07 - 29:16
    deploy it. And we have to deploy it on the
    internet - on the real internet - like the
  • 29:16 - 29:20
    one we have out there, not some
    theoretical internet where there are no
  • 29:20 - 29:24
    bugs and everyone knows how to implement
    protocols, but the real internet with lots
  • 29:24 - 29:32
    of IoT devices and enterprise firewalls
    and all these kinds of things. And now I
  • 29:32 - 29:41
    want to get back to this version number.
    This may sound like a trivial thing, but
  • 29:41 - 29:50
    TLS 1.3 has a new version number for the
    protocol version. Here's a Wireshark dump
  • 29:50 - 29:56
    from a TLS 1.3 handshake. And if you're
    trying to look for the version number, you
  • 29:56 - 30:02
    will find multiple version numbers. And in
    case you cannot see it, I have made it a
  • 30:02 - 30:14
    bit larger. So at the top you see
    "Version: TLS 1.0", encoded as 0x0301.
  • 30:14 - 30:20
    Okay. That looks strange. Then, a few
    lines later, you have "Version TLS: 1.2",
  • 30:20 - 30:28
    0x0303. But we thought this was TLS 1.3...
    I mean it says here at the top but somehow
  • 30:28 - 30:34
    there are these other versions. And then
    if you scroll further down, you will see
  • 30:34 - 30:40
    "Extension: supported_versions". And then
    here it lists TLS 1.3, which is encoded as
  • 30:40 - 30:47
    0x0304. So, what's going on here? This
    looks strange. So, the first thing to
  • 30:47 - 30:52
    realize is why do we encode these versions
    in such a strange way; why are we not
  • 30:52 - 31:01
    using 0x0100 for TLS 1.0? It's TLS 1.0
    came after SSL version 3, which kind of
  • 31:01 - 31:09
    makes it version 3.1; and that's how we
    encode it. TLS 1.0 is really just SSL
  • 31:09 - 31:18
    version 3.1, TLS 1.1 is SSL version 3.2
    and so on and for TLS 1.3, it's
  • 31:18 - 31:26
    complicated. So, the very first version
    you saw earlier in this Wireshark dump was
  • 31:26 - 31:31
    the so-called record layer and this is
    kind of a protocol inside the TLS protocol
  • 31:31 - 31:37
    which has its own version number, which is
    totally meaningless but it's just there.
  • 31:37 - 31:41
    And it turned out, for compatibility
    reasons, it's best to just let this on the
  • 31:41 - 31:46
    version of TLS 1.0 and then, we have the
    least problems. And this is kind of...
  • 31:46 - 31:55
    this record layer protocol is kind of the
    encoding of the TLS packages. Now, if we
  • 31:55 - 32:00
    have a new TLS version, we cannot just
    tell everyone "tomorrow we will use TLS
  • 32:00 - 32:06
    1.3" and everyone has to update, because
    we know many people won't. And so, we
  • 32:06 - 32:10
    somehow need to be able to deploy this new
    version and still be compatible with
  • 32:10 - 32:20
    devices that only speak the old version.
    So, let's assume we have a client that
  • 32:20 - 32:28
    supports TLS 1.2, and we have a server
    that only supports TLS 1.0. How does that
  • 32:28 - 32:35
    work? That's an extremely complicated
    mechanism here. So, the client connects
  • 32:35 - 32:44
    and says "Hello. I speak TLS 1.2". Server
    says "Okay, I don't know TLS 1.2, but
  • 32:44 - 32:50
    what's the highest version I support?"
    It's TLS 1.0, so he sents that back. And
  • 32:50 - 32:56
    then, they can speak TLS 1.0 and - in case
    the client still supports that - and we
  • 32:56 - 33:06
    have a connection. This is very simple. I
    would think so. So, to illustrate how you
  • 33:06 - 33:11
    would program something like that, you
    would say "Yeah, if client_max_version is
  • 33:11 - 33:16
    smaller than than server_max_version, then
    we use the client_max_version. Otherwise,
  • 33:16 - 33:24
    we use the server_max_version. So, you
    would think that there's no way anyone
  • 33:24 - 33:32
    could possibly not get that right, right?
    I mean, it's very simple. But I was saying
  • 33:32 - 33:36
    earlier, we were talking about the real
    internet. So... And on the real internet,
  • 33:36 - 33:41
    we have enterprise products. In case you
    don't know that, an enterprise product is
  • 33:41 - 33:44
    something that's very expensive and it's
    buggy.
  • 33:44 - 33:55
    LaughterApplause
    hanno: So, yeah. We will have web pages
  • 33:55 - 34:01
    that run with firewalls from Cisco or we
    will have people using IBM Domino web
  • 34:01 - 34:07
    server and all these kinds of things. And
    this is the TLS version negotiation in the
  • 34:07 - 34:14
    enterprise edition. So a client says "Yeah
    I want to connect with TLS 1.2" and the
  • 34:14 - 34:19
    server says "Oh I don't support this this
    very new version. It's from 2008. I mean
  • 34:19 - 34:29
    that's 10 years in Enterprise years.
    That's very long." So the server just
  • 34:29 - 34:34
    sends an error if the client connects with
    the TLS version that it doesn't know. It
  • 34:34 - 34:39
    doesn't implement this version negotiation
    correctly. And this is called version
  • 34:39 - 34:47
    intolerance. This has happened every time
    there was a new TLS version. Every time we
  • 34:47 - 34:52
    had devices that had this problem. If we
    tried to connect with the new TLS version
  • 34:52 - 34:55
    they would just fail. They would send an
    error or they would just cut the
  • 34:55 - 35:03
    connection or have a timeout or crash. So
    browsers needed to handle this somehow
  • 35:03 - 35:08
    because the problem here is, when a
    browser introduces new TLS version and
  • 35:08 - 35:12
    everything breaks, then users will blame
    the browser and then they will say "Yeah I
  • 35:12 - 35:16
    will no longer use this browser, I'll now
    switch back to Internet Explorer" or
  • 35:16 - 35:24
    something like that. So browsers needed to
    handle this somehow. What the browsers did
  • 35:24 - 35:30
    was "Okay, we try it with the latest TLS
    version we support. And if we get an error
  • 35:30 - 35:35
    we try it again with one version lower.
    And again one version lower and eventually
  • 35:35 - 35:41
    we may succeed to connect." So here we
    have a browser and we have an enterprise
  • 35:41 - 35:50
    server that supports TLS 1.0 and we will
    eventually get a connection. Do you
  • 35:50 - 35:56
    remember POODLE I mentioned earlier? There
    was this padding oracle in SSLv3, which
  • 35:56 - 36:07
    was discovered in 2014. You may wonder
    SSLv3 which is from 1996, that's really
  • 36:07 - 36:15
    old. Who uses that in 2014? It was
    deprecated for 16 years. I mean who uses
  • 36:15 - 36:24
    that? Windows Phone 7 used it. On this
    Nokia phones they also never got an
  • 36:24 - 36:36
    update. Normal browsers and servers at
    least used TLS 1.0. They maybe didn't use
  • 36:36 - 36:45
    TLS 1.2, but they used TLS 1.0. But we
    have these browsers that are trying to
  • 36:45 - 36:51
    reconnect if there's an error. And so what
    an attacker could do is that the attacker
  • 36:51 - 36:58
    wants to exploit SSLv3. So he just blocks
    all connections with the newer TLS version
  • 36:58 - 37:06
    and therefore forces the client to go into
    SSLv3. And then he can exploit this attack
  • 37:06 - 37:19
    that only works on SSLv3. These downgrades
    are causing security issues. What do we do
  • 37:19 - 37:25
    now? We could add another work workaround.
    There was a standard called SCSV which
  • 37:25 - 37:32
    basically gives the server a way to tell
    the client that it's not broken. It says
  • 37:32 - 37:40
    "hey, I have this kind of special cipher
    suite" which tells the client "hey, if you
  • 37:40 - 37:46
    did these strange downgrades here, please
    don't do that. I'm a well behaving
  • 37:46 - 37:52
    server." So we had a workaround for broken
    servers and then we needed another
  • 37:52 - 37:57
    workaround for the security issues caused
    by those workarounds. But at some points
  • 37:57 - 38:02
    even enterprise servers mostly had fixed
    this version intolerance issues and
  • 38:02 - 38:10
    browsers stopped doing these downgrades.
    Attacks like POODLE no longer worked.
  • 38:10 - 38:16
    However I just said they fixed it. No of
    course they have not fixed it. I mean they
  • 38:16 - 38:21
    fixed it for TLS 1.2. But of course they
    did not fix it for future TLS versions
  • 38:21 - 38:29
    because they were not around yet. This TLS
    1.3, we would get version intolerance
  • 38:29 - 38:33
    again and breaking servers and would have
    to introduce downgrades again and all the
  • 38:33 - 38:42
    nice security would not be very helpful.
    The TLS working group realized that and
  • 38:42 - 38:48
    redesigned the handshake. It was
    redesigned in a way that the old version
  • 38:48 - 38:53
    fields still said that we are connecting
    with TLS 1.2 and then we introduce an
  • 38:53 - 39:00
    extension, supported_versions, which
    signals the support for all the TLS
  • 39:00 - 39:05
    versions we can speak and which signals
    support for TLS 1.3 and possibly for
  • 39:05 - 39:13
    future versions. Now at this point you may
    wonder if we'll have version intolerance
  • 39:13 - 39:18
    with this new extension, once TLS 1.4 gets
    out because the server may be implemented
  • 39:18 - 39:23
    that it sends an error if it sees an
    unknown version in this new version
  • 39:23 - 39:32
    extension. David Benjamin from Google
    thought about this and said "Yeah we have
  • 39:32 - 39:37
    to do something about that. We have to
    improve the future compatibility for
  • 39:37 - 39:45
    future TLS versions." And he invented this
    GREASE mechanism. The idea here is, a
  • 39:45 - 39:50
    server should just ignore unknown versions
    in this extension. He gets a list of TLS
  • 39:50 - 39:54
    versions and if there's one in there that
    he doesn't know about, he should just
  • 39:54 - 40:01
    ignore it and then connect with one of the
    versions he knows about. So we could kind
  • 40:01 - 40:07
    of try to train servers to actually do
    that. And the idea here is we're just
  • 40:07 - 40:13
    sending random bogus TLS versions that are
    reserved values that will never be used
  • 40:13 - 40:18
    for a real TLS version. But we can just
    randomly add them to this extension in
  • 40:18 - 40:22
    order to make sure that if a server
    implements this incorrectly, they will
  • 40:22 - 40:27
    hopefully recognize that early because
    there will be connection failures with
  • 40:27 - 40:41
    normal browsers. The hope here is if
    enterprise vendors will implement a broken
  • 40:41 - 40:45
    version negotiation, they will hopefully
    notice that before they ship the product
  • 40:45 - 40:52
    and then it can no longer be updated
    because that's how the Internet works. So
  • 40:52 - 40:56
    we have this new version negotiation
    mechanism we no longer need these
  • 40:56 - 41:00
    downgrades and we have this GREASE
    mechanism to make it future proof. So now
  • 41:00 - 41:17
    we can ship TLS 1.3, right? Then there was
    this middle box issue. Oh sorry, that's a
  • 41:17 - 41:26
    wrong year. It must be 2016, sorry. In
    2016, in summer, TLS 1.3 was almost
  • 41:26 - 41:33
    finished. But then it took almost another
    year till it got out. Oh sorry, I mixed up
  • 41:33 - 41:41
    the years. It's correct. In 2017, when TLS
    1.3 was almost finished, but it took until
  • 41:41 - 41:49
    2018 until it was actually finished. The
    reason for that was that when browser
  • 41:49 - 41:55
    vendors implemented a draft version of TLS
    1.3, they noticed a lot of connection
  • 41:55 - 42:01
    failures. And the reason for these
    connection failures turned out, were
  • 42:01 - 42:05
    devices that were trying to analyze the
    traffic and trying to be smart. And they
  • 42:05 - 42:09
    thought "OK this is something that looks
    very strange. It doesn't look like a TLS
  • 42:09 - 42:16
    package how we're used to it. So let's
    just drop it, yeah?" So "Yeah, this is a
  • 42:16 - 42:23
    strange TLS package, I don't know what
    to do with this, I'll drop it." These were
  • 42:23 - 42:26
    largely passive middle boxes. So we're not
    talking about things like man in the
  • 42:26 - 42:30
    middle devices that are intercepting a TLS
    connection but just something like a
  • 42:30 - 42:34
    router, where you would expect it just
    forwards traffic. But it tries to be
  • 42:34 - 42:39
    smart, it tries to do advanced security
    enterprise. I don't know. And they were
  • 42:39 - 42:47
    dropping traffic that looked like TLS 1.3
    Then the browser vendors proposed some
  • 42:47 - 42:57
    changes to TLS 1.3 so it looks more like
    TLS 1.2. The main thing was, they
  • 42:57 - 43:03
    introduced some bogus messages from TLS
    1.2 that were supposed to be ignored. So
  • 43:03 - 43:08
    one such message is the so-called
    ChangeCipherSpec message in TLS 1.2, which
  • 43:08 - 43:16
    originally didn't exist in 1.3 due to this
    new handshake design. This message in 1.2,
  • 43:16 - 43:23
    it signals that everything from now on is
    encrypted. The idea was "okay, if we sent
  • 43:23 - 43:28
    a bogus ChangeCipherSpec message early in
    the handshake, then maybe this would
  • 43:28 - 43:33
    confuse those devices, thinking everything
    after that is encrypted and they cannot
  • 43:33 - 43:38
    analyze it." And it turned out this
    worked. A lot of this reduced the
  • 43:38 - 43:45
    connection failures a lot. There are a few
    other things. And then eventually the
  • 43:45 - 43:52
    failure rates got low enough that browsers
    thought "Okay, now we can deploy this."
  • 43:52 - 44:00
    There were a few more issues. This is a
    Pixma printer from Canon. These things
  • 44:00 - 44:06
    have an HTTPS server. They have network
    support. And we have to talk about these
  • 44:06 - 44:16
    people here. If you remember the Snowden
    relations, one of the things that got
  • 44:16 - 44:20
    highlighted there was that there's a
    random number generator called Dual EC
  • 44:20 - 44:26
    DRBG. And that has a backdoor and
    basically these days everyone believes
  • 44:26 - 44:30
    this is a backdoor by the NSA and they
    have some secret keys so they can predict
  • 44:30 - 44:40
    what random values this RNG will output.
    Also what was in the Snowden documents was
  • 44:40 - 44:45
    that at some point the NSA offered 10
    million dollars to RSA security, so they
  • 44:45 - 44:56
    implement this RNG. Then there was a
    proposal, a draft, for a TLS extension,
  • 44:56 - 45:03
    called Extended Random, that adds some
    extra random numbers to the TLS handshake.
  • 45:03 - 45:08
    Why? It wasn't really clear like it was
    just "Yeah we can do this." It was just a
  • 45:08 - 45:12
    proposal. I mean everyone can write a
    proposal for a new extension, it was never
  • 45:12 - 45:21
    finalized, but it was out there. And in
    2014, a research team looked closer at
  • 45:21 - 45:29
    this Dual EC RNG and figured out that if
    you use this ER extension then it's much
  • 45:29 - 45:39
    easier to exploit this backdoor in this
    RNG. And coincidentally RSA's TLS library,
  • 45:39 - 45:45
    BSAFE, also contains support for that
    extension. But it was switched off. They
  • 45:45 - 45:49
    didn't find any implementations that
    actually used it. So it was thought of
  • 45:49 - 45:54
    "okay, this was no big deal, all right".
    But actually it seems these these Canon
  • 45:54 - 46:01
    printers, they had enabled this extension.
    They use this RSA BSAFE library and
  • 46:01 - 46:08
    enabled this ER extension, which was only
    a draft. And so as ER was only a draft, it
  • 46:08 - 46:14
    had no official extension number. So such
    a TLS extension has a number so that the
  • 46:14 - 46:19
    server knows what kind of extension this
    is. And for this implementation they just
  • 46:19 - 46:24
    used the next available number. And it
    turned out that this number collided with
  • 46:24 - 46:33
    one of the mandatory extensions that TLS
    1.3 introduced. So these these Canon
  • 46:33 - 46:36
    printers could not interpret that new
    extension. They thought this is this
  • 46:36 - 46:45
    Extended Random and it didn't make any
    sense, and so you had connection failures.
  • 46:45 - 46:50
    In the TLS protocol they just gave this
    extension a new number and then this no
  • 46:50 - 46:58
    longer happened. There were many more such
    issues and they continue to show up. For
  • 46:58 - 47:03
    example recently, Java, which is like also
    very popular in enterprise environments,
  • 47:03 - 47:07
    it now ships with TLS 1.3 support but it
    doesn't really work. So you have
  • 47:07 - 47:17
    connection failures there. Now with all
    these deployment issues, what about future
  • 47:17 - 47:21
    TLS versions? Will we have all that again?
    And we have this GREASE mechanism and it
  • 47:21 - 47:25
    helps a bit like it prevents this version
    intolerance issues but it doesn't prevent
  • 47:25 - 47:32
    these more complicated middle box issues.
    There was a proposal from David Benjamin
  • 47:32 - 47:36
    from Google who said "Yeah, maybe we
    should just, every few months, like every
  • 47:36 - 47:41
    two or three months, ship a new temporary
    TLS version which we will use for three
  • 47:41 - 47:48
    months and then we will deprecate it again
    to just constantly change the protocol so
  • 47:48 - 47:51
    that the Internet gets used to the fact
    that new protocols get introduced."
  • 47:51 - 47:57
    Laughter
    My prediction here is that these
  • 47:57 - 48:01
    deployment issues are going to get worse.
    I mean, we know now that they exist and we
  • 48:01 - 48:08
    kind of have some ideas how to prevent
    them, but if you go to enterprise security
  • 48:08 - 48:14
    conferences, you will know that the latest
    trend in enterprise security is this thing
  • 48:14 - 48:19
    called artificial intelligence: We use
    machine learning and fancy algorithms to
  • 48:19 - 48:28
    detect bad stuff. And that worries me. And
    here's a blog post from Cisco, where they
  • 48:28 - 48:33
    want to use machine learning to detect bad
    TLS traffic, because they see all this
  • 48:33 - 48:37
    traffic is encrypted and we can no longer
    analyze it, we don't know if malware in
  • 48:37 - 48:43
    there, so let's use some machine learning;
    it will detect bad traffic. So, what I'm
  • 48:43 - 48:48
    very worried that will happen here is that
    the next generation of TLS deployment
  • 48:48 - 48:53
    issues will be AI-supported TLS
    intolerance issues and it may be much
  • 48:53 - 49:04
    harder to fix and analyze. Speaking of
    enterprise environments, one of the very
  • 49:04 - 49:12
    early changes in TLS 1.3 was that it
    removed the RSA encryption handshake. One
  • 49:12 - 49:15
    reason was that it doesn't have forward
    secrecy. The other was these, all these
  • 49:15 - 49:23
    Bleichenbacher attacks that I talked about
    earlier. And then, there came an email to
  • 49:23 - 49:31
    the TLS working group from the banking
    industry and I quote: "I recently learned
  • 49:31 - 49:35
    of a proposed change that would affect
    many of my organization's member
  • 49:35 - 49:40
    institutions: the deprecation of the RSA
    key exchange. Deprecation of the RSA key
  • 49:40 - 49:44
    exchange in TLS 1.3 will cause significant
    problems for financial institutions,
  • 49:44 - 49:49
    almost all of whom are running TLS
    internally and have significant, security-
  • 49:49 - 49:55
    critical investments in out-of-band TLS
    decryption." What it basically means is,
  • 49:55 - 49:59
    they are using TLS for some connection;
    they have some device in the middle that
  • 49:59 - 50:06
    is decrypting the traffic and analyzing it
    somehow which - if they do it internally -
  • 50:06 - 50:12
    it's okay, but this no longer works with
    TLS 1.3, because we always negotiate a new
  • 50:12 - 50:21
    key for each connection and it's no longer
    possible to have the static decryption.
  • 50:21 - 50:26
    There was an answer from Kenny Patterson,
    he's a professor from London, he said: "My
  • 50:26 - 50:29
    view concerning your request: no.
    Rationale: We're trying to build a more
  • 50:29 - 50:37
    secure internet."
    Applause
  • 50:37 - 50:41
    "You're a bit late to the party. We're
    metaphorically speaking at the stage of
  • 50:41 - 50:46
    emptying the ash trays and hunting for the
    not quite empty beer cans. More exactly,
  • 50:46 - 50:51
    we are at draft 15 and RSA key transport
    disappeared from the spec about a dozen
  • 50:51 - 50:56
    drafts ago. I know the banking industry is
    usually a bit slow off the mark, but this
  • 50:56 - 51:01
    takes the biscuit." Okay.
    Laughter
  • 51:01 - 51:08
    There were several proposals then to add a
    visibility mode to TLS 1.3, which would in
  • 51:08 - 51:14
    another way allow these connections that
    could be passively observed and decrypted,
  • 51:14 - 51:19
    but they were all rejected and the general
    opinion in the TLS working group was that
  • 51:19 - 51:24
    the goal of monitoring traffic content is
    just fundamentally not the goal of TLS.
  • 51:24 - 51:31
    The goal of TLS is to have an encrypted
    channel that no one else can read. The
  • 51:31 - 51:38
    industry eventually went to ETSI, which is
    the European technology standardization
  • 51:38 - 51:44
    organization, and they recently published
    something called Enterprise TLS...
  • 51:44 - 51:51
    Laughter
    ...which modifies TLS 1.3 in a way that it
  • 51:51 - 51:58
    would allow these decryptions. The IETF
    protested against that and primarily
  • 51:58 - 52:03
    because of the... they used the name TLS,
    because it sounds like this is some
  • 52:03 - 52:08
    addition to TLS or something, and
    apparently ETSI has previously promised to
  • 52:08 - 52:14
    them that they would not use the name TLS
    and then they named it Enterprise TLS.
  • 52:14 - 52:24
    Okay, but yeah... TLS 1.3 is finished. You
    can start using it. You should update your
  • 52:24 - 52:30
    servers so that they use it. Your browser
    probably already supports it. So, in
  • 52:30 - 52:41
    summary: TLS 1.3 deprecates many insecure
    constructions. It's faster and deploying
  • 52:41 - 52:48
    new things on the internet is a mess. So,
    yeah. That's it. And I think we have a few
  • 52:48 - 53:00
    minutes for questions.
    Applause
  • 53:00 - 53:04
    Herald: Alright, yeah. As Hanno mentioned, we
    have 6 minutes or so for questions. We
  • 53:04 - 53:08
    have 5 microphones in the room. So, if you
    want to ask a question, hurry up to one of
  • 53:08 - 53:12
    the microphones and please make sure to
    ask a short, concise question, so that we
  • 53:12 - 53:16
    can get as many in as we can possibly can.
    Maybe, you just go ahead over there. Mic
  • 53:16 - 53:18
    2.
    Mic 2: Thank you very much for this
  • 53:18 - 53:24
    interesting talk. Is there a way to
    prevent the uses of this Enterprise TLS?
  • 53:24 - 53:27
    Hanno: The question is if there is a way
    to prevent the use of that Enterprise TLS.
  • 53:27 - 53:33
    Yes, there is, because the basic idea is
    that they will use a static Diffie-Hellman
  • 53:33 - 53:38
    key exchange and if you just connect twice
    and see that they are using the same
  • 53:38 - 53:43
    again, then you may reject that. Although
    the problem is, some servers may also use
  • 53:43 - 53:52
    that for optimization. So, there are
    longer discussions on this question, so...
  • 53:52 - 53:57
    I cannot fully answer it, but there more
    or less... there are options.
  • 53:57 - 54:00
    Herald: Alright. Before we go to the next
    question, a quick request for all the
  • 54:00 - 54:05
    people leaving the room: Please do so as
    quietly as possible, so we can finish this
  • 54:05 - 54:11
    Q&A in peace and don't have all this noise
    going on. Mic 3, please.
  • 54:11 - 54:17
    Mic 3: Hi. I was wondering about the
    replay attacks. Why didn't they implement
  • 54:17 - 54:22
    something like sequence numbers into the
    TLS protocol?
  • 54:22 - 54:25
    Hanno: Yeah. There is something like that
    in there. The problem is, you sometimes
  • 54:25 - 54:30
    have a situation where you have multiple
    TLS termination points - for example, if
  • 54:30 - 54:34
    you have a CDN network that is
    internationally distributed - and you may
  • 54:34 - 54:40
    not be able to keep state across all of
    them.
  • 54:40 - 54:44
    Herald: Alright. Then, let's take a
    question from our viewers in the internet.
  • 54:44 - 54:50
    The signal angel, please.
    Signal angel: Alright. Binarystrike asks:
  • 54:50 - 54:55
    "With regards to TLS 1.3 in the
    enterprise, shouldn't we move away from
  • 54:55 - 55:01
    perimeter interception devices to also
    putting control on the end point, like we
  • 55:01 - 55:10
    would have in a zero-trust environment?"
    Hanno: So, in my opinion, yes. But, there
  • 55:10 - 55:15
    are many people in the enterise security
    industry who think that this is not
  • 55:15 - 55:20
    feasible. But, I mean, discussion about
    network design, that would be a whole
  • 55:20 - 55:25
    other talk. Yeah.
    Herald: Alright. Then, let's take a
  • 55:25 - 55:30
    question from mic 4.
    Mic 4: Yeah. It's also related to the
  • 55:30 - 55:37
    Enterprise TLS. The browser can connect to
    an Enterprise TLS server without any
  • 55:37 - 55:41
    problems?
    Hanno: Yeah. So, it's built that it's
  • 55:41 - 55:47
    compatible with the existing TLS protocol.
    Mic 4: Okay, thanks.
  • 55:47 - 55:50
    Hanno: And the reason of whether you can
    avoid that or not, that's really a more
  • 55:50 - 55:54
    complicated discussion, that would kind of
    be a whole sub-talk, so I cannot answer
  • 55:54 - 55:59
    this in a minute, but come to me later if
    you are interested in details.
  • 55:59 - 56:02
    Herald: Alright. Then, let's take another
    question from the interwebs.
  • 56:02 - 56:06
    Signal Angel: We have one more question
    from IRC: "Would you recommend
  • 56:06 - 56:15
    inserting bogus values into handshakes to
    train implementors?"
  • 56:15 - 56:19
    Hanno: I mean that what I said what is
    done, that's actually what browsers are
  • 56:19 - 56:24
    doing, and I think this is a good idea. I
    just think that this covers only a small
  • 56:24 - 56:29
    fraction of these deployment issues.
    Herald: Okay, we still have plenty of
  • 56:29 - 56:35
    time, so let's go to mic 2 please.
    Mic 2: Yeah, as you said, we have still a
  • 56:35 - 56:41
    lot of dirty workarounds concerning TLS
    1.3 and all the implementatons in the
  • 56:41 - 56:52
    browers and so on. Is there a way to make,
    like, a requirement for the TLS 1.3 or 1.4
  • 56:52 - 57:01
    compliance to meet some compliance to the
    standard? So you have like a test you can
  • 57:01 - 57:06
    perform, a self-test or something like
    that and if you pass that you are allowed
  • 57:06 - 57:16
    to use the TLS 1.3 logo or 1.4 logo.
    Hanno: You can do that in theory. The
  • 57:16 - 57:23
    problem is you don't really want to have a
    certification regime that people like have
  • 57:23 - 57:29
    to ask for a logo to be able to be allowed
    to implement TLS. and I mean that's kind
  • 57:29 - 57:33
    of one of the downsides of the open
    architecture of the Internet, right? We
  • 57:33 - 57:36
    allow everyone to put devices on the
    Internet, so we kind of have to live with
  • 57:36 - 57:44
    that. And there's no TLS police, so, we
    kind of have no way of preventing people
  • 57:44 - 57:49
    to use broken TLS implementations. And I
    mean people won't care if they have a logo
  • 57:49 - 57:55
    for it or not, right?
    Herald: Alright, let's go to mic 5 all the
  • 57:55 - 57:59
    way in the back there.
    Mic 5: Okay. I have a question about
  • 57:59 - 58:06
    Shor's algorithm and TLS 1.3, because
    since quantum computing is getting very
  • 58:06 - 58:11
    popular lately and there are a lot of
    improvements in the industries, so what's
  • 58:11 - 58:16
    the current situation regarding TLS 1.3
    and all those quantum-based algorithms
  • 58:16 - 58:22
    that break the complexity into polynomial
    times?
  • 58:22 - 58:27
    Hanno: There's no major change here. So,
    with TLS 1.3 you still are using
  • 58:27 - 58:32
    algorithms that can be broken with quantum
    computers if you have a quantum computer.
  • 58:32 - 58:36
    Which currently you don't, but you may
    have in the future. There is work done on
  • 58:36 - 58:42
    standardizing future algorithms that are
    safe from quantum attacks, but that's kind
  • 58:42 - 58:47
    of in an early stage. And there was an
    experiment by Google to introduce a
  • 58:47 - 58:54
    quantum-safe handshake, but they only ran
    it for a few months. But, I think we will
  • 58:54 - 58:57
    see extensions within the next few years
    that will introduce quantum-safe
  • 58:57 - 59:03
    algorithms, but right now there's no
    change from TLS 1.2 to 1.3. Both can be
  • 59:03 - 59:08
    attacked with quantum computers.
    Herald: Okay, so I think we are getting to
  • 59:08 - 59:12
    our last or second to last question, so
    let's go to mic 3, I think you've been
  • 59:12 - 59:17
    waiting the longest.
    Mic 3: Okay. In older versions of TLS
  • 59:17 - 59:23
    there was a problem for small devices such
    as IoT and the industrial devices. Has
  • 59:23 - 59:31
    there been a change in 1.3 to allow them
    to participate?
  • 59:31 - 59:33
    Hanno: I mean I'm not sure what entirely
    you mean with the problem, I mean...
  • 59:33 - 59:38
    Mic 3: Of performance, of performance.
    Hanno: ...of course TLS needs some... the
  • 59:38 - 59:44
    performance issues of TLS have usually
    been overstated. So even in a relatively
  • 59:44 - 59:50
    low-power device you can implement the
    crypto. I mean the whole protocol is
  • 59:50 - 59:55
    relatively complex and you need to
    implement it somehow, but I don't think
  • 59:55 - 60:00
    that's such a big issue anymore because
    even IoT devices have relatively powerfull
  • 60:00 - 60:05
    processors these days.
    Herald: Okay, alright, that concludes our
  • 60:05 - 60:10
    Q&A, unfortunately we are out of time. So
    please give a huge round of applause for
  • 60:10 - 60:12
    this great talk.
  • 60:12 - 60:15
    applause
  • 60:15 - 60:20
    35C3 postroll music
  • 60:20 - 60:38
    subtitles created by c3subtitles.de
    in the year 2019. Join, and help us!
Title:
35C3 - The Rocky Road to TLS 1.3 and better Internet Encryption
Description:

more » « less
Video Language:
English
Duration:
01:00:38

English subtitles

Revisions