diff options
Diffstat (limited to 'slides/2021-pets')
30 files changed, 1030 insertions, 0 deletions
| diff --git a/slides/2021-pets/.gitignore b/slides/2021-pets/.gitignore new file mode 100644 index 0000000..d1e39cc --- /dev/null +++ b/slides/2021-pets/.gitignore @@ -0,0 +1,9 @@ +main.aux +main.fdb_latexmk +main.fls +main.log +main.nav +main.out +main.pdf +main.snm +main.toc diff --git a/slides/2021-pets/README b/slides/2021-pets/README new file mode 100644 index 0000000..8b89967 --- /dev/null +++ b/slides/2021-pets/README @@ -0,0 +1,3 @@ +My (transcribed) PETS 2021 talk. + +Edit 2024-10-15: seems like there's some nit compiling now. diff --git a/slides/2021-pets/beamercolorthemergd.sty b/slides/2021-pets/beamercolorthemergd.sty new file mode 100644 index 0000000..74ced1c --- /dev/null +++ b/slides/2021-pets/beamercolorthemergd.sty @@ -0,0 +1,24 @@ +\mode<presentation> + +%%% +% Color definitions +%%% +\RequirePackage{xcolor} +\definecolor{rgdGreen}{RGB}{33,114,106} +\definecolor{rgdYellow}{RGB}{255,210,4} +\definecolor{rgdOrange}{RGB}{232,114,12} +\colorlet{rgdGray}{gray!33} +\colorlet{rgdBlack}{black} + +%%% +% Beamer colors +%%% +\setbeamercolor*{titlepage}{fg=rgdBlack} +\setbeamercolor*{author}{fg=rgdGreen} +\setbeamercolor*{date}{fg=black} +\setbeamercolor*{header}{bg=rgdYellow,fg=black} +\setbeamercolor*{trailer}{bg=rgdGray,fg=black} +\setbeamercolor*{item}{fg=rgdGreen} +\setbeamercolor*{alerted text}{fg=rgdGreen} + +\mode<all> diff --git a/slides/2021-pets/beamerfontthemergd.sty b/slides/2021-pets/beamerfontthemergd.sty new file mode 100644 index 0000000..a6d212c --- /dev/null +++ b/slides/2021-pets/beamerfontthemergd.sty @@ -0,0 +1,9 @@ +\mode<presentation> + +\setbeamerfont{title}{size=\large,shape=\bfseries} +\setbeamerfont{subtitle}{size=\normalsize,shape=\bfseries} +\setbeamerfont{frametitle}{size=\large,shape=\bfseries} +\setbeamerfont{institute}{size=\small} +\setbeamerfont{date}{size=\small} + +\mode<all> diff --git a/slides/2021-pets/beamerinnerthemergd.sty b/slides/2021-pets/beamerinnerthemergd.sty new file mode 100644 index 0000000..1c50b47 --- /dev/null +++ b/slides/2021-pets/beamerinnerthemergd.sty @@ -0,0 +1,43 @@ +\mode<presentation> + +%%% +% Title page +%%% +\defbeamertemplate*{title page}{rgd}[1][]{ +  \begin{tikzpicture}[remember picture, overlay] +    \usebeamercolor{titlepage} +     Add top-left triangle with university logo +    \filldraw[draw=rgdGray,fill=rgdGray] +      (current page.north west) -- +      (current page.north) -- +        node[draw=none,pos=0.5](LogoMul){\includegraphics[width=3.5cm]{img/kau}} +      (current page.west) -- +      (current page.north west); +    % Add title +    \node[ +      text=fg, +      text width=0.75\paperwidth, +    ] (Title) at ([shift={(0,-0.5cm)}]current page){% +      \centering\usebeamerfont{title}\inserttitle\\% +    }; +    % Add date +    \node[ +      text=fg, +      text width=0.75\paperwidth, +      below=0pt of Title, +    ] (Subtitle) {% +      \centering\usebeamerfont{date}\insertdate\\% +    }; +    % Add authors +    \usebeamercolor{author} +    \node[ +      text=fg, +      text width=0.75\paperwidth, +      below=0pt of Subtitle, +    ] (Author) {% +      \centering\usebeamerfont{author}\insertauthor\\% +    }; +  \end{tikzpicture} +} + +\mode<all> diff --git a/slides/2021-pets/beamerouterthemergd.sty b/slides/2021-pets/beamerouterthemergd.sty new file mode 100644 index 0000000..456290a --- /dev/null +++ b/slides/2021-pets/beamerouterthemergd.sty @@ -0,0 +1,69 @@ +\mode<presentation> + +%%% +% Frame header +%%% +\defbeamertemplate*{frametitle}{corporate}[1][]{% +  \nointerlineskip +  % Add frame title +  \begin{beamercolorbox}[ +    wd=\paperwidth, +    ht=3ex, +    dp=1.5ex, +    left, +    leftskip=2ex +  ]{header} +    \insertframetitle +  \end{beamercolorbox} +  % Add line after header +  \nointerlineskip +  \begin{beamercolorbox}[ +    wd=\paperwidth, +    ht=0.25ex +  ]{trailer} +  \end{beamercolorbox}% +} + +%%% +% Frame trailer +%%% +\defbeamertemplate*{footline}{corporate}{% +  \hbox{% +    % Add metadata +    \begin{beamercolorbox}[ +      wd=0.50\paperwidth, +      ht=2ex, +      dp=0.5ex, +      left, +      leftskip=2ex +    ]{trailer} +		\href{https://rgdd.github.io}{rgdd.github.io} +		$\;\;\;\;\;\;\;\;\cdots\;\;\;\;\;\;\;\;$ +		\href{https://twitter.com/\_\_rgdd}{@\_\_rgdd} +		$\;\;\;\;\;\;\;\cdots\;\;\;\;\;\;\;$ +		\href{mailto:rasmus.dahlberg@kau.se}{rasmus.dahlberg@kau.se} +    \end{beamercolorbox}% +    % Add title +    \begin{beamercolorbox}[ +      wd=0.45\paperwidth, +      ht=2ex, +      dp=0.5ex, +      left, +      leftskip=2ex +    ]{header} +      \insertsubtitle +    \end{beamercolorbox}% +    % Add page counter +    \begin{beamercolorbox}[ +      wd=0.05\paperwidth, +      ht=2ex, +      dp=0.5ex, +      right, +      rightskip=1ex +    ]{header} +      \insertframenumber/\inserttotalframenumber +    \end{beamercolorbox}% +  } +} + +\mode<all> diff --git a/slides/2021-pets/beamerthemergd.sty b/slides/2021-pets/beamerthemergd.sty new file mode 100644 index 0000000..022ef2c --- /dev/null +++ b/slides/2021-pets/beamerthemergd.sty @@ -0,0 +1,23 @@ +\mode<presentation> + +%%% +% Load beamer settings +%%% +\usecolortheme{rgd} +\usefonttheme{rgd} +\useinnertheme{rgd} +\useoutertheme{rgd} + +%%% +% Disable navigation tools on slides +%%% +\setbeamertemplate{navigation symbols}{} + +%%% +% Object styles +%%% +\setbeamertemplate{itemize item}[square] +\setbeamertemplate{itemize subitem}[default] +\setbeamertemplate{sections/subsections in toc}[square] + +\mode<all> diff --git a/slides/2021-pets/handout.pdf b/slides/2021-pets/handout.pdfBinary files differ new file mode 100644 index 0000000..211f95a --- /dev/null +++ b/slides/2021-pets/handout.pdf diff --git a/slides/2021-pets/img/beverwijk.jpg b/slides/2021-pets/img/beverwijk.jpgBinary files differ new file mode 100644 index 0000000..3ac9d1a --- /dev/null +++ b/slides/2021-pets/img/beverwijk.jpg diff --git a/slides/2021-pets/img/chrome.png b/slides/2021-pets/img/chrome.pngBinary files differ new file mode 100644 index 0000000..b874d44 --- /dev/null +++ b/slides/2021-pets/img/chrome.png diff --git a/slides/2021-pets/img/ct.tex b/slides/2021-pets/img/ct.tex new file mode 100644 index 0000000..ae1213c --- /dev/null +++ b/slides/2021-pets/img/ct.tex @@ -0,0 +1,72 @@ +\begin{tikzpicture}[ +	-latex, +	entity/.style = { +		draw = gray!30, +		thick, +		rounded rectangle, +		fill = white, +		minimum width = 2cm, +		font = \fontsize{8}{8}\selectfont, +		text = white, +	}, +	relation/.style = { +		draw = none, +		font = \fontsize{6}{6}\selectfont, +	}, +	path/.style = { +		draw, +		thick, +		-latex, +	}, +] +	\node[entity, fill=darkBlue] (Log) at (0,0) { Log }; +	\node[entity, fill=darkGreen, below=1.5cm of Log] (Browser) {Browser}; +	\node[entity, fill=darkOrange, left=1.5cm of Log] (CA) {CA}; +	\node[entity, fill=darkRed, below=1.5cm of CA] (Website) {Website}; + +	% Logging +	\path[path] (CA) edge[bend left] +			node[relation,right,below]{Certificate} +		(Log);	 +	\path[path] (Log) edge[bend left] +			node[relation,left,above]{Proofs} +		(CA); + +	% Distribution +	\path[path] (CA) -- +			node[relation, below, sloped]{% +					\begin{tabular}{c} +						Certificate\\ +						Proofs \\ +					\end{tabular} +				} +		(Website); + + +	% Serve +	\path[path] (Website) -- +			node[relation, below] { +				\begin{tabular}{c} +					Certificate\\ +					Proofs \\ +				\end{tabular} +			} +		(Browser); + +	% Monitor +	\path[path, dashed] (Website.15) -- +			node[relation]{% +				\includegraphics[width=.8cm]{img/magnify} +			} +		(Log.290); + +	% Verify +	\path[path, rounded corners] +		(Browser.0) -| +		($ (Browser) + (1.25,.75) $) +			node[relation, above]{ +				Verify +			} -| +		(Browser.30); + +\end{tikzpicture} diff --git a/slides/2021-pets/img/design-full.pdf b/slides/2021-pets/img/design-full.pdfBinary files differ new file mode 100644 index 0000000..5602116 --- /dev/null +++ b/slides/2021-pets/img/design-full.pdf diff --git a/slides/2021-pets/img/design-incremental.pdf b/slides/2021-pets/img/design-incremental.pdfBinary files differ new file mode 100644 index 0000000..7c7160d --- /dev/null +++ b/slides/2021-pets/img/design-incremental.pdf diff --git a/slides/2021-pets/img/diginotar.jpg b/slides/2021-pets/img/diginotar.jpgBinary files differ new file mode 100644 index 0000000..c185e38 --- /dev/null +++ b/slides/2021-pets/img/diginotar.jpg diff --git a/slides/2021-pets/img/kau.png b/slides/2021-pets/img/kau.pngBinary files differ new file mode 100755 index 0000000..0c7c885 --- /dev/null +++ b/slides/2021-pets/img/kau.png diff --git a/slides/2021-pets/img/magnify.png b/slides/2021-pets/img/magnify.pngBinary files differ new file mode 100644 index 0000000..9b8ec7d --- /dev/null +++ b/slides/2021-pets/img/magnify.png diff --git a/slides/2021-pets/img/mullvad.png b/slides/2021-pets/img/mullvad.pngBinary files differ new file mode 100644 index 0000000..4574eb1 --- /dev/null +++ b/slides/2021-pets/img/mullvad.png diff --git a/slides/2021-pets/img/phase-1.png b/slides/2021-pets/img/phase-1.pngBinary files differ new file mode 100644 index 0000000..6d90fa0 --- /dev/null +++ b/slides/2021-pets/img/phase-1.png diff --git a/slides/2021-pets/img/phase-2.png b/slides/2021-pets/img/phase-2.pngBinary files differ new file mode 100644 index 0000000..0638293 --- /dev/null +++ b/slides/2021-pets/img/phase-2.png diff --git a/slides/2021-pets/img/phase-3-4.png b/slides/2021-pets/img/phase-3-4.pngBinary files differ new file mode 100644 index 0000000..f7fd529 --- /dev/null +++ b/slides/2021-pets/img/phase-3-4.png diff --git a/slides/2021-pets/img/safari.png b/slides/2021-pets/img/safari.pngBinary files differ new file mode 100644 index 0000000..0fb75ec --- /dev/null +++ b/slides/2021-pets/img/safari.png diff --git a/slides/2021-pets/img/tb.png b/slides/2021-pets/img/tb.pngBinary files differ new file mode 100644 index 0000000..3fd6852 --- /dev/null +++ b/slides/2021-pets/img/tb.png diff --git a/slides/2021-pets/img/thanks.pdf b/slides/2021-pets/img/thanks.pdfBinary files differ new file mode 100644 index 0000000..9ad4dc8 --- /dev/null +++ b/slides/2021-pets/img/thanks.pdf diff --git a/slides/2021-pets/main.tex b/slides/2021-pets/main.tex new file mode 100644 index 0000000..861b8ed --- /dev/null +++ b/slides/2021-pets/main.tex @@ -0,0 +1,27 @@ +\pdfminorversion=4 +%\documentclass[handout,aspectratio=169]{beamer} +\documentclass[aspectratio=169]{beamer} +\usetheme{rgd} + +\input{src/preamble} + +\title{%full version that is shown on the front page +	Privacy-Preserving \& Incrementally-Deployable Support for Certificate +	Transparency in Tor +} +\subtitle{%short version that is shown in the footer on each slide +	Certificate Transparency in Tor +} +\author{% +	\textbf{Rasmus Dahlberg}, Tobias Pulls, Tom Ritter, and Paul Syverson +} +\date{% +  July 15, 2021 +} + +\begin{document} +  \input{src/titlepage} +  \input{src/start} +  \input{src/body} +  \input{src/end} +\end{document} diff --git a/slides/2021-pets/slides.pdf b/slides/2021-pets/slides.pdfBinary files differ new file mode 100644 index 0000000..39a9e6b --- /dev/null +++ b/slides/2021-pets/slides.pdf diff --git a/slides/2021-pets/src/body.tex b/slides/2021-pets/src/body.tex new file mode 100644 index 0000000..8d38999 --- /dev/null +++ b/slides/2021-pets/src/body.tex @@ -0,0 +1,413 @@ +\begin{frame} +	% +	% The problem that we are trying to take on in this paper is adding support +	% for CT in Tor Browser.  In other words, right now CT is not enforced at +	% all and that is something we would like to change. +	% +	% The reason why we would like to change that is - first of all - we don't +	% want users of Tor Browser to be subject to DigiNotar style attacks.  This +	% is in fact easier against Tor Browser because you can position +	% yourself in the network by volunteering to run Tor relays.  This type of +	% attacker has been observed several times in Tor - for example by +	% using self-signed certificates or simply targeting HTTP traffic.  Now that +	% encryption on the web matured and continues to mature, you kind of need a +	% mis-issued certificate to pull of these attacks.  So, this is probably a +	% good enough argument already to add CT in Tor Browser. +	% +	% The second threat that is very important for Tor is that an attacker may +	% rely on interception to de-anonymize a subset of users.  For context, +	% recall that Tor is a low-latency anonymity network that routes your +	% traffic through a guard relay, a middle relay, and an exit relay.  At +	% each hop a layer of encryption is pealed off, such that the guard only +	% learns the sender's identity and the exit only learns the visited website. +	%  +	% If the attacker can intercept the encrypted traffic at the exit - using a +	% mis-issued certificate - it would be trivial to de-anonymize a user that +	% logs in to a service. +	% +	% We have also observed cases in the past where attackers break Tor's +	% anonymity by serving zero-day exploits to the browser.  A pre-requisite to +	% serve such an exploit is the ability to make it load.  Again, because the +	% web is mostly encrypted these days, a mis-issued certificate can help to +	% make the loading procedure happen. +	% +	% So, in terms of threat modelling we assume a powerful attacker that has +	% access to a browser zero-day exploit.  The attacker also has the usual Tor +	% capabilities like controlling and denying service to a fraction of relays, +	% and in addition to that the attacker has access to a Certificate Authority +	% that can mis-issue certificates on request. +	% +	% Our design further permits the attacker to control enough CT logs, so that +	% you can trivially bypass today's definition of CT compliance. +	% +	% This is actually one of the reasons why we started looking into Tor in +	% the first place.   If a major problem with full decentralized verification +	% is privacy, then we might have better luck in Tor's more private setting. +	% +	\mktitle{Problem statement} +	\begin{columns} +		\begin{column}{0.5\textwidth} +			\begin{itemize} +				\item Tor Browser does not enforce CT +				\item Guard against prominent threats +					\begin{itemize} +						\item DigiNotar style attacks +						\item Interception to deanonymize +					\end{itemize} +				\item Aim higher than CT compliance +			\end{itemize} +		\end{column} +		\begin{column}{0.5\textwidth} +			\centering\includegraphics[width=.5\columnwidth]{img/tb} +		\end{column} +	\end{columns} +	\vfill +	\pause +	\centering\alert{% +		Attacker with browser exploit, CA, CT logs, and usual Tor capabilities +	} +\end{frame} + +\begin{frame} +	% +	% What we are proposing is a gradual roll-out plan. +	% +	% The first step is to catch up with today's CT compliant browsers.  Pairs +	% of logs are trusted blindly because there is no follow-up verification +	% of the log's SCTs.  Recall from earlier that SCTs are promises of public +	% logging.  In an ideal world, these promises are also verified by someone. +	% +	% Is this first step suboptimal? +	% - Yes. +	% Is it a significant improvement when compared to what we had before? +	% - Also yes. +	% +	% How to do this is not really a research problem to be honest.  It is, +	% however, a reasonable starting point that we know doesn't break the web. +	% The reason why we know that is because other browsers already do it. +	% I like to think of this first increment as ruling out many weaker +	% attackers that may control certificate authorities but not enough CT logs. +	% +	% Next, we propose some incremental steps to get started with the +	% decentralized verification that will reduce trust in the log ecosystem. +	% I will get back to this later, because it is more intuitive to introduce +	% the full design that places no blind trust in the log ecosystem. +	% +	% In terms of trust assumptions we go from +	%   pairs of logs that are trusted blindly, +	%   to some log that is trusted blindly, +	%   to no log that is trusted blindly. +	% +	\vfill +	\mktitle{Gradual roll-out plan} +	\begin{enumerate} +		\item Catch up with CT compliant browsers +			\floatright{\emph{pairs of logs} are trusted blindly} +		\item Steps towards decentralized verification +			\floatright{\emph{some log} is trusted blindly} +		\item Fully decentralized verification +			\floatright{\emph{no log} is trusted blindly} +	\end{enumerate} +	\vfill +\end{frame} + +\begin{frame} +	% +	% Okay.  What I'm hoping to do for the remainder of this presentation is to +	% give you an intuition of +	% a) how we arrived at the full design that is now in front of us, and +	% b) what complexities can we get rid of to roll it out gradually +	% +	% To help us think and reason about the design we divided it into phases. +	% +	% Phase 1 takes place before phase 2. +	% Phase 2 takes place before phase 3. +	% And so forth. +	% +	% For security, it should be difficult for the attacker to reliably +	% interfere without detection in any phase.  Misbehavior of Certificate +	% Authorities and/or CT logs are detected after the final phase played out. +	% +	% Examples of misbehavior include creating a mis-issued certificate or not +	% making it available to the public after promising to do so. +	% +	% Let's look at each phase separately. +	% +	\mktitle{Overview of the full design} +	\centering\includegraphics[height=.5\textheight]{img/design-full} +	\vfill +	\pause +	\alert{Security? Difficult to interfere without detection in any phase} +\end{frame} + +\begin{frame} +	% +	% The first phase happens in Tor Browser. +	% A so-called SFO, which is really just a certificate chain and its +	% associated SCTs, is presented to Tor Browser during a website visit. +	% If this SFO is CT compliant, we accept the connection to avoid any +	% blocking and degraded user experience. +	% +	% Now we want to do better than just trusting the logs' promises of public +	% logging.  This means that we will need to audit encountered SFOs by +	% interacting with the logs. +	% +	% The simplest thing that comes to mind is to fetch an inclusion proof from +	% a log.  This interaction is privacy invasive with a regular browser, but +	% less so with Tor Browser because of its anonymity properties. +	% +	% An immediate problem, however, is that Tor Browser has a disk avoidance +	% criteria.  This means that no browsing related activity can be persisted +	% after closing Tor Browser.  This includes encountered SFOs that have yet +	% to be audited.  In practise, it takes up to 24 hours before a certificate +	% is logged.  This follows from a so-called Maximum Merge Delay. +	% +	% In other words, we will have to wait at least 24 hours before a newly +	% issued certificate can be audited.  Tor Browser has likely been shutdown +	% by then, which means that the SFO will be deleted and thus not audited. +	% +	% A second problem is that the attacker controls the log, and in our threat +	% model the attacker also has a zero-day exploit against the browser.  The +	% attacker could trivially delay the log's response while taking control of +	% the browser to disable the auditing mechanism all together. +	% +	% So, what we need is to get the encountered SFO away from Tor Browser as +	% soon as possible so that _someone_ can audit it.  A straw man design would +	% be to send all SFOs to a centralized third-party that is trusted. +	% However, that party would get a considerable aggregation of browsing +	% history.  Such population data is valuable and better not collected. +	% +	% Another problem is that a centralized solution does not scale with the +	% network.  What we do instead is to utilize Tor's existing relays to help +	% with CT auditing.  Such Certificate Transparency Relays are called CTRs in +	% our design.  Relays may be assigned the CTR flag similar to how a Tor +	% relay may be assigned the HSDir flag if some conditions are met. +	% +	% To reduce overhead, only a sample of SFOs are submitted to randomly +	% selected CTRs.  The probability of detection can therefore not be larger +	% than the probability that an encountered SFO is submitted for auditing. +	% +	% Note that it is important that the attacker cannot infer which CTR +	% received an SFO because Tor's threat model includes DoS attacks on +	% individual CTRs.  If you can take the right CTR offline, the submitted +	% SFO would not be audited and any misbehavior would thus not be detected. +	% +	% We discuss how the attacker can try to infer this in the paper using their +	% zero-day exploit.  It boils down to winning a race against us submitting +	% the SFO on a one-time Tor circuit that was prepared ahead-of-time. +	% +	\mktitle{Submission phase} +	\centering\includegraphics[width=.75\textwidth]{img/phase-1} +	\vfill +	\begin{columns} +		\begin{column}{.1\textwidth} +		\end{column} +		\begin{column}{.4\textwidth} +			\textbf{Straw man proposals} +			\begin{itemize} +				\item Fetch an inclusion proof +				\item Rely on a centralized party +			\end{itemize} +		\end{column} +		\begin{column}{.1\textwidth} +		\end{column} +		\begin{column}{.4\textwidth} +			\textbf{What we do instead} +			\begin{itemize} +				\item Use Tor relays, ``CTRs'' +				\item Probabilistic submit +			\end{itemize} +		\end{column} +	\end{columns} +	\vfill +	\pause +	\centering\alert{It must be difficult to infer which CTR received an SFO} +\end{frame} + +\begin{frame} +	% +	% Okay.  +	% +	% A CTR received a submitted SFO.  Now what? +	% +	% The simplest thing would be to challenge the log to prove inclusion if +	% the SFO's Maximum Merge Delay elapsed, and otherwise wait until it does. +	% +	% The problem with contacting the log immediately is that it leaks a lot of +	% valuable information to the attacker.  For example, it is deterministic +	% when the CTR will do its auditing.  That helps with interference planning. +	% +	% It also leaks real-time browsing patterns which are helpful for traffic +	% analysis against Tor.  Since we will anyway need to buffer newly issued +	% SFOs until the Maximum Merge Delay elapsed, it is not an added complexity +	% to always buffer SFOs for a random amount of time to reduce this leakage. +	% +	% Leakage to CT logs are also reduced because CTRs cache audited SFOs. +	% +	% To summarize the basics of the buffer phase then. +	% +	% You receive an SFO.  If you have not seen it before, you buffer the SFO +	% until the log's Maximum Merge Delay elapsed.  You also add a random +	% auditing delay to obfuscate real-time browsing patterns. +	% +	% Phase 3 starts when it is time to do the auditing. +	% +	% The attacker's best bet to interfere in phase 2 is to do a so-called +	% network-wide flush.  Please refer to our paper for more details.  The +	% TL;DR is that we cannot prevent such interference, but it is trivially +	% detected and draws unwanted attention if CTRs publish relevant metrics. +	%  +	\mktitle{Buffering phase} +	\begin{columns} +		\begin{column}{.5\textwidth} +			\begin{itemize} +				\item Buffer until logging is required +				\item Add a random delay to leak less +				\item Cache audited SFOs to leak less +			\end{itemize} +		\end{column} +		\begin{column}{.5\textwidth} +			\centering +			\includegraphics[width=.5\columnwidth]{img/phase-2} +		\end{column} +	\end{columns} +	\vfill +	\pause +	\centering\alert{% +		The attacker's best bet to interfere is trivially detectable +	} +\end{frame} + +\begin{frame} +	% +	% After an SFO's buffering phase is over, the CTR will challenge a log to +	% prove inclusion.  This inclusion proof will reference the first signed +	% tree head in Tor's consensus that should have merged it by now. +	% +	% If you are familiar with gossip, notice that the difficulty of presenting +	% an undetected split-view here is as difficult as breaking Tor's consensus +	% mechanism.  Other user agents than Tor Browser can benefit from this. +	% +	% Anyhow, an important detail that we discuss in the paper is that the +	% attacker (who controls the log) can likely infer which CTR queried for +	% inclusion.  Surprisingly, perhaps, it may even be so despite using Tor. +	% +	% It is problematic if the attacker can infer the CTR's identity.  Then you +	% basically do a DoS on that relay and the mis-issued SFO goes unnoticed. +	% +	% To err on the safe side, we decided to assume that the attacker can in +	% fact identify which CTR queried for inclusion.  In other words, once a +	% mis-issued SFO has been queried for, the querying CTR becomes unavailable. +	% +	% To prepare against this threat each CTR collaborates with another CTR. +	% That other CTR is called a watchdog in our design.  Before doing an +	% inclusion query, the CTR sends the SFO upfront to a watchdog.  If the +	% query succeeded the watchdog receives an acknowledgment.  If there is no +	% timely acknowledgment, it is the watchdog's responsibility to report that +	% SFO to a trusted auditor that will investigate the issue further. +	% +	% The reason why it is not the watchdog that does the final investigation is +	% because the average Tor relay operator cannot be expected to do so.  Tor +	% relays are also designed not to write data to disk unless debugging is +	% enabled.  Such disk writes would increase the risk of unwanted search, +	% seizure, and forensic analysis of the operator's physical servers. +	% +	% Now you might feel like you got the run around.  We started by saying that +	% we cannot have a centralized third-party auditor.  Yet, in the end it is a +	% centralized third-party auditor that investigates potential issues. +	% +	% What's different here is that the number of SFOs that reach these auditors +	% are reduced in numbers.  Under normal circumstances, an auditor should not +	% receive any report at all.  If some log suffers from bad availability, the +	% number of reports are also limited in our design because CTRs back-off +	% immediately after a failed query.  What we trust these auditors with is a +	% tiny subset of SFOs that need further investigation. +	% +	% These auditors also do not have to scale with the network because the +	% expected number of reports is very small. +	% +	\begin{columns} +		\begin{column}{.6\textwidth} +			\mktitle{Audit and report phases} +			\begin{itemize} +				\item Fetch inclusion proof against a specific STH +				\item Rely on Tor's consensus to agree on STHs +				\item Watchdog CTRs do the reporting if needed +					\begin{itemize} +						\item Protects against CTR identification +					\end{itemize} +			\end{itemize} +		\end{column} +		\begin{column}{.4\textwidth} +			\includegraphics[width=\columnwidth]{img/phase-3-4} +		\end{column} +	\end{columns} +	\vfill +	\pause +	\centering\alert{Why not just send to a trusted auditor immediately?} +\end{frame} + +\begin{frame} +	% +	% Let's put it all together. +	% +	% For each certificate validation in Tor Browser, we basically flip a coin +	% if it should be submitted to a random CTR for auditing.  We made it as +	% difficult as possible for the attacker to identify this CTR. +	% +	% CTRs buffer incoming SFOs until they can be audited.  To reduce leakage +	% to the logs, random delays are added and audited SFOs are cached. +	% +	% SFOs are audited against signed tree heads in Tor's consensus.  This makes +	% it as difficult to fork the log as it is to forge a valid Tor consensus. +	% Other ecosystems can benefit from this and not just Tor. +	% +	% While an SFO is audited we erred on the safe side and assumed that the +	% attacker can infer from the inclusion query which CTR holds evidence of +	% Certificate Authority +	% and/or log misbehavior.  This means that the holding CTR can be knocked +	% offline shortly thereafter.  To guard against this threat, a watchdog +	% receives the SFO upfront.  If there is no timely acknowledgment, a report +	% is sent to a trusted auditor that investigates the issue further. +	% +	% Such reporting should be rare, even if a log becomes unavailable our +	% design ensures that a limited amount of SFOs leak to these auditors. +	% +	% Although these auditors don't have to scale with the network anymore, it +	% requires both new software and operations to be deployed.  The overall +	% complexity in phase two, three, and four, is also quite a leap from just +	% basic CT compliance.  Therefore, we proposed a simplified version that +	% can be deployed incrementally. +	% +	\mktitle{Putting it all together} +	\centering\includegraphics[height=.5\textheight]{img/design-full} +	\vfill +	\pause +	\alert{This is quite a leap from CT compliance} +\end{frame} + +\begin{frame} +	% +	% Phase 1 is identical in our incremental design.  The main difference is +	% that no inclusion proofs will be fetched.  Instead, CTRs are going to +	% cross-log certificates and possibly entire SFOs if CT logs allow it. +	% +	% You can think of this as using the log ecosystem against the attacker.  CT +	% logs are basically repurposed as CT auditors.  A cross-logged certificate +	% becomes public so that Certificate Authority misbehavior can be detected +	% by anyone that inspects the logs. +	% +	% Of course, this assumes that at least some log is honest. +	% +	% We can also detect log misbehavior if CT logs allowed logging of SCTs, not +	% just certificates.  That, however, requires an extended CT log API. +	% +	% Personally, I think that would be a valuable addition to the log ecosystem +	% because it provides a well-defined place to do casual SFO reporting. +	% +	\mktitle{Incremental design} +	\centering\includegraphics[height=.33\textheight]{img/design-incremental} +	\vfill +	\pause +	\alert{Use the log ecosystem against the attacker}\\ +\end{frame} diff --git a/slides/2021-pets/src/end.tex b/slides/2021-pets/src/end.tex new file mode 100644 index 0000000..56beaf3 --- /dev/null +++ b/slides/2021-pets/src/end.tex @@ -0,0 +1,34 @@ +\begin{frame} +	%  +	% As a take away I hope that you are convinced that Tor Browser would +	% benefit from CT. +	% - This was the first part of the presentation. +	% +	% CT would also benefit from more auditing, which we can do here in a secure +	% and privacy-preserving manner because of and how we use Tor. +	% - This was the second part of the presentation. +	% +	% Although not presented here, we show in our paper that the resulting +	% system is also performant based on estimations from two public data sets. +	% +	% An important insight from our work is that pushing the auditing logic +	% away from Tor Browser is important to defend against relevant threats. +	% The simple approach of "just fetching an inclusion proof" does not work. +	% +	% That's it.  Thanks! +	\vfill +	\begin{columns} +		\begin{column}{0.6\textwidth} +			\mktitle{Take away} +			\begin{itemize} +				\item Tor Browser would benefit from CT +				\item CT would benefit from more auditing +				\item Delegated auditing is key in our setting +			\end{itemize} +		\end{column} +		\begin{column}{0.4\textwidth} +			\centering +			\includegraphics[width=.8\columnwidth]{img/thanks} +		\end{column} +	\end{columns} +\end{frame} diff --git a/slides/2021-pets/src/preamble.tex b/slides/2021-pets/src/preamble.tex new file mode 100644 index 0000000..403d146 --- /dev/null +++ b/slides/2021-pets/src/preamble.tex @@ -0,0 +1,112 @@ +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%                                  Packages                                    % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\usepackage[utf8]{inputenc} + +\usepackage[ +  lambda, advantage, operators, sets, adversary, landau, probability, notions, +  logic, ff, mm, primitives, events, complexity, asymptotics, keys +]{cryptocode} + +\usepackage{rotate} +\usepackage{graphicx} +\usepackage{mathtools} +\usepackage{amsmath} +\usepackage{amssymb} +\usepackage{flowchart} +\usepackage{smartdiagram} +\usepackage{wasysym} +\usepackage{graphicx} +\usepackage{color} +\usepackage{drawstack} +\usepackage{tikz} +\usepackage{tikz-qtree} +\usetikzlibrary{ +  arrows,% +  decorations.markings,% +  backgrounds,% +  calc,% +  fit,% +  positioning,% +  shapes.misc,% +  shadows,% +  shapes.arrows,% +  shapes,% +  snakes,% +} +\usepackage{booktabs} +\usepackage{smartdiagram} +%\usepackage{floatrow}% this one causes error on arch for some reason +\usepackage[position=bottom]{subfig}            % environment for nested figures + +\usepackage{xcolor} +\definecolor{darkGreen}{HTML}{008000} +\definecolor{darkBlue}{HTML}{2809B2} +\definecolor{darkRed}{HTML}{CC0000} +\definecolor{darkGray}{HTML}{808080} +\definecolor{darkOrange}{HTML}{D77D00} +\definecolor{darkPurple}{HTML}{800080} +\colorlet{lightGray}{gray!33} +\colorlet{lightYellow}{yellow!50} +\definecolor{darkGreen}{HTML}{008000} +\definecolor{darkBlue}{HTML}{2809B2} +\definecolor{darkRed}{HTML}{CC0000} + +\usepackage{hyperref} +\hypersetup{ +  colorlinks = true,                              % Color links instead of boxes +  urlcolor   = darkBlue,                            % Color external hyper links +  linkcolor  = darkBlue,                                  % Color internal links +  citecolor  = darkBlue,                                       % Color citations +} + +% Figures, tables and code +\usepackage{booktabs} +\usepackage{colortbl} +\usepackage{flowchart} +\usepackage{adjustbox} +\usepackage{listings} + +\lstdefinestyle{CStyle}{ +    backgroundcolor=\color{lightGray!25}, +    commentstyle=\color{darkGreen}, +    keywordstyle=\color{darkBlue}, +    numberstyle=\tiny\color{darkRed}, +    stringstyle=\color{darkPurple}, +    basicstyle=\footnotesize, +    breakatwhitespace=false, +    breaklines=false, +    captionpos=b, +    keepspaces=true, +    numbers=left, +    numbersep=5pt, +    showspaces=false, +    showstringspaces=false, +    showtabs=false, +    tabsize=2, +    language=C, +    morekeywords={size_t,def,in,zip,True,False,ord,u8,u64}, +} + +\setbeamertemplate{itemize item}[circle] +\setbeamertemplate{itemize subitem}[default] +\setbeamertemplate{caption}[numbered] + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +%                                 Defines                                      % +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +\makeatletter +\let\@@magyar@captionfix\relax %needed for \titlefloatright +\makeatother + +\newcommand{\tyes}{\textcolor{darkGreen}{\ding{51}}} +\newcommand{\tno}{\textcolor{darkRed}{\ding{55}}} +\newcommand{\burl}[1]{\tiny{\url{#1}}} +\newcommand{\TODO}[1]{\textcolor{red}{TODO}: #1} +\newcommand{\floatright}[1]{\hspace{0pt plus 1 filll}#1$\;$} + +\def\rding{\rotatebox[origin=c]{-91}{\ding{224}}} +\def\lding{\rotatebox[origin=c]{91}{\ding{224}}} + +% TODO: fix this properly... +\newcommand{\mktitle}[1]{\centering\textbf{\large#1}\vfill\normalsize} diff --git a/slides/2021-pets/src/start.tex b/slides/2021-pets/src/start.tex new file mode 100644 index 0000000..00226e2 --- /dev/null +++ b/slides/2021-pets/src/start.tex @@ -0,0 +1,189 @@ +% +% Title page +% +% Hi everyone.  Welcome to our talk "privacy-preserving and incrementally  +% deployable support for Certificate Transparency in Tor".  I'm Rasmus, a PhD +% student at Karlstad University.  This is joint work together with +% 	Tobias Pulls from Karlstad University, +% 	Tom Ritter from Mozilla, and +%	Paul Syverson from the US Naval Research Laboratory. +% + +\begin{frame} +	% +	% To get started I would like to remind us of the past. +	% +	% The year is 2011.  Summer just arrived, and we are located in the northern +	% parts of Netherlands.  The offices of DigiNotar appear to be operating as +	% usual.  Had we been there at the time, we probably wouldn't have thought +	% they'd be out of business in September. +	% +	\vfill +	\begin{columns} +		\begin{column}{0.45\textwidth} +			\mktitle{A flash-back into the past} +			\begin{itemize} +				\item June, 2011 +				\item Netherlands, Beverwijk +				\item DigiNotar +			\end{itemize} +		\end{column} +		\begin{column}{0.55\textwidth} +			\centering +			\includegraphics[width=\columnwidth]{img/beverwijk} +			\burl{https://creativecommons.org/licenses/by-sa/3.0/} +			% https://commons.wikimedia.org/wiki/File:Nzkanaal2.jpg +		\end{column} +	\end{columns} +\end{frame} + +\begin{frame} +	% +	% What happened? +	%  +	% Let me give you the backdrop. +	% +	% DigiNotar was a so-called certificate authority that issued certificates +	% for the web.  Your browser uses these certificates to verify that you are +	% really visiting the website that you intended to and not some attacker. +	% +	% Sounds great!  What's the catch? +	% Well. +	% You have to trust that no Certificate Authority is going to mess up the +	% certificate issuance process.  Any failure in this process may result in a +	% mis-issued certificate, which in turn may result in insecure connections. +	% +	% Okay.  So, +	% I think most of you know what happened.  DigiNotar was hacked.  They +	% mis-issued certificates for Google, Mozilla, Tor, and many others. +	%	 +	% This was actually detected by DigiNotar. +	% In response, they decided to be silent and cover it up. +	% +	% The main reason why we, the public, detected that DigiNotar was no longer +	% operating in good faith is because of a large scale attack in Iran.  Some +	% of the mis-issued certificates were used to intercept network traffic of +	% 300k gmail users.  Perhaps we were actually lucky to detect the attack at +	% all.  If the attacker had been more stealthy, DigiNotar might still have +	% been in operation today.  That is a scary though.  Can we do better? +	% +	% Fortunately, the answer is yes.  We can do better.  The overall ecosystem +	% improved significantly since 2011.  This talk covers one such improvement: +	% - Certificate Transparency +	% +	\vfill +	\begin{columns} +		\begin{column}{0.45\textwidth} +			\mktitle{What happened?} +			\begin{itemize} +				\item DigiNotar issued web certificates +				\item Did not live up to expectations +				\item Then tried to cover it up\footnotemark +			\end{itemize} +		\end{column} +		\begin{column}{0.55\textwidth} +			\centering +			\includegraphics[width=\columnwidth]{img/diginotar} +			\burl{https://www.bbc.com/news/technology-14989334} +		\end{column} +	\end{columns} +	\vfill +	\pause +	\centering\alert{A stealthy attacker might have gotten away with it!} +	\footnotetext[1]{% +		\tiny{ +			FoxIT. +			Black Tulip: Report of the investigation into the DigiNotar Certificate +				Authority breach. +			Page 3. +		} +	} +\end{frame} + +\begin{frame} +	% +	% Just to make sure that we are on the same page. +	% +	% A large scale attack should not be necessary to detect if a trusted party +	% like DigiNotar misbehaves.  And it is not like we are only talking about a +	% single isolated incident.  The real problem is that we have hundreds of +	% Certificate Authorities that claim to issue certificates only to the +	% rightful domain owners.  Every now and then, someone gets it wrong.  What +	% we are left with is an incident that endangers our digital safety, +	% sometimes even our physical safety depending on the real-world context. +	% +	% What Certificate Transparency brings to the table is the ability to detect +	% mis-issued certificates.  The basic idea is that every issued certificate +	% must be disclosed in a public log that anyone can inspect. +	% +	% Usually, Certificate authorities are the ones doing the logging.  Websites +	% then serve the issued certificate together with some proofs of logging. +	% The browser verifies these proofs before accepting the certificate as +	% valid. +	% +	% This is actually great, because now a website can look for certificates +	% that match their domain name in the log.  If something shows up that they +	% did not ask for - well - now they are aware of that.  They probably +	% wouldn't have been without the log.  In response, you might question the +	% certificate authority, initiate a revocation process, and so forth. +	% +	\vfill +	\begin{columns} +		\begin{column}{0.5\textwidth} +			\mktitle{Larger problem and solution?} +			\begin{itemize} +				\item Digitar was not a one-time incident\footnotemark +				\item Many other parties can get it wrong +				\item Add visibility into issued certificates\footnotemark +			\end{itemize} +		\end{column} +		\begin{column}{0.5\textwidth} +			\input{img/ct} +		\end{column} +	\end{columns} +	\footnotetext[2]{\burl{https://sslmate.com/certspotter/failures}} +	\footnotetext[3]{\burl{https://certificate.transparency.dev/}} +\end{frame} + +\begin{frame} +	% +	% Certificate Transparency, or CT for short, has been - and is still being - +	% gradually rolled-out by Google and others.  For example, every certificate +	% must be CT compliant to validate in Google Chrome and Apple's Safari. +	% +	% CT compliance basically means that at least two logs must have "promised" +	% to make that certificate available to the public.  Such a promise is +	% usually called an SCT and it is hard-coded into the issued certificate. +	%  +	% Browsers currently use SCTs as proofs of logging.  It is possible to +	% verify that these promises are in fact true.  That is an important part to +	% ensure that blind trust is not shifted from Certificate Authorities to CT +	% logs.  However, such verification is challenging because of the added +	% complexity and possible privacy concerns. +	% +	% For example, to verify that a certificate is in fact included in a log, +	% you need to interact with the log ecosystem.  Such interactions leak +	% a user's browsing patterns to the logs and that is kind of problematic. +	% +	\mktitle{Certificate Transparency (CT) compliance\footnotemark} +	\begin{columns} +		\begin{column}{0.25\textwidth} +		\end{column} +		\begin{column}{0.25\textwidth} +			\centering\includegraphics[width=.67\columnwidth]{img/chrome} +		\end{column} +		\begin{column}{0.25\textwidth} +			\centering\includegraphics[width=.7\columnwidth]{img/safari} +		\end{column} +		\begin{column}{0.25\textwidth} +		\end{column} +	\end{columns} +	\vfill +	``Two logs promised that they will make the certificate public'' + +	\footnotetext[4]{% +		\burl{https://github.com/chromium/ct-policy/blob/master/ct_policy.md} +		\& +		\burl{https://support.apple.com/en-us/HT205280}% +	} +\end{frame} diff --git a/slides/2021-pets/src/titlepage.tex b/slides/2021-pets/src/titlepage.tex new file mode 100644 index 0000000..9b18039 --- /dev/null +++ b/slides/2021-pets/src/titlepage.tex @@ -0,0 +1,3 @@ +\begin{frame} +  \titlepage +\end{frame} | 
