appliedcryptography/slides/2-1.tex

\documentclass[aspectratio=169, lualatex, handout]{beamer}
\makeatletter\def\input@path{{theme/}}\makeatother\usetheme{cipher}

\title{Applied Cryptography}
\author{Nadim Kobeissi}
\institute{American University of Beirut}
\instituteimage{images/aub_white.png}
\date{\today}
\coversubtitle{CMPS 297AD/396AI\\Fall 2025}
\coverpartname{Part 2: Real-World Cryptography}
\covertopicname{2.1: Transport Layer Security}
\coverwebsite{https://appliedcryptography.page}

\begin{document}
\begin{frame}[plain]
	\titlepage
\end{frame}

\begin{frame}{Why we're interested in TLS}
	\begin{itemize}[<+->]
		\item Encrypts all your web traffic (the \textbf{S} in HTTP\textbf{S}!)
		\item Great way to introduce \textbf{authenticated key exchange}.
		\item Great way to make you hate certificates and certificate authorities.
		\item How TLS handles \textbf{authentication} and key exchange.
		\item A comprehensive survey of \textbf{TLS 1.2 attacks}:
		      \begin{itemize}
			      \item POODLE (Padding Oracle On Downgraded Legacy Encryption)
			      \item Lucky Thirteen timing attack
			      \item SMACK (State Machine AttaCK)
			      \item FREAK (Factoring RSA Export Keys)
			      \item Logjam attack on Diffie-Hellman
			      \item And many more...
		      \end{itemize}
		\item How these attacks informed the design of \textbf{TLS 1.3}.
		\item Lessons learned for building secure protocols.
	\end{itemize}
\end{frame}

\begin{frame}{TLS attacks timeline (to 2015)}
	\bigimagewithcaption{tls_attacks_timeline_2015.png}{TLS attacks up until 2015.}
\end{frame}

\begin{frame}{TLS isn't very interesting}
	\begin{itemize}
		\item Too complicated for no good reason.
		\item Doesn't accomplish properties as interesting as those of more modern protocols, or even Signal.
		\item Certificate authorities.
		\item Very important however to understand, basically a golden door into the world of protocols.
	\end{itemize}
\end{frame}

\begin{frame}{...and yet...}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\begin{itemize}[<+->]
				\item Web browsing (HTTPS)
				\item Email (IMAPS, POP3S, SMTPS)
				\item Instant messaging (WhatsApp, Telegram)
				\item Video conferencing (Zoom, Teams)
				\item Online banking
				\item Social media (Facebook, Twitter)
				\item Cloud storage (Dropbox, Google Drive)
				\item VPN connections
				\item Mobile app communication
				\item Medical devices
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\begin{itemize}[<+->]
				\item Streaming services (Netflix, Spotify)
				\item IoT device communication
				\item Remote desktop protocols
				\item Voice over IP (VoIP)
				\item Software updates
				\item Database connections
				\item Git repositories (GitHub, GitLab)
				\item Real-time communication (WebRTC)
				\item Cryptocurrency wallets
				\item Smart home devices
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\section{Transport Layer Security}

\begin{frame}{Primary applications that drove TLS development}
	\begin{itemize}[<+->]
		\item \textbf{E-commerce websites}
		      \begin{itemize}
			      \item Credit card numbers
			      \item Personal information
			      \item Purchase history
		      \end{itemize}
		\item \textbf{Online banking}
		      \begin{itemize}
			      \item Account credentials
			      \item Financial transactions
			      \item Sensitive financial data
		      \end{itemize}
		\item \textbf{General web browsing}
		      \begin{itemize}
			      \item User credentials
			      \item Private communications
			      \item Personal data protection
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Passive vs Active Attackers}
	\begin{columns}
		\begin{column}{0.5\textwidth}
			\textbf{Passive Attacker}
			\begin{itemize}
				\item \textbf{Eavesdropping only}
				\item Observes network traffic
				\item Records all messages
				\item Cannot modify or inject messages
				\item Examples:
				      \begin{itemize}
					      \item ISP logging traffic
					      \item Government surveillance
					      \item WiFi sniffing
				      \end{itemize}
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{Active Attacker}
			\begin{itemize}
				\item \textbf{Can modify/inject messages}
				\item Intercepts and alters traffic
				\item Can impersonate parties
				\item Controls network routing
				\item Examples:
				      \begin{itemize}
					      \item Man-in-the-middle attacks
					      \item Malicious WiFi hotspots
					      \item Compromised routers
				      \end{itemize}
			\end{itemize}
		\end{column}
	\end{columns}
	\begin{alertblock}{Protocol Design Impact}
		Identity protection works against passive attackers, but active attackers can force identity revelation through protocol manipulation
	\end{alertblock}
\end{frame}

\begin{frame}{Key security goal: Defeating man-in-the-middle attacks}
	\begin{itemize}[<+->]
		\item \textbf{MITM attack scenario:}
		      \begin{enumerate}
			      \item Attacker intercepts encrypted traffic.
			      \item Decrypts the traffic to read content.
			      \item Re-encrypts and forwards to destination.
		      \end{enumerate}
		\item \textbf{How TLS defeats MITM:}
		      \begin{itemize}
			      \item Server authentication using \textbf{certificates}.
			      \item Trusted \textbf{certificate authorities} (CAs).
			      \item Optional client authentication.
		      \end{itemize}
		\item Without proper authentication, encryption alone is \textbf{not enough}!
	\end{itemize}
\end{frame}

\begin{frame}{Four requirements for wide TLS adoption}
	\begin{itemize}[<+->]
		\item \textbf{Efficiency}
		      \begin{itemize}
			      \item Minimize performance penalty vs. unencrypted connections.
		      \end{itemize}
		\item \textbf{Interoperability}
		      \begin{itemize}
			      \item Work on any hardware and operating system.
		      \end{itemize}
		\item \textbf{Extensibility}
		      \begin{itemize}
			      \item Support additional features and algorithms.
		      \end{itemize}
		\item \textbf{Versatility}
		      \begin{itemize}
			      \item Not bound to specific applications.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Notice how we're mentioning design requirements now?}
	\bigimagewithcaption{fischer.png}{Fischer et al., The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts, USENIX Security 2024}
\end{frame}

\begin{frame}{Notice how we're mentioning design requirements now?}
	\begin{center}
		\bigimagewithcaption{fischer_sectioned.png}{Fischer et al., The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts, USENIX Security 2024}
	\end{center}
\end{frame}

\begin{frame}{Efficiency and interoperability}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{Efficiency matters for:}
			\begin{itemize}[<+->]
				\item \textbf{Servers}
				      \begin{itemize}
					      \item Reduce hardware costs
					      \item Handle more connections
				      \end{itemize}
				\item \textbf{Clients}
				      \begin{itemize}
					      \item Avoid perceptible delays
					      \item Preserve battery life
				      \end{itemize}
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{Interoperability ensures:}
			\begin{itemize}[<+->]
				\item Works across different:
				      \begin{itemize}
					      \item Hardware platforms
					      \item Operating systems
					      \item Software implementations
				      \end{itemize}
				\item Universal compatibility
				\item No vendor lock-in
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Extensibility and versatility}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{Extensibility allows:}
			\begin{itemize}[<+->]
				\item Adding new cryptographic algorithms
				\item Supporting new features
				\item Adapting to security threats
				\item Protocol evolution over time
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{Versatility means:}
			\begin{itemize}[<+->]
				\item Application-agnostic design
				\item Like TCP: doesn't care about upper layers
				\item Can secure any application protocol
				\item Reusable security infrastructure
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{The confusing SSL/TLS naming}
	\begin{itemize}[<+->]
		\item \textbf{1995}: Netscape develops SSL (Secure Sockets Layer).
		\item \textbf{SSL 2.0 and SSL 3.0}: Both had serious security flaws.
		\item \textbf{Confusing terminology}: People still call TLS ``SSL''.
		      \begin{itemize}
			      \item Even security experts do this!
			      \item ``SSL certificate'' really means ``TLS certificate''
		      \end{itemize}
		\item TLS = Transport Layer Security (SSL's successor)
	\end{itemize}
\end{frame}

\begin{frame}{TLS version evolution}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.0 (1999)}
		      \begin{itemize}
			      \item Least secure TLS version.
			      \item Still better than SSL 3.0.
		      \end{itemize}
		\item \textbf{TLS 1.1 (2006)}
		      \begin{itemize}
			      \item Better, but includes weak algorithms.
		      \end{itemize}
		\item \textbf{TLS 1.2 (2008)}
		      \begin{itemize}
			      \item Much better, but very complex.
			      \item High security only if configured correctly.
			      \item Supports vulnerable features (e.g., AES-CBC with padding oracles).
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3: The great cleanup}
	\begin{itemize}[<+->]
		\item \textbf{Problem}: TLS 1.2 inherited decades of legacy features.
		      \begin{itemize}
			      \item Suboptimal security and performance.
			      \item Complex and error-prone configurations.
			      \item High risk of implementation bugs.
		      \end{itemize}
		\item \textbf{Solution}: Complete redesign for TLS 1.3.
		      \begin{itemize}
			      \item Kept only the good parts.
			      \item Added modern security features.
			      \item Simplified the bloated design.
		      \end{itemize}
		\item \textbf{Result}: TLS 1.3 is more secure, efficient, and simpler.
		\item TLS 1.3 = ``mature TLS''.
	\end{itemize}
\end{frame}

\begin{frame}{Fantastic resource on understanding TLS}{And secure channel protocol design in general}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\begin{itemize}
				\item The Illustrated TLS 1.2 connection: \url{https://tls12.xargs.org}
				\item The Illustrated TLS 1.3 connection: \url{https://tls13.xargs.org}
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\imagewithcaption{tls_illustrated}{}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{TLS architecture: Two main protocols}
	\begin{itemize}[<+->]
		\item \textbf{Handshake Protocol}
		      \begin{itemize}
			      \item Determines secret keys shared between client and server.
			      \item Handles authentication and key exchange.
			      \item Runs once at the beginning of a connection.
		      \end{itemize}
		\item \textbf{Record Protocol}
		      \begin{itemize}
			      \item Describes how to use established keys to protect data.
			      \item Processes data packets called \textbf{records}.
			      \item Defines packet format for encapsulating higher-layer data.
		      \end{itemize}
		\item Think of it as: handshake = setup, record = ongoing protection.
	\end{itemize}
\end{frame}

\begin{frame}{Cipher Suites: The building blocks of TLS security}
	\begin{itemize}[<+->]
		\item \textbf{What is a cipher suite?}
		      \begin{itemize}
			      \item A combination of cryptographic algorithms used together
			      \item Defines exactly how data will be secured
			      \item Like a recipe: specifies all ingredients for secure communication
		      \end{itemize}
		\item \textbf{Four components of a cipher suite}:
		      \begin{enumerate}
			      \item \textbf{Key exchange algorithm}: How to establish shared keys (RSA, ECDHE, DHE)
			      \item \textbf{Authentication algorithm}: How to verify identity (RSA, ECDSA)
			      \item \textbf{Bulk encryption algorithm}: How to encrypt data (AES, ChaCha20)
			      \item \textbf{MAC algorithm}: How to ensure integrity (SHA256, SHA384, Poly1305)
		      \end{enumerate}
		\item \textbf{Example}: \texttt{TLS\_ECDHE\_RSA\_WITH\_AES\_128\_GCM\_SHA256}
		      \begin{itemize}
			      \item \texttt{ECDHE}: Elliptic Curve Diffie-Hellman Ephemeral (key exchange)
			      \item \texttt{RSA}: RSA signatures (authentication)
			      \item \texttt{AES\_128\_GCM}: AES with 128-bit keys in GCM mode (encryption + MAC)
			      \item \texttt{SHA256}: SHA-256 for handshake integrity
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Common cipher suites in practice}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.2 cipher suites} (verbose naming):
		      \begin{itemize}
			      \item \texttt{TLS\_ECDHE\_RSA\_WITH\_AES\_256\_GCM\_SHA384}
			      \item \texttt{TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_GCM\_SHA256}
			      \item \texttt{TLS\_RSA\_WITH\_AES\_128\_CBC\_SHA256}
			      \item \texttt{TLS\_DHE\_RSA\_WITH\_AES\_256\_CBC\_SHA256}
		      \end{itemize}
		\item \textbf{TLS 1.3 cipher suites} (simplified naming):
		      \begin{itemize}
			      \item \texttt{TLS\_AES\_128\_GCM\_SHA256}
			      \item \texttt{TLS\_AES\_256\_GCM\_SHA384}
			      \item \texttt{TLS\_CHACHA20\_POLY1305\_SHA256}
		      \end{itemize}
		\item \textbf{Why TLS 1.3 names are shorter}:
		      \begin{itemize}
			      \item Key exchange is always (EC)DHE (forward secrecy mandatory)
			      \item Authentication tied to certificate type
			      \item Only specifies symmetric crypto algorithms
		      \end{itemize}
		\item \textbf{Cipher suite negotiation}: Client proposes, server chooses
	\end{itemize}
\end{frame}

\begin{frame}{The TLS handshake: Basic flow}
	\begin{columns}[c]
		\begin{column}{0.6\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Step 1}: Client initiates secure connection.
				      \begin{itemize}
					      \item Sends \texttt{ClientHello} message.
					      \item Includes supported ciphers and other parameters.
				      \end{itemize}
				\item \textbf{Step 2}: Server responds.
				      \begin{itemize}
					      \item Checks client's message and parameters.
					      \item Responds with \texttt{ServerHello} message.
					      \item Selects cipher suite and provides certificate.
				      \end{itemize}
				\item \textbf{Step 3}: Key establishment.
				      \begin{itemize}
					      \item Both parties process each other's messages.
					      \item Establish session keys for encryption.
				      \end{itemize}
				\item \textbf{Result}: Ready to exchange encrypted data!
			\end{itemize}
		\end{column}
		\begin{column}{0.4\textwidth}
			\imagewithcaption{tls_handshake.png}{TLS handshake overview.}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Critical step: Certificate validation}
	\begin{itemize}[<+->]
		\item \textbf{The crux of TLS security}: Server authenticates itself to client
		\item \textbf{What is a certificate?}
		      \begin{itemize}
			      \item A public key + signature of that key
			            \begin{itemize}
				            \item Encoded in an insanely asinine byte format
			            \end{itemize}
			      \item Associated information (domain name, organization, etc.)
			      \item Essentially says: ``I am google.com, and my public key is [key]''
		      \end{itemize}
		\item \textbf{Certificate validation process}:
		      \begin{enumerate}
			      \item Browser receives certificate from server
			      \item Verifies the certificate's signature
			      \item If signature is valid \rightarrow certificate and public key are trusted
			      \item Browser proceeds with connection
		      \end{enumerate}
	\end{itemize}
\end{frame}

\begin{frame}{Certificate Authorities: The trust foundation}
	\begin{itemize}[<+->]
		\item \textbf{Problem}: How does the browser know which public key to use for verification?
		\item \textbf{Solution}: Certificate Authorities (CAs)
		      \begin{itemize}
			      \item Public keys hardcoded in your browser/OS.
			      \item Trusted organizations that issue certificates.
			      \item Act as trusted third parties.
		      \end{itemize}
		\item \textbf{CA's role}:
		      \begin{itemize}
			      \item Verify that public keys belong to claimed entities.
			      \item Sign certificates with their private keys.
			      \item Protect their private keys from compromise.
		      \end{itemize}
		\item \textbf{Without CAs}: No way to distinguish legitimate servers from MITM attackers!
	\end{itemize}
\end{frame}

\begin{frame}{Traditional CA validation nightmare}
	\begin{itemize}[<+->]
		\item \textbf{Getting a certificate before 2015}:
		      \begin{itemize}
			      \item Contact a Certificate Authority (Verisign, Thawte, etc.).
			      \item Pay \$50-300+ per certificate per year.
			            \begin{itemize}
				            \item Completely arbitrary extortionate amounts.
			            \end{itemize}
			      \item Manual validation process takes days/weeks.
		      \end{itemize}
		\item \textbf{Domain Validation (DV) process}:
		      \begin{enumerate}
			      \item Submit CSR (Certificate Signing Request).
			      \item CA sends email to \texttt{admin@domain.com}.
			      \item Click verification link in email.
			      \item Wait for manual review and approval.
			      \item Download and install certificate.
		      \end{enumerate}
		\item \textbf{Extended Validation (EV) certificates}:
		      \begin{itemize}
			      \item Even more expensive (\$150-1000+/year).
			      \item Weeks of back-and-forth communication.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Let's Encrypt: revolution in TLS certificates (2015)}
	\begin{itemize}[<+->]
		\item \textbf{Game-changing}:
		      \begin{itemize}
			      \item \textbf{Free} certificates for everyone.
			      \item \textbf{Automated} issuance and renewal.
			      \item \textbf{90-day} certificate lifetime (encourages automation).
			      \item Open source, non-profit initiative.
		      \end{itemize}
		\item \textbf{ACME protocol} (Automated Certificate Management Environment):
		      \begin{itemize}
			      \item Domain validation via HTTP or DNS challenges.
			      \item Prove control of domain programmatically.
			      \item Certificate issued in seconds, not days.
			      \item Automatic renewal before expiration.
		      \end{itemize}
		\item \textbf{Impact on the web}:
		      \begin{itemize}
			      \item HTTPS adoption jumped from 40\% to 90\%+ of web traffic.
			      \item Eliminated cost barrier for small websites.
			      \item Made ``HTTPS everywhere'' a reality.
		      \end{itemize}
		\item \textbf{Philosophy}: Encryption should be the default, not a luxury.
	\end{itemize}
\end{frame}

\begin{frame}{Let's Encrypt: active certificates}
	\bigimagewithcaption{letsencrypt_certs.png}{Source: Let's Encrypt}
\end{frame}

\begin{frame}{Let's Encrypt: certificates issued}
	\bigimagewithcaption{letsencrypt_issuance.png}{Source: Let's Encrypt}
\end{frame}

\begin{frame}{Percentage of HTTPS traffic in Firefox}
	\bigimagewithcaption{letsencrypt_https.png}{Source: Let's Encrypt}
\end{frame}

\begin{frame}{Certificate chains in practice}
	\begin{itemize}[<+->]
		\item \textbf{Real-world example}: Connecting to \texttt{www.google.com}
		\item \textbf{Certificate chain structure}:
		      \begin{itemize}
			      \item \textbf{Certificate 0}: \texttt{www.google.com}'s certificate.
			      \item \textbf{Certificate 1}: Intermediate CA (Google Trust Services).
			      \item \textbf{Certificate 2}: Root CA (GlobalSign).
		      \end{itemize}
		\item \textbf{Verification process}:
		      \begin{enumerate}
			      \item Check Google's signature on Certificate 0.
			      \item Check GlobalSign's signature on Certificate 1.
			      \item Trust GlobalSign's root certificate (pre-installed).
		      \end{enumerate}
		\item \textbf{Chain of trust}: Each certificate vouches for the next.
	\end{itemize}
\end{frame}

\begin{frame}{Exploring certificates with OpenSSL}
	\begin{itemize}[<+->]
		\item \textbf{Connect and view certificate}:
		      \begin{itemize}
			      \item \texttt{openssl s\_client -connect www.google.com:443}
			      \item Shows certificate chain and raw certificate data
		      \end{itemize}
		\item \textbf{Parse certificate details}:
		      \begin{itemize}
			      \item \texttt{openssl x509 -text -noout}
			      \item Reveals subject, issuer, validity dates, algorithms
		      \end{itemize}
		\item \textbf{Certificate markers}:
		      \begin{itemize}
			      \item \texttt{s:} = subject (who the certificate is for)
			      \item \texttt{i:} = issuer (who signed the certificate)
		      \end{itemize}
		\item Try this at home! Great way to understand the certificate ecosystem.
	\end{itemize}
\end{frame}

\begin{frame}{TLS Record Protocol: The data transport layer}
	\begin{itemize}[<+->]
		\item \textbf{What is the Record Protocol?}
		      \begin{itemize}
			      \item Transport protocol for all TLS data.
			      \item Agnostic to the meaning of transported data.
			      \item Makes TLS suitable for any application.
		      \end{itemize}
		\item \textbf{Two main phases}:
		      \begin{enumerate}
			      \item \textbf{During handshake}: Carries handshake messages.
			      \item \textbf{After handshake}: Carries encrypted application data.
		      \end{enumerate}
		\item \textbf{Key insight}: Like TCP, doesn't care about upper layers!
	\end{itemize}
\end{frame}

\begin{frame}{TLS Record: Basic structure}
	\begin{itemize}[<+->]
		\item \textbf{TLS Record = chunk of data ≤ 16KB}
		\item \textbf{Simple header structure}:
		      \begin{itemize}
			      \item Only 3 fields (vs. 14 in IPv4, 13 in TCP)
			      \item 5-byte header + payload
		      \end{itemize}
		\item \textbf{Visual representation}:
	\end{itemize}
	\pause
	\begin{center}
		\begin{tabular}{|c|c|c|c|}
			\hline
			\textbf{ContentType} & \textbf{ProtocolVersion} & \textbf{Length} & \textbf{Payload} \\
			\hline
			1 byte               & 2 bytes                  & 2 bytes         & ≤ 16KB           \\
			\hline
		\end{tabular}
	\end{center}
\end{frame}

\begin{frame}{TLS Record fields breakdown}
	\begin{itemize}[<+->]
		\item \textbf{Byte 1 - ContentType}:
		      \begin{itemize}
			      \item \texttt{22} = Handshake data
			      \item \texttt{23} = Encrypted application data
			      \item \texttt{21} = Alerts (error messages)
		      \end{itemize}
		\item \textbf{Bytes 2-3 - ProtocolVersion}:
		      \begin{itemize}
			      \item Always \texttt{03 01} (historical reasons)
			      \item Same across TLS versions (confusing!)
		      \end{itemize}
		\item \textbf{Bytes 4-5 - Length}:
		      \begin{itemize}
			      \item 16-bit integer encoding payload length
			      \item Maximum: $2^{14}$ bytes = 16KB
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{ContentType: What's in this record?}
	\begin{center}
		\begin{tabular}{|c|c|l|}
			\hline
			\textbf{Value} & \textbf{Name}    & \textbf{Contains}                         \\
			\hline
			21             & Alert            & Error messages, warnings                  \\
			\hline
			22             & Handshake        & \parbox[t]{3cm}{ClientHello, ServerHello, \\Certificate, etc.} \\
			\hline
			23             & Application Data & \parbox[t]{3cm}{Encrypted user data       \\(HTTP, email, etc.)} \\
			\hline
		\end{tabular}
	\end{center}
	\pause
	\begin{itemize}
		\item \textbf{Key point}: ContentType tells receiver how to process the payload.
		\item \textbf{During handshake}: Mostly type 22 records.
		\item \textbf{After handshake}: Mostly type 23 records.
	\end{itemize}
\end{frame}

\begin{frame}{Encrypted records (ContentType = 23)}
	\begin{itemize}[<+->]
		\item \textbf{When ContentType = 23}:
		      \begin{itemize}
			      \item Payload is encrypted and authenticated.
			      \item Contains: ciphertext + authentication tag.
		      \end{itemize}
		\item \textbf{How does receiver know how to decrypt?}
		      \begin{itemize}
			      \item Cipher and key established during handshake.
			      \item ``Magic of TLS'': if you receive encrypted data, you already have the key!
		      \end{itemize}
		\item \textbf{Decryption process}:
		      \begin{enumerate}
			      \item Verify authentication tag.
			      \item Decrypt ciphertext.
			      \item Process decrypted application data.
		      \end{enumerate}
	\end{itemize}
\end{frame}

\begin{frame}{Nonces: Ensuring unique encryption}
	\begin{itemize}[<+->]
		\item \textbf{Problem}: Each record needs a unique nonce for encryption.
		\item \textbf{TLS solution}: Derive nonces from sequence numbers.
		      \begin{itemize}
			      \item Each party maintains 64-bit sequence number.
			      \item Incremented for each new record.
			      \item Starts at 0, goes 1, 2, 3, ...
		      \end{itemize}
		\item \textbf{Nonce derivation}:
		      \begin{itemize}
			      \item Client: \texttt{sequence\_number $\oplus$ client\_write\_iv}
			      \item Server: \texttt{sequence\_number $\oplus$ server\_write\_iv}
		      \end{itemize}
		\item \textbf{No nonce reuse}: Different IVs and keys per direction.
	\end{itemize}
\end{frame}

\begin{frame}{Example: Sequence numbers in action}
	\begin{center}
		\textbf{Client sending records:}
		\begin{tabular}{|c|c|}
			\hline
			\textbf{Record \#} & \textbf{Sequence Number} \\
			\hline
			1st record         & 0                        \\
			\hline
			2nd record         & 1                        \\
			\hline
			3rd record         & 2                        \\
			\hline
		\end{tabular}
	\end{center}
	\pause
	\begin{center}
		\textbf{Client receiving records:}
		\begin{tabular}{|c|c|}
			\hline
			\textbf{Record \#} & \textbf{Sequence Number} \\
			\hline
			1st record         & 0                        \\
			\hline
			2nd record         & 1                        \\
			\hline
			3rd record         & 2                        \\
			\hline
		\end{tabular}
	\end{center}
	\pause
	\begin{itemize}
		\item \textbf{Safe to reuse numbers}: Different keys and IVs per direction!
	\end{itemize}
\end{frame}

\begin{frame}{Zero padding example}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{Without padding:}
			\begin{itemize}
				\item Short message \rightarrow\ small ciphertext
				\item Long message \rightarrow\ large ciphertext
				\item Attacker learns message sizes
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{With padding:}
			\begin{itemize}
				\item Short message + padding \rightarrow\ large ciphertext
				\item Long message + padding \rightarrow\ large ciphertext
				\item All messages look the same size!
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Trade-off}: Security vs. bandwidth efficiency
	\end{center}
\end{frame}

\begin{frame}{TLS: the handshake protocol}
	\begin{itemize}[<+->]
		\item \textbf{The crux of TLS}: Process to establish shared secret keys.
		\item \textbf{Goal}: Initiate secure communications between client and server.
		\item \textbf{Key outcome}: Both parties agree on:
		      \begin{itemize}
			      \item TLS version to use
			      \item Cipher suite for encryption
			      \item Shared secret keys for protection
		      \end{itemize}
		\item \textbf{Interoperability requirement}: Any TLS 1.3 client must work with any TLS 1.3 server.
		      \begin{itemize}
			      \item Achieved through standardized message formats.
			      \item Works regardless of implementation or programming language.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{TLS: the handshake protocol}
	\bigimagewithcaption{tls_13_handshake}{TLS 1.3 handshake protocol. Source: Serious Cryptography}
\end{frame}

\begin{frame}{Client vs. Server: Different roles in the handshake}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{Client's role:}
			\begin{itemize}[<+->]
				\item \textbf{Proposes} configurations
				\item Lists supported TLS versions
				\item Lists supported cipher suites
				\item Orders preferences (most preferred first)
				\item Generates Diffie-Hellman key pair
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{Server's role:}
			\begin{itemize}[<+->]
				\item \textbf{Chooses} final configuration
				\item Selects TLS version to use
				\item Picks cipher suite from client's list
				\item Should follow client's preferences
				\item Responds with its own DH public key
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Think of it like ordering at a restaurant:}\\
		Client: ``Here's what I like...'' \quad Server: ``We'll go with this option.''
	\end{center}
\end{frame}

\begin{frame}{ClientHello: ``I want to establish a TLS connection''}
	\begin{itemize}[<+->]
		\item \textbf{Client's opening message to server}
		\item \textbf{Key contents}:
		      \begin{itemize}
			      \item List of supported cipher suites (in order of preference)
			      \item Diffie-Hellman public key (generated just for this session!)
			      \item 32-byte random value
			      \item Optional extensions and parameters
		      \end{itemize}
		\item \textbf{Critical security detail}: DH private key stays with client.
		\item \textbf{Format requirement}: Must follow exact byte format from TLS 1.3 spec.
		      \begin{itemize}
			      \item Ensures any server can parse any client's message.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{ServerHello: ``Here's what we'll use and who I am''}
	\begin{itemize}[<+->]
		\item \textbf{Server's response}: Packed with crucial information!
		\item \textbf{Configuration decisions}:
		      \begin{itemize}
			      \item Selected cipher suite (from client's list)
			      \item Server's Diffie-Hellman public key
			      \item 32-byte random value
		      \end{itemize}
		\item \textbf{Authentication materials}:
		      \begin{itemize}
			      \item Certificate (contains server's public key)
			      \item Signature of ClientHello + ServerHello contents
			      \item MAC of all the above information
		      \end{itemize}
		\item \textbf{Crypto magic}: MAC uses key derived from DH shared secret!
	\end{itemize}
\end{frame}

\begin{frame}{Client verification: ``Can I trust this server?''}
	\begin{itemize}[<+->]
		\item \textbf{When client receives ServerHello}:
		\item \textbf{Step 1}: Certificate validation
		      \begin{itemize}
			      \item Check certificate chain to trusted CA
			      \item Verify certificate hasn't expired
			      \item Confirm certificate matches domain name
		      \end{itemize}
		\item \textbf{Step 2}: Signature verification
		      \begin{itemize}
			      \item Use certificate's public key to verify signature
			      \item Ensures server controls the private key
		      \end{itemize}
		\item \textbf{Step 3}: Derive shared secrets
		      \begin{itemize}
			      \item Compute DH shared secret: $g^{ab} \bmod p$
			      \item Derive symmetric keys from shared secret
		      \end{itemize}
		\item \textbf{Step 4}: MAC verification
		      \begin{itemize}
			      \item Verify MAC using derived symmetric key
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{All checks pass: Ready for encrypted communication!}
	\begin{center}
		\textbf{After successful verification:}
	\end{center}
	\begin{itemize}[<+->]
		\item Client is confident it's talking to the legitimate server.
		\item Both parties have the same shared secret keys.
		\item Ready to send encrypted application data!
		\item \textbf{Security guarantees achieved}:
		      \begin{itemize}
			      \item \textbf{Confidentiality}: Traffic is encrypted
			      \item \textbf{Integrity}: Traffic is authenticated
			      \item \textbf{Authentication}: Server identity verified
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Real-world example: Visiting \texttt{aub.edu.lb}}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{Step 1}: Browser sends ClientHello
			\begin{itemize}[<+->]
				\item Lists supported ciphers
				\item Includes DH public key
				\item Adds random nonce
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{Step 2}: Server responds
			\begin{itemize}[<+->]
				\item Sends ServerHello
				\item Provides certificate for ``\texttt{aub.edu.lb}''
				\item Includes signature and MAC
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Step 3}: Browser verification
	\end{center}
	\begin{itemize}[<+->]
		\item Certificate validated using browser's built-in CA certificates
		\item Must be signed by trusted certificate authority
		\item Certificate must match domain name: ``\texttt{aub.edu.lb}''
		\item All cryptographic checks must pass
	\end{itemize}
	\pause
	\begin{center}
		\textbf{Step 4}: Browser requests initial page over encrypted channel!
	\end{center}
\end{frame}

\begin{frame}{Security guarantees after successful TLS handshake}
	\begin{itemize}[<+->]
		\item \textbf{All communications are encrypted and authenticated}
		\item \textbf{What an eavesdropper can see}:
		      \begin{itemize}
			      \item Client IP address
			      \item Server IP address
			      \item Encrypted content (but can't read it!)
			      \item Traffic patterns and timing
		      \end{itemize}
		\item \textbf{What an eavesdropper CANNOT do}:
		      \begin{itemize}
			      \item Read the underlying plaintext
			      \item Modify messages without detection
			      \item Impersonate either party
		      \end{itemize}
		\item \textbf{Authentication guarantee}: If messages are tampered with, receiving party will detect it!
		\item \textbf{Bottom line}: Enough security for most applications.
	\end{itemize}
\end{frame}

\begin{frame}{Forward Secrecy: Protecting past communications}
	\begin{itemize}[<+->]
		\item \textbf{The problem}: What if a server's private key is compromised?
		      \begin{itemize}
			      \item Attacker could decrypt \textbf{all past} TLS sessions.
			      \item Years of stored encrypted traffic becomes readable.
			      \item Example: NSA's alleged collection of encrypted internet traffic.
		      \end{itemize}
		\item \textbf{Forward secrecy (Perfect Forward Secrecy - PFS)}:
		      \begin{itemize}
			      \item Ensures past sessions remain secure even if long-term keys are compromised.
			      \item Each session uses unique, \textbf{ephemeral keys}.
			            \begin{itemize}
				            \item \textit{ephemeral: ``lasting a very short time''}
			            \end{itemize}
			      \item Session keys are deleted after use.
		      \end{itemize}
		\item \textbf{Security guarantee}: ``Even if you compromise me today, you can't read yesterday's traffic.''
		\item \textbf{Critical for}: Journalists, activists, whistleblowers, ordinary citizens
	\end{itemize}
\end{frame}

\begin{frame}{How TLS achieves forward secrecy}
	\begin{itemize}[<+->]
		\item \textbf{Ephemeral Diffie-Hellman key exchange}:
		      \begin{itemize}
			      \item Server generates fresh DH key pair for each session.
			      \item Client generates fresh DH key pair for each session.
			      \item Shared secret computed: $g^{ab} \bmod p$ (then deleted!).
		      \end{itemize}
		\item \textbf{Key lifecycle}:
		      \begin{enumerate}
			      \item Generate ephemeral keys for handshake.
			      \item Derive session keys from ephemeral shared secret.
			      \item \textbf{Delete ephemeral private keys immediately}.
			      \item Use session keys for encrypted communication.
			      \item Delete session keys when connection ends.
		      \end{enumerate}
		\item \textbf{Server's long-term private key}: Only used to \textbf{sign} the handshake
		      \begin{itemize}
			      \item Not used to derive session keys directly.
			      \item Compromising it doesn't reveal past session keys.
		      \end{itemize}
		\item \textbf{Result}: Each TLS session is cryptographically independent.
	\end{itemize}
\end{frame}

\begin{frame}{How things can go wrong with TLS}
	\begin{itemize}[<+->]
		\item \textbf{Common TLS failure scenarios:}
		      \begin{itemize}
			      \item Even with the most secure ciphers, TLS can be compromised
			      \item Security relies on assumptions about honest behavior
		      \end{itemize}
		\item \textbf{Key assumption}: All three parties behave honestly
		      \begin{itemize}
			      \item Client
			      \item Server
			      \item Certificate Authority (CA)
		      \end{itemize}
		\item \textbf{Reality check}: What if one party is compromised?
		\item \textbf{Implementation matters}: Poor TLS implementations create vulnerabilities
	\end{itemize}
\end{frame}

\begin{frame}{Compromised Certificate Authority}
	\begin{itemize}[<+->]
		\item \textbf{Root CAs}: Organizations that browsers trust to validate certificates
		\item \textbf{Normal process}:
		      \begin{itemize}
			      \item CA verifies legitimacy of certificate owner.
			      \item CA signs certificate with their private key.
			      \item Browser trusts CA's signature.
		      \end{itemize}
		\item \textbf{Attack scenario}: CA's private key is compromised
		      \begin{itemize}
			      \item Attacker can create certificates for \textbf{any domain}.
			      \item No approval needed from actual domain owner.
			      \item Can impersonate legitimate servers.
		      \end{itemize}
		\item \textbf{Attack capabilities}:
		      \begin{itemize}
			      \item Create fake certificates for \texttt{google.com}, \texttt{instagram.com}, etc.
			      \item Intercept user credentials and communications.
			      \item Man-in-the-middle attacks become trivial.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Real-world example: DigiNotar}
	\begin{itemize}[<+->]
		\item \textbf{What happened}:
		      \begin{itemize}
			      \item Dutch certificate authority DigiNotar was hacked.
			      \item Attackers gained access to CA's private keys.
			      \item Created fake certificates for Google services.
		      \end{itemize}
		\item \textbf{Impact}:
		      \begin{itemize}
			      \item Users unknowingly connected to malicious servers.
			      \item Credentials and communications intercepted.
			      \item Trust in entire CA system questioned.
		      \end{itemize}
		\item \textbf{Aftermath}:
		      \begin{itemize}
			      \item DigiNotar went bankrupt.
			      \item All major browsers removed DigiNotar certificates.
			      \item Led to improved CA monitoring and transparency.
		      \end{itemize}
		\item \textbf{Lesson}: CAs are high-value targets for attackers!
	\end{itemize}
\end{frame}

\begin{frame}{Real-world example: Kazakhstan government certificate}
	\begin{columns}[c]
		\begin{column}{0.8\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{2015}: Kazakhstan government creates ``national security certificate''
				      \begin{itemize}
					      \item Root certificate that could enable MITM attacks.
					      \item Would allow government to intercept HTTPS traffic.
					      \item Required manual installation on users' devices.
				      \end{itemize}
				\item \textbf{July 2019}: Government mandates certificate installation
				      \begin{itemize}
					      \item ISPs instructed users to install ``Qaznet Trust Certificate''.
					      \item Issued by state CA: Qaznet Trust Network.
					      \item Initial targets: Google, Facebook, Twitter.
				      \end{itemize}
				\item \textbf{August 2019}: Browser vendors fight back
				      \begin{itemize}
					      \item Mozilla (Firefox) and Google (Chrome) block the certificate.
					      \item Apple (Safari) joins the blocking effort.
					      \item Microsoft reiterates certificate not in trusted root store.
				      \end{itemize}
				\item \textbf{December 2020}: Government tries again, browsers block again
			\end{itemize}
		\end{column}
		\begin{column}{0.2\textwidth}
			\imagewithcaption{tls_borat.jpg}{}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Kazakhstan case: Lessons for TLS security}
	\begin{itemize}[<+->]
		\item \textbf{Government-level MITM attempts are real}
		      \begin{itemize}
			      \item Nation-states can create sophisticated infrastructure.
			      \item Legal pressure on ISPs and users.
			      \item ``National security'' justifications.
		      \end{itemize}
		\item \textbf{Browser vendors as guardians}:
		      \begin{itemize}
			      \item Coordinate to protect users from malicious CAs.
			      \item Can override user certificate installations.
			      \item Technical measures against political pressure.
		      \end{itemize}
		\item \textbf{Certificate transparency importance}:
		      \begin{itemize}
			      \item Public logs make rogue certificates detectable.
			      \item Community monitoring of CA behavior.
			      \item Enables coordinated responses to threats.
		      \end{itemize}
		\item \textbf{Bottom line}: Even governments can't easily break modern TLS
	\end{itemize}
\end{frame}

\begin{frame}{Certificate Transparency}
	\begin{itemize}[<+->]
		\item \textbf{The problem}: CAs can issue certificates without anyone knowing.
		      \begin{itemize}
			      \item Rogue certificates for targeted attacks.
			      \item Compromised CAs issuing malicious certificates.
			      \item No way to detect misbehavior after the fact.
		      \end{itemize}
		\item \textbf{Certificate Transparency (CT) solution} (2013):
		      \begin{itemize}
			      \item CAs must submit all certificates to public logs.
			      \item Logs are cryptographically append-only.
			      \item Anyone can monitor logs for suspicious certificates.
		      \end{itemize}
		\item \textbf{How it works}:
		      \begin{enumerate}
			      \item CA issues certificate and submits to CT logs.
			      \item Log returns Signed Certificate Timestamp (SCT).
			      \item Certificate includes SCT as proof of logging.
			      \item Browsers reject certificates without valid SCTs.
		      \end{enumerate}
		\item \textbf{Result}: CA misbehavior becomes publicly detectable!
	\end{itemize}
\end{frame}

\begin{frame}{Example: How Let's Encrypt uses CT}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{The Static CT API}: Evolution of Certificate Transparency.
				      \begin{itemize}
					      \item Logs represented as simple flat files (``tiles'').
					      \item Download log data just like downloading files.
					      \item CDN-friendly, cheaper to operate.
				      \end{itemize}
				\item \textbf{Key advantages}:
				      \begin{itemize}
					      \item 10x+ cheaper to operate (~\$10k/year vs traditional logs).
					      \item More reliable (simpler architecture).
					      \item Easier to download and share data.
				      \end{itemize}
				\item \textbf{Sunlight}:
				      \begin{itemize}
					      \item Open source CT implementation used by Let's Encrypt.\footnote{\url{https://letsencrypt.org/2025/06/11/reflections-on-a-year-of-sunlight/}}
					      \item \url{https://sunlight.dev}
				      \end{itemize}
				\item \textbf{Status}: Chrome and Safari now accepting Static CT API logs!
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Critical examination: Are browser vendors truly neutral?}
	\begin{itemize}[<+->]
		\item \textbf{Browser vendors as gatekeepers}:
		      \begin{itemize}
			      \item Google (Chrome), Mozilla (Firefox), Apple (Safari), Microsoft (Edge).
			      \item Unilateral power to accept/reject certificates.
			      \item Who watches the watchers?
		      \end{itemize}
		\item \textbf{Political and economic pressures}:
		      \begin{itemize}
			      \item Companies have business interests and government relations.
			      \item What if a government pressures Google/Apple directly?
			      \item Corporate decisions affecting global internet security.
		      \end{itemize}
		\item \textbf{The CA model's fundamental problems}:
		      \begin{itemize}
			      \item \textbf{Single point of failure}: Any CA can issue certificates for any domain.
			      \item \textbf{Asymmetric trust}: Must trust \textbf{all} CAs, not just one.
			      \item \textbf{Centralized control}: Small number of entities control global trust.
			      \item \textbf{Economic incentives}: CAs profit from issuing more certificates.
		      \end{itemize}
		\item \textbf{Question}: Is this the best we can do for global internet security?
	\end{itemize}
\end{frame}

\begin{frame}{Thinking beyond: Decentralized trust alternatives}
	\begin{itemize}[<+->]
		\item \textbf{Why consider alternatives?}
		      \begin{itemize}
			      \item Reduce single points of failure.
			      \item Eliminate centralized gatekeepers.
			      \item Increase transparency and auditability.
		      \end{itemize}
		\item \textbf{Blockchain-based certificate systems}:
		      \begin{itemize}
			      \item Certificates recorded on public blockchain.
			      \item Cryptographic proof of certificate history.
			      \item Examples: Namecoin, Ethereum Name Service (ENS)
			      \item \textbf{Trade-offs}: Scalability, energy consumption, governance.
		      \end{itemize}
		\item \textbf{Web of Trust models}:
		      \begin{itemize}
			      \item Users vouch for each other's identities (like PGP).
			      \item Decentralized reputation systems.
			      \item \textbf{Trade-offs}: User complexity, bootstrap problem
		      \end{itemize}
		\item \textbf{DNS-based alternatives}: DANE (DNS-based Authentication of Named Entities)
		\item \textbf{Your turn}: What other models could work? What are the trade-offs?
	\end{itemize}
\end{frame}

\begin{frame}{Compromised Server}
	\begin{itemize}[<+->]
		\item \textbf{Worst-case scenario}: Server is fully controlled by attacker
		\item \textbf{What the attacker gains}:
		      \begin{itemize}
			      \item Session keys (server is TLS termination point)
			      \item All transmitted data \textbf{before} encryption
			      \item All received data \textbf{after} decryption
			      \item Server's private key
		      \end{itemize}
		\item \textbf{Attack capabilities}:
		      \begin{itemize}
			      \item Read all user communications in plaintext
			      \item Impersonate the legitimate server
			      \item Use private key to create malicious servers
		      \end{itemize}
		\item \textbf{Bottom line}: TLS won't save you if the server is compromised!
	\end{itemize}
\end{frame}

\begin{frame}{Server compromise: Mitigation strategies}
	\begin{itemize}[<+->]
		\item \textbf{Good news}: High-profile services are well-protected
		      \begin{itemize}
			      \item Gmail, iCloud, major banks
			      \item Multiple layers of security
		      \end{itemize}
		\item \textbf{Hardware Security Modules (HSMs)}:
		      \begin{itemize}
			      \item Store private keys in separate, tamper-resistant hardware
			      \item Even if server is compromised, keys may remain safe
		      \end{itemize}
		\item \textbf{Key Management Systems (KMS)}:
		      \begin{itemize}
			      \item Centralized key storage and management
			      \item Limits exposure of private keys
		      \end{itemize}
		\item \textbf{More common threats}: Web application vulnerabilities
		      \begin{itemize}
			      \item SQL injection, cross-site scripting (XSS)
			      \item Carried out \textbf{over} legitimate TLS connections
			      \item Independent of TLS security
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Compromised Client}
	\begin{itemize}[<+->]
		\item \textbf{Attack scenario}: Browser or client application is compromised
		\item \textbf{What the attacker gains}:
		      \begin{itemize}
			      \item Session keys from compromised client
			      \item All decrypted data visible to client
			      \item Ability to modify client behavior
		      \end{itemize}
		\item \textbf{Advanced attack}: Installing rogue CA certificates
		      \begin{itemize}
			      \item Add malicious CA to client's trusted store
			      \item Client silently accepts invalid certificates
			      \item Enables seamless man-in-the-middle attacks
		      \end{itemize}
		\item \textbf{Scope difference}:
		      \begin{itemize}
			      \item Compromised CA/server: affects \textbf{all} clients
			      \item Compromised client: affects \textbf{only that} client
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Client compromise: Attack techniques}
	\begin{itemize}[<+->]
		\item \textbf{Malware installation}:
		      \begin{itemize}
			      \item Trojans, viruses, browser plugins
			      \item Can intercept data before encryption
		      \end{itemize}
		\item \textbf{Certificate store manipulation}:
		      \begin{itemize}
			      \item Add attacker's CA certificate to trusted store
			      \item Modify certificate validation logic
		      \end{itemize}
		\item \textbf{Browser hijacking}:
		      \begin{itemize}
			      \item Redirect traffic through attacker's proxy
			      \item Modify DNS settings
		      \end{itemize}
		\item \textbf{Protection strategies}:
		      \begin{itemize}
			      \item Keep browsers and OS updated
			      \item Use reputable antivirus software
			      \item Certificate pinning (for developers)
			      \item Monitor certificate store changes
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{TLS security: A chain is only as strong as its weakest link}
	\begin{center}
		\textbf{Three points of failure in the TLS trust model:}
	\end{center}
	\begin{columns}[c]
		\begin{column}{0.33\textwidth}
			\textbf{Certificate Authority}
			\begin{itemize}
				\item Must protect private keys
				\item Must verify identities correctly
				\item Must not issue rogue certificates
			\end{itemize}
		\end{column}
		\begin{column}{0.33\textwidth}
			\textbf{Server}
			\begin{itemize}
				\item Must protect private keys
				\item Must maintain secure infrastructure
				\item Must handle session keys safely
			\end{itemize}
		\end{column}
		\begin{column}{0.33\textwidth}
			\textbf{Client}
			\begin{itemize}
				\item Must validate certificates properly
				\item Must protect trusted CA store
				\item Must remain malware-free
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Compromise any one component} \rightarrow\ \textbf{TLS security fails!}
	\end{center}
\end{frame}

\section{Attacks on TLS}

\begin{frame}{TLS attacks timeline (to 2015)}
	\bigimagewithcaption{tls_attacks_timeline_2015.png}{TLS attacks up until 2015.}
\end{frame}

\begin{frame}{Lucky Thirteen (2013)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Target}: TLS's CBC (Cipher Block Chaining) mode with HMAC
				\item \textbf{The vulnerability}: Timing differences in MAC verification\footnote{\url{https://appliedcryptography.page/papers/\#lucky-thirteen}}
				      \begin{itemize}
					      \item TLS 1.0-1.2 used MAC-then-encrypt with CBC mode
					      \item Padding oracle attacks exploit timing differences
					      \item Different MAC verification procedures for valid vs. invalid padding
				      \end{itemize}
				\item \textbf{Attack mechanism}:
				      \begin{enumerate}
					      \item Attacker modifies ciphertext to create invalid padding
					      \item Measures server response time
					      \item Timing differences reveal padding validity
					      \item Uses timing to guess plaintext byte-by-byte
				      \end{enumerate}
				\item \textbf{Why ``Lucky Thirteen''?} Attack requires exactly 13 bytes of padding
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Lucky Thirteen: Technical details}
	\begin{itemize}[<+->]
		\item \textbf{CBC padding in TLS}:
		      \begin{itemize}
			      \item Messages padded to block boundary (16 bytes for AES)
			      \item Padding bytes contain length of padding
			      \item Example: \texttt{...data|05|05|05|05|05|05} (5 bytes padding)
		      \end{itemize}
		\item \textbf{The timing leak}:
		      \begin{itemize}
			      \item \textbf{Valid padding}: MAC checked on message after padding removal
			      \item \textbf{Invalid padding}: TLS spec says to check MAC as if padding had zero-length
			      \item Different amounts of data processed creates timing difference
		      \end{itemize}
		\item \textbf{Statistical attack}:
		      \begin{itemize}
			      \item Send thousands of modified ciphertexts
			      \item Measure response times
			      \item Statistical analysis reveals timing patterns
		      \end{itemize}
		\item \textbf{Result}: Can decrypt HTTPS cookies, passwords, session tokens
	\end{itemize}
\end{frame}

\begin{frame}{Lucky Thirteen: Real-world impact}
	\begin{itemize}[<+->]
		\item \textbf{Affected systems}: All TLS 1.0-1.2 implementations using CBC
		      \begin{itemize}
			      \item OpenSSL, NSS, GnuTLS, SChannel
			      \item Millions of web servers worldwide
		      \end{itemize}
		\item \textbf{Practical exploitation}:
		      \begin{itemize}
			      \item Requires man-in-the-middle position
			      \item Can extract secrets from encrypted sessions
			      \item Especially dangerous on shared networks (Wi-Fi)
		      \end{itemize}
		\item \textbf{Mitigation attempts}:
		      \begin{itemize}
			      \item Constant-time implementations (hard to get right)
			      \item Prefer AEAD ciphers (AES-GCM)
			      \item Ultimately: abandon CBC mode entirely
		      \end{itemize}
		\item \textbf{Legacy}: Demonstrated fundamental flaws in MAC-then-encrypt
	\end{itemize}
\end{frame}

\begin{frame}{POODLE (2014): Downgrade attacks strike}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Full name}: Padding Oracle On Downgraded Legacy Encryption\footnote{\url{https://appliedcryptography.page/papers/\#google-poodle}}
				\item \textbf{Target}: SSL 3.0 (ancient protocol from 1996)
				\item \textbf{The setup}:
				      \begin{itemize}
					      \item Browsers support SSL 3.0 for ``compatibility''
					      \item Attacker forces downgrade from TLS to SSL 3.0
					      \item SSL 3.0 has weaker padding validation
				      \end{itemize}
				\item \textbf{Attack flow}:
				      \begin{enumerate}
					      \item Client attempts TLS 1.2 connection
					      \item Attacker blocks/corrupts TLS handshake
					      \item Client ``gracefully'' falls back to SSL 3.0
					      \item Attacker exploits SSL 3.0 padding oracle
				      \end{enumerate}
				\item \textbf{Discovered by}: Google Security Team
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{POODLE: The padding oracle vulnerability}
	\begin{itemize}[<+->]
		\item \textbf{SSL 3.0 padding flaw}:
		      \begin{itemize}
			      \item Padding bytes can contain \textbf{any values}
			      \item Only padding length is validated
			      \item Unlike TLS, which requires specific padding patterns
		      \end{itemize}
		\item \textbf{Attack technique}:
		      \begin{itemize}
			      \item Replace last block of ciphertext with target block
			      \item If padding is valid, server processes message
			      \item If padding is invalid, server returns error
			      \item Use oracle to guess plaintext bytes
		      \end{itemize}
		\item \textbf{Efficiency}:
		      \begin{itemize}
			      \item Extract one byte per 256 requests (on average)
			      \item Much faster than previous padding oracle attacks
		      \end{itemize}
		\item \textbf{Practical impact}: Steal HTTP cookies, session tokens
	\end{itemize}
\end{frame}

\begin{frame}{POODLE: Industry response and lessons}
	\begin{itemize}[<+->]
		\item \textbf{Immediate response}:
		      \begin{itemize}
			      \item Major browsers disabled SSL 3.0 support
			      \item Server administrators configured to reject SSL 3.0
			      \item ``Fallback SCSV'' mechanism introduced
		      \end{itemize}
		\item \textbf{Fallback SCSV}: Cryptographic downgrade protection
		      \begin{itemize}
			      \item Client signals highest supported version
			      \item Server detects and rejects artificial downgrades
			      \item Prevents attacker-induced fallbacks
		      \end{itemize}
		\item \textbf{Broader lessons}:
		      \begin{itemize}
			      \item Backward compatibility creates security risks
			      \item Legacy protocols should be completely removed
			      \item Graceful degradation can be graceful exploitation
		      \end{itemize}
		\item \textbf{Long-term impact}: Accelerated retirement of old protocols
	\end{itemize}
\end{frame}

\begin{frame}{Triple Handshakes and Cookie Cutters (2014)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Discovered by}: Inria Prosecco team (future TLS 1.3 verifiers!)
				\item \textbf{Core problem}: TLS handshake can be \textbf{resumed} with different certificates\footnote{\url{https://appliedcryptography.page/papers/\#triple-handshakes}}
				      \begin{itemize}
					      \item Client connects to Server A, establishes session
					      \item Session can be resumed with Server B using different certificate
					      \item Client may not notice certificate change
				      \end{itemize}
				\item \textbf{Attack scenario}:
				      \begin{itemize}
					      \item Attacker has certificate for \texttt{evil.com}
					      \item Tricks client into resuming session with \texttt{good.com}
					      \item Client thinks it's talking to \texttt{good.com}
					      \item Actually talking to attacker with \texttt{evil.com} certificate
				      \end{itemize}
				\item \textbf{Impact}: Breaks TLS authentication guarantees
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Triple Handshakes: The technical attack}
	\begin{itemize}[<+->]
		\item \textbf{Session resumption vulnerability}:
		      \begin{itemize}
			      \item TLS allows resuming sessions with different certificates
			      \item Session keys remain the same
			      \item Client authentication context gets confused
		      \end{itemize}
		\item \textbf{``Triple handshake'' attack}:
		      \begin{enumerate}
			      \item Handshake 1: Client \leftarrow\ Attacker (using evil certificate)
			      \item Handshake 2: Attacker \leftarrow\ Server (using good certificate)
			      \item Handshake 3: Client \leftarrow\ Server (resumed session, confused identity)
		      \end{enumerate}
		\item \textbf{Result}: Client sends sensitive data to attacker
		\item \textbf{Renegotiation attacks}: Similar issues with TLS renegotiation
		\item \textbf{Cookie cutter}: Attacker can splice different handshakes together
	\end{itemize}
\end{frame}

\begin{frame}{Triple Handshakes: Fixes and prevention}
	\begin{itemize}[<+->]
		\item \textbf{Extended Master Secret (RFC 7627)}:
		      \begin{itemize}
			      \item Bind session keys to handshake transcript
			      \item Prevents session resumption with different handshakes
			      \item Master secret includes hash of all handshake messages
		      \end{itemize}
		\item \textbf{Renegotiation Indication Extension}:
		      \begin{itemize}
			      \item Cryptographically bind renegotiated connections
			      \item Prevents injection of malicious handshakes
		      \end{itemize}
		\item \textbf{TLS 1.3 solution}:
		      \begin{itemize}
			      \item Completely removes renegotiation
			      \item Simplified session resumption with PSK
			      \item Cannot resume with different certificates
		      \end{itemize}
		\item \textbf{Significance}: Showed TLS state machine was more complex than realized
	\end{itemize}
\end{frame}

\begin{frame}{Heartbleed (2014): The bug that broke the internet}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Not a protocol flaw}: Implementation bug in OpenSSL\footnote{\url{https://appliedcryptography.page/papers/\#matter-heartbleed}}
				\item \textbf{The vulnerability}: Buffer over-read in heartbeat extension
				      \begin{itemize}
					      \item Heartbeat: ``keep-alive'' mechanism for TLS
					      \item Client sends data + length field
					      \item Server echoes data back
				      \end{itemize}
				\item \textbf{The bug}: No bounds checking on length field
				      \begin{itemize}
					      \item Send 1 byte of data, claim it's 64KB
					      \item Server copies 64KB from memory
					      \item Returns server's memory contents to attacker
				      \end{itemize}
				\item \textbf{Impact}: Arbitrary memory disclosure
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Heartbleed: What attackers could steal}
	\begin{itemize}[<+->]
		\item \textbf{Server's private keys}:
		      \begin{itemize}
			      \item TLS private keys used for authentication
			      \item Allows impersonation of legitimate servers
			      \item Forward secrecy completely broken
		      \end{itemize}
		\item \textbf{Session keys and user data}:
		      \begin{itemize}
			      \item Active TLS session keys
			      \item Usernames, passwords, session cookies
			      \item Credit card numbers, personal information
		      \end{itemize}
		\item \textbf{Memory contents}:
		      \begin{itemize}
			      \item Random 64KB chunks of server memory
			      \item Could contain anything: keys, data, code
			      \item Repeated requests reveal more memory
		      \end{itemize}
		\item \textbf{No evidence of exploitation}: Attack leaves no traces in logs
	\end{itemize}
\end{frame}

\begin{frame}{Heartbleed: The simple attack}
	\begin{center}
		\textbf{Normal heartbeat request:}
	\end{center}
	\begin{center}
		\texttt{Type=1, Length=4, Data="PING"}
	\end{center}
	\begin{center}
		Server responds: \texttt{"PING"}
	\end{center}
	\pause
	\begin{center}
		\textbf{Malicious heartbeat request:}
	\end{center}
	\begin{center}
		\texttt{Type=1, Length=65535, Data="A"}
	\end{center}
	\begin{center}
		Server responds: \texttt{"A" + 65534 bytes of memory}
	\end{center}
	\pause
	\begin{itemize}[<+->]
		\item \textbf{One line of C code}: \texttt{memcpy(bp, pl, payload);}
		\item \textbf{Missing check}: \texttt{if (payload != 1 + 2 + hblen) error();}
		\item \textbf{Lesson}: Simple bugs can have massive consequences
	\end{itemize}
\end{frame}

\begin{frame}{Heartbleed: Global impact and response}
	\begin{itemize}[<+->]
		\item \textbf{Affected systems}:
		      \begin{itemize}
			      \item 17\% of all SSL/TLS web servers (500,000+ sites)
			      \item Major services: Yahoo, Flickr, Stack Overflow
			      \item OpenSSL versions 1.0.1 through 1.0.1f
		      \end{itemize}
		\item \textbf{Emergency response}:
		      \begin{itemize}
			      \item OpenSSL fixed within days
			      \item Mass certificate revocation and reissuance
			      \item Users advised to change all passwords
		      \end{itemize}
		\item \textbf{Long-term consequences}:
		      \begin{itemize}
			      \item Increased funding for OpenSSL development
			      \item Core Infrastructure Initiative (CII) formed
			      \item Better security auditing of critical libraries
		      \end{itemize}
		\item \textbf{Branding success}: First security vulnerability with logo and website
	\end{itemize}
\end{frame}

\begin{frame}{SMACK and FREAK: Two attacks from one paper (2015)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Research by}: Inria Prosecco team (again!)\footnote{\url{https://appliedcryptography.page/papers/\#smack-tls}}
				\item \textbf{Two major attack classes discovered}:
				      \begin{itemize}
					      \item \textbf{SMACK}: State Machine AttaCKs
					      \item \textbf{FREAK}: Factoring RSA Export Keys
				      \end{itemize}
				\item \textbf{SMACK core insight}: TLS implementations have \textbf{state machines}
				      \begin{itemize}
					      \item Expected message sequence: ClientHello → ServerHello → Certificate → ...
					      \item Implementations track current state
					      \item But different implementations have different state machines!
				      \end{itemize}
				\item \textbf{FREAK core insight}: Legacy export-grade RSA still supported
				      \begin{itemize}
					      \item 512-bit RSA keys can be factored in hours
					      \item Downgrade attacks force use of weak keys
				      \end{itemize}
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{SMACK: How state machine attacks work}
	\begin{itemize}[<+->]
		\item \textbf{Example scenario}: Web server with two TLS libraries
		      \begin{itemize}
			      \item Library A handles initial handshake
			      \item Library B handles application data
		      \end{itemize}
		\item \textbf{Attack technique}:
		      \begin{enumerate}
			      \item Send duplicate or out-of-order handshake messages
			      \item Library A and Library B enter different states
			      \item Library A thinks handshake is complete
			      \item Library B thinks handshake is still in progress
		      \end{enumerate}
		\item \textbf{Result}:
		      \begin{itemize}
			      \item Bypass authentication
			      \item Downgrade security parameters
			      \item Inject malicious data
		      \end{itemize}
		\item \textbf{Discovery method}: Systematic testing with model checking
	\end{itemize}
\end{frame}

\begin{frame}{SMACK: How state machine attacks work}
	\bigimagewithcaption{tls_smack.png}{}
\end{frame}

\begin{frame}{FREAK: Factoring RSA Export Keys}
	\begin{itemize}[<+->]
		\item \textbf{Export-grade cryptography legacy}:
		      \begin{itemize}
			      \item 1990s US export restrictions required weak crypto
			      \item 512-bit RSA keys for international software
			      \item Restrictions lifted, but support remained in implementations
		      \end{itemize}
		\item \textbf{FREAK attack flow}:
		      \begin{enumerate}
			      \item Client requests strong RSA key exchange
			      \item Attacker modifies ClientHello to request export-grade RSA
			      \item Server responds with 512-bit RSA parameters
			      \item Attacker factors 512-bit RSA key (8-10 hours)
			      \item Attacker can decrypt entire TLS session
		      \end{enumerate}
		\item \textbf{Vulnerable systems}: 36.7\% of all browser-trusted sites
		\item \textbf{Impact}: Complete compromise of TLS connections
	\end{itemize}
\end{frame}

\begin{frame}{When math was classified as weapons}
	\begin{itemize}[<+->]
		\item \textbf{US Export Administration Regulations (1970s-1990s)}:
		      \begin{itemize}
			      \item Cryptographic software classified as ``munitions''
			      \item Same category as tanks, missiles, and fighter jets
			      \item Export required State Department license (like arms dealing!)
		      \end{itemize}
		\item \textbf{The absurd reality}:
		      \begin{itemize}
			      \item Mathematical algorithms = weapons of war
			      \item Publishing crypto code = illegal arms export
			      \item Explaining RSA algorithm abroad = potential felony
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{When math was classified as weapons}
	\begin{itemize}[<+->]
		\item \textbf{Practical impact}:
		      \begin{itemize}
			      \item US software artificially weakened for international markets
			      \item 40-bit keys for ``export grade'' crypto (easily breakable)
			      \item Non-US developers gained competitive advantage
		      \end{itemize}
		\item \textbf{The irony}: Trying to keep crypto weak made \textbf{everyone} less secure
		      \begin{itemize}
			      \item Dual-use problem: same algorithms protect banks and terrorists
			      \item Weak crypto created systemic vulnerabilities
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Bernstein v. United States}
	\begin{columns}[c]
		\begin{column}{0.7\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Daniel J. Bernstein}: Graduate student at UC Berkeley (1990s)
				      \begin{itemize}
					      \item Developed ``Snuffle'' encryption algorithm
					      \item Wanted to publish academic paper and source code
					      \item Government: ``That's illegal arms export!''
				      \end{itemize}
				\item \textbf{The lawsuit}: Bernstein v. United States (1995-2003)
				      \begin{itemize}
					      \item Argued cryptographic code is protected speech
					      \item First Amendment covers mathematical expressions
					      \item Government can't censor academic research
				      \end{itemize}
			\end{itemize}
		\end{column}
		\begin{column}{0.3\textwidth}
			\imagewithcaption{djb.jpg}{Daniel J. Bernstein}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Bernstein v. United States}
	\begin{columns}[c]
		\begin{column}{0.7\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Key victories}:
				      \begin{itemize}
					      \item 1996: Court rules source code is speech
					      \item 1999: 9th Circuit affirms First Amendment protection
					      \item Export controls on publicly available crypto unconstitutional
				      \end{itemize}
				\item \textbf{Legacy}: Opened floodgates for strong cryptography
				      \begin{itemize}
					      \item TLS, HTTPS, modern secure communications
					      \item Academic freedom in cryptographic research
					      \item Foundation for today's digital security
				      \end{itemize}
				\item \textbf{Fun fact}: Bernstein later created Curve25519 (used in TLS 1.3!)
			\end{itemize}
		\end{column}
		\begin{column}{0.3\textwidth}
			\imagewithcaption{djb.jpg}{Daniel J. Bernstein}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{``The Crypto Wars''}
	\begin{columns}[c]
		\begin{column}{0.33\textwidth}
			\imagewithcaption{export_1.jpg}{RSA tattoo}
		\end{column}
		\begin{column}{0.33\textwidth}
			\imagewithcaption{export_2.jpg}{RSA t-shirt}
		\end{column}
		\begin{column}{0.33\textwidth}
			\imagewithcaption{export_3.jpg}{Netscape ``not for export'' floppy}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{The Cypherpunk Manifesto (1993)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Key principles}:\footnote{\url{https://www.activism.net/cypherpunk/manifesto.html}}
				      \begin{itemize}
					      \item Cryptography essential for privacy
					      \item Cannot trust governments/corporations
					      \item ``We must defend our own privacy''
				      \end{itemize}
				\item \textbf{``Cypherpunks write code''}:
				      \begin{itemize}
					      \item Software defends privacy
					      \item Code is free for all to use
					      \item ``Software can't be destroyed''
				      \end{itemize}
				\item \textbf{Vision}: Cryptography will spread globally, enabling anonymous transactions
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{The Moral Character of Cryptographic Work}{Rogaway, 2015}
	\begin{itemize}[<+->]
		\item \textbf{Core thesis}: Cryptography is inherently political - it configures power
		      \begin{itemize}
			      \item Not just puzzles and math, but tools that shape society
			      \item Confers intrinsic moral dimension on the field
		      \end{itemize}
		\item \textbf{The Snowden wake-up call}:
		      \begin{itemize}
			      \item Ordinary people lack basic communication privacy
			      \item Mass surveillance threatens democracy and human dignity
			      \item Cryptography's failure: focused on theory, not protecting people
		      \end{itemize}
		\item \textbf{Academic cryptography's problems}:
		      \begin{itemize}
			      \item Divorced from real-world privacy concerns
			      \item Serves governments and corporations, not ordinary people
			      \item Marginalized secure messaging and anti-surveillance work
		      \end{itemize}
		\item \textbf{Distinction}: Crypto-for-security (commercial) vs. crypto-for-privacy (social/political)
	\end{itemize}
\end{frame}

\begin{frame}{Rogaway's call to action}
	\begin{itemize}[<+->]
		\item \textbf{Cryptographers' moral obligations}:
		      \begin{itemize}
			      \item Remember responsibility to humanity
			      \item Consider societal implications of work
			      \item Use academic freedom to resist mass surveillance
		      \end{itemize}
		\item \textbf{Concrete recommendations}:
		      \begin{itemize}
			      \item Develop anti-surveillance technologies
			      \item Think twice about military funding
			      \item Work on secure messaging and privacy tools
			      \item Apply practice-oriented provable security to privacy
		      \end{itemize}
		\item \textbf{Vision for the field}:
		      \begin{itemize}
			      \item Build cryptographic commons beyond corporate/government reach
			      \item Make surveillance more expensive
			      \item Create ``boring crypto'' that just works for people
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{FREAK}
	\bigimagewithcaption{tls_freak.png}{}
\end{frame}

\begin{frame}{SMACK: Real vulnerabilities found}
	\begin{itemize}[<+->]
		\item \textbf{miTLS vs. OpenSSL}:
		      \begin{itemize}
			      \item Attacker can skip client authentication
			      \item Exploit differences in certificate validation
		      \end{itemize}
		\item \textbf{NSS (Firefox) vulnerabilities}:
		      \begin{itemize}
			      \item Early application data acceptance
			      \item Certificate validation bypass
		      \end{itemize}
		\item \textbf{Java JSSE attacks}:
		      \begin{itemize}
			      \item Premature transition to application data
			      \item Authentication bypass in specific configurations
		      \end{itemize}
		\item \textbf{The root cause}: Complex state machines without formal verification
		\item \textbf{Solution approach}: Model checking and formal verification
		      \begin{itemize}
			      \item Systematically test all possible message sequences
			      \item Verify implementations match specifications
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Logjam: When Diffie-Hellman goes wrong (2015)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Research team}: 14 researchers from 10 institutions\footnote{\url{https://appliedcryptography.page/papers/\#imperfect-dh}}
				\item \textbf{Target}: Diffie-Hellman key exchange in TLS
				\item \textbf{Two main attacks}:
				      \begin{itemize}
					      \item \textbf{Logjam}: Downgrade to weak 512-bit DH groups
					      \item \textbf{Precomputation}: Break commonly used 1024-bit groups
				      \end{itemize}
				\item \textbf{Context}: 1990s US export restrictions on cryptography
				      \begin{itemize}
					      \item ``Export-grade'' crypto limited to weak parameters
					      \item Legacy support for 512-bit DH groups remained
				      \end{itemize}
				\item \textbf{Fundamental question}: Can we still break today's crypto by exploiting legacy weak parameters?
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Logjam: The downgrade attack}
	\begin{itemize}[<+->]
		\item \textbf{Attack flow}:
		      \begin{enumerate}
			      \item Client offers strong DH groups (2048-bit)
			      \item Attacker modifies ClientHello to request weak DH (512-bit)
			      \item Server responds with 512-bit DH parameters
			      \item Attacker breaks 512-bit DH in real-time
			      \item Attacker can now decrypt entire session
		      \end{enumerate}
		\item \textbf{Breaking 512-bit DH}:
		      \begin{itemize}
			      \item Academic cluster: 7 minutes
			      \item Amazon EC2: under \$100 per connection
			      \item NSA-level resources: near real-time
		      \end{itemize}
		\item \textbf{Vulnerable servers}: 8.4\% of top 1 million HTTPS sites
		\item \textbf{The irony}: Export restrictions from 1990s still creating vulnerabilities in 2015
	\end{itemize}
\end{frame}

\begin{frame}{Logjam: The downgrade attack}
	\bigimagewithcaption{logjam_2.png}{}
\end{frame}

\begin{frame}{Logjam: Precomputation attacks on 1024-bit groups}
	\begin{itemize}[<+->]
		\item \textbf{The number field sieve algorithm}:
		      \begin{itemize}
			      \item Most efficient known algorithm for breaking DH
			      \item Has expensive precomputation phase
			      \item Once precomputation is done, individual logs are cheaper
		      \end{itemize}
		\item \textbf{Attack economics}:
		      \begin{itemize}
			      \item Precomputation for 1024-bit group: several months, millions of dollars
			      \item Individual discrete logs: 30 seconds
			      \item Amortized cost: profitable for high-value targets
		      \end{itemize}
		\item \textbf{Widespread vulnerability}:
		      \begin{itemize}
			      \item 18\% of top 1M HTTPS sites use single 1024-bit group
			      \item 66\% of VPN servers use same group
			      \item 26\% of SSH servers use same group
		      \end{itemize}
		\item \textbf{NSA implications}: Could explain some of NSA's cryptanalytic capabilities
	\end{itemize}
\end{frame}

\begin{frame}{Logjam: Precomputation attacks on 1024-bit groups}
	\bigimagewithcaption{logjam_1.png}{}
\end{frame}

\begin{frame}{Logjam: The ``well-known groups'' problem}
	\begin{itemize}[<+->]
		\item \textbf{Common practice}: Everyone uses the same DH parameters
		      \begin{itemize}
			      \item RFC 5114 specifies ``standard'' groups
			      \item Apache mod\_ssl ships with default parameters
			      \item Easier than generating custom parameters
		      \end{itemize}
		\item \textbf{Concentration risk}:
		      \begin{itemize}
			      \item Breaking one group breaks many servers
			      \item Amortizes the cost of precomputation
			      \item Creates attractive targets for nation-state actors
		      \end{itemize}
		\item \textbf{Timeline for 1024-bit groups}:
		      \begin{itemize}
			      \item 2015: Academic resources could break with significant effort
			      \item 2020: Within reach of well-funded adversaries
			      \item 2025: Potentially routine for state actors
		      \end{itemize}
		\item \textbf{Recommendation}: Move to 2048-bit DH or elliptic curves
	\end{itemize}
\end{frame}

\begin{frame}{Logjam: Intelligence services exploit these issues!}
	\bigimagewithcaption{logjam_3.png}{}
\end{frame}

\begin{frame}{Logjam: Countermeasures and lessons}
	\begin{itemize}[<+->]
		\item \textbf{Immediate fixes}:
		      \begin{itemize}
			      \item Disable export-grade DH entirely
			      \item Upgrade to 2048-bit or larger DH groups
			      \item Prefer elliptic curve Diffie-Hellman (ECDH)
		      \end{itemize}
		\item \textbf{Browser responses}:
		      \begin{itemize}
			      \item Reject connections with weak DH parameters
			      \item Implement warnings for short DH keys
		      \end{itemize}
		\item \textbf{Broader lessons}:
		      \begin{itemize}
			      \item Legacy cryptography creates long-term vulnerabilities
			      \item Export restrictions had lasting negative security impact
			      \item Centralized parameters create systemic risks
			      \item Need to plan for cryptographic algorithm transitions
		      \end{itemize}
		\item \textbf{Policy implications}: Demonstrated real-world harm from crypto restrictions
	\end{itemize}
\end{frame}

\begin{frame}{SWEET32: Birthday attacks on 64-bit block ciphers (2016)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Researchers}: Karthikeyan Bhargavan and Gaëtan Leurent (Inria)\footnote{\url{https://appliedcryptography.page/papers/\#inria-sweet32}}
				\item \textbf{Target}: 64-bit block ciphers (3DES, Blowfish)
				\item \textbf{Core vulnerability}: Birthday paradox in block cipher usage
				      \begin{itemize}
					      \item 64-bit blocks $\rightarrow$ $2^{32}$ blocks before collisions
					      \item Long-lived TLS connections can encrypt that much data
					      \item Collision reveals information about plaintext
				      \end{itemize}
				\item \textbf{Attack name}: \textbf{SWEET32} - birthday attacks on block ciphers
				\item \textbf{Practical scenario}: HTTPS connections sending repetitive data
				      \begin{itemize}
					      \item JavaScript making repeated AJAX requests
					      \item Cookies or authentication tokens repeated in each request
				      \end{itemize}
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{SWEET32: The birthday attack mechanics}
	\begin{itemize}[<+->]
		\item \textbf{Birthday paradox}:
		      \begin{itemize}
			      \item For $n$-bit blocks, expect collision after $2^{n/2}$ blocks
			      \item 64-bit blocks: collision after $2^{32} = 4$ billion blocks
			      \item At 1 Mbps: 9 hours, at 10 Mbps: 1 hour
		      \end{itemize}
		\item \textbf{Collision exploitation}:
		      \begin{itemize}
			      \item When same plaintext block encrypted twice → same ciphertext
			      \item Attacker identifies when collision occurs
			      \item Can deduce relationships between plaintext blocks
		      \end{itemize}
		\item \textbf{Attack requirements}:
		      \begin{itemize}
			      \item Long-lived TLS connection
			      \item Ability to generate traffic (malicious JavaScript)
			      \item Repetitive plaintext content (cookies, tokens)
		      \end{itemize}
		\item \textbf{Proof of concept}: Extracted HTTP cookies in 30 hours
	\end{itemize}
\end{frame}

\begin{frame}{SWEET32: Real-world impact and remediation}
	\begin{itemize}[<+->]
		\item \textbf{Vulnerable systems}:
		      \begin{itemize}
			      \item Legacy systems still using 3DES
			      \item Some VPN implementations
			      \item Older TLS configurations
		      \end{itemize}
		\item \textbf{Attack limitations}:
		      \begin{itemize}
			      \item Requires very long connections
			      \item Needs repetitive plaintext patterns
			      \item Success rate depends on traffic patterns
		      \end{itemize}
		\item \textbf{Countermeasures}:
		      \begin{itemize}
			      \item Migrate to 128-bit block ciphers (AES)
			      \item Implement connection limits (rekeying)
			      \item Disable 3DES in TLS configurations
		      \end{itemize}
		\item \textbf{Browser responses}: Disabled 3DES by default
		\item \textbf{Lesson}: Even ``theoretical'' attacks can become practical
	\end{itemize}
\end{frame}

\begin{frame}{Transcript Collision Attacks (2016)}
	\begin{columns}[c]
		\begin{column}{1\textwidth}
			\begin{itemize}[<+->]
				\item \textbf{Researchers}: Karthikeyan Bhargavan and Gaëtan Leurent (Inria)\footnote{\url{https://appliedcryptography.page/papers/\#inria-collisions}}
				\item \textbf{Novel attack class}: Hash collision attacks on protocol transcripts
				\item \textbf{Core idea}:
				      \begin{itemize}
					      \item Protocols hash their message transcripts for integrity
					      \item Find two different transcripts with same hash
					      \item Substitute one transcript for another
				      \end{itemize}
				\item \textbf{Targets}: TLS, IKE (IPsec), SSH
				\item \textbf{Hash collision research}: Building on advances in MD5 and SHA-1
				      \begin{itemize}
					      \item Google's SHA-1 collision (SHAttered) published in 2017
					      \item But collision attacks were becoming practical by 2016
				      \end{itemize}
			\end{itemize}
		\end{column}
	\end{columns}
\end{frame}

\begin{frame}{Transcript Collision}
	\bigimagewithcaption{tls_collision.png}{}
\end{frame}

\begin{frame}{Transcript Collision: Attack on TLS}
	\begin{itemize}[<+->]
		\item \textbf{TLS transcript hashing}:
		      \begin{itemize}
			      \item TLS computes hash of all handshake messages
			      \item Used in Finished message for integrity verification
			      \item Older TLS versions used MD5 and SHA-1
		      \end{itemize}
		\item \textbf{Attack scenario}:
		      \begin{enumerate}
			      \item Attacker finds two handshake transcripts with same hash
			      \item First transcript: legitimate client-server handshake
			      \item Second transcript: attacker's malicious handshake
			      \item Attacker substitutes malicious transcript
		      \end{enumerate}
		\item \textbf{Consequences}:
		      \begin{itemize}
			      \item Bypass authentication checks
			      \item Downgrade security parameters
			      \item Inject malicious content
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Transcript Collision: Cross-protocol attacks}
	\begin{itemize}[<+->]
		\item \textbf{Cross-protocol confusion}:
		      \begin{itemize}
			      \item Same hash function used in multiple protocols
			      \item IKE and TLS both use SHA-1 for transcript hashing
			      \item Attacker crafts messages that are valid in both protocols
		      \end{itemize}
		\item \textbf{Attack example}:
		      \begin{itemize}
			      \item Client connects to TLS server
			      \item Attacker substitutes IKE handshake with same hash
			      \item Client's TLS stack processes IKE messages
			      \item Potential for memory corruption or bypass
		      \end{itemize}
		\item \textbf{Mitigation strategies}:
		      \begin{itemize}
			      \item Use strong hash functions (SHA-256,SHA-384)
			      \item Protocol-specific message formats
			      \item Separate hash contexts for different protocols
		      \end{itemize}
		\item \textbf{Lesson}: Hash collisions threaten more than just digital signatures
	\end{itemize}
\end{frame}

\begin{frame}{Qualys SSL Labs}
	\begin{itemize}
		\item Free online service to analyze TLS/SSL configuration.
		\item Tests any public HTTPS server.
		\item Provides detailed security assessment.
		\item Available at: \url{https://www.ssllabs.com/ssltest/}
	\end{itemize}
\end{frame}

\section{How TLS 1.3 Transformed Protocol Design}

\begin{frame}{TLS 1.3: The great cleanup}
	\begin{itemize}[<+->]
		\item \textbf{Problem}: TLS 1.2 inherited decades of legacy features.
		      \begin{itemize}
			      \item Suboptimal security and performance.
			      \item Complex and error-prone configurations.
			      \item High risk of implementation bugs.
		      \end{itemize}
		\item \textbf{Solution}: Complete redesign for TLS 1.3.
		      \begin{itemize}
			      \item Kept only the good parts.
			      \item Added modern security features.
			      \item Simplified the bloated design.
		      \end{itemize}
		\item \textbf{Result}: TLS 1.3 is more secure, efficient, and simpler.
		\item TLS 1.3 = ``mature TLS''.
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3: Learning from TLS 1.2's mistakes}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.2's legacy problem}:
		      \begin{itemize}
			      \item Decades of accumulated features and algorithms
			      \item Many insecure options still supported for compatibility
			      \item Complex configurations prone to errors
		      \end{itemize}
		\item \textbf{TLS 1.3's philosophy}: \textbf{Remove everything dangerous}
		      \begin{itemize}
			      \item If it's been broken, remove it
			      \item If it's complex and error-prone, simplify it
			      \item If it's not needed, delete it
		      \end{itemize}
		\item \textbf{Result}: A much cleaner, more secure protocol
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3: Algorithmic spring cleaning}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{TLS 1.2 supported:}
			\begin{itemize}[<+->]
				\item MD5 (broken)
				\item SHA-1 (broken)
				\item RC4 (broken)
				\item AES-CBC (padding oracles)
				\item MAC-then-encrypt
				\item Various weak ciphers
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{TLS 1.3 only allows:}
			\begin{itemize}[<+->]
				\item Strong hash functions only
				\item Authenticated encryption
				\item Modern, secure algorithms
				\item No legacy cruft
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Philosophy}: ``If you can configure it wrong, remove the option!''
	\end{center}
\end{frame}

\begin{frame}{Authenticated encryption: No more MAC-then-encrypt}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.2 approach}: MAC-then-encrypt
		      \begin{itemize}
			      \item Compute MAC over plaintext
			      \item Encrypt (plaintext + MAC)
			      \item Vulnerable to padding oracle attacks
		      \end{itemize}
		\item \textbf{TLS 1.3 approach}: Authenticated encryption only
		      \begin{itemize}
			      \item AES-GCM, ChaCha20-Poly1305
			      \item Encryption and authentication in one step
			      \item No padding oracle vulnerabilities
		      \end{itemize}
		\item \textbf{Benefits}:
		      \begin{itemize}
			      \item More efficient (one cryptographic operation)
			      \item More secure (no composition attacks)
			      \item Simpler implementation
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Supported cryptographic algorithms}
	\begin{itemize}[<+->]
		\item \textbf{Authenticated Encryption} (only 3 algorithms):
		      \begin{itemize}
			      \item AES-GCM (128-bit or 256-bit keys)
			      \item AES-CCM (128-bit keys, slightly less efficient than GCM)
			      \item ChaCha20-Poly1305 (256-bit keys, from RFC 7539)
		      \end{itemize}
		\item \textbf{Key Derivation Function (KDF)}:
		      \begin{itemize}
			      \item HKDF construction based on HMAC (RFC 5869)
			      \item Uses SHA-256 or SHA-384 hash functions
		      \end{itemize}
		\item \textbf{Diffie-Hellman Key Exchange}:
		      \begin{itemize}
			      \item \textbf{Elliptic Curves}: 3 NIST curves + Curve25519 + Curve448
			      \item \textbf{Integer Groups}: 2,048, 3,072, 4,096, 6,144, 8,192 bits (RFC 7919)
		      \end{itemize}
		\item \textbf{Security note}: 2,048-bit DH provides $<$100-bit security
		      \begin{itemize}
			      \item Inconsistent with other 128-bit security choices
			      \item Still practically impossible to break
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3 extensions and variations}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.3 supports many options}:
		      \begin{itemize}
			      \item Client certificate authentication
			      \item Preshared key handshakes
			      \item Various extensions for specific needs
		      \end{itemize}
		\item \textbf{Client certificate authentication}:
		      \begin{itemize}
			      \item Server can require client to prove its identity
			      \item Mutual authentication (both parties verified)
			      \item Common in enterprise environments
		      \end{itemize}
		\item \textbf{Preshared keys (PSK)}:
		      \begin{itemize}
			      \item Skip certificate verification
			      \item Use pre-established shared secrets
			      \item Faster handshake, but requires prior key distribution
		      \end{itemize}
		\item \textbf{Flexibility}: TLS 1.3 adapts to different security requirements.
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3: formal verification during the design phase}
	\begin{itemize}[<+->]
		\item \textbf{Revolutionary approach}: Protocol design meets formal methods
		      \begin{itemize}
			      \item Traditional approach: Design protocol \rightarrow\ implement \rightarrow\ find bugs \rightarrow\ patch
			      \item TLS 1.3 approach: Design protocol \rightarrow\ prove correctness \rightarrow\ implement
		      \end{itemize}
		\item \textbf{Formal verification}: Mathematical proofs of security properties
		      \begin{itemize}
			      \item Prove protocol satisfies security requirements
			      \item Eliminate entire classes of implementation bugs
			      \item Higher confidence in security guarantees
		      \end{itemize}
		\item \textbf{Industry-academia collaboration}:
		      \begin{itemize}
			      \item Inria's Prosecco team (France)
			      \item Microsoft Research Cambridge (Project Everest)
			      \item Direct input into IETF standardization process
		      \end{itemize}
		\item \textbf{Result}: First cryptographic protocol with machine-checked security proofs \textit{as it was being designed!}
	\end{itemize}
\end{frame}

\begin{frame}{Inria Prosecco: Proving TLS 1.3 security}
	\begin{itemize}[<+->]
		\item \textbf{Team Prosecco} (Programming securely with cryptography):
		      \begin{itemize}
			      \item Led by Karthikeyan Bhargavan at Inria Paris
			      \item World-leading experts in cryptographic protocol analysis
		      \end{itemize}
		\item \textbf{Key contributions to TLS 1.3}:
		      \begin{itemize}
			      \item Formal models of the handshake protocol
			      \item Machine-checked proofs of key security properties
			      \item Discovery and prevention of potential attacks
		      \end{itemize}
		\item \textbf{Tools and methods}:
		      \begin{itemize}
			      \item ProVerif: Automated protocol verification tool
			      \item Symbolic analysis of cryptographic protocols
			      \item Found subtle issues before standardization
		      \end{itemize}
		\item \textbf{Impact}: Security flaws caught during design, not after deployment
	\end{itemize}
\end{frame}

\begin{frame}{Project Everest: Verified cryptographic implementations}
	\begin{itemize}[<+->]
		\item \textbf{Project Everest}: Microsoft Research Cambridge initiative
		      \begin{itemize}
			      \item Goal: Provably secure, high-performance cryptographic code
			      \item From high-level specifications to assembly language
		      \end{itemize}
		\item \textbf{\fstar programming language}:
		      \begin{itemize}
			      \item Functional language with dependent types
			      \item Enables specification and verification of code properties
			      \item Compiles to efficient C code
		      \end{itemize}
		\item \textbf{\haclstar cryptographic library}:
		      \begin{itemize}
			      \item Verified implementations of crypto primitives
			      \item ChaCha20, Poly1305, Curve25519, etc.
			      \item Mathematical proofs of correctness and security
		      \end{itemize}
		\item \textbf{miTLS}: Verified TLS implementation
		      \begin{itemize}
			      \item Reference implementation with security proofs
			      \item Demonstrates that formal verification scales to real protocols
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{ProVerif: Automated protocol verification}
	\begin{itemize}[<+->]
		\item \textbf{What is ProVerif?}
		      \begin{itemize}
			      \item Automated tool for analyzing cryptographic protocols.
			            \begin{itemize}
				            \item \url{https://proverif.inria.fr}
			            \end{itemize}
			      \item Developed by Bruno Blanchet at Inria Paris.
			      \item Uses symbolic model of cryptography.
		      \end{itemize}
		\item \textbf{How ProVerif works}:
		      \begin{itemize}
			      \item Protocol modeled in applied pi-calculus.
			      \item Automated search for attacks and proofs.
			      \item Handles unbounded number of protocol sessions.
		      \end{itemize}
		\item \textbf{TLS 1.3 verification with ProVerif}:
		      \begin{itemize}
			      \item Modeled complete TLS 1.3 handshake protocol.
			      \item Proved secrecy of session keys.
			      \item Proved forward secrecy properties.
			      \item Found potential attacks on early draft versions.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{\fstar: Functional programming with verification}
	\begin{itemize}[<+->]
		\item \textbf{What is \fstar?}
		      \begin{itemize}
			      \item Functional programming language with dependent types.
			      \item Developed by Microsoft Research and Inria.
			      \item Enables specification and proof of program properties.
		      \end{itemize}
		\item \textbf{\fstar key features}:
		      \begin{itemize}
			      \item Static type system catches bugs at compile-time.
			      \item Can express and verify complex security properties.
			      \item Compiles to efficient C code via KreMLin compiler.
		      \end{itemize}
		\item \textbf{TLS 1.3 implementation in \fstar}:
		      \begin{itemize}
			      \item \textbf{miTLS}: Complete TLS 1.3 stack with proofs.
			      \item \textbf{\haclstar}: Verified crypto library (ChaCha20, Poly1305, Curve25519).
			      \item \textbf{EverCrypt}: Agile crypto provider with algorithm selection.
		      \end{itemize}
		\item \textbf{Real-world impact}:
		      \begin{itemize}
			      \item \haclstar integrated into Firefox, Python, Linux kernel.
			      \item Proves that verified code can be practical and fast.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Formal verification benefits for TLS 1.3}
	\begin{itemize}[<+->]
		\item \textbf{Design-time bug prevention}:
		      \begin{itemize}
			      \item Subtle protocol flaws caught before standardization.
			      \item Avoided costly post-deployment patches.
			      \item Higher confidence in initial design.
		      \end{itemize}
		\item \textbf{Implementation guidance}:
		      \begin{itemize}
			      \item Formal specifications guide implementers.
			      \item Clear mathematical definitions of security properties.
			      \item Reduced ambiguity in standard documents.
		      \end{itemize}
		\item \textbf{Security assurance}:
		      \begin{itemize}
			      \item Mathematical proofs complement traditional security analysis.
			      \item Machine-checked proofs eliminate human error.
			      \item Covers complex interaction between protocol components.
		      \end{itemize}
		\item \textbf{Industry adoption}:
		      \begin{itemize}
			      \item \haclstar used in Firefox, Linux kernel.
			      \item Proves formal methods can produce practical code.
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Removing dangerous features: The CRIME attack example}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.2 feature}: Optional data compression
		      \begin{itemize}
			      \item Reduces bandwidth usage
			      \item Seemed like a good idea...
		      \end{itemize}
		\item \textbf{The CRIME attack}: Compression leaks information
		      \begin{itemize}
			      \item Compressed length reveals patterns in plaintext
			      \item Attackers can inject data and observe compression ratios
			      \item Can extract secrets like authentication cookies
		      \end{itemize}
		\item \textbf{TLS 1.3 solution}: Remove compression entirely
		      \begin{itemize}
			      \item No compression = no compression-based attacks
			      \item Security over efficiency
		      \end{itemize}
		\item \textbf{Lesson}: Features that seem helpful can create vulnerabilities
	\end{itemize}
\end{frame}

\begin{frame}{Zero padding: Defeating traffic analysis}
	\begin{itemize}[<+->]
		\item \textbf{Traffic analysis attack}:
		      \begin{itemize}
			      \item Attackers observe encrypted traffic patterns.
			      \item Extract info from timing, message sizes, etc.
			      \item Ciphertext size ≈ plaintext size (reveals message length).
		      \end{itemize}
		\item \textbf{TLS 1.3 solution}: Zero padding
		      \begin{itemize}
			      \item Add zeros to plaintext before encryption.
			      \item Inflates ciphertext size.
			      \item Hides true message length from observers.
		      \end{itemize}
		\item \textbf{Example}: 100-byte message + 900 zero bytes = looks like 1000-byte message.
	\end{itemize}
\end{frame}

\begin{frame}{Downgrade protection: Preventing version rollback}
	\begin{itemize}[<+->]
		\item \textbf{Downgrade attack scenario}:
		      \begin{enumerate}
			      \item Client sends ClientHello supporting TLS 1.3
			      \item Attacker modifies message to claim only TLS 1.2 support
			      \item Server responds with weaker TLS 1.2 connection
			      \item Attacker exploits TLS 1.2 vulnerabilities
		      \end{enumerate}
		\item \textbf{TLS 1.3 defense}: Magic values in server random
		      \begin{itemize}
			      \item Server encodes connection type in first 8 bytes of random value
			      \item TLS 1.2: \texttt{44 4F 57 4E 47 52 44 01}
			      \item TLS 1.1: \texttt{44 4F 57 4E 47 52 44 00}
			      \item TLS 1.3: Random bytes (no pattern)
		      \end{itemize}
		\item \textbf{Attack detection}: Client sees wrong pattern \rightarrow\ knows it's under attack!
	\end{itemize}
\end{frame}

\begin{frame}{The magic downgrade detection values}
	\begin{center}
		\textbf{What do those hex values spell?}
	\end{center}
	\pause
	\begin{center}
		\texttt{44 4F 57 4E 47 52 44 01} = ``\textbf{DOWNGRD}\textbackslash x01''\\
		\texttt{44 4F 57 4E 47 52 44 00} = ``\textbf{DOWNGRD}\textbackslash x00''
	\end{center}
	\pause
	\begin{itemize}[<+->]
		\item \textbf{Clever engineering}: Human-readable sentinel values
		\item \textbf{Easy debugging}: Hex dumps show ``DOWNGRD'' string
		\item \textbf{Security through visibility}: Makes downgrade attempts obvious
		\item \textbf{Cryptographic protection}: Random value is signed by server
		      \begin{itemize}
			      \item Attacker can't modify it without breaking signature
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Performance boost: Single round-trip handshake}
	\begin{columns}[c]
		\begin{column}{0.5\textwidth}
			\textbf{TLS 1.2 handshake:}
			\begin{itemize}[<+->]
				\item Client \rightarrow\ Server: ClientHello
				\item Client \leftarrow\ Server: ServerHello + Certificate
				\item Client \rightarrow\ Server: Key exchange
				\item Client \leftarrow\ Server: Finished
				\item \textbf{2 round trips} before encrypted data
			\end{itemize}
		\end{column}
		\begin{column}{0.5\textwidth}
			\textbf{TLS 1.3 handshake:}
			\begin{itemize}[<+->]
				\item Client \rightarrow\ Server: ClientHello + Key exchange
				\item Client \leftarrow\ Server: ServerHello + Certificate + Finished
				\item \textbf{1 round trip} before encrypted data
			\end{itemize}
		\end{column}
	\end{columns}
	\pause
	\begin{center}
		\textbf{Performance impact}: Hundreds of milliseconds saved per connection
	\end{center}
\end{frame}

\begin{frame}{Why single round-trip matters}
	\begin{itemize}[<+->]
		\item \textbf{Real-world impact}:
		      \begin{itemize}
			      \item High-traffic servers: thousands of connections per second
			      \item Mobile networks: high latency connections
			      \item User experience: faster page loads
		      \end{itemize}
		\item \textbf{Latency examples}:
		      \begin{itemize}
			      \item Local network: 1ms \rightarrow\ savings minimal
			      \item Cross-country: 50ms \rightarrow\ saves 50ms per connection
			      \item Satellite internet: 500ms \rightarrow\ saves 500ms per connection!
		      \end{itemize}
		\item \textbf{Efficiency gain}: Client sends DH key exchange immediately
		      \begin{itemize}
			      \item No waiting for server's algorithm selection
			      \item Client predicts what server will choose
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{Session resumption: Even faster connections}
	\begin{itemize}[<+->]
		\item \textbf{The idea}: Reuse keys from previous connections
		      \begin{itemize}
			      \item Client and server remember shared \textbf{preshared key (PSK)}
			      \item Skip certificate validation in subsequent connections
			      \item Combine PSK with fresh Diffie-Hellman exchange
		      \end{itemize}
		\item \textbf{Security benefits}:
		      \begin{itemize}
			      \item Forward secrecy maintained (fresh DH keys)
			      \item Authentication via MAC instead of certificates
		      \end{itemize}
		\item \textbf{Performance benefits}:
		      \begin{itemize}
			      \item Faster handshake
			      \item Less CPU usage (no certificate operations)
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{0-RTT}
	\begin{itemize}[<+->]
		\item \textbf{Zero Round-Trip Time (0-RTT)}:
		      \begin{itemize}
			      \item Client sends encrypted data in \textbf{first message}
			      \item No waiting for server response
			      \item Uses PSK from previous session
		      \end{itemize}
		\item \textbf{Process}:
		      \begin{enumerate}
			      \item Client: ClientHello + PSK + DH key + \textbf{encrypted data}
			      \item Server: Processes everything, responds with MAC
			      \item Client: Verifies MAC, knows it's talking to right server
		      \end{enumerate}
		\item \textbf{Performance impact}: Eliminates connection setup delay entirely
		\item \textbf{Use case}: Perfect for frequently-visited websites
	\end{itemize}
\end{frame}

\begin{frame}{0-RTT security considerations}
	\begin{itemize}[<+->]
		\item \textbf{Replay attack vulnerability}:
		      \begin{itemize}
			      \item Attacker records 0-RTT data packet
			      \item Replays it to server later
			      \item Server can't distinguish replay from legitimate connection
			            \begin{itemize}
				            \item You can probably formally prove that this problem can't be completely solved without a round trip
			            \end{itemize}
		      \end{itemize}
		\item \textbf{Mitigation strategies}:
		      \begin{itemize}
			      \item Server remembers recent 0-RTT messages
			      \item Applications design requests to be replay-safe
			      \item Don't use 0-RTT for sensitive operations
		      \end{itemize}
		\item \textbf{Trade-off}: Performance vs. replay protection
		      \begin{itemize}
			      \item Perfect for browsing, reading content
			      \item Dangerous for payments, account changes
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}{TLS 1.3: Summary of improvements}
	\begin{itemize}[<+->]
		\item \textbf{Security improvements}:
		      \begin{itemize}
			      \item Removed all weak algorithms and dangerous features
			      \item Authenticated encryption only
			      \item Downgrade protection
		      \end{itemize}
		\item \textbf{Performance improvements}:
		      \begin{itemize}
			      \item Single round-trip handshake
			      \item Session resumption with PSK
			      \item 0-RTT for repeat connections
		      \end{itemize}
		\item \textbf{Simplicity improvements}:
		      \begin{itemize}
			      \item Fewer configuration options
			      \item Standardized elliptic curve formats
			      \item Cleaner protocol design
		      \end{itemize}
		\item \textbf{Result}: More secure, faster, and easier to implement correctly
	\end{itemize}
\end{frame}

\begin{frame}{The future of protocol design}
	\begin{itemize}[<+->]
		\item \textbf{TLS 1.3 as a model}:
		      \begin{itemize}
			      \item First major protocol with end-to-end formal verification
			      \item Demonstrates feasibility of formal methods at scale
			      \item Sets new standard for protocol security assurance
		      \end{itemize}
		\item \textbf{Expanding to other protocols}:
		      \begin{itemize}
			      \item Signal Protocol (secure messaging)
			      \item WireGuard VPN protocol
			      \item Post-quantum cryptographic protocols
		      \end{itemize}
		\item \textbf{Challenges ahead}:
		      \begin{itemize}
			      \item Scaling formal methods to larger, more complex protocols
			      \item Training developers in formal verification techniques
			      \item Balancing mathematical rigor with practical engineering
		      \end{itemize}
		\item \textbf{Vision}: All security-critical protocols designed with formal verification
		      \begin{itemize}
			      \item Higher security guarantees for everyone
			      \item Fewer catastrophic vulnerabilities
		      \end{itemize}
	\end{itemize}
\end{frame}

\begin{frame}[plain]
	\titlepage
\end{frame}
\end{document}