======================================================================= TLS AND HTTPS: WHY ENCRYPTION MATTERS ======================================================================= WITHOUT TLS (HTTP) ┌──────────┐ ┌──────────┐ │ │ GET /login?password=secret │ │ │ Client │ ───────────────────────────> │ Server │ │ │ (plaintext, readable) │ │ └──────────┘ └──────────┘ ↑ └─────── Anyone on the network can read this! WITH TLS (HTTPS) ┌──────────┐ ┌──────────┐ │ │ [encrypted gibberish] │ │ │ Client │ ───────────────────────────> │ Server │ │ │ (only server can read) │ │ └──────────┘ └──────────┘ TLS encrypts your data so only the intended recipient can read it. Even if someone intercepts the packet, they see random bytes. ======================================================================= ======================================================================= WHERE DOES TLS FIT IN THE TCP/IP MODEL? ======================================================================= TLS sits BETWEEN the Transport Layer (TCP) and Application Layer (HTTP): Without TLS (plain HTTP): [Ethernet] [IP] [TCP port 80] [HTTP Request - readable] With TLS (HTTPS): [Ethernet] [IP] [TCP port 443] [TLS: Encrypted HTTP - unreadable] Key points: - TLS encrypts the application data BEFORE it goes into TCP - Different port numbers (80 vs 443) tell the server what to expect - Port 80: Server expects plain HTTP immediately - Port 443: Server expects TLS handshake first, then encrypted HTTP Why different ports? - The server needs to know whether to start with TLS handshake or not - Port 80: Client sends HTTP directly - Port 443: Client sends TLS messages first to set up encryption - It's like calling a regular phone (80) vs. a secure line (443) What is 'ClientHello' and 'ServerHello'? ClientHello = First TLS message from client to server - Says: 'I want to use TLS, here are the encryption methods I support' - Contains: List of cipher suites, TLS version, random number - This is APPLICATION DATA inside a TCP packet, not a TCP flag ServerHello = Second TLS message from server to client - Says: 'OK, let's use THIS specific encryption method' - Contains: Chosen cipher suite, TLS version, random number - Also APPLICATION DATA inside a TCP packet These are NOT like SYN/ACK (which are TCP flags). They are actual DATA messages with structure and fields. TLS wraps HTTP, then TCP wraps TLS: 1. Take HTTP request: 'GET /login?password=...' 2. Encrypt it with TLS: [random-looking bytes] 3. Put it in TCP packet to port 443 4. Send over network ======================================================================= ======================================================================= DEMO 1: HTTP WITHOUT ENCRYPTION (PLAINTEXT) ======================================================================= Let's build a complete HTTP packet (TCP + HTTP): Packet structure: [TCP Header: sport=54321, dport=80] [HTTP Request] Total size: 82 bytes TCP header: 20 bytes HTTP data: 62 bytes Full Packet Hex Dump: 0000 D4 31 00 50 00 00 03 E8 00 00 13 88 50 18 20 00 .1.P........P. . 0010 00 00 00 00 47 45 54 20 2F 61 63 63 6F 75 6E 74 ....GET /account 0020 3F 70 61 73 73 77 6F 72 64 3D 4D 79 53 65 63 72 ?password=MySecr 0030 65 74 31 32 33 20 48 54 54 50 2F 31 2E 31 0D 0A et123 HTTP/1.1.. 0040 48 6F 73 74 3A 20 62 61 6E 6B 2E 63 6F 6D 0D 0A Host: bank.com.. 0050 0D 0A .. Notice: You can READ the password in the hex dump! Look at the ASCII column on the right -> 'password=MySecret123' The packet structure shows: - Bytes 0-19: TCP header (port 80 visible) - Bytes 20+: HTTP request (completely readable) Anyone with a packet sniffer (Wireshark, tcpdump) can see: - The URL you're visiting - Passwords and credentials - Cookies and session tokens - Personal information This is why HTTP is dangerous for sensitive data. ======================================================================= DEMO 2: HTTPS WITH ENCRYPTION (UNREADABLE) ======================================================================= HOW does the data get encrypted? The encryption process: 1. TCP handshake completes (SYN, SYN-ACK, ACK) 2. TLS handshake completes (ClientHello, ServerHello, etc.) 3. Both sides now have shared encryption keys 4. Client takes HTTP request: 'GET /account?password=MySecret123...' 5. Client encrypts it using the TLS session key 6. Client wraps encrypted data in TLS record header 7. Client puts TLS record in TCP packet to port 443 8. Server receives, decrypts using the same key Let's see what this looks like on the wire: Packet structure: [TCP Header: sport=54321, dport=443] [TLS: Encrypted HTTP] Total size: 89 bytes TCP header: 20 bytes TLS record: 69 bytes - TLS header: 5 bytes (type, version, length) - Encrypted data: 64 bytes (the HTTP request, encrypted) Full Packet Hex Dump: 0000 D4 31 01 BB 00 00 07 D0 00 00 17 70 50 18 20 00 .1.........pP. . 0010 00 00 00 00 17 03 03 00 40 D4 7F 3A 91 C8 25 6F ........@..:..%o 0020 4E B2 11 83 9D 47 2C 6A 15 8F 9A 2D 73 11 6C 84 N....G,j...-s.l. 0030 9F 3D 4A 71 5E 88 B3 21 09 6D 4F 82 7A 93 1C 5F .=Jq^..!.mO.z.._ 0040 68 A4 0F 97 2B 44 1D 89 73 F5 8C 61 3E 29 94 B7 h...+D..s..a>).. 0050 6F 11 C5 82 3A 67 94 1F 28 o...:g..( Notice: Complete gibberish after the TCP header! The ASCII column shows no readable text. Compare with Demo 1: Demo 1 (HTTP): Port 80, readable 'GET /account?password=...' Demo 2 (HTTPS): Port 443, random bytes The packet structure shows: - Bytes 0-19: TCP header (port 443 visible) - Bytes 20-24: TLS record header (type=0x17, version=0x0303) - Bytes 25+: Encrypted data (unreadable gibberish) This encrypted blob contains the SAME HTTP request: - Original: 'GET /account?password=MySecret123...' - Encrypted using the TLS session key (established in handshake) - Only the server (with the matching decryption key) can read it An attacker sees random bytes and cannot: - Read the URL - See passwords - Extract cookies - Understand anything The encryption key is unique for this session and was established during the TLS handshake (which we'll see in Demo 3). ======================================================================= DEMO 3: TLS HANDSHAKE - HOW ENCRYPTION IS ESTABLISHED ======================================================================= IMPORTANT: TLS handshake is DIFFERENT from TCP handshake! There are TWO handshakes when you connect to an HTTPS website: 1. TCP Handshake (Layer 3 - Transport Layer): Client -> Server: SYN Server -> Client: SYN-ACK Client -> Server: ACK Result: TCP connection established 2. TLS Handshake (Layer 4 - Application Layer): Client -> Server: ClientHello Server -> Client: ServerHello [More messages...] Result: Encryption keys established Key differences: TCP handshake: - Uses TCP flags (SYN, ACK) - Establishes connection (can we talk?) - No encryption yet TLS handshake: - Uses application data (ClientHello, ServerHello) - These are DATA inside TCP packets, not TCP flags - Establishes encryption (how do we encrypt?) - Happens AFTER TCP connection exists Think of it: TCP handshake = Opening a phone line TLS handshake = Agreeing on a secret code to speak in ======================================================================= Now, let's look at the TLS handshake in detail: Before any encrypted data flows, client and server perform the TLS HANDSHAKE to agree on encryption keys. TLS Handshake steps: 1. ClientHello -> Client: 'I want to use TLS, here are my options' 2. ServerHello -> Server: 'OK, let's use these encryption methods' 3. Certificate -> Server: 'Here's my identity proof (certificate)' 4. Key Exchange -> Both: 'Let's agree on a secret encryption key' 5. Finished -> Both: 'Handshake complete, let's start encrypting!' After TLS handshake completes, all HTTP data is encrypted. (The TCP connection stays open for the entire time.) ----------------------------------------------------------------------- Example: TLS ClientHello (Step 1) ----------------------------------------------------------------------- ClientHello message structure: version: TLS 1.2 ciphers: List of encryption algorithms client supports extensions: Additional features (SNI, ALPN, etc.) Hex Dump of ClientHello: 0000 16 03 03 00 31 01 00 00 2D 03 03 00 00 00 00 44 ....1...-......D 0010 4E 45 A2 8F 1A 9E 98 C6 E6 2D 1D 64 EC 56 32 F2 NE.......-.d.V2. 0020 1A E8 CA CA F1 FF 97 BB 03 A8 19 00 00 06 C0 2F .............../ 0030 C0 30 00 9E 01 00 .0.... Server responds with ServerHello, choosing one cipher from the list. Then both sides use that cipher to encrypt all subsequent data. ======================================================================= WHAT ARE CIPHER SUITES? ======================================================================= Cipher suite = Recipe for encryption Example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Breaking it down: TLS = Protocol ECDHE = Key exchange method (how to agree on secret key) RSA = Authentication method (verify server identity) AES_128_GCM = Encryption algorithm (scramble the data) SHA256 = Hash function (verify data integrity) Client offers many cipher suites. Server picks one they both support. Modern ciphers (like this one) provide: - Forward secrecy (past communications stay secret) - Strong encryption (AES-128 is industry standard) - Authentication (RSA verifies server identity) ======================================================================= WHY THIS MATTERS ======================================================================= Without TLS: - Passwords transmitted in plaintext - Session cookies stolen - Credit card numbers visible - Personal data exposed With TLS (HTTPS): - All HTTP data encrypted - Man-in-the-middle attacks prevented - Data integrity verified - Server identity authenticated Always use HTTPS for: - Login pages - Payment forms - Personal information - Any sensitive communication Look for the padlock icon in your browser! ======================================================================= FREQUENTLY ASKED QUESTIONS ======================================================================= Q: What does the 'S' in HTTPS stand for? ----------------------------------------------------------------------- S = Secure HTTPS = HyperText Transfer Protocol Secure It's the same HTTP protocol you already know, but wrapped in TLS encryption. HTTP: Client -> [readable data] -> Server HTTPS: Client -> [encrypted data] -> Server The encryption is transparent to your application. Your browser handles all the TLS complexity automatically. Q: What is TLS? What is SSL? Are they different? ----------------------------------------------------------------------- SSL = Secure Sockets Layer (old, deprecated) TLS = Transport Layer Security (modern, current) History: 1995: SSL 2.0 (had security flaws) 1996: SSL 3.0 (better, but still flawed) 1999: TLS 1.0 (renamed and improved SSL 3.0) 2006: TLS 1.1 2008: TLS 1.2 (widely used today) 2018: TLS 1.3 (current standard) Today: - SSL is completely deprecated (insecure) - TLS is what everyone uses - People still say "SSL" out of habit, but they mean TLS When you see: - "SSL certificate" -> Really means TLS certificate - "SSL/TLS" -> Just means TLS (SSL mentioned for legacy reasons) - HTTPS -> Uses TLS (not SSL) Use TLS 1.2 or TLS 1.3. Never use SSL. Q: What other protocols use TLS/SSL for encryption? ----------------------------------------------------------------------- TLS can encrypt ANY TCP-based protocol. Common examples: 1. HTTPS (HTTP over TLS) - Port 443 - Web browsing, APIs, web applications - Most common use of TLS 2. FTPS (FTP over TLS) - Ports 989/990 - Secure file transfer - Note: Different from SFTP (which uses SSH, not TLS) 3. SMTPS (SMTP over TLS) - Port 465/587 - Sending email securely - Prevents email interception 4. IMAPS (IMAP over TLS) - Port 993 - Receiving email securely - Protects email credentials and content 5. POP3S (POP3 over TLS) - Port 995 - Another email protocol (older than IMAP) - Also benefits from TLS encryption The pattern: Take any plaintext protocol, wrap it in TLS, and you get the secure version. Usually indicated by adding an 'S' to the name. TLS works at the transport layer, so it can protect any application protocol that runs over TCP. Q: Does every request need a new TLS handshake and encryption key? ----------------------------------------------------------------------- NO! TLS handshake happens ONCE per TCP connection, just like TCP handshake. Here's how a typical HTTPS session works: 1. TCP Handshake (once): Client -> Server: SYN, SYN-ACK, ACK [TCP connection established] 2. TLS Handshake (once): Client -> Server: ClientHello Server -> Client: ServerHello, Certificate, etc. [Encryption keys established] 3. Send many encrypted HTTP requests (reusing same session): Client -> Server: Encrypted HTTP Request 1 Server -> Client: Encrypted HTTP Response 1 Client -> Server: Encrypted HTTP Request 2 Server -> Client: Encrypted HTTP Response 2 [All use the SAME encryption key from step 2] 4. Connection closes: TCP connection closes (FIN-ACK) TLS session ends automatically How does the server know it's the same client? The TLS session is tied to the TCP connection: - Same TCP connection = same TLS session - Same source port + destination port = same connection - As long as TCP connection is open, TLS session is valid The encryption key is stored in memory for this connection: - Browser stores: "Connection to example.com:443 uses key XYZ" - Server stores: "Connection from 192.168.1.100:54321 uses key XYZ" - They use the same key for all data on this connection When does the session end? The TLS session ends when the TCP connection closes: - Idle timeout (60-120 seconds of no activity) - Explicit close (browser navigates away) - Connection error (network failure) - New TCP connection = new TLS handshake required Session Resumption (advanced): - Some browsers can resume TLS sessions across new TCP connections - Uses session IDs or session tickets - Avoids full handshake, faster reconnection - But still requires a partial handshake Key insight: TCP connection = physical phone line TLS session = secret code you agreed on - Open the phone line once (TCP handshake) - Agree on secret code once (TLS handshake) - Talk many times using that code (many HTTP requests) - Hang up when done (TCP close, TLS ends) Typical web page load: 1. TCP handshake (once) 2. TLS handshake (once) 3. GET /index.html (encrypted with TLS) 4. GET /style.css (encrypted with SAME key) 5. GET /script.js (encrypted with SAME key) 6. GET /logo.png (encrypted with SAME key) 7. Connection stays open for more requests... Only ONE TCP handshake and ONE TLS handshake for dozens of requests! This is much more efficient than re-establishing security for every request. =======================================================================