diff options
Diffstat (limited to 'slides/2021-pets/src')
| -rw-r--r-- | slides/2021-pets/src/body.tex | 413 | ||||
| -rw-r--r-- | slides/2021-pets/src/end.tex | 34 | ||||
| -rw-r--r-- | slides/2021-pets/src/preamble.tex | 112 | ||||
| -rw-r--r-- | slides/2021-pets/src/start.tex | 189 | ||||
| -rw-r--r-- | slides/2021-pets/src/titlepage.tex | 3 |
5 files changed, 751 insertions, 0 deletions
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} |