The Rocky Road to The Rocky Road to Hanno Bck https://hboeck.de - - PowerPoint PPT Presentation

▶
the rocky road to the rocky road to
SMART_READER_LITE
LIVE PREVIEW

The Rocky Road to The Rocky Road to Hanno Bck https://hboeck.de - - PowerPoint PPT Presentation

May 01, 2023 402 likes •2.33k views

The Rocky Road to The Rocky Road to Hanno Bck https://hboeck.de @hanno 1 Transport Layer Security Transport Layer Security A protocol to create an encrypted and authenticated layer around other protocols 2 TLS 1.3 was published in

slide-1
SLIDE 1

The Rocky Road to The Rocky Road to

Hanno Böck https://hboeck.de @hanno

1

slide-2
SLIDE 2

Transport Layer Security Transport Layer Security

A protocol to create an encrypted and authenticated layer around other protocols

2

slide-3
SLIDE 3

TLS 1.3 was published in August 2018 TLS 1.3 was published in August 2018

3

slide-4
SLIDE 4

How did we get there? How did we get there?

4

slide-5
SLIDE 5

In 1995 Netscape introduced Secure In 1995 Netscape introduced Secure Socket Layer or SSL version 2 Socket Layer or SSL version 2

5

slide-6
SLIDE 6

In 1996 it was followed up with SSL In 1996 it was followed up with SSL version 3 version 3

6

slide-7
SLIDE 7

In 1999 the IETF took over and renamed In 1999 the IETF took over and renamed it to TLS it to TLS

7

slide-8
SLIDE 8

SSL/TLS History SSL/TLS History

1995: SSL 2 1996: SSL 3 1999: TLS 1.0 2006: TLS 1.1 2008: TLS 1.2 2018: TLS 1.3

8

slide-9
SLIDE 9

Vulnerabilities Vulnerabilities

C C S C C S C C S

9

slide-10
SLIDE 10

Padding Oracles in CBC mode Padding Oracles in CBC mode

10

slide-11
SLIDE 11

block cipher encryption Key Ciphertext Plaintext block cipher encryption Key Ciphertext Plaintext block cipher encryption Key Ciphertext Plaintext Initialization Vector (IV)

WhiteTimberwolf, Wikimedia Commons, Public Domain

11

slide-12
SLIDE 12

CBC Padding for Block Ciphers (AES) CBC Padding for Block Ciphers (AES)

Encryption of data blocks means we have to fill up space

12

slide-13
SLIDE 13

CBC in TLS CBC in TLS

MAC-then-Pad-then-Encrypt

13

slide-14
SLIDE 14

Valid Padding Valid Padding

00 01 01 02 02 02 03 03 03 03 ...

14

slide-15
SLIDE 15

We assume a situation where the attacker can see whether the padding is valid

15

slide-16
SLIDE 16

block cipher decryption Key Plaintext Ciphertext Initialization Vector (IV) block cipher decryption Key Plaintext Ciphertext

Attacker wants to decrypt Attacker manipulates / XOR with guess ?== 00 -> padding valid

16

slide-17
SLIDE 17

block cipher decryption Key Plaintext Ciphertext Initialization Vector (IV) block cipher decryption Key Plaintext Ciphertext

Attacker knows Attacker manipulates to 01 Attacker wants to know Attacker manipulates to guess 01 ?== 01 01 -> padding valid

17

slide-18
SLIDE 18

2002: Serge Vaudenay discovers Padding 2002: Serge Vaudenay discovers Padding Oracle Oracle

Vaudenay, 2002

18

slide-19
SLIDE 19

TLS errors TLS errors

decryption_failed bad_record_mac

19

slide-20
SLIDE 20

If an attacker can see the TLS error he can use a padding oracle

20

slide-21
SLIDE 21

However TLS errors are encrypted: Attack is not practical

21

slide-22
SLIDE 22

2003: Timing attack allows practical 2003: Timing attack allows practical padding oracle attack padding oracle attack

Canvel et al, 2003

22

slide-23
SLIDE 23

TLS 1.2 fixed it (kind of) TLS 1.2 fixed it (kind of)

This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.

23

slide-24
SLIDE 24

Lucky Thirteen (2013) Lucky Thirteen (2013)

Actually it is large enough to be exploitable

AlFardan, Paterson 2013

24

slide-25
SLIDE 25

It is possible to make TLS with CBC timing safe, but it adds a lot of complexity to the code

25

slide-26
SLIDE 26

POODLE (2014) POODLE (2014)

SSLv3 has a padding oracle flaw by design

Möller et al, 2014

26

slide-27
SLIDE 27

POODLE-TLS (2014) POODLE-TLS (2014)

Implementations fail to check the padding, making TLS vulnerable to POODLE, too

Langley, 2014

27

slide-28
SLIDE 28

Lucky Microseconds in s2n (2015) Lucky Microseconds in s2n (2015)

Sorry Amazon, your fix for Lucky Thirteen doesn't work

Albrecht, Paterson, 2015

28

slide-29
SLIDE 29

LuckyMinus20 in OpenSSL (2016) LuckyMinus20 in OpenSSL (2016)

When OpenSSL tried to fix Lucky Thirteen they introduced another padding oracle

Somorovsky, 2016

29

slide-30
SLIDE 30

The original attack didn't work in practice, because TLS errors are encrypted

30

slide-31
SLIDE 31

But what if there are implementations that create

  • ther errors that an attacker can see? For example TCP

errors, connection resets or timeouts?

31

slide-32
SLIDE 32

Yes, you can find servers doing that

32

slide-33
SLIDE 33

Bleichenbacher attacks Bleichenbacher attacks RSA Encryption RSA Encryption

33

slide-34
SLIDE 34

Bleichenbacher, 1998

34

slide-35
SLIDE 35

RSA PKCS #1 1.5 Encryption RSA PKCS #1 1.5 Encryption

00 | 02 | [random] | 00 | 03 | 03 | [secret]

35

slide-36
SLIDE 36

A valid decryption always starts with 00 02

36

slide-37
SLIDE 37

What shall a server do if it doesn't? Send an error?

37

slide-38
SLIDE 38

Sending an error tells the attacker something: Decrypted data does not start with 00 02

38

slide-39
SLIDE 39

Attacker can send modified ciphertext and learn enough to decrypt data

39

slide-40
SLIDE 40

So TLS 1.0 introduced some countermeasures

40

slide-41
SLIDE 41

2003: Klima-Pokorny-Rosa attack Countermeasures were incomplete

Klima et al, 2003

41

slide-42
SLIDE 42

2014: Java is vulnerable to Bleichenbacher attacks And OpenSSL via timing

Meyer et al, 2014

42

slide-43
SLIDE 43

2016: DROWN 2016: DROWN SSL 2 is vulnerable to Bleichenbacher attacks by design

Aviram et al, 2016

43

slide-44
SLIDE 44

2017: Return of Bleichenbacher's Oracle Threat 2017: Return of Bleichenbacher's Oracle Threat (ROBOT) (ROBOT) ~1/3 of top webpages and at least 15 different implementations vulnerable

Böck, Somorovsky, Young, 2017

44

slide-45
SLIDE 45

2018: 9 Lives of Bleichenbacher's CAT 2018: 9 Lives of Bleichenbacher's CAT Cache sidechannels that work against almost most RSA implementations

Ronen et al, 2018

45

slide-46
SLIDE 46

Bleichenbacher attack countermeasures Bleichenbacher attack countermeasures

TLS 1.0 TLS 1.1 TLS 1.2

Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used to attack a TLS server which is using PKCS#1 encoded RSA. The attack takes advantage of the fact that by failing in different ways, a TLS server can be coerced into revealing whether a particular message, when decrypted, is properly PKCS#1 formatted
  • r not.
The best way to avoid vulnerability to this attack is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. Thus, when it receives an incorrectly formatted RSA block, a server should generate a random 48-byte value and proceed using it as the premaster
  • secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not. Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used to attack a TLS server that is using PKCS#1 v 1.5 encoded
  • RSA. The attack takes advantage of the fact that, by failing
in different ways, a TLS server can be coerced into revealing whether a particular message, when decrypted, is properly PKCS#1 v1.5 formatted or not. The best way to avoid vulnerability to this attack is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. Thus, when a server receives an incorrectly formatted RSA block, it should generate a random 48-byte value and proceed using it as the premaster
  • secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not. [PKCS1B] defines a newer version of PKCS#1 encoding that is more secure against the Bleichenbacher attack. However, for maximal compatibility with TLS 1.0, TLS 1.1 retains the
  • riginal encoding. No variants of the Bleichenbacher attack
are known to exist provided that the above recommendations are followed. Implementation Note: Public-key-encrypted data is represented as an
  • paque vector <0..2^16-1> (see Section 4.7).
Thus, the RSA-encrypted PreMasterSecret in a ClientKeyExchange is preceded by two length
  • bytes. These bytes are redundant in the case of
RSA because the EncryptedPreMasterSecret is the
  • nly data in the ClientKeyExchange and its
length can therefore be unambiguously
  • determined. The SSLv3 specification was not
clear about the encoding of public-key-encrypted data, and therefore many SSLv3 implementations do not include the length bytes, encoding the RSA encrypted data directly in the ClientKeyExchange message. This specification requires correct encoding of the EncryptedPreMasterSecret complete with length bytes. The resulting PDU is incompatible with many SSLv3 implementations. Implementors upgrading from SSLv3 must modify their implementations to generate and accept the correct encoding. Implementors who wish to be compatible with both SSLv3 and TLS should make their implementation's behavior dependent on the protocol version. Implementation Note: It is now known that remote timing-based attacks
  • n SSL are possible, at least when the client
and server are on the same LAN. Accordingly, implementations that use static RSA keys SHOULD use RSA blinding or some other anti-timing technique, as described in [TIMING]. Note: The version number in the PreMasterSecret MUST be the version
  • ffered by the client in the ClientHello, not the version
negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, many implementations use the negotiated version instead, and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations. Client implementations, MUST and Server implementations MAY, check the version number. In practice, since the TLS handshake MACs prevent downgrade and no good attacks are known on those MACs, ambiguity is not considered a serious security risk. Note that if servers choose to check the version number, they should randomize the PreMasterSecret in case of error, rather than generate an alert, in order to avoid variants on the Bleichenbacher attack. [KPR03] Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. [KPR03] can be used to attack a TLS server that reveals whether a particular message, when decrypted, is properly PKCS#1 formatted, contains a valid PreMasterSecret structure, or has the correct version number. As described by Klima [KPR03], these vulnerabilities can be avoided by treating incorrectly formatted message blocks and/or mismatched version numbers in a manner indistinguishable from correctly formatted RSA blocks. In other words:
  • 1. Generate a string R of 46 random bytes
  • 2. Decrypt the message to recover the plaintext M
  • 3. If the PKCS#1 padding is not correct, or the length of message
M is not exactly 48 bytes: pre_master_secret = ClientHello.client_version || R else If ClientHello.client_version <= TLS 1.0, and version number check is explicitly disabled: pre_master_secret = M else: pre_master_secret = ClientHello.client_version || M[2..47] Note that explicitly constructing the pre_master_secret with the ClientHello.client_version produces an invalid master_secret if the client has sent the wrong version in the original pre_master_secret. An alternative approach is to treat a version number mismatch as a PKCS-1 formatting error and randomize the premaster secret completely:
  • 1. Generate a string R of 48 random bytes
  • 2. Decrypt the message to recover the plaintext M
  • 3. If the PKCS#1 padding is not correct, or the length of message
M is not exactly 48 bytes: pre_master_secret = R else If ClientHello.client_version <= TLS 1.0, and version number check is explicitly disabled: premaster secret = M else If M[0..1] != ClientHello.client_version: premaster secret = R else: premaster secret = M Although no practical attacks against this construction are known, Klima et al. [KPR03] describe some theoretical attacks, and therefore the first construction described is RECOMMENDED. In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected. Instead, it MUST continue the handshake with a randomly generated premaster secret. It may be useful to log the real cause of failure for troubleshooting purposes; however, care must be taken to avoid leaking the information to an attacker (through, e.g., timing, log files, or other channels.) The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure against the Bleichenbacher attack. However, for maximal compatibility with earlier versions of TLS, this specification uses the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed. Implementation note: Public-key-encrypted data is represented as an
  • paque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
PreMasterSecret in a ClientKeyExchange is preceded by two length
  • bytes. These bytes are redundant in the case of RSA because the
EncryptedPreMasterSecret is the only data in the ClientKeyExchange and its length can therefore be unambiguously determined. The SSLv3 specification was not clear about the encoding of public-key- encrypted data, and therefore many SSLv3 implementations do not include the length bytes -- they encode the RSA-encrypted data directly in the ClientKeyExchange message. This specification requires correct encoding of the EncryptedPreMasterSecret complete with length bytes. The resulting PDU is incompatible with many SSLv3 implementations. Implementors upgrading from SSLv3 MUST modify their implementations to generate and accept the correct encoding. Implementors who wish to be compatible with both SSLv3 and TLS should make their implementation's behavior dependent on the protocol version. Implementation note: It is now known that remote timing-based attacks
  • n TLS are possible, at least when the client and server are on the
same LAN. Accordingly, implementations that use static RSA keys MUST use RSA blinding or some other anti-timing technique, as described in [TIMING].

46

slide-47
SLIDE 47

With every new TLS version the With every new TLS version the countermeasures became more countermeasures became more complicated complicated

47

slide-48
SLIDE 48

Many more attacks on poor choices in Many more attacks on poor choices in TLS 1.2 and earlier TLS 1.2 and earlier

SLOTH, FREAK, Logjam, SWEET32, Triple Handshake

48

slide-49
SLIDE 49

Fixing bugs like TLS 1.2 and earlier Fixing bugs like TLS 1.2 and earlier

49

slide-50
SLIDE 50

Use workarounds for known security issues

50

slide-51
SLIDE 51

If workarounds are insufficient use more workarounds

51

slide-52
SLIDE 52

Create optional secure modes, but keep the insecure

  • nes

52

slide-53
SLIDE 53

Fixing bugs like TLS 1.3 Fixing bugs like TLS 1.3

53

slide-54
SLIDE 54

Remove insecure cryptographic constructions

54

slide-55
SLIDE 55

TLS 1.3 Deprecations TLS 1.3 Deprecations

CBC-Modes, RC4, Triple-DES GCM with explicit nonces RSA Encryption, PKCS #1 1.5 MD5, SHA1 Diffie Hellman with custom or small parameters Obscure, custom and insecure Elliptic Curves

55

slide-56
SLIDE 56

Formal Verification Formal Verification

Researchers have started to formally analyze TLS in recent years

56

slide-57
SLIDE 57

Many vulnerabilities were found during protocol analysis

57

slide-58
SLIDE 58

These analyses have contributed to and guided the design of TLS 1.3

58

slide-59
SLIDE 59

Security is nice, but there's something Security is nice, but there's something else we care about: else we care about: Speed! Speed!

59

slide-60
SLIDE 60

TLS Fresh Handshake TLS Fresh Handshake

TLS 1.2 TLS 1.3

60

slide-61
SLIDE 61

TLS 1.3 handshake removes one round trip from fresh handshakes

61

slide-62
SLIDE 62

Handshake improves forward secrecy on session resumption and protects more data

62

slide-63
SLIDE 63

TLS 1.3 has a faster and more secure handshake

Watch 33C3 talk

63

slide-64
SLIDE 64

TLS 1.3 Zero Round Trip (0-RTT) TLS 1.3 Zero Round Trip (0-RTT)

64

slide-65
SLIDE 65

If we previously connected we can use a pre-shared Key (PSK) to send data without any round trip

65

slide-66
SLIDE 66

More speed! More speed!

66

slide-67
SLIDE 67

But 0-RTT is not for free But 0-RTT is not for free

67

slide-68
SLIDE 68

Replay attacks Replay attacks

68

slide-69
SLIDE 69

0-RTT should only be used where it's 0-RTT should only be used where it's safe safe

69

slide-70
SLIDE 70

Example HTTPS Example HTTPS

GET Request: Idempotent POST Request: Not Idempotent

70

slide-71
SLIDE 71

In theory HTTP GET requests are In theory HTTP GET requests are idempotent and safe for 0-RTT idempotent and safe for 0-RTT

71

slide-72
SLIDE 72

Do web developers know what Do web developers know what idempotent means? idempotent means?

72

slide-73
SLIDE 73

0-RTT does not have strong forward secrecy

73

slide-74
SLIDE 74

Many speculate that future TLS 1.3 attacks will exploit 0-RTT

74

slide-75
SLIDE 75

0-RTT is optional

75

slide-76
SLIDE 76

If it turns out being too bad we can disable it

76

slide-77
SLIDE 77

Deployment Deployment

77

slide-78
SLIDE 78

It's not enough to design a faster, more secure TLS protocol, you also have to deploy it

78

slide-79
SLIDE 79

On the Internet

79

slide-80
SLIDE 80

The real Internet

80

slide-81
SLIDE 81

The version number The version number

81

slide-82
SLIDE 82

This may sound trivial, but one other new thing that TLS 1.3 brings is a new version number

82

slide-83
SLIDE 83

83

slide-84
SLIDE 84

84

slide-85
SLIDE 85

85

slide-86
SLIDE 86

TLS 1.0 came aer SSL 3

86

slide-87
SLIDE 87

SSL 3 03 00 TLS 1.0 03 01 TLS 1.1 03 02 TLS 1.2 03 03 TLS 1.3 It's complicated

87

slide-88
SLIDE 88

TLS record layer TLS record layer

A protocol inside the protocol which has its own meaningless version number

88

slide-89
SLIDE 89

We can't update the whole Internet at once

89

slide-90
SLIDE 90

When we deploy a new version of TLS we need to still support old versions

90

slide-91
SLIDE 91

Let's assume we have a client supporting TLS 1.2 and a server supporting TLS 1.0

91

slide-92
SLIDE 92

TLS Version Negotiation TLS Version Negotiation

92

slide-93
SLIDE 93

This is very simple This is very simple

93

slide-94
SLIDE 94

if (client_max_version < server_max_version) { connection_version = client_max_version; } else { connection_version = server_max_version; }

94

slide-95
SLIDE 95

There's no way anyone could possibly get that wrong

95

slide-96
SLIDE 96

Okay, we were talking about the real Internet

96

slide-97
SLIDE 97

There are Enterprise Products There are Enterprise Products

97

slide-98
SLIDE 98

TLS Version Negotiation Enterprise Edition TLS Version Negotiation Enterprise Edition

98

slide-99
SLIDE 99

Version intolerance Version intolerance

99

slide-100
SLIDE 100

Version intolerance shows up every single time a new TLS version is introduced

100

slide-101
SLIDE 101

What did browsers do? What did browsers do?

101

slide-102
SLIDE 102

102

slide-103
SLIDE 103

Remember POODLE (2014)? Remember POODLE (2014)?

Guanaco, Wikimedia Commons, CC0

103

slide-104
SLIDE 104

POODLE was a Padding Oracle in SSL 3 POODLE was a Padding Oracle in SSL 3

104

slide-105
SLIDE 105

Who used SSL 3 in 2014? Who used SSL 3 in 2014? It was deprecated for 16 years It was deprecated for 16 years

105

slide-106
SLIDE 106

Nokia Phones with Windows Mobile (built 2011) Nokia Phones with Windows Mobile (built 2011)

Image: Petar Milošević, CC by 4.0

106

slide-107
SLIDE 107

But most browsers and most servers But most browsers and most servers used at least TLS 1.0 used at least TLS 1.0

107

slide-108
SLIDE 108

108

slide-109
SLIDE 109

So how to fix these insecure So how to fix these insecure downgrades? downgrades?

Let's add another workaround

109

slide-110
SLIDE 110

SCSV: Introduce a mechanism that lets well-behaving servers detect when clients did a downgrade

110

slide-111
SLIDE 111

At some point Enterprise servers had fixed version intolerance and browsers stopped these downgrades

111

slide-112
SLIDE 112

Have I said they fixed version intolerance? Of course not!

112

slide-113
SLIDE 113

They fixed version intolerance for TLS 1.2, not for 1.3

113

slide-114
SLIDE 114

New version negotiation in TLS 1.3 New version negotiation in TLS 1.3

Old version field (legacy_version) stays at TLS 1.2 New extension (supported_versions) signals support for future TLS versions.

114

slide-115
SLIDE 115

Does that mean we will have the same problem again with TLS 1.4?

115

slide-116
SLIDE 116

GREASE GREASE

(Generate Random Extensions And Sustain Extensibility)

116

slide-117
SLIDE 117

Servers should ignore unknown versions in supported_versions

117

slide-118
SLIDE 118

Let's train servers to actually do that

118

slide-119
SLIDE 119

GREASE values are reserved, bogus TLS versions that will never be used for real TLS versions

119

slide-120
SLIDE 120

Clients can randomly send GREASE values in the TLS handshake

120

slide-121
SLIDE 121

Implementors with broken version negotiation will hopefully notice that before shipping their product

121

slide-122
SLIDE 122

Okay, so with the new version negotiation and GREASE we can ship TLS 1.3?

122

slide-123
SLIDE 123

The Middlebox disaster The Middlebox disaster

123

slide-124
SLIDE 124

In summer 2017 TLS 1.3 was almost finished and ready to go, but it took another year until it was actually finalized

124

slide-125
SLIDE 125

Browser vendors noticed a high number of connection failures when trying to deploy TLS 1.3

125

slide-126
SLIDE 126

The reason: Devices analyzing traffic and trying to be smart

126

slide-127
SLIDE 127

"Let's look at this TLS package. I've never seen something like that... let's better discard it."

127

slide-128
SLIDE 128

These were largely passive middleboxes that should just pass traffic through

128

slide-129
SLIDE 129

How to fix How to fix

Browser vendors proposed some changes to TLS 1.3 that made it look more like TLS 1.2

129

slide-130
SLIDE 130

ChangeCipherSpec in TLS 1.2 ChangeCipherSpec in TLS 1.2

The ChangeCipherSpec (CCS) message signals the change from unencrypted to encrypted content

130

slide-131
SLIDE 131

Let's send a bogus CCS early in the handshake and hope this will confuse "smart" middleboxes into thinking that everything aerwards is encrypted and shouldn't be touched

131

slide-132
SLIDE 132

MiNe, Wikimedia Commons, CC by 2.0

132

slide-133
SLIDE 133

133

slide-134
SLIDE 134

Dual EC DRBG Dual EC DRBG

The NSA created a random number generator with a backdoor and convinced NIST to standardize it

134

slide-135
SLIDE 135

With a generous offer of 10 Million Dollar they convinced RSA security to use Dual EC DRBG

135

slide-136
SLIDE 136

Extended Random Extended Random

There exists a dra for a TLS extension that adds some extra random numbers to the TLS handshake

136

slide-137
SLIDE 137

Why? Why?

137

slide-138
SLIDE 138

In 2014 researchers figured out that Extended Random makes the Dual EC DRBG backdoor much more effective

Checkoway et al, 2014

138

slide-139
SLIDE 139

Coincidentally RSA's BSAFE library also contained support for Extended Random - but it was switched off by default, so everyone thought it's no big deal

139

slide-140
SLIDE 140

Canon Pixma printers had a local HTTPS server, implemented with RSA BSAFE and Extended Random switched on

140

slide-141
SLIDE 141

Extended Random was only a dra, so it had no official Extension number, RSA just used one of the next available numbers

141

slide-142
SLIDE 142

This number collided with one of the new extensions in TLS 1.3, resulting in connection failures of TLS 1.3 supporting browsers and these Canon printers

142

slide-143
SLIDE 143

There were many more TLS deployment issues and There were many more TLS deployment issues and they continue they continue

143

slide-144
SLIDE 144

What about future TLS versions? What about future TLS versions?

144

slide-145
SLIDE 145

We have GREASE, which helps a bit We have GREASE, which helps a bit

145

slide-146
SLIDE 146

There's even a proposal to regularly roll out temporary TLS versions every few months

146

slide-147
SLIDE 147

My prediction: These deployment problems are going My prediction: These deployment problems are going to get worse to get worse

147

slide-148
SLIDE 148

148

slide-149
SLIDE 149

149

slide-150
SLIDE 150

In the future we may have AI-supported TLS change intolerance, and that may be much harder to fix

150

slide-151
SLIDE 151

Speaking of Enterprise environments Speaking of Enterprise environments

151

slide-152
SLIDE 152

TLS removed the RSA encryption TLS removed the RSA encryption handshake very early handshake very early

152

slide-153
SLIDE 153

It doesn't have Forward Secrecy and it It doesn't have Forward Secrecy and it suffers from Bleichenbacher attacks suffers from Bleichenbacher attacks

153

slide-154
SLIDE 154

An E-Mail to the TLS Working Group from An E-Mail to the TLS Working Group from the Banking Industry the Banking Industry

[tls] Industry Concerns about TLS 1.3

154

slide-155
SLIDE 155

I recently learned of a proposed change that would affect many of my organization's member institutions: the deprecation of 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.

BITS/TLS list

155

slide-156
SLIDE 156

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

Kenny Paterson

156

slide-157
SLIDE 157

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 dra 15 and RSA key transport disappeared from the spec about a dozen dras ago. I know the banking industry is usually a bit slow off the mark, but this takes the biscuit.

Kenny Paterson

157

slide-158
SLIDE 158

This led to several proposals to add a "visibility" mode to TLS 1.3, which were all rejected by the IETF TLS working group

158

slide-159
SLIDE 159

The prevailing opinion in the TLS working group was that the goal of monitoring traffic content is fundamentally at odds with the goal of TLS

159

slide-160
SLIDE 160

So the industry went to ETSI, the European standardization organization

160

slide-161
SLIDE 161

They published Enterprise TLS (ETLS) They published Enterprise TLS (ETLS)

161

slide-162
SLIDE 162

The IETF wasn't happy about the abuse of the name TLS

162

slide-163
SLIDE 163

163 . 1

slide-164
SLIDE 164

What's le? What's le?

163 . 2

slide-165
SLIDE 165

Many attacks aren't against the cryptography of the protocol itself

163 . 3

slide-166
SLIDE 166

Despite all the protocol issues the biggest TLS security flaw is probably that people aren't using it

163 . 4

slide-167
SLIDE 167

SSL Stripping SSL Stripping

163 . 5

slide-168
SLIDE 168

We should use HTTPS by default

163 . 6

slide-169
SLIDE 169

We also need to enforce it with HSTS (HTTP Strict Transport Security)

163 . 7

slide-170
SLIDE 170

E-Mail E-Mail

163 . 8

slide-171
SLIDE 171

Server-to-Server STARTTLS is usually optional and unauthenticated

163 . 9

slide-172
SLIDE 172

MTA-STS MTA-STS

Publishing a TLS policy for SMTP via HTTPS

163 . 10

slide-173
SLIDE 173

Certificates Certificates

163 . 11

slide-174
SLIDE 174

Popular Hacker Opinion Popular Hacker Opinion

"The whole Certificate Authority system is broken"

163 . 12

slide-175
SLIDE 175

Things have improved considerably, yet not everyone wants to recognize that

163 . 13

slide-176
SLIDE 176

Certificates Transparency Certificates Transparency

163 . 14

slide-177
SLIDE 177

CAs that repeatedly violate rules get CAs that repeatedly violate rules get distrusted distrusted

163 . 15

slide-178
SLIDE 178

No CA is too big to fail No CA is too big to fail

If you don't believe it ask Symantec

163 . 16

slide-179
SLIDE 179

Future attacks Future attacks

163 . 17

slide-180
SLIDE 180

Compression attacks Compression attacks

CRIME, BREACH, TIME, HEIST

163 . 18

slide-181
SLIDE 181

There's yet no satisfying fix for compression attacks

163 . 19

slide-182
SLIDE 182

Domain Validation Domain Validation

163 . 20

slide-183
SLIDE 183

Certificates are issued based on checks of domain

  • wnership, yet these checks happen over an

unencrypted Internet

163 . 21

slide-184
SLIDE 184

Getting Certificates via BGP Hijacking Getting Certificates via BGP Hijacking

163 . 22

slide-185
SLIDE 185

This is definitely possible, but hasn't been seen in the real world yet

163 . 23

slide-186
SLIDE 186

No, Extended Validation does not help

163 . 24

slide-187
SLIDE 187

Summary Summary

164

slide-188
SLIDE 188

TLS 1.3 deprecates many insecure TLS 1.3 deprecates many insecure constructions constructions

165

slide-189
SLIDE 189

TLS 1.3 is faster TLS 1.3 is faster

166

slide-190
SLIDE 190

Deploying new things on the Internet is a Deploying new things on the Internet is a mess mess

167

slide-191
SLIDE 191

Encrypt your connections! Encrypt your connections!

168