Accountable Proxying over TLSattacks and proofs for middlebox protocols

Karthik Bhargavan

http://prosecco.inria.fr+

Ioana Boreanu, Antoine Delignat-Lavaud, Pierre-Alain Fouque, Cristina Onete

Analyzing Middlebox Security Protocols

Client Middlebox Server

UntrustedNetwork

UntrustedNetwork

• What are the intended security properties?• What are the new attack vectors?• How do we prove that a proposed protocol is secure?

Secure Channels over Insecure Networks

Threat:• Read• Tamper• Impersonate

Web Server

Internet

Web User

Malcious JavaScript

Network Attacker

Malicious Websites

Datacenter

Secure Channels over Insecure Networks

Threat:• Read• Tamper• Impersonate

Web Server

Internet

Web User

Solution: a secure (authentic, confidential) channel • A long-solved problem in theoretical cryptography• In practice: Just use TLS 1.2• But despite years of study, getting it right is still a challenge!

Malcious JavaScript

Network Attacker

Malicious Websites

Datacenter

Many, many recent attacks on TLS• BEAST CBC predictable IVs [Sep’11]

• CRIME Compression before Encryption [Sep’12]

• RC4 Keystream biases [Mar’13]

• Lucky 13 MAC-Encode-Encrypt CBC [May’13]

• 3Shake Insecure resumption [Apr’14]

• POODLE SSLv3 MAC-Encode-Encrypt [Dec’14]

• SMACK State machine attacks [Jan’15]

• FREAK Export-grade 512-bit RSA [Mar’15]

• LOGJAM Export-grade 512-bit DH [May’15]

• SLOTH RSA-MD5 signatures [Jan’16]

• DROWN SSLv2 RSA-PKCS#1v1.5 [Mar’16]

Many, many recent attacks on TLS• BEAST CBC predictable IVs [Sep’11]

• CRIME Compression before Encryption [Sep’12]

• RC4 Keystream biases [Mar’13]

• Lucky 13 MAC-Encode-Encrypt CBC [May’13]

• 3Shake Insecure resumption [Apr’14]

• POODLE SSLv3 MAC-Encode-Encrypt [Dec’14]

• SMACK State machine attacks [Jan’15]

• FREAK Export-grade 512-bit RSA [Mar’15]

• LOGJAM Export-grade 512-bit DH [May’15]

• SLOTH RSA-MD5 signatures [Jan’16]

• DROWN SSLv2 RSA-PKCS#1v1.5 [Mar’16]

Why so many attacks?

1. TLS design was too focused on interop

• 100s of possible modes in TLS 1.2

• Lots of hard-to-analyze corner-cases

2. Not enough attention to threat model

• Users ignored theoretical attacks,

until they suddenly became practical

First realistic TLS proofs came after 20 years!

Formal security analysis hand-in-hand with standardization• Cryptographic proofs (of drafts 5,9,10)

• Mechanized cryptographic proofs (of draft 18)

• Automated symbolic protocol analysis (of draft 10, 18, 20)

• Verified implementations (of draft 18)

Many proofs, in various models, providing higher assurance.Can we build on these to analyze Middlebox security protocols?

Analyzing Middlebox Security Protocols

Client (C) Middlebox (M) Server (S)

UntrustedNetwork

Network Attacker Network Attacker

UntrustedNetwork

New 3-party security goals: C, M, and S must jointly agree on session keys & params

Middleboxes over TLS Connections

TLS TLS

Is the composition of TLS connections always secure?• Does it provide an end-to-end security between C and S?• Do C, M, and S agree on each others identities?

Client (C) Middlebox (M) Server (S)

Relying on Strong Trust Assumptions

TLS TRUSTED CHANNEL

CDN: server fully trusts middlebox with its private key

Relying on Strong Trust Assumptions

TLSTRUSTED CHANNEL

Firewall: client fully trusts middlebox as a proxy

KeylessSSL: Limiting Server-side Trust

TLS KEY USAGE API

Server partially trusts middlebox to terminate TLSbut does not hand over its private key

Clients CDN (TLS terminator) Key Server

Fewer trust assumptions, but tricky to get right.Content delivery over TLS: a cryptographic analysis of Keyless SSL, K Bhargavan, I. Boureanu, P-A. Fouque, C. Onete, B. Richard. Euro S&P 2017

mcTLS: Towards Accountable Middleboxes[

TLS TLS

Client Server

TLS

PERMISSIONS (M1,read)

Middleboxes

Middlebox must be explicitly authorized by both client and server, and is given limited permissions.

mcTLS: Towards Accountable Middleboxes[

TLS’ (C-M) TLS’ (M-S)

Client (C) Server (S)

TLS (C-S) forwarded by M

Middlebox (M)

Three TLS channels, run in parallel (for efficiency)• How do we prove that their composition is secure?• C-M and M-S channels run modified TLS handshakes

Authentication Attacks on mcTLS[

Client (C) Server (S)Middlebox (M)

Malicious Server (S’)

Session (C-M-S) Session (C-M-S’)

Impact: a CDN middlebox may send wrong cached server pages to client

Authentication Attacks on mcTLS[

Client (C) Server (S)Middlebox (M)

Session (C-M-S’) Session (C-M-S)

Impact: a Firewall may apply allowmalware in from malicious S’

From Attacks to Proofs

Security Properties– Entity Authentication– Channel Security– Configuration Soundness (honest; corrupt MW; corrupt endpoint)

Intuition: “small” ACCE 2-party sessions are bound together in the multiparty handshake

18

Authenticated and confidential channel establishment (ACCE) with accountable proxies (AP)

C1-master S1-masterC2-cumulative MW2-cumulative

MW3-cumulative S3-cumulative

A New Formal Model: ACCE-AP

Extending ACCE

Accountability!

Check our

paper!

19

Check our

paper!

Proposed Protocol: Accountable Proxying over Secure Channels

Generic Protocol: instantiable with any ACCE protocol

We give a TLS1.3instantiation

Modular: it does not modify the base-protocol

20

are identical, even if A can corrupt all servers (for the SACCEprotocols) and all parties (for the ACCE protocol). We callthe latter property pseudo-uniqueness of ek.

Our main reason for this assumption on the export keysis our notion of binding. We need to ensure that eachconfiguration yields a unique set of binders even whena legitimate party in the handshake misbehaves. Such acondition helps us bypass e.g.attacks of the triple-handshakekind, like those on mcTLS shown in Section II-C. Twoimportant aspects should be mentioned, regarding the pseudo-uniqueness assumption: (1) it is non-standard in AKE security(though interestingly it holds for TLS 1.3); (2) we do notrequire this same condition for the channel keys ck.

We do not demand pseudo-uniqueness of channel keyssince they play no part in binding. As we do not considerresumption, or other short-cuts needing stronger keys, weonly need channel keys be pseudo-random.The ACCE-AP-security of the 1-middlebox-version of⇧. We provide two security theorems for the multicontexthandshake proposed in Figure 4: Theorem 1 captures entityauthentication and channel security, and Theorem 2 capturesconfiguration soundness (in its three aspects). The proofs aredescribed in the full version.

Theorem 1. Let ⇧ be protocol in Figure 4, for which⇧1,⇧2,⇧3 and 1, 2, 3 are defined as above. If ⇧1,⇧3

are 2-SACCE secure, and ⇧2 is 2-ACCE secure, then:– ⇧ guarantees ACCE-AP entity authentication andchannel security;

Theorem 2. Let ⇧ be the protocol in Fig. 4, for which⇧1,⇧2,⇧3 and 1, 2, 3 are defined as above. If: (1)⇧1,⇧3 are 2-SACCE secure and ⇧2 is 2-ACCE secure; (2) 1, 2, 3 extend ⇧1,⇧2,⇧3 to also yield export keys ek

which are indistinguishable from random and pseudo-unique;(3) the KDF used to compute t1, t2, t3 is a secure PRF;(4) the hash function used for the recurring session hash iscollision-resistant, then:

– ⇧ is configuration sound w.r.t. partnering, maliciousmiddleboxes, and malicious endpoints.

These theorems informally guarantee 4 properties: anetwork adversary cannot convince an (honest) party it ispart of a different configuration than is actually the case; allaccess-control keys are correctly distributed (middleboxes getthe keys they are entitled to, and no collusion of maliciousmiddleboxes can learn anything about keys it is not entitledto know); middleboxes can detect malicious behavior inone endpoint (with respect to the permissions); no networkadversary can learn anything about the messages sent at therecord layer of our multicontext handshake.

The security of the handshake, however, makes no guar-antee w.r.t. the integrity and authenticity of messages sentat the proxied record layer. The secure-channel statementguarantees the integrity and authenticity of messages, but only

within a two-party session. To capture integrity on the end-to-end record layer, we need to consider the functionalitiesand permissions of the middleboxes. We do so next.Record-layer security. For a middlebox MW and a messagefragment m (as given by the division into contexts), letm

0 = MW (m) be the message m0 obtained by the honest

modification of m by MW . Note that m0 could be the sameas m, a correctly formatted message other than m, or it couldalso be an error message ?.

For the one-middlebox case, we can prove the followingresult w.r.t. record-layer security. The case of several middle-boxes will be discussed in the full paper, since it presentsmore problems.

Theorem 3. For any handshake of the protocol in Figure 4,for all instances ending in an accepting state w.r.t. theconfiguration, for all contexts, consider a message-fragmentm sent from one endpoint (which we will call sender) to theother endpoint (here called the receiver). Assume that thereceiver receives a ciphertext c⇤, for which it accepts theauthentication of the message, decrypting it to a messagefragment m⇤. Then:

– If the middlebox is corrupted, but has read-only permis-sions for the context corresponding to fragments m,m

⇤,then m

⇤ = m.– If the sender is corrupted, but the receiver and middleboxare honest, then m

⇤ = MW (m).

We can make no integrity and authenticity statement fora corrupted middlebox with write access. However, this isa flaw inherent to using read and write keys. The secondguarantee in Theorem 3 is something no SSL inspectionmethod, including mcTLS, has so far provided. Indeed, ourdouble-encryption thwarts the middlebox-bypass attack wepresented in Section II-C. This is a useful guarantee, as itensures that honest proxies always perform their due taskson messages sent to them, even by a dishonest endpoint.Enhancing integrity. We could also make this integrityguarantee stronger, and ensure, like mcTLS, that a messagethat is sent unchanged from the honest sender to the honestreceiver can be distinguished from a message that modifiedby a potentially-malicious middlebox with write access. Thisis easily done by adding a MAC, under, e.g., a key derivedfrom the export key of the master session under a new label.At the record layer, instead of just sending an authenticatedencryption under the read and write key of a message, wecould also add a MAC of that same message computed withthe write key for that fragment. We choose to avoid thisoverhead, since the guarantees we can offer for the recordlayer are anyway limited.

C. Prototype Implementation

We built a proof-of-concept implementation of theACCE-AP-⇧ protocol instantiated with TLS 1.3, as per

are identical, even if A can corrupt all servers (for the SACCEprotocols) and all parties (for the ACCE protocol). We callthe latter property pseudo-uniqueness of ek.

Our main reason for this assumption on the export keysis our notion of binding. We need to ensure that eachconfiguration yields a unique set of binders even whena legitimate party in the handshake misbehaves. Such acondition helps us bypass e.g.attacks of the triple-handshakekind, like those on mcTLS shown in Section II-C. Twoimportant aspects should be mentioned, regarding the pseudo-uniqueness assumption: (1) it is non-standard in AKE security(though interestingly it holds for TLS 1.3); (2) we do notrequire this same condition for the channel keys ck.

We do not demand pseudo-uniqueness of channel keyssince they play no part in binding. As we do not considerresumption, or other short-cuts needing stronger keys, weonly need channel keys be pseudo-random.The ACCE-AP-security of the 1-middlebox-version of⇧. We provide two security theorems for the multicontexthandshake proposed in Figure 4: Theorem 1 captures entityauthentication and channel security, and Theorem 2 capturesconfiguration soundness (in its three aspects). The proofs aredescribed in the full version.

Theorem 1. Let ⇧ be protocol in Figure 4, for which⇧1,⇧2,⇧3 and 1, 2, 3 are defined as above. If ⇧1,⇧3

are 2-SACCE secure, and ⇧2 is 2-ACCE secure, then:– ⇧ guarantees ACCE-AP entity authentication andchannel security;

Theorem 2. Let ⇧ be the protocol in Fig. 4, for which⇧1,⇧2,⇧3 and 1, 2, 3 are defined as above. If: (1)⇧1,⇧3 are 2-SACCE secure and ⇧2 is 2-ACCE secure; (2) 1, 2, 3 extend ⇧1,⇧2,⇧3 to also yield export keys ek

which are indistinguishable from random and pseudo-unique;(3) the KDF used to compute t1, t2, t3 is a secure PRF;(4) the hash function used for the recurring session hash iscollision-resistant, then:

– ⇧ is configuration sound w.r.t. partnering, maliciousmiddleboxes, and malicious endpoints.

These theorems informally guarantee 4 properties: anetwork adversary cannot convince an (honest) party it ispart of a different configuration than is actually the case; allaccess-control keys are correctly distributed (middleboxes getthe keys they are entitled to, and no collusion of maliciousmiddleboxes can learn anything about keys it is not entitledto know); middleboxes can detect malicious behavior inone endpoint (with respect to the permissions); no networkadversary can learn anything about the messages sent at therecord layer of our multicontext handshake.

The security of the handshake, however, makes no guar-antee w.r.t. the integrity and authenticity of messages sentat the proxied record layer. The secure-channel statementguarantees the integrity and authenticity of messages, but only

within a two-party session. To capture integrity on the end-to-end record layer, we need to consider the functionalitiesand permissions of the middleboxes. We do so next.Record-layer security. For a middlebox MW and a messagefragment m (as given by the division into contexts), letm

0 = MW (m) be the message m0 obtained by the honest

modification of m by MW . Note that m0 could be the sameas m, a correctly formatted message other than m, or it couldalso be an error message ?.

For the one-middlebox case, we can prove the followingresult w.r.t. record-layer security. The case of several middle-boxes will be discussed in the full paper, since it presentsmore problems.

Theorem 3. For any handshake of the protocol in Figure 4,for all instances ending in an accepting state w.r.t. theconfiguration, for all contexts, consider a message-fragmentm sent from one endpoint (which we will call sender) to theother endpoint (here called the receiver). Assume that thereceiver receives a ciphertext c⇤, for which it accepts theauthentication of the message, decrypting it to a messagefragment m⇤. Then:

– If the middlebox is corrupted, but has read-only permis-sions for the context corresponding to fragments m,m

⇤,then m

⇤ = m.– If the sender is corrupted, but the receiver and middleboxare honest, then m

⇤ = MW (m).

We can make no integrity and authenticity statement fora corrupted middlebox with write access. However, this isa flaw inherent to using read and write keys. The secondguarantee in Theorem 3 is something no SSL inspectionmethod, including mcTLS, has so far provided. Indeed, ourdouble-encryption thwarts the middlebox-bypass attack wepresented in Section II-C. This is a useful guarantee, as itensures that honest proxies always perform their due taskson messages sent to them, even by a dishonest endpoint.Enhancing integrity. We could also make this integrityguarantee stronger, and ensure, like mcTLS, that a messagethat is sent unchanged from the honest sender to the honestreceiver can be distinguished from a message that modifiedby a potentially-malicious middlebox with write access. Thisis easily done by adding a MAC, under, e.g., a key derivedfrom the export key of the master session under a new label.At the record layer, instead of just sending an authenticatedencryption under the read and write key of a message, wecould also add a MAC of that same message computed withthe write key for that fragment. We choose to avoid thisoverhead, since the guarantees we can offer for the recordlayer are anyway limited.

C. Prototype Implementation

We built a proof-of-concept implementation of theACCE-AP-⇧ protocol instantiated with TLS 1.3, as per

Record-layer guarantees...Entity authentication + Channel security Configuration soundness

Provable Security for Accountable Proxying

Be careful when modifying TLS or using it in new ways• Even experts often get it wrong

Many middlebox functionalities can be built on top of TLS• Accountable proxies with provable security, but incurs overhead

Formal models can help find attacks, guide stronger designs• Applied cryptography researchers are willing to help

• Paper:

• INRIA Prosecco: https://prosecco.inria.fr • Project Everest: https://project-everest.github.io