Πανεπιστήμιο Κύπρου Τμήμα Πληροφορικής [ΕΠΛ682 Advanced Security Topics] On the Effective Prevention of TLS Man-in-the-Middle Attacks in Web Applications Όνομα: Φιλίππου Χρίστα Καθηγητής : Δρ. Ηλίας Αθανασόπουλος Authors: Nikolaos Karapanos Srdjan Capkun Department of Computer Science, ETH Zurich
Contents Part (0/0): Contents o Introduction Background and Summary Importance o MITM How it works o Server Invariance What is it How it works o Attacker Models What is it Types of Models o TLS Channel ID based What is it MITM SITB Attack on Channel ID based Authentication o SISCA Protocol What is it How it works o Experimental Results SISCA with MITM SITB Attack on Verification phase SISCA with MITM SITB Attack on Initialization phase Incompatible Cross-Origin Communications o Papers Relation Comments o Conclusion
Introduction Part (1/2): Background and Summary o Consider TLS Man-In-The-Middle (MITM) attacks in the context of web applications. o The attacker is able to: Successfully impersonate the legitimate server to the user. Successfully impersonate the user to the server. à Goal: Compromise the user s online account and data. à Goal: Spying on the user (MITM: Man-in-the-Middle attack). o Explains the recently proposed client authentication protocols cannot fully prevent such attacks. o Objective: Shows that strong client authentication, such as Channel ID-based authentication, can be combined with the concept of server invariance to protect against the attacks. Leverage Channel ID-based authentication combined with server invariance for a novel mechanism SISCA SISCA prevent user impersonation via TLS MITM attacks.
Introduction Part (2/2):Importance Importance Attack methods are rising rapidly. TLS using RC4 encryption is used by every browser and we use it every day through the internet. With this kind of encryption weakness, our personal data (emails, ids, iban, accounts etc) can be compromised due to malicious acts. o TLS enables users to securely access/ interact with their online accounts, and protects, among common user authentication credentials (eg. passwords and cookies). o Such credentials are considered weak. o They are transmitted over the network and are susceptible to theft and abuse.
MITM (Man-in-the-Middle) in TLS Part (1/2): How it works?
Server Invariance Part (1/2): What is it? o Security control which accepts that the attacker can successfully impersonate the server and tries to detect if he attacked the connection. o No priori trust is necessary. Consider a browser s first connection to a particular server: o Scenario 1: The first connection is not intercepted by the attacker. Then, server invariance implies that the attacker is allowed to intercept none of the subsequent connections to that server. o Scenario 2: The first connection is intercepted by the attacker. Then, server invariance implies that the attacker has to intercept all subsequent connections to that server. àin both scenarios, if the attacker violates server invariance, attacker will be detected.
Server Invariance Part (2/2): How it works? o Server invariance protocol consists of two phases: 1. Initialization: is executed in the first connection to the server. could be intercepted by the attacker. The browser establishes a point of reference. 2. Verification: Is executed in subsequent connections to the same server. The browser verifies that the point of reference remains unchanged, i.e., the browser keeps connecting to the same entity.
Attacker Models and Goals Part (1/2): What is TLS? o Adversary s Goals: The attacker s goal in a MITM attack is: to impersonate the user (victim) to the legitimate server to compromise the user s online account and data (spy on the user, abuse his account for malicious purposes). to only impersonate the server to the user and serves to the user fake content. o The MITM+certificate attacker: 1) 2) holds a valid certificate for the domain of the target web server, binding the identity of the server to the public key, (holds the corresponding private key). The attacker has no access to the private key of the target web server. only holds an invalid (e.g., self-signed) certificate. The attacker will succeed in impersonating the server to the user à if the latter ignores the security warnings of the browser.
Attacker Models and Goals Part (2/2): Types of Models o The MITM+key attacker: Holds the private key of the legitimate server. o The attacker is able to get the user s weak credentials (passwords and HTTP cookies). o However he is not able to compromise the user s browser or his devices (e.g., mobile phones). MITL + Certificate attacker MITL + key attacker
TLS Channel IDs Part (1/2): How it works? o Is a TLS extension. o Identification of the same browser across multiple TLS connections. Example: o A browser visits a TLS-enabled web server for the first time. o It creates a new private/public key pair. o This TLS connection is identified by the corresponding public key, which is linked with a value called Channel ID. o Upon subsequent TLS connections to the same the same web origin, the user s browser uses the same Channel ID. *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
MITM Attack on Channel ID-Based Authentication Part (2/2): Channel ID Valnerability (SITB Script in the Browser) user MITM 1. Tries to visit www.example.com. 4. Receives the malicious respond. 6. Re- initializes TLS connection at www.example.com (JavaScript is executing). 2. Intercepts the TLS connection. Presents a valid/ Invalid (with user ignoring browser s warning) certificate. 3. Responds with a malicious JavaScript (HTTP). 5. Closes the TLS connection (forces the user to initiate new one). 7. Gains full control over user s session (monitoring, issue malicious requests, etc). Server origin Works also for Cross Origin Communications. *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA (Server Invariance with Strong Client Authentication Part (1/2): What is it? o Combines Channel ID based client authentication and server invariance. o Prevent the attacker from impersonating the server in the first place. This way, the attacker can neither steal weak user credentials (MITM attack) nor ship malicious JavaScript (MITM-SITB). o strong client authentication (e.g. Channel ID based) is not necessary for preventing MITM attacks. o MITM attacker can perform user impersonation via two approaches: 1. The conventional MITM attack à the attacker compromises (εκθέτει σε κίνδυνο) the user s credentials and uses them for impersonation. This attack can be effectively prevented by strong client authentication 2. The MITM-SITB attack à inject user s browser with malicious script. Client authentication alone cannot prevent this attack. *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA (Server Invariance with Strong Client Authentication Part (2/2): How it works? o Independent from rest protocols. o Is executed before any HTTP traffic influenced by the attacker. o They choose to implement it at the Application layer via HTTP header. o Transmitted with the first HTTP request/ response. o Basic SISCA Protocol (see Example): Notations: ü SISCA Keys: k s1, k s2 ü Browser s and server s Random values: r b, r s respectively ü Browser s Channel Id: cid b *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA (Server Invariance with Strong Client Authentication Part (1/3): MITM SITB Attack (on Verification phase) Resilience of SISCA to MITM-SITB (conventional MITM is prevented by Channel-ID based authentication). *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA (Server Invariance with Strong Client Authentication Part (2/3): MITM SITB Attack (on Initialization phase) Resilience of SISCA to MITM-SITB (conventional MITM is prevented by Channel-ID based authentication). *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA (Server Invariance with Strong Client Authentication Part (3/3): Incompatible Cross-Origin Communications When another domains through cross-origin communication are incompatible (does not support SISCA) *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
SISCA Benefits and Drawbacks Part (1/1): Comments Advantages: o Incremental deployment à SISCA is scalable. à A structural approach, meaning that the started with a basic version of our protocol then they incrementally added features. o MITM + certificate attack prevention. o Autonomous protocol. o No user decision is necessary whenever server invariance violation is detected. o Resists MITM + key attack. Disadvantages: o It only protects against MITM attackers whose goal is only to impersonate the server to the user. *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
Papers Relation Part (1/1): Paper Compination The previous paper was focused on plaintext recovery though a TLS connection. What if we use their Recovery Algorithm to recover SISCA keys? MITM Recovery Algorithm Input : t1 or t2.. Output: Ks1 or Ks2 *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
Conclusion Part (1/1): Conclusions o SISCA can act as: an additional, strong protection layer. combination of existing proposals/ protocols. Focus on amending today s server authentication issues, towards the effective prevention of TLS MITM attacks. *Figure 4-2: https://hpbn.co/transport-layer-security-tls/#tls-handshake
Thank you for your attention!