TLS/SSL in distributed systems Eugen Babinciuc
Contents 1. Introduction to TLS/SSL 2. A quick review of cryptography 3. TLS/SSL in distributed systems 4. Conclusions
Introduction to TLS/SSL
TLS/SSL History Secure Sockets Layer (SSL) was originally developed by Netscape SSL 1.0 was never publicly released SSL 2.0 was released in 1995 SSL 3.0 was released in 1996 Transport Layer Security (TLS) TLS 1.0 was defined in 1999 and was an upgrade of SSL 3.0 TLS 1.1 was defined in 2006 TLS 1.2 was defined in 2008
Transport Layer Security (TLS) TLS is a security protocol that provides secure communication between applications over unsecured channels. It provides the following security properties: Privacy Data integrity
A quick review of Cryptography Symmetric Cryptography One shared key Asymmetric/Public Cryptography Key Pair Public Key Private Key
Symmetric Cryptography One Key
Asymmetric Cryptography Key Pair
Key Exchange Cl Client Server S Cl S
Secure data transmission Cl Client Server S Cl S S Cl S
A A A S Man in the Middle Attack (MiTM) Cl Client Server S Cl S Attacker
X.509 Certificate (TLS/SSL Certificate) example.com Server example.com S h CA Certificate Authority S CA S CA
Certificate Authority Cl S Client Server Cl S? CA =? h Certificate Authority S h CA S h CA CA
TLS/SSL protocol TLS protocol has two layers: - TLS Handshake Protocol - TLS Record Protocol
TLS/SSL Handshake protocol TLS Version Session ID Selected Cipher Random Number Client Verify Certificate ClientHello ServerHello Server Certificate ClientCertificate* ClientKeyExchange Finished Finished TLS Version Session ID List of Cipher Suites Random number Server Pre Master Key
TLS/SSL Handshake protocol - Agree on protocol version - Select cryptographic algorithms - Optionally authenticate each other - Establish a shared secret (master key)
TLS/SSL Record protocol - Uses the master key that was established during Handshake Protocol - Uses symmetric key cryptography - Ensures data confidentiality - Ensures data integrity
TLS/SSL Vulnerabilities What about the Heartbleed vulnerability? Isn t TLS/SSL broken?
Openssl Heartbleed Vulnerability Please send me back: Ping (4 letters) Ping (4 letters) Client Server
Openssl Heartbleed Vulnerability - TLS has a Heartbeat Extension, which is similar to an echo service. - It may be used for a Liveliness Check - It has two types of messages: HeartbeatRequest HeartbeatResponse
Openssl Heartbleed Vulnerability Please send me back: Ping; user=admin; Ping (100 letters) password=qwerty; private_key=124973518 (100 letters) Attacker Server
Openssl Heartbleed Vulnerability HeartbeatRequest Payload PayloadSize Attacker Payload = 1 byte PayloadSize = 64KB HeartbeatResponse Payload + other data PayloadSize Server Memory Payload
Cryptography summary - TLS is based on public key cryptography - Certificates should be signed by a CA - Self-Signed certificates are vulnerable to MiTM - Only the owner of the private key can decrypt the message that was encrypted with his public key
Typical HTTPS Communication HTTP + TLS = HTTPS HTTPS Client Server
Encapsulation of data TLS TCP Client Server
TLS in TCP/IP Stack Application Layer Transport Layer HTTP TCP, UDP TLS Network Layer IP Data link layer Ethernet
TLS in OSI Model Application Layer Presentation Layer Session Layer Transport layer Network layer Data link layer Physical layer HTTP TCP, UDP IP Ethernet TLS
Distributed applications
Distributed applications Client Load Balancer Back-end services
Distributed applications Load balancer features: Stickiness Client IP forwarding
Load Balancer with Stickiness Client Load Balancer Back-end services
Load Balancer without Stickiness Client Load Balancer Back-end services
Load Balancer and Client IP IP: 2.2.2.2 IP: 10.0.0.2 IP: 1.1.1.1 IP: 10.0.0.1 Client IP: 1.1.1.1 Load Balancer IP: 10.0.0.1 Back-end services
Case Studies on application architectures that use TLS
Different Architectures TLS architectures in distributed systems: HTTPS HTTP HTTPS HTTPS TCP TCP
First Case HTTPS - HTTP HTTPS Client Load Balancer Back-end services
Second Case HTTPS - HTTPS HTTPS Client Load Balancer Back-end services
Third Case TCP - TCP TCP HTTPS Client Load Balancer Back-end services
Proxy Protocol IP TCP Proxy Protocol DATA
"PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n" Proxy Protocol Proxy Protocol format: TCP/IPv4 (maximum 56 chars) "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n TCP/IPv6 : (maximum 104 chars) "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n"
Summary HTTPS-HTTP Supports Sticky Sessions Supports X-Forwarded-For header Internal network should be trusted HTTPS-HTTPS Supports Sticky Sessions Supports X-Forwarded-For header SSL certificate should be installed on load balancer
Summary TCP-TCP Generic TCP load balancer Should be used Proxy Protocol header Provides best security
TLS in AWS Client Elastic Load Balancer EC2 Instances AWS Cloud
Conclusions You should use TLS for secure communication between applications. There are multiple architectures that use TLS in distributed systems, your choice should be made based on your needs.
?