DS517 – Data Security

Lecture 5
Transport Layer Security
The protocol and the challenges of TLS
Elias Athanasopoulos
[email protected]
Overview
• TLS is the de facto protocol that is used for secure
communications over the web
– Guarantees confidentiality, integrity and site
authentication
• The protocol requires an infrastructure for
important trust decisions
– Trust in TLS is facilitated through the use of digital
certificates obtained by Certificate Authorities (CAs)
• We have improvements in cryptography used in
TLS, however, the trust model (CA/Browser)
faces, still, a lot of challenges

2
Roadmap
• How TLS works
• Cryptographic protocol issues
• Trust model issues
• Security enhancements
• Ongoing research

3
HOW TLS WORKS

4
 History of TLS

Protocol Year
SSL 1.0 n/a
Netscape SSL 2.0 1995
SSL 3.0 1996
TLS 1.0 1999
TLS 1.1 2006
TLS 1.2 2008
We are here
TLS 1.3 In use since 2018

5
Protocol Composition
• TLS Handshake
– Several slightly different forms based on the
cipher suite used
– Cipher suite: (a) key-exchange algorithm, (b) bulk
encryption algorithm, (c) MAC algorithm
• TLS Record Protocol
– The part of the protocol that transmits encrypted
data

6
TLS Handshake
Client Server
TCP SYN
SYN ACK TCP
ACK
ClientHello
ServerHello
Certificate
ServerHelloDone
ClientKeyExchange TLS
ChangeCipherSpec
Finished
ChangeCipherSpec
Finished
Data (GET / HTTP/1.1)
Encrypted 7
ClientHello
ServerHello
• Client advertises the ciphers it supports
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_RC4_128_SHA
...
• Server selects one from the list
• Server sends its certificate
• ServerHelloDone announces that there are
no more messages from the server at this point

8
ClientKeyExchange
• The client encrypts a secret with the server’s
public key (found in the certificate)
• ChangeCipherSpec signals that from now
on messages will be encrypted
• Finished, the first message to be encrypted
and the client’s last message of the
handshake, contains a MAC (cryptographic
checksum) of all handshake messages
exchanged

9
ChangeCipherSpec
• The server decrypts the secret found in
the ClientKeyExchange message using
its certificate’s private key, and derives the
master secret and communication keys
• Finished, signals a switch to encrypted
communication and completes the handshake

10
TLS Record Protocol

The right record size

- Small records have larger CPU overhead due to frequent MAC
verification
- Large records will have to be reassembled by the TCP layer
before they can be processed by the TLS layer
- Not always possible to tune the record size

11
CRYPTOGRAPHIC PROTOCOL ISSUES

12
Overview
• TLS is heavily based on cryptography
• Not only one algorithm is used, but many
– Symmetric encryption, asymmetric encryption,
cryptographic hash functions
• Sometimes combining all these cryptographic
primitives may lead to unfortunate choices
• Many sophisticated attacks, since TLS is a very
popular target

13
Weaknesses in
cryptographic primitives
• Weak encryption and signature key lengths
– As computational power increases, old key lengths are
considered vulnerable (any symmetric key less than 64
bits, RSA key less of 512 bits or less)
– Studies show that 4% support RSA with 512 and 93%
Single DES; they may support it, but it may not be
actually used in practice
– Appropriate keys should be also used by CAs when
issuing certificates
• Weak hash functions
– MD5 and other, nowadays, hash functions should not
be used in digital certificates

14
Implementation flaws and
related attacks
• Many values in TLS are generated randomly (e.g., keys)
– The Netscape browser had a weak PRNG (TLS session key was
predictable)
– In 2008, OpenSSL in Debian reduced the randomness and had
TLS certificates with predictable private keys
– Recently, 0.5% of TLS certificates were found to have
recoverable RSA private keys due to shared prime factors
• Remote timing attacks have been used against TLS servers
that use an optimized variant of RSA decryption
– The decryption algorithm makes branching decisions that are
functionally dependent on the long-term certified secret key
– Measurable differences in execution time
– Previous OpenSSL implementations of ECDSA enabled similar
remote timing attacks

15
Oracle attacks
Textbook RSA
• SSL 3.0 uses “textbook” RSA and suffers from
ciphertext malleability
– If upon decryption and decoding, the plaintext is not
properly encoded, an error is returned to the client
– An adversary captures an encrypted premaster secret,
and, in separate handshakes, submits adaptively
modified versions of it (malleability)
– The adversary can eventually (∼1M queries) recover
the premaster secret
– TLS 1.0 consequently recommends that encoding
errors are handled indistinguishably

16
Chosen-plaintext attack
• An attacker can perform cryptanalysis by
obtaining the ciphertext of their own plaintexts
• Notice, the attacker has not access to the
encryption key
– But the attacker can observe encrypted traffic and
send also their own traffic, to be encrypted, and then
being observed
• The attacker’s goal is to reveal encrypted content
created by the victim

17
Example
• Alice connects to Bob and establishes a secret
cookie
• Alice visits Mallory (the attacker) and receives a
malicious JavaScript code
• The malicious code can generate requests
towards Bob
– The code has not access to the secret cookie, but it
can control (some of) the request’s payload (e.g.,
fetch https://bob/myimage)
• Mallory can also observe the encrypted traffic
from Alice to Bob

18
Oracles

Mallory’s requests
Alice Bob
(encrypted traffic)

Mallory Oracle

Secret cookie

19
Oracle attacks
CBC initialization
• TLS 1.0 uses Cipher-block Chaining (CBC) mode,
when used with a block symmetric cipher
– Not applicable to stream ciphers (e.g., RC4)
• The initialization vector (IV) used in CBC by TLS
1.0 is predictable
– IV is set equal to the last block of ciphertext sent
• With a predictable IV, an attacker can submit
adaptively chosen cross-site requests for a
domain with a secure cookie to learn the value of
the cookie
– The attack is commonly known as BEAST

20
ECB Overview
Block 1 of Symmetric Cipher Block 1 of
plaintext (e.g., AES, DES) ciphertext

key

Block 2 of Symmetric Cipher Block 2 of

plaintext (e.g., AES, DES) ciphertext

key

...

Block N of Symmetric Cipher Block N of

plaintext (e.g., AES, DES) ciphertext

key
21
22
CBC Overview
Symmetric Cipher
Block 1 of
plaintext
⊕ (e.g., AES, DES)
Block 1 of
ciphertext
IV key

Block 2 of Symmetric Cipher Block 2 of

plaintext
⊕ (e.g., AES, DES) ciphertext
Block 1 key
of ciphertext
...

Block N of Symmetric Cipher Block N of

plaintext
⊕ (e.g., AES, DES) ciphertext
Block N-1 key
of ciphertext 23
Oracle attacks
Compression
• TLS does not obfuscate the length of a
compressed TLS record
• An adversary can inject partial plaintext and
observe the post-compression record length
– A change of length can signal an existing pattern in
the unknown (encrypted) part
• The attack is called CRIME and, similarly to
BEAST, it can recover secret values from
cookies

24
Protocol-level attacks
Ciphersuite downgrade
• In SSL 2.0, a MitM could influence and
downgrade the negotiation to the weakest
cryptographic option
– Fixed in SSL 3.0
– Client sends an authenticated digest of previous
handshake messages
• Recall, cryptographic negotiation is sent in the
clear, since no encryption has been
established at this point

25
Protocol-level attacks
Version downgrade
• The TLS version is also negotiated in the clear
• A MitM can change the versions exchanged
and force the parties to fall back in a weaker
protocol implementation
• TLS prohibits downgrading to SSL versions
• Downgrading from TLS version to an older TLS
version is still possible
– Mitigation: include the most up-to-date
cryptographic algorithms during negotiation

26
Protocol-level attacks
Renegotiation
• TLS can renegotiate for changing the ciphersuite,
session key, or other relevant connection
parameters
• The renegotiation protocol was discovered to be
flawed in 2009
• The bug allowed an adversary to establish a
connection to a server, send data, renegotiate,
and pass the renegotiated connection onto a
client that believes it is forming an initial
connection
27
TRUST MODEL ISSUES

28
CA/B model
• Assume a perfect TLS protocol
implementation
• In order to have TLS operational we need to
have the management of digital certificates by
Certificate Authorities (CA) and the correct
usage of them in web browsers
• This ecosystem of certificate handling and
browsers is called the CA/B model

29
Certification
Hostname validation by CAs
• Certificates are bind in domain names
• A CA needs to validate that a domain name is
valid
– This is usually enforced by authenticating the client
that wants to purchase the certificate through e-mail
• Many DNS attacks can corrupt this
communication
• Social engineering attacks are also possible
– A certificate for login.live.com (Hotmail) was
issued to a client that had acquired the e-mail address
[email protected]

30
Certification
Hostname validation by clients
• Clients are not only web browsers
– Site-specific applications (e.g., Facebook, Twitter)
• Although browsers attempt to validate the
hostname, many other clients that support
TLS did not
– Android mobile apps, e-commerce backend
systems, cloud clients

31
Certification
Parsing attacks
• Certificates have a complex format
• Implementation errors in certain parsing
libraries can accept incorrect invalid
certificates
– bank.com\0evil.com (where \0 is the null
character) was validated by some CAs as
bank.com and by some browsers as
evil.com

32
Anchoring trust
• Validating a certificate needs access to the
issuer’s public key
– How can we trust a public key?
– Major vendors (Microsoft, Google, Mozilla) install
these “public keys” or self-signed CA certificates in
their operating systems and browsers
• However, several other smaller CAs exist, which
are certified by major CAs
– A given certificate may be issued by an intermediate
CA
– A chain, including several CAs, is built and needs to be
validated for trusting the certificate
33
Anchoring trust
Security issues
• CA compromise
– Compromising a CA allows an attacker to issue certificates
that controls or MitM existing connections
– In 2011, two CAs were compromised, Comodo and
DigiNotar
• Compelled certificates
– Nation states can issue ‘trustable’ certificates and MitM
the connection of their citizens
• Transitivity of trust
– Hard to validate many intermediate CAs
– If the entire chain is not validated correctly the invalid
certificates may be accepted

34
Maintenance of trust
• Certificates have expiration date
– Beyond the expiration date, a certificate may be come invalid for
many other reasons (CA was compromised, the domain has
expired, etc.)
– Making a certificate invalid is a process called revocation
• Blocking revocation
– Clients should be able to update their lists of revoked
certificates
– A MitM could block traffic to the blacklist site or caching can
prevent updating
• Ownership transfer
– Certificates are bound to domain names
– A domain ownership change should revoke existing certificates

35
Interpretation of trust
• Certificates are managed by software but the
user can vet on the final decision
• It is important for users to understand
– The role of the certificates
– The validation status of the certificates
– What is the importance of an error related to
certificate validation
• Browsers have certain decorations and UX
messages for informing users

36
Interpretation of trust
Available mechanisms
• Browser security cues
– The URL begins with https:// and a lock icon is displayed
somewhere
• Browser security warnings
– Browsers display warnings if an HTTPS connection fails
• Mixed content
– Browsers will issue a mixed scripting warning if the site embeds
any scripting that are not accessed over HTTPS
• Mobile browsers
– Site specific apps hide warnings that are displayed by browsers
• HTTPS form submit
– Browsers include a general warning (at least the first time) when
any information is not submitted over HTTPS

37
Interpretation of trust
Security issues
• Stripping TLS
– A site that offers both TLS and non-TLS content can
disable TLS through MitM
• Spoofing browser
– Web sites can generate content (e.g., pop-up
windows) for hiding browser indicators
• Conceding a warning
– A MitM may choose to substitute in a certificate with
an untrusted chain and hope that users click-through
or otherwise ignore the warning

38
SECURITY ENHANCEMENTS

39
 Comparative evaluation
of proposals

Primitives

Criteria

Proposals

40
Proposals
• Key pinning
– Client history: remembers the last acceptable
public key for a particular site and warns the user
for any change
– Server: allows the server to specify in an HTTPS
header which certificate to pin and for how long
– Preloaded: vendor include a list of pins within the
browser itself
– DNS: servers pin their public key in their DNSSEC
record for clients to validate against

41
Proposals
• Multipath probing
– Certificate validation based on crowdsourcing
– Clients can cooperate for a certificate validation (“I have seen
this certificate before” or “I do not trust the CA that issued this
certificate”)
• Channel-bound credentials
– Cookies/passwords are bound to specific TLS sessions and
certificates
• Credential-bound channels
– Instead of having the server decide to accept a credential based
on its binding to a client certificate, the client decides whether
to accept a server certificate based on its binding to the client’s
credential
– Assumes a pre-shared password

42
Proposals
• Whenever there is a problem with a digital certificate,
it is questionable if the problem is connected with an
attack
– Is the certificate simply expired or a MitM is using an
expired certificate to attack?
• Key manifest
– A specification of all keys that could be used by the domain
• Key agility is an update mechanism for new certificates
– Signing the new certificate with the old certificate’s key
– Linking the certificate changes through use of a master
secret

43
Proposals
• HTTPS-only Pinning
– Support only HTTPS connections and not HTTP for
avoid SSL/TLS stripping
– This is communicated through headers
• Visual Cues for Secure POST
– Indicator that a POST form is not using HTTPS

44
Proposals
• Browser-stored CRL
– Browser vendors periodically update their browser with a
CRL (Certificate Revocation List) instead of having the
browser polling this information
• Certificate Status Stapling
– Browser-stored CRL but for OCSP (online certificate status
checking protocol)
• Short-lived Certificates
– Replacement of long-lasting certificates with short-lived
ones that certificate holders frequently renew
• List of Active Certificates
– A publicly searchable list of valid certificates

45
ONGOING RESEARCH

46
Important orthogonal
problems
• HTTPS does not bridge the cognitive gap between
the domain name and the content of a certificate
– A digital certificate is too technical for the average
user?
– This gap is exploited by phishing attacks
• A compromised client-platform (e.g., due to
malware) can subvert HTTPS protections,
including how protections are communicated to
the user
– Research on trusted execution in hostile environments

47
Protocol-level TLS–analysis and
modification
• Analysing TLS security in sufficiently broad
models remains an open research problem
• Security analysis of TLS has provided both
positive (security proofs) and negative
(attacks) results
• Problems in little-used components of TLS
results in disabling features (e.g., CBC-mode
and compression) rather than protocol
redesign

48
Trust model infrastructure
• Is the CA/B trust model a good solution?
– In the real world, we have short trust chains, but
CA/B allows long chains
– The end-user, as a relying party, in many cases
would have no knowledge of or business
relationship with CAs involved in these chains
• Users can go online for the first time and
without any personal choices, ‘trust’ millions
of sites
49
Human element/interface
• For a range of ‘soft’ errors (e.g., expired
certificates), it is unclear whether browsers
should fail open or outsource the decision to
the user
• The inability of the community to provide
interfaces and/or mechanisms that average
users can understand remains problematic

50
References
• SoK: SSL and HTTPS: Revisiting past challenges
and evaluating certificate trust model
enhancements, in Oakland 2013, by Jeremy
Clark and Paul C. van Oorschot

51