LDNWebPerf June 2016 - Natasha Rooney

Upgrading to HTTPS still seems to be difficult for some, and one the given reasons is: performance. Current in use TLS versions can take three round trips before any application data can be sent, which may seem like too many to spare for some. However, optimisations and solutions exist which can cut this wait time down and make it negligible. Not only that, but new versions of TLS may bring the round trip times down to zero. Natasha will go through the methods of working with speedy TLS, and how it’ll get even speedier in the future.

Transcript

1. @thisNatasha
   TLS Perf:
   from three to zero in one spec
   Natasha Rooney, @thisNatasha
   

   View Slide

2. @thisNatasha
   

   View Slide

3. @thisNatasha
   Lots of Poppies
   - Public Key Crypto
   - TLS History
   - TLS 1.2
   - Evil RTTs
   - TLS Config
   - TLS 1.3
   - ACME / Let’s Encrypt
   - Some cool links
   - Sleep.
   

   View Slide

4. @thisNatasha
   Why do i need ssl/tls?
   

   View Slide

5. @thisNatasha
   @thisNatasha
   781 data breaches
   in 2015
   170m records stolen
   Average $3.8m per breach
   http://www.idtheftcenter.org/ITRC-Surveys-Studies/2015databreaches.html
   @thisNatasha
   

   View Slide

6. @thisNatasha
   Quick intro to
   Public Key Cryptography
   

   View Slide

7. @thisNatasha
   Let’s get that Pikachu!
   Jessie James
   

   View Slide

8. @thisNatasha
   @thisNatasha
   Symmetric Crypto
   (Caesar Cipher)
   

   View Slide

9. @thisNatasha
   Key = 3
   Let’s get that Pikachu!
   =
   Ohw’v jhw wkdw Slndfkx!
   Jessie James
   

   View Slide

10. @thisNatasha
    Key = 3
    Let’s get that Pikachu!
    =
    Ohw’v jhw wkdw Slndfkx!
    Jessie James
    

    View Slide

11. @thisNatasha
    Key = 3
    Let’s get that Pikachu!
    =
    Ohw’v jhw wkdw Slndfkx!
    Jessie James
    Ohw’v jhw wkdw Slndfkx!
    =
    Let’s get that Pikachu!
    

    View Slide

12. @thisNatasha
    @thisNatasha
    Asymmetric Crypto
    2 Keys
    1 Secret Key
    (keep it to yourself!)
    1 Public Key
    (share with others)
    

    View Slide

13. @thisNatasha
    Jessie James
    PUBLIC
    

    View Slide

14. @thisNatasha
    Jessie James
    Let’s get that Pikachu!
    1cd87b63a2a933ca2...
    PUBLIC
    PUBLIC
    

    View Slide

15. @thisNatasha
    Jessie James
    Let’s get that Pikachu!
    1cd87b63a2a933ca2...
    Let’s get that Pikachu!
    PUBLIC
    PUBLIC
    

    View Slide

16. @thisNatasha
    Jessie James
    Let’s get that Pikachu!
    1cd87b63a2a933ca2...
    Let’s get that Pikachu!
    PUBLIC
    PUBLIC
    PUBLIC
    1cd87b63a2a933ca2...
    

    View Slide

17. @thisNatasha
    

    View Slide

18. @thisNatasha
    Does this key really
    belong to james?
    PUBLIC
    

    View Slide

19. @thisNatasha
    @thisNatasha
    Certs
    Certificate Authority (CA)
    issues a Certificate
    CA checks James’s identity
    Digicert, Versign
    (but anyone can be a CA)
    

    View Slide

20. @thisNatasha
    @thisNatasha
    Certs
    Certificate Authority (CA)
    issues a Certificate
    X.509
    Version Number
    Serial Number
    Algorithm ID
    Issuer
    Validity period
    Subject name
    Subject Public Key Info
    Certificate Signature Algorithm
    Certificate Signature
    ...
    

    View Slide

21. @thisNatasha
    Jessie James
    Let’s get that Pikachu!
    1cd87b63a2a933ca2...
    Let’s get that Pikachu!
    Giant Meowth
    Certificate
    Authority
    PUBLIC
    PUBLIC
    

    View Slide

22. @thisNatasha
    

    View Slide

23. @thisNatasha
    Jessie James
    Let’s get that Pikachu!
    1cd87b63a2a933ca2...
    Let’s get that Pikachu!
    Giant Meowth
    Certificate
    Authority
    PUBLIC
    PUBLIC
    

    View Slide

24. @thisNatasha
    @thisNatasha
    SSL / TLS
    Also use
    Public Key Cryptography
    HTTPS
    

    View Slide

25. @thisNatasha
    TLS History.
    

    View Slide

26. @thisNatasha
    7. Application Data HTTP /
    IMAP
    6. Data Presentation,
    Encryption
    SSL / TLS
    5. Session and connection
    management
    -
    4. Transport of packets and
    streams
    TCP / UDP
    3. Routing and delivery of
    datagrams on the Network
    IP / IPSec
    2. Local Data Connection Ethernet
    1. Physical data connection
    (cables)
    CAT5
    OSI Model
    

    View Slide

27. @thisNatasha
    @thisNatasha
    SSL
    (TLS is the same, just later
    versions)
    SSLv1 Netscape
    1994: SSLv2 Netscape
    Navigator 1.1
    SSLv2 Security poor
    1995: SSLv3
    

    View Slide

28. @thisNatasha
    @thisNatasha
    TLS
    A Crypto Protocol Framework
    1996: TLS Working Group
    Microsoft vs Netscape
    1999: TLSv1
    2006: TLSv1.1 (sec fixes)
    2008: TLSv1.2 configurable
    and flexible
    

    View Slide

29. @thisNatasha
    

    View Slide

30. @thisNatasha
    @thisNatasha
    TLS Aims
    Not just crypto...
    Cryptographic Security
    Interoperability
    Extensibility
    Efficiency
    

    View Slide

31. @thisNatasha
    @thisNatasha
    TLS Aims
    Don’t have a TIF
    Message tampering
    Message interception
    Message forgery
    

    View Slide

32. @thisNatasha
    @thisNatasha
    TLS Basics
    Not just crypto...
    1. Handshake including
    authentication and key
    exchange
    2. Data exchange
    3. Shutdown
    

    View Slide

33. @thisNatasha
    Er, I can see why this take
    some time...
    

    View Slide

34. @thisNatasha
    TLS 1.2
    

    View Slide

35. @thisNatasha
    @thisNatasha
    6-10 messages
    Handshake
    Full handshake with server
    authentication
    - Exchange capabilities
    - Agree on params
    - Validate certs
    - Agree master secret
    - Verify handshake was not
    modified
    Abbreviated handshake
    (resumes earlier session)
    

    View Slide

36. @thisNatasha
    Handshake Flow
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    Key Exchange
    Authentication Algorithm Strength Mode
    Cipher MAC or PRF
    TLS / Handshake Cheat Sheet
    Key Exchange Method: creates the pre master secret.
    Premaster secret is combined with PRF to create master
    secret
    RSA, DHE_RSA,
    ECDHE_RSA,
    ECDHE_ECDSA
    Authentication Method: Uses public key crypto and
    certificates public key together. Once certificate is
    validated the client can used public key.
    RSA or ECDSA
    Certs: X.509, ASN.1
    DER encoding.
    Server
    Hello,
    Certificate
    - Server selects cipher & compression
    method
    - Server send certificate
    - Client authenticates
    Key Exchange Pre-master secret exchanged between
    client & server, client validates certificate
    Master
    Secret
    Client & Server can compute Master Secret.
    MAC Server verifies MAC, returns to client to
    verify also.
    Finished Handshake complete.
    Client Hello Client sends TLS Version, Ciphersuites,
    Compression methods
    Ciphers, Standards and Terms
    Encryption
    3DES, AES, ARIA,
    CAMELLIA, RC4, and
    SEED
    [1] Steam: adds MAC [2]
    Block: adds IV and
    padding after encryption
    [3] Encryption (AEAD):
    encryption and integrity
    validation, using nonce,
    no padding, no IV.
    Master Secret
    Pre-master secret:
    combines params to
    help client and server
    create master secret.
    Master Secret: both
    server and client create
    this from pre-master
    secret to symmetrically
    encrypt
    Integrity Validation
    PRF: Pseudorandom
    Function. Takes a
    secret, a seed, and a
    unique label. TLS1.2
    suites use PRF based
    on HMAC and SHA256
    MAC: used for integrity
    validation in handshake
    and record.
    

    View Slide

37. @thisNatasha
    [1] Client Hello
    Cli-ant Ser-ver
    Server Hello [2]
    Certificate [3]
    Server Key Exchange [4]
    Server Hello Done [5]
    [6] Client Key Exchange
    [7] (Change Cipher Spec)
    [8] Finished
    (Change Cipher Spec) [9]
    Finished [10]
    TLS Handshake
    

    View Slide

38. @thisNatasha
    

    View Slide

39. @thisNatasha
    [1] Client Hello
    Cli-ant Ser-ver
    Server Hello [2]
    Certificate [3]
    Server Key Exchange [4]
    Server Hello Done [5]
    [6] Client Key Exchange
    [7] (Change Cipher Spec)
    [8] Finished
    (Change Cipher Spec) [9]
    Finished [10]
    TLS Handshake
    

    View Slide

40. @thisNatasha
    2 Roundtrips
    And a lotta CPU...
    

    View Slide

41. @thisNatasha
    @thisNatasha
    Abbreviated
    Handshake
    Session Resumption
    Client and Server keep
    session security params
    Session ID
    Sent in ServerHello
    Client sends in next
    ClientHello
    

    View Slide

42. @thisNatasha
    [1] Client Hello (+ SessionID)
    Cli-ant Ser-ver
    (+ SessionID) Server Hello [2]
    (Change Cipher Spec) [3]
    Finished [4]
    [5] (Change Cipher Spec)
    [6] Finished
    TLS Abbreviated Handshake
    

    View Slide

43. @thisNatasha
    1 Roundtrip
    A lot nicer
    

    View Slide

44. @thisNatasha
    @thisNatasha
    Key Exchange
    Depends on negotiated algorithm
    suite and algorithm
    - RSA: attackers can de-encrypt
    everything if has server private
    key, being replaced
    - DHE_RSA: has forward secrecy but
    slow
    - ECDHE_RSA and ECDHE_ECDSA: Fast and
    forward secrecy. Can be used with
    RSA or ECDSA
    - Server speaks first
    - Server sends params and signature
    of params for authentication
    

    View Slide

45. @thisNatasha
    @thisNatasha
    Authentication
    Certificate + Public Key
    Coupled with Key Exchange
    Public Key Crypto (RSA or ECDSA)
    RSA method:
    - Client creates a random value as
    premaster secret
    - Encrypts with public key
    - Server decrypts
    - Constructs Session Keys
    - Finished.
    

    View Slide

46. @thisNatasha
    @thisNatasha
    Encryption
    Usually AES, 3 types.
    3DES, AES, ARIA, CAMELLIA, RC4,
    and SEED
    AES most popular
    Types:
    - Stream
    - Block
    - Authenticated
    (associated AEAD)
    

    View Slide

47. @thisNatasha
    Authenticated Encryption
    Seq Num Header
    Header Nonce Ciphertext
    Plaintext
    Authenticate
    Encrypt
    

    View Slide

48. @thisNatasha
    Handshake Flow
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    Key Exchange
    Authentication Algorithm Strength Mode
    Cipher MAC or PRF
    TLS / Handshake Cheat Sheet
    Key Exchange Method: creates the pre master secret.
    Premaster secret is combined with PRF to create master
    secret
    RSA, DHE_RSA,
    ECDHE_RSA,
    ECDHE_ECDSA
    Authentication Method: Uses public key crypto and
    certificates public key together. Once certificate is
    validated the client can used public key.
    RSA or ECDSA
    Certs: X.509, ASN.1
    DER encoding.
    Server
    Hello,
    Certificate
    - Server selects cipher & compression
    method
    - Server send certificate
    - Client authenticates
    Key Exchange Pre-master secret exchanged between
    client & server, client validates certificate
    Master
    Secret
    Client & Server can compute Master Secret.
    MAC Server verifies MAC, returns to client to
    verify also.
    Finished Handshake complete.
    Client Hello Client sends TLS Version, Ciphersuites,
    Compression methods
    Ciphers, Standards and Terms
    Encryption
    3DES, AES, ARIA,
    CAMELLIA, RC4, and
    SEED
    [1] Steam: adds MAC [2]
    Block: adds IV and
    padding after encryption
    [3] Encryption (AEAD):
    encryption and integrity
    validation, using nonce,
    no padding, no IV.
    Master Secret
    Pre-master secret:
    combines params to
    help client and server
    create master secret.
    Master Secret: both
    server and client create
    this from pre-master
    secret to symmetrically
    encrypt
    Integrity Validation
    PRF: Pseudorandom
    Function. Takes a
    secret, a seed, and a
    unique label. TLS1.2
    suites use PRF based
    on HMAC and SHA256
    MAC: used for integrity
    validation in handshake
    and record.
    

    View Slide

49. @thisNatasha
    

    View Slide

50. @thisNatasha
    TLS Record
    Type Version Length
    Header Data
    TLS Record
    TLS Header
    

    View Slide

51. @thisNatasha
    

    View Slide

52. @thisNatasha
    @thisNatasha
    Renegotiation
    New (encrypted) handshake
    with new security params
    requested...
    Why?
    - Requesting Client Certs
    - Benefit from fully encrypted
    handshake
    - Different encryption strength
    in different parts of the
    site.
    

    View Slide

53. @thisNatasha
    Weren’t we here to talk
    about performance?
    

    View Slide

54. @thisNatasha
    “People sometimes care about
    security, but they always
    care about speed; no one ever
    wanted their web site to be
    slower.”
    Ivan Ristić
    

    View Slide

55. @thisNatasha
    @thisNatasha
    BANDWIDTH
    Can buy more of this
    LATENCY
    This still stings. Bad.
    

    View Slide

56. @thisNatasha
    @thisNatasha
    BANDWIDTH
    Can buy more of this
    LATENCY
    This still stings. Bad.
    

    View Slide

57. @thisNatasha
    Mobile Network:
    - 3G 100-500ms latency to
    base station.
    - 4G < 100ms
    - 100 Mbits/s stationary
    - Waking from idle 100ms
    - Transatlantic cables: 99.7%
    the speed of light.
    - Transatlantic cables:
    latency < 100ms, 59ms.
    

    View Slide

58. @thisNatasha
    

    View Slide

59. @thisNatasha
    SYN
    Cli-ant Ser-ver
    SYN + ACK
    ACK
    Get /page
    TCP
    

    View Slide

60. @thisNatasha
    SYN (with cookie and GET)
    Cli-ant Ser-ver
    SYN + ACK (and data)
    TCP Fast Open
    

    View Slide

61. @thisNatasha
    Cli-ant Ser-ver
    TCP and TLS
    TCP Handshake
    [1] Client Hello
    Server Hello [2]
    Certificate [3]
    Server Key Exchange [4]
    Server Hello Done [5]
    [6] Client Key Exchange
    [7] (Change Cipher Spec)
    [8] Finished
    (Change Cipher Spec) [9]
    Finished [10]
    Get /page
    

    View Slide

62. @thisNatasha
    Cli-ant Ser-ver
    TCP and TLS with Session Tickets
    TCP Fast Open Handshake
    [1] Client Hello
    Server Hello [2]
    (Change Cipher Spec) [3]
    Finished [4]
    [5] (Change Cipher Spec)
    [6] Finished
    

    View Slide

63. @thisNatasha
    2 Roundtrips
    Before anything is even sent
    

    View Slide

64. @thisNatasha
    @thisNatasha
    BANDWIDTH
    Can buy more of this
    LATENCY
    This still stings. Bad.
    

    View Slide

65. @thisNatasha
    RTTs are EVIL.
    They make evil people do this:
    

    View Slide

66. @thisNatasha
    

    View Slide

67. @thisNatasha
    Cli-ant Ser-ver
    TCP and TLS with Session Tickets
    TCP Handshake
    [1] Client Hello
    Server Hello [2]
    (Change Cipher Spec) [3]
    Finished [4]
    [5] (Change Cipher Spec)
    [6] Finished
    

    View Slide

68. @thisNatasha
    Can Optimise TCP
    

    View Slide

69. @thisNatasha
    Optimise TCP
    - initcwnd around 10 segments
    - Slow start can restart, even after 1 second
    - Keep TCP Connections Open: Use Keep Alives (HTTP1.1)
    

    View Slide

70. @thisNatasha
    @thisNatasha
    Can Tune Server
    Keep Alives and Connections
    Ivan’s Tests:
    IE11 closes 30 secs
    Safari 7 after 60 secs
    Chrome 35 300 secs
    Firefox 30 when server
    closes.
    

    View Slide

71. @thisNatasha
    But you can’t control what
    browsers users use...
    

    View Slide

72. @thisNatasha
    New standards could help...
    

    View Slide

73. @thisNatasha
    @thisNatasha
    TLS False Start Send application data in Handshake
    30% reduction in handshake latency
    Dangerous, failure
    Still in use
    Google Project
    

    View Slide

74. @thisNatasha
    SPDY HTTP2 QUIC
    Speed and security
    

    View Slide

75. @thisNatasha
    

    View Slide

76. @thisNatasha
    @thisNatasha
    BANDWIDTH
    Can buy more of this
    LATENCY
    This still stings. Bad.
    

    View Slide

77. @thisNatasha
    CDN
    - Edge Caching
    - CDNs can manage connection
    - CDNs can optimise traffic
    

    View Slide

78. @thisNatasha
    CDN
    - Edge Caching
    - CDNs can manage connection
    - CDNs can optimise traffic
    

    View Slide

79. @thisNatasha
    CDN benefits outweigh any
    kind TLS tuning.
    

    View Slide

80. @thisNatasha
    @thisNatasha
    Throwing Money
    Solutions
    Then it’ll go away...
    CDNs
    Bigger Server
    Server Cluster
    

    View Slide

81. @thisNatasha
    Great, but what can we do
    with TLS?
    

    View Slide

82. @thisNatasha
    Cryptographic Operations do
    take (some) CPU time.
    

    View Slide

83. @thisNatasha
    @thisNatasha
    Optimising the Handshake
    Key Size: Longer keys
    - better protection
    - More CPU intensive
    Key Algorithm: RSA sucks.
    - RSA required strength too slow
    - ECDSA faster (3072 bit RSA)
    Key Exchange: RSA, DHE or ECDHE
    - RSA has no forward secrecy
    - DHE is slow
    - ECDHE is your friend
    (security and performance are influenced by
    named curve)
    Key Exchange
    

    View Slide

84. @thisNatasha
    

    View Slide

85. @thisNatasha
    @thisNatasha
    Performance Hits: size, must be
    validated, revocation checked
    Certificates
    Only include needed certs
    Make sure a complete chain can be
    created
    Use ECDSA certs (1kb shorter than
    RSA)
    Don’t use too many hostnames on
    the same cert
    

    View Slide

86. @thisNatasha
    When certs live out their
    lifetime they need to be
    “revoked”, how does the
    browser know?
    

    View Slide

87. @thisNatasha
    @thisNatasha
    Get your revocation info out quick,
    select a fast CA,
    and use OSCP stapling
    Revocation
    Checking
    CRL: Certificate Revocation Lists
    OSCP: Online Cert Status Protocol
    Browsers CRLs download can be 10secs
    OSCP certificate lookup in 1 request
    Use CAs with fast and reliable OCSP
    responders
    Use CAs which update their
    responders quickly
    OSCP Stapling (450 bytes on
    handshake)
    

    View Slide

88. @thisNatasha
    @thisNatasha
    Full handshake will happen once,
    rest will be abbreviated
    Session Resumption Server admin could:
    Configure session caching so
    sessions remain valid for a day
    Clients do the rest!
    

    View Slide

89. @thisNatasha
    Worst is over once the
    Handshake finishes.
    

    View Slide

90. @thisNatasha
    Transport Overhead
    

    View Slide

91. @thisNatasha
    TCP/IP overhead is 52 bytes
    per packet, properly
    implemented TLS is not much!
    

    View Slide

92. @thisNatasha
    IPv6 adds 72 bytes
    

    View Slide

93. @thisNatasha
    Symmetric Encryption Overhead
    AES_128_GCM
    

    View Slide

94. @thisNatasha
    Not all mobile devices run
    hardware-accelerated AES.
    

    View Slide

95. @thisNatasha
    

    View Slide

96. @thisNatasha
    

    View Slide

97. @thisNatasha
    Buffering Latency
    Application Payload (32kb)
    TLS Record (16kb) TLS Record (16kb)
    TCP Packet
    

    View Slide

98. @thisNatasha
    @thisNatasha
    TCP packets may arrive out-of-order
    Need to be buffered!
    Buffering Latency
    Extra time:
    - Buffering
    - TCP Recovery (extra RTT)
    - Overflowing initcwnd
    TLS Tuning (experiment!):
    - turn TLS record size down (16kb)
    - 4kb
    Better to leave to the web servers:
    - Discover MTU
    - They vary record size over
    connection lifetime
    

    View Slide

99. @thisNatasha
    @thisNatasha
    Inequality between client and server
    CPU time can be used to DoS
    (but more are moving to ECDHE_RSA or
    ECDHE_ECDSA)
    CPU time inequality RSA can be used to DoS
    (still uses RSA for auth)
    With ECDHE_ECDSA clients will then
    do 1.5 times more work
    

    View Slide

100. @thisNatasha
     Still sounds like TLS takes a
     lot of CPU energy...
     

     View Slide

101. @thisNatasha
     @thisNatasha
     In the Past
     - CPUs were slow
     - TLS (SSL) was heavy
     - Hardware Accelerators and
     Certs were expensive
     Now
     - Clients and Servers have fast
     processors, plenty of RAM
     - Hardware accelerators not needed
     - Certificates are cheap
     - Latency is most of the issue.
     

     View Slide

102. @thisNatasha
     So, CPU overhead is not your
     issue. RTTs and network
     latencies are.
     

     View Slide

103. @thisNatasha
     RTTs are EVIL.
     They make evil people do this:
     

     View Slide

104. @thisNatasha
     IS TLS Fast Yet?
     istlsfastyet.com
     

     View Slide

105. @thisNatasha
     So what can we do about these
     RTTs?
     

     View Slide

106. @thisNatasha
     TLS 1.3
     

     View Slide

107. @thisNatasha
     [1] Client Hello
     Cli-ant Ser-ver
     Server Hello [2]
     Encrypted Extensions [3]
     Certificate [4]
     Server Key Exchange [4]
     Certificate Verify [5]
     Finished [6]
     [6] Client Key Exchange
     [7] (Change Cipher Spec)
     [8] Finished
     (Change Cipher Spec) [9]
     Finished [10]
     TLS 1.3 Handshake
     

     View Slide

108. @thisNatasha
     [1] Client Hello (KeyShare Extension)
     Cli-ant Ser-ver
     (KeyShare Extension) Server Hello [2]
     Encrypted Extensions [3]
     Certificate [4]
     Server Key Exchange [4]
     Certificate Verify [5]
     Finished [6]
     [6] Client Key Exchange
     [7] (Change Cipher Spec)
     [8] Finished
     (Change Cipher Spec) [9]
     Finished [10]
     TLS 1.3 Handshake
     

     View Slide

109. @thisNatasha
     [1] Client Hello (KeyShare Extension)
     Cli-ant Ser-ver
     (KeyShare Extension) Server Hello [2]
     Encrypted Extensions [3]
     Certificate [4]
     Certificate Verify [5]
     Finished [6]
     [8] Finished
     TLS 1.3 Handshake
     

     View Slide

110. @thisNatasha
     1 RTT
     Yay.
     

     View Slide

111. @thisNatasha
     @thisNatasha
     or/ Session Resumption
     TLS 1.3 Abbreviated
     handshake
     Identifiers and Tickets are
     obsolete!
     Replaces with PSK (pre-
     shared key mode)
     PSK created on previous connection
     after the handshake
     PSK then presented on next visit!
     

     View Slide

112. @thisNatasha
     [1] Client Hello (KeyShare & pre shared key)
     Cli-ant Ser-ver
     (pre shared key) Server Hello [2]
     Encrypted Extensions [3]
     (Change Cipher Spec) [3]
     Finished [4]
     [5] (Change Cipher Spec)
     [5] Finished
     TLS 1.3 Abbreviated Handshake (PSK)
     

     View Slide

113. @thisNatasha
     [1] Client Hello (KeyShare & pre shared key)
     Cli-ant Ser-ver
     (pre shared key) Server Hello [2]
     Encrypted Extensions [3]
     Finished [4]
     [5] Finished
     TLS 1.3 Abbreviated Handshake (PSK)
     

     View Slide

114. @thisNatasha
     1 RTT
     Yay. Can we do better?
     

     View Slide

115. @thisNatasha
     [1] Client Hello (KeyShare & early data)
     [2] Finished
     [3] ApplicationData
     [4] end_of_early_data (alert)
     Cli-ant Ser-ver
     (KeyShare and early data) Server Hello [5]
     Encrypted Extensions [6]
     Server Configuration [7]
     Certificate [8]
     Certificate Verify [9]
     Finished [10]
     [11] Finished
     TLS 1.3 0-RTT Handshake
     

     View Slide

116. @thisNatasha
     Previous Connection:
     - Server sends
     ServerConfiguration
     after handshake
     - Includes:
     - Identifier
     - Semi-static (EC)DH
     parameters
     - Expiration
     - etc.
     

     View Slide

117. @thisNatasha
     [1] Client Hello (KeyShare & early data)
     [2] Finished
     [3] ApplicationData (as above)
     [4] end_of_early_data (alert)
     Cli-ant Ser-ver
     (KeyShare and early data) Server Hello [5]
     Encrypted Extensions [6]
     Server Configuration [7]
     Certificate [8]
     Certificate Verify [9]
     Finished [10]
     [11] Finished
     TLS 1.3 0-RTT Handshake
     

     View Slide

118. @thisNatasha
     O RTT
     Or same round-trip time as for an unencrypted HTTP request
     

     View Slide

119. @thisNatasha
     @thisNatasha
     Some Caveats
     0-RTT Security
     No server random means replay
     attacks still possible
     1 RTT needed to get ephemeral
     secret, so this has no Forward
     Secrecy
     MITM could tamper with 0-RTT data
     if key is compromised
     

     View Slide

120. @thisNatasha
     ACME / Let’s Encrypt
     

     View Slide

121. @thisNatasha
     ...webmasters often need 1-3
     hours to obtain and install a
     certificate for a domain
     

     View Slide

122. @thisNatasha
     @thisNatasha
     Old Certificate way
     Issuance and Identity
     Verification
     - Generate a Certificate Signing
     Request (CSR).
     - ⌘C⌘V CSR into a CA webpage
     - Prove domain ownership by:
     - Put a CA-provided challenge on
     the web server.
     - Put a CA-provided challenge at
     a DNS location (target domain)
     - Receive CA challenge via e-
     mail corresponding to the
     domain and respond
     - Download the certificate and
     install
     

     View Slide

123. @thisNatasha
     

     View Slide

124. @thisNatasha
     

     View Slide

125. @thisNatasha
     This is accomplished by
     running a certificate
     management agent on the web
     server.
     

     View Slide

126. @thisNatasha
     @thisNatasha
     ACME Process
     https://example.com/
     Domain Validation
     Agent proves to CA that the web
     server controls the domain
     Certifcate Issuance and Revocation
     Agent requests, renews and revoke
     certificates
     

     View Slide

127. @thisNatasha
     @thisNatasha
     Domain Validation
     Used to be done by email...
     Agent creates new key pair
     Proves to CA it has access to server
     CA asks domain to complete “challenges”:
     - Agent creates a file on server
     - CA provides a nonce
     - Agent signs nonce with private key
     - Agent tells CA it’s ready to complete
     validation
     

     View Slide

128. @thisNatasha
     Certificate Issuance and Revocation
     - Thank-you public key crypto!
     Issue Certificate
     - Agent asks CA to issue a cert with a
     public key
     - Agent also authorises by signing with
     authorised key
     - CA verifies both signatures
     - CA issues cert with public key from CSR
     CSR: PKCS#10 Certificate Signing Request
     Revoke Certificate
     - Agent signs revocation request with key
     pair
     - CA verifies authorisation
     - CA publishes to CRL, OCSP
     - Browsers learn they shouldn’t accept
     cert
     CRL, OCSP
     

     View Slide

129. @thisNatasha
     

     View Slide

130. @thisNatasha
     Setting Up TLS.
     

     View Slide

131. @thisNatasha
     

     View Slide

132. @thisNatasha
     Recap
     

     View Slide

133. @thisNatasha
     Lots of Poppies
     - Public Key Crypto
     - TLS History
     - TLS 1.2
     - Evil RTTs
     - TLS Config
     - TLS 1.3
     - ACME / Let’s Encrypt
     - @supersole
     - Sleep.
     

     View Slide

134. @thisNatasha
     

     View Slide

135. @thisNatasha
     Thank-you
     People: Ivan Ristic, Eric Rescola, Patrick McManus,
     Mark Nottingham, Tim Taubert, Ilya Grigorik, Yan Zhu.
     

     View Slide