diff options
| author | Rasmus Dahlberg <rasmus@rgdd.se> | 2024-10-15 16:08:16 +0200 |
|---|---|---|
| committer | Rasmus Dahlberg <rasmus@rgdd.se> | 2024-10-15 16:08:16 +0200 |
| commit | 385cc92bc91e1a6c3724085c060e76bf40c13ed3 (patch) | |
| tree | 26d0a8f81f2caa472830fd40a51844bb202c1355 /summary/src/ctga | |
Import PhD thesis
Diffstat (limited to 'summary/src/ctga')
22 files changed, 1471 insertions, 0 deletions
diff --git a/summary/src/ctga/.gitignore b/summary/src/ctga/.gitignore new file mode 100644 index 0000000..8bb88c8 --- /dev/null +++ b/summary/src/ctga/.gitignore @@ -0,0 +1,9 @@ +main.pdf +*.blg +*.bbl +*.fls +*.fdb_latexmk +*.log +*.out +*.aux +*.swp diff --git a/summary/src/ctga/img/design.pdf b/summary/src/ctga/img/design.pdf Binary files differnew file mode 100644 index 0000000..3a9aba1 --- /dev/null +++ b/summary/src/ctga/img/design.pdf diff --git a/summary/src/ctga/img/parser.tex b/summary/src/ctga/img/parser.tex new file mode 100644 index 0000000..dba221b --- /dev/null +++ b/summary/src/ctga/img/parser.tex @@ -0,0 +1,66 @@ +\resizebox{\columnwidth}{!}{% +\begin{tikzpicture}[% + -latex, + sibling distance=10em, + level distance=22pt, + parser/.style = {% + draw, + shape=rectangle, + rounded corners, + align=center, + top color=white, + bottom color=mydblue!20, + }, + label/.style = {% + draw=none, + align=center, + text=mydblue, + font=\scriptsize, + }, + arrow/.style = {% + draw, + -latex, + rounded corners, + }, +] + + \node[parser](eth){Ethernet}; + \node[parser,right=of eth](udp){UDP}; + \coordinate(ip) at ($ (eth) !.5! (udp) $); + \node[parser,above=of ip](ipv4){IPv4}; + \node[parser,below=of ip](ipv6){IPv6}; + + \node[parser,right=of udp](dns){DNS}; + \node[parser](dnsp) at ($ (dns) + (1,1.1) $){preamble}; + \node[parser](dnsq) at ($ (dns) + (2.25,.45) $){domain name}; + \node[parser](dnst) at ($ (dns) + (2.25,-.45) $){query type}; + \node[parser](dnsc) at ($ (dns) + (1,-1.1) $){query class}; + + \path[arrow] ($ (eth) + (-1.25,0) $) -- node[left,pos=0]{\texttt{pkt\_in}} (eth); + + \path[arrow] (eth) |- node[label,above left,pos=1]{\texttt{type=0x0800}} (ipv4); + \path[arrow] (eth) |- node[label,below left,pos=1]{\texttt{type=0x86DD}} (ipv6); + \path[arrow] (ipv4) -| node[label,above right, pos=0]{\texttt{proto=0x17}} (udp); + \path[arrow] (ipv6) -| node[label,below right, pos=0]{\texttt{proto=0x17}} (udp); + \path[arrow] (udp) -- node[label,above]{\texttt{sport=53}} (dns); + + \path[arrow,dashed] (dns) |- (dnsp); + \path[arrow,dashed] (dnsp) -| node[label,above right,pos=0]{\texttt{qd=an=1}} (dnsq); + \path[arrow,dashed] (dnsq) -- node[label,right]{\texttt{known log}} (dnst); + \path[arrow,dashed] (dnst) |- node[label,below right,pos=1]{\texttt{TXT}} (dnsc); + \path[arrow,dashed] + (dnsq) edge[out=5, in=355, looseness=8] + node[label,right]{ + \begin{tabular}{c} + variable \\ + length + \end{tabular} + } + (dnsq); + \path[arrow,dashed] + (dnsc) -- + node[label,below right,pos=.8]{\texttt{IN}} + node[pos=1.2,rotate=90]{\texttt{clone}} + ($ (dnsc) + (-1.5,0) $); +\end{tikzpicture} +} diff --git a/summary/src/ctga/img/perf-netfpga.pdf b/summary/src/ctga/img/perf-netfpga.pdf Binary files differnew file mode 100644 index 0000000..309a689 --- /dev/null +++ b/summary/src/ctga/img/perf-netfpga.pdf diff --git a/summary/src/ctga/img/perf-xdp.pdf b/summary/src/ctga/img/perf-xdp.pdf Binary files differnew file mode 100644 index 0000000..041cbdd --- /dev/null +++ b/summary/src/ctga/img/perf-xdp.pdf diff --git a/summary/src/ctga/img/pl.pdf b/summary/src/ctga/img/pl.pdf Binary files differnew file mode 100644 index 0000000..0b39f91 --- /dev/null +++ b/summary/src/ctga/img/pl.pdf diff --git a/summary/src/ctga/img/ps.pdf b/summary/src/ctga/img/ps.pdf Binary files differnew file mode 100644 index 0000000..cf3db16 --- /dev/null +++ b/summary/src/ctga/img/ps.pdf diff --git a/summary/src/ctga/img/related.tex b/summary/src/ctga/img/related.tex new file mode 100644 index 0000000..31a86e8 --- /dev/null +++ b/summary/src/ctga/img/related.tex @@ -0,0 +1,37 @@ +\resizebox{1\columnwidth}{!}{% + \begin{tikzpicture}[% + ns/.style = { + draw=none, + }, + ps/.style = { + draw, + -latex, + }, + ] + \node[ns](gossip){}; + \node[ns,right=0pt of gossip](retroactive){\textbf{Retroactive}}; + \node[ns,left=0pt of gossip](proactive){\textbf{Proactive}}; + + % proactive + \node[ns,left=12pt of proactive](cross){STH cross-logging~\cite{minimal-gossip,ietf-cross-logging,hof-cross-logging,catena}}; + \node[ns,above=0pt of cross](push){STH pushing~\cite{google-gossip}}; + \node[ns,below=0pt of cross](cosi){STH cosigning~\cite{cosi}}; + + \path[ps] (proactive) -- (push.east); + \path[ps] (proactive) -- (cross); + \path[ps] (proactive) -- (cosi.east); + + % retroactive + \node[ns,right=12pt of retroactive](implicit){Implicit via multipath~\cite{mpaudit}}; + \node[ns,above=0pt of implicit](pool){STH pooling~\cite{chuat-gossip,ietf-gossip}}; + \node[ns,below=0pt of implicit](trust){Trusted auditing~\cite{ietf-gossip}}; + \node[ns,above=14pt of retroactive.north east](feedback){SCT feedback~\cite{ietf-gossip}}; + \node[ns,below=14pt of retroactive.south east](bee){CT honey bee~\cite{ct-honey-bee}}; + + \path[ps] (retroactive) -- (feedback); + \path[ps] (retroactive) -- (pool.west); + \path[ps] (retroactive) -- (implicit); + \path[ps] (retroactive) -- (trust.west); + \path[ps] (retroactive) -- (bee); + \end{tikzpicture} +} diff --git a/summary/src/ctga/img/wcov-goo.pdf b/summary/src/ctga/img/wcov-goo.pdf Binary files differnew file mode 100644 index 0000000..976e5bd --- /dev/null +++ b/summary/src/ctga/img/wcov-goo.pdf diff --git a/summary/src/ctga/img/wcov-nor.pdf b/summary/src/ctga/img/wcov-nor.pdf Binary files differnew file mode 100644 index 0000000..110cf88 --- /dev/null +++ b/summary/src/ctga/img/wcov-nor.pdf diff --git a/summary/src/ctga/main.tex b/summary/src/ctga/main.tex new file mode 100644 index 0000000..bc5ff45 --- /dev/null +++ b/summary/src/ctga/main.tex @@ -0,0 +1,70 @@ +\begin{kaupaper}[ + author={% + \textbf{Rasmus Dahlberg}, + Tobias Pulls, + Jonathan Vestin, + Toke H{\o}iland-J{\o}rgensen, and + Andreas Kassler + }, + title={% + Aggregation-Based Certificate Transparency Gossip + }, + reference={% + SECURWARE (2019) + }, + summary={% + Another often overlooked part of Certificate Transparency is that monitors + and end-users who browse websites must observe the same append-only + logs. For example, if the same append-only logs are not observed, an + end-user may connect to a website that serves a mis-issued certificate + that no monitor will discover. This would largely defeat the purpose of + public logging, which is why RFC~6962 specifies that multiple gossip + protocols should be defined separately in the future. We define one such + protocol that plugs into the (at the time current) idea of having + end-users interact with the logs through DNS. Our work is exploratory, + using recent advancements in programmable packet processors that allow + turning routers, switches, and network interface cards into + \emph{aggregators} of tree heads that the logs signed and transmitted in + plaintext via DNS. The aggregated tree heads are then used as a reference + while challenging the logs to prove consistency, thus protecting + entire vantage points from undetected split views. A different + network path (like Tor) can be used to break out of a local vantage point + to increase the likelihood of global consistency. If the security + definition for \emph{aggregation indistinguishability} is satisfied, + vantage points without an aggregator may also receive protection due to + herd immunity. Our P4 and XDP prototypes satisfy the notion of + aggregation indistinguishability at line-rate with regard to throughput. + Prevalent vantage points to roll out aggregation-based gossip include + autonomous systems and Internet exchange points that route the traffic of + many users. Our RIPE Atlas measurements show that 32 autonomous systems + could protect 30-50\% of the IPv4 space from undetected split views. + End-users merely need to use plaintext DNS for opt-in. + }, + participation={\vspace{-.25cm} + Andreas and Tobias had the initial idea of exploring the intersection + between Certificate Transparency and programmable packet processors. I did most of the + design and writing with feedback from Tobias, our RIPE Atlas measurements, + and our performance benchmarks with Jonathan and Toke. + }, + label={ + paper:ctga + }, +] + \maketitle + \begin{abstract} + \input{src/ctga/src/abstract} + \end{abstract} + + \input{src/ctga/src/introduction} + \input{src/ctga/src/background} + \input{src/ctga/src/design} + \input{src/ctga/src/implementation} + \input{src/ctga/src/measurements} + \input{src/ctga/src/related} + \input{src/ctga/src/discussion} + \input{src/ctga/src/conclusion} + \input{src/ctga/src/acknowledgments} + + \bibliographystyle{plain} + \bibliography{src/ctga/src/ref} +\end{kaupaper} diff --git a/summary/src/ctga/src/abstract.tex b/summary/src/ctga/src/abstract.tex new file mode 100644 index 0000000..5483f7e --- /dev/null +++ b/summary/src/ctga/src/abstract.tex @@ -0,0 +1,16 @@ +\noindent +Certificate Transparency (CT) requires that every certificate which is issued by +a certificate authority must be publicly logged. While a CT log can be +untrusted in theory, it relies on the assumption that every client observes and +cryptographically verifies the same log. As such, some form of gossip mechanism +is needed in practice. Despite CT being adopted by several major browser +vendors, no gossip mechanism is widely deployed. +We suggest an aggregation-based gossip mechanism that passively observes +cryptographic material that CT logs emit in plaintext, aggregating at packet +processors (such as routers and switches) to periodically verify log consistency +off-path. In other words, gossip is provided as-a-service by the network. Our +proposal can be implemented for a variety of programmable packet processors at +line-speed without aggregation distinguishers (throughput), and based on +20 days of RIPE Atlas measurements that represent clients from 3500 autonomous +systems we show that significant protection against split-viewing CT logs can be +achieved with a realistic threat model and an incremental deployment scenario. diff --git a/summary/src/ctga/src/acknowledgments.tex b/summary/src/ctga/src/acknowledgments.tex new file mode 100644 index 0000000..a35331b --- /dev/null +++ b/summary/src/ctga/src/acknowledgments.tex @@ -0,0 +1,5 @@ +\section*{Acknowledgements} +We would like to thank Stefan Alfredsson and Philipp Winter for their RIPE Atlas +credits, as well as Jonas Karlsson and Ricardo Santos for helping with the +NetFPGA setup. We also received funding from the HITS research profile which is +funded by the Swedish Knowledge Foundation. diff --git a/summary/src/ctga/src/background.tex b/summary/src/ctga/src/background.tex new file mode 100644 index 0000000..e924d57 --- /dev/null +++ b/summary/src/ctga/src/background.tex @@ -0,0 +1,90 @@ +\section{Background} \label{ctga:sec:background} +First additional prerequisites are provided on CT and the status quo, +then the techniques which allow us to program custom packet processors are +introduced. + +\subsection{Certificate Transparency} \label{ctga:sec:background:ct} +The main motivation of CT is that the CA ecosystem is error-prone~\cite{laurie}: + a CA can normally issue certificates for \emph{any} domain name, and + given that there are hundreds of trusted CAs an attacker only needs to + target the weakest link~\cite{ca-ecosystem}. +While the requirement of CT logging all certificates cannot prevent mis-issuance +proactively, it allows anyone to detect it retroactively by monitoring the +logs~\cite{ct}. After a log promises to include a certificate by issuing a +Signed Certificate Timestamp (SCT), a new STH including the appended certificate +must be issued within a Maximum Merge Delay (MMD). Typically, logs use 24~hour +MMDs. Should non-included SCTs and/or inconsistent STHs be found, +binding evidence of misbehaviour exists because these statements are +digitally signed by the logs. Other than MMD a log's policy defines parameters +such as STH frequency: + the number of STHs that can be issued during an MMD, making it harder to + track clients~\cite{ietf-gossip}. + +CT is being deployed across Apple's platform~\cite{apple-ct} and Google's +Chrome~\cite{google-ct}. The status quo is to trust a CA-signed certificate if +it is accompanied by two or more SCTs, thereby relying on at least one log to +append each certificate so that mis-issuance can be detected by monitors that +inspect the logs. The next step of this incremental deployment is to +\emph{verify} that these certificates are logged by querying for +inclusion~\cite{google-gossip}, and that the log's append-only property is +respected by challenging the log to prove STH consistency. Finally, to fully +distrust CT logs we need mechanisms that detect split-views. One such mechanism +which is based on programmable packet processors (introduced next) is presented +in Section~\ref{ctga:sec:design}, and it is compared to related work on CT gossip in +Section~\ref{ctga:sec:related}. + +\subsection{Programmable Data Planes} \label{ctga:sec:background:pdp} +Packet processors such as switches, routers, and network interface cards +are typically integrated tightly using customized hardware and application-% +specific integrated circuits. This inflexible design limits the +potential for innovation and leads to long product upgrade cycles, where it +takes \emph{years} to introduce new processing capabilities and support for +different protocols and header fields (mostly following lengthy +standardization cycles). +The recent shift towards flexible \emph{match+action} packet-processing +pipelines---including + RMT~\cite{rmt}, + Intel Flexpipe~\cite{flexpipe}, + Cavium XPA~\cite{cavium}, and + Barefoot Tofino~\cite{barefoot}---% +now have the potential to change the way in which packet processing hardware is +implemented: + it enables programmability using high-level languages, such as P4, + while at the same time maintaining performance comparable to fixed-function + chips. + +\subsubsection{P4} +The main goal of P4 is to simplify + \barbelow{p}rogramming of + \barbelow{p}rotocol-independent + \barbelow{p}acket + \barbelow{p}rocessors +by providing an abstract programming model for the network data plane~\cite{p4}. +In this setting, the functionality of a packet processing device is specified +without assuming any hardwired protocols and headers. Consequently, a P4 program +must parse headers and connect the values of those protocol fields to the +actions that should be executed based on a pipeline of reconfigurable +match+action tables. +Based on the specified P4 code, a front-end compiler generates a high-level +intermediate representation that a back-end compiler uses to create a target-% +dependent program representation. Compilers are available for several platforms, +including + the software-based simple switch architecture~\cite{p4bm}, + SDNet for Xilinx NetFPGA boards~\cite{p4netfpga}, and + Netronome's smart network interfaces~\cite{p4netronome}. +It is also possible to compile basic P4 programs into eBPF byte +code~\cite{p42ebpf}. + +\subsubsection{XDP} +The Berkeley Packet Filter (BPF) is a Linux-based packet filtering +mechanism~\cite{bpf}. Verified bytecode is injected from user space, and +executed for each received packet in kernel space by a just-in-time compiler. +Extended BPF (eBPF) +enhances the original BPF concept, enabling faster runtime and many new +features. For example, an eBPF program can be attached to the Linux traffic +control tool \texttt{tc}, and additional hooks were defined for a faster eXpress +Data Path (XDP)~\cite{xdp}. In contrast to the Intel Data Plane Development Kit +(DPDK), which runs in user space and completely controls a given network +interface that supports a DPDK driver, XDP cooperates with the Linux stack to +achieve fast, programmable, and reconfigurable packet processing using C-like +programs. diff --git a/summary/src/ctga/src/conclusion.tex b/summary/src/ctga/src/conclusion.tex new file mode 100644 index 0000000..f001ace --- /dev/null +++ b/summary/src/ctga/src/conclusion.tex @@ -0,0 +1,23 @@ +\section{Conclusion and Future Work} \label{ctga:sec:conclusion} +Wide spread modifications of TLS clients are inevitable to support CT gossip. +We propose that these modifications include challenging the logs to +prove certificate inclusion based on STHs \emph{fetched in plaintext}, thereby +enabling the traversed packet processors to assist in split view detection +retroactively by aggregating STHs for periodic off-path verification. Our +results show that the aggregation-step can be implemented without throughput-% +based distinguishers for a distant attacker, and that our approach offers rapid +incremental deployment with high impact on a significant fraction of Internet +users. Beyond being an application neutral approach that is complementary to +proactive gossip, a compelling aspect is that core packet processors are used +(rather than clients) as a key building block: + should a consistency issue arise, it is already in the hands of an actor + that is better equipped to investigate the cause manually. +Further, considering that far from all TLS clients are backed by big browser +vendors (not to mention other use-cases of transparency logs in general) it is +likely a long-term win to avoid pushing complex retroactive gossip logic into +all the different types of clients when there are orders of magnitudes fewer +packet processors that could aggregate to their own off-path challengers. +Future work includes different instantiations of the aggregation step and +evaluating whether aggregation indistinguishability is provided based on +throughput and/or latency. The setting may also change in some scenarios, +e.g., if DNS caches are aggregated the transport need not be plaintext. diff --git a/summary/src/ctga/src/design.tex b/summary/src/ctga/src/design.tex new file mode 100644 index 0000000..a04e36b --- /dev/null +++ b/summary/src/ctga/src/design.tex @@ -0,0 +1,129 @@ +\section{Design} \label{ctga:sec:design} +An overview of aggregation-based gossip is shown in Figure~\ref{ctga:fig:agg}. The +setting consists of logs that send plaintext STHs to clients over a network, and +as part of the network inline \emph{packet processors} passively aggregate +observed STHs to their own off-path \emph{challengers} which challenge the logs +to prove consistency. A log cannot present split views to different clients that +share an aggregating vantage point because it would trivially be detected by +that vantage point's challenger. A log also cannot present a persistent split +view to different challengers because they are off-path in the sense that they +are indistinguishable from one another. This means that every client that is +covered by an aggregator must be on the same view because at least one +challenger will otherwise detect an inconsistency and report it. A client that +is not directly covered by an aggregator may receive indirect protection in the +form of herd immunity. This is discussed in Section~\ref{ctga:sec:discussion:herd}. +\begin{figure}[!t] + \centering + \includegraphics[width=\columnwidth]{src/ctga/img/design.pdf} + \caption[ ]{% + Packet processor that aggregates plaintext STHs for off-path verification. + } + \label{ctga:fig:agg} +\end{figure} + +\subsection{Threat Model and Security Notion} \label{ctga:sec:agg:thr} +The overarching threat is undetectable domain impersonation (ex-post) by an +attacker that is capable of compromising at least one CA and a sufficient number +of CT logs to convince a client into accepting a forged certificate. +We assume that any illegitimately issued certificate +would be detected by the legitimate domain owner through self or delegated +third-party monitoring. +This means that an attacker must either provide a split view towards the victim +or the monitoring entity. +We also assume that clients query the logs for certificate inclusion based on +STHs that they acquire from the logs via plaintext mechanisms that packet +processors can observe, and that some other entities than challengers process +STHs using the chosen off-paths (Section~\ref{ctga:sec:discussion:limitations}). +We do not account for the fact that CA compromises may be detected by other +means, focusing solely on split-viewing CT logs. + +\subsubsection{Limitations} +Our gossip mechanism is limited to STHs that packet processors can observe. +As such, a client isolated by an attacker is not protected. We limit ourselves +to attackers that act over a network some distance +(in the sense of network path length) from a client in plaintext so that +aggregation can take place. Our limitations and assumptions are further +discussed in Section~\ref{ctga:sec:discussion:limitations}. + +\subsubsection{Attackers} +Exceptionally powerful attackers can isolate clients, \emph{but clients are not +necessarily easy to isolate} for a significant number of relevant attackers. +Isolation may require physical control over a device~\cite{fbi-apple}, +clients may be using anonymity networks like Tor where path selection is +inherently unpredictable~\cite{tor}, or sufficiently large parts of the network +cannot be controlled to ensure that no aggregation takes place. +This may be the case if we consider + a nation state actor attacking another nation state actor, + the prevalence of edge security middleboxes, and + that home routers or NICs nearby the clients could aggregate. +Any attacker that cannot account for these considerations is within our +threat model. + +\subsubsection{Security Notion} +To bypass our approach towards gossip an adaptive attacker may attempt to +actively probe the network for aggregating packet processors. This leads us to +the key security notion: + \emph{aggregation indistinguishability}. +An attacker should not be able to determine if a packet processor is aggregating +STHs. The importance of aggregation indistinguishability motivates the design of +our gossip mechanism into two distinct components: + aggregation that takes place inline at packet processors, and + periodic off\mbox{-}path log challenging that checks whether the observed STHs + are consistent. + +\subsection{Packet Processor Aggregation} \label{ctga:sec:aggregator} +An aggregating packet-processor determines for each packet if it is STH-related. +If so, the packet is cloned and sent to a challenging component for off-path +verification. +The exact definition of \emph{STH-related} depends on the plaintext source, but it +is ultimately the process of inspecting multiple packet headers such as +transport protocol and port number. It should be noted that the original packet +must not be dropped or modified. For example, an aggregator would have a +trivial aggregation distinguisher if it dropped any malformed STH. + +For each aggregating packet processor we have to take IP fragmentation into +consideration. Recall that IP fragmentation usually occurs when a packet is +larger than the MTU, splitting it into multiple smaller IP packets that are +reassembled at the destination host. Normally, an STH should not be fragmented +because it is much smaller than the de-facto minimum MTU of (at least) 576~% +bytes~\cite{min-mtu,ipv6}, but an attacker could use fragmentation to +\emph{intentionally} spread expected headers across multiple packets. +Assuming stateless packet processing, an aggregator cannot identify +such fragmented packets as STH-related because some header would be absent + (cf.\ stateless firewalls). +All tiny fragments should therefore be aggregated to account for intentional IP +fragmentation, which appears to have little or no impact on normal traffic +because tiny fragments are anomalies~\cite{frag-study-02}. The threat of +multi-path fragmentation is discussed in Section~\ref{ctga:sec:discussion:limitations}. + +Large traffic loads must also be taken into account. If an aggregating +packet processor degrades in performance as the portion of STH-related traffic +increases, a distant attacker may probe for such behaviour to determine if a +path contains an aggregator. Each \emph{implementation} must therefore be +evaluated individually for such behaviour, and if trivial aggregation +distinguishers exist this needs to be solved. For example, STH-related traffic +could be aggregated probabilistically to reduce the amount of work. +Another option is to load-balance the traffic before aggregation, i.e., avoid +worst-case loads that cannot be handled. + +\subsection{Off-Path Log Challenging} \label{ctga:sec:challenger} +A challenger is setup to listen for aggregated traffic, reassembling IP +fragments and storing the aggregated STHs for periodic off-path verification. +Periodic off\mbox{-}path verification means that the challenger challenges the log +based on its own (off-path fetched) STHs and the observed (aggregated) STHs to +verify log consistency periodically, e.g., every day. +The definition of \emph{off-path} is that the challenger must not be linkable to +its aggregating packet processor(s) or any other challenger (including itself). +Without an off-path there is no gossip step amongst aggregator-challenger +instances that are operated by different actors, and our approach towards gossip +would only assert that clients behind the same vantage point observe the same +logs. If a log cannot distinguish between different challengers due to the +use of off-paths, however, it is non-trivial to maintain a targeted split-view +towards an unknown location. Therefore, we get a form of \emph{implicit +gossip}~\cite{mpaudit} because at least one challenger would detect an +inconsistency unless everybody observes the same log. If every challenger +observes the same log, so does every client that is covered by an aggregating +packet processor. Notably the challenger component \emph{does not run inline} +to avoid timing distinguishers. Note that there are other important +considerations when implementing a challenger, as discussed in +Section~\ref{ctga:sec:discussion:limitations}. diff --git a/summary/src/ctga/src/discussion.tex b/summary/src/ctga/src/discussion.tex new file mode 100644 index 0000000..3a542d1 --- /dev/null +++ b/summary/src/ctga/src/discussion.tex @@ -0,0 +1,126 @@ +\section{Discussion} \label{ctga:sec:discussion} +Next we discuss assumptions, limitations and deployment, showing that +our approach towards retroactive gossip can be deployed to detect +split-views by many relevant attackers with relatively little effort. The +main drawback is reliance on clients fetching STHs in plaintext, e.g., using +CT-over-DNS~\cite{ct-over-dns}. + +\subsection{Assumptions and Limitations} \label{ctga:sec:discussion:limitations} +Aggregation-based gossip is limited to network traffic that packet processors +can observe. The strongest type of attacker in this setting---who can completely +isolate a client---trivially defeats our gossip mechanism and other retroactive +approaches in the literature (see Section~\ref{ctga:sec:related}). +A weaker attacker cannot isolate a client, but is located nearby in a network +path length sense. This limits the opportunity for packet processor aggregation, +but an attacker cannot rule it out given aggregation indistinguishability. +Section~\ref{ctga:sec:implementation} showed based on performance that it is non-% +trivial to distinguish between (non\mbox{-})aggregating packet processors on two +different targets using P4 and XDP. Off-path challengers must also be +indistinguishable from one another to achieve \emph{implicit gossip}. +While we suggested the use of anonymity networks like Tor, a prerequisite is +that this is in and of itself not an aggregation distinguisher. +Therefore, we assume that other entities also use off-paths to fetch and verify +STHs. The fact that a unique STH \emph{is not audited} from an off-path could +also be an aggregation distinguisher. To avoid this we could rely on a +verifiable STH history~\cite{ver-sth} +and wait until the next MMD to audit or simply monitor the full log so that +consistency proofs are unnecessary. + +The existence of multiple network paths are fundamental to the structure and +functioning of the Internet. A weak attacker may use IP fragmentation such that +each individual STH fragment is injected from a different location to make +aggregation harder, approaching the capabilities of a stronger attacker that +is located closer to the client. This is further exacerbated by the deployment +of multi-path transport protocols like MPTCP (which can also be fragmented). +Looking back at our RIPE Atlas measurements in Section~\ref{ctga:sec:measurements}, the +results towards Google's world-wide infrastructure better represent an active +attacker that takes \emph{some} measures to circumvent aggregation by +approaching a client nearby the edge. Given that the likelihood of aggregation +is high if \emph{any} IXP is present (Figure~\ref{ctga:fig:wcov}), aggregation at +well-connected IXPs are most likely to be circumvented. + +\subsection{Deployment} \label{ctga:sec:disussion:deployment} +Besides aggregating at strategic locations in the Internet's backbone, +ISPs and enterprise networks have the opportunity to protect all of their +clients with relatively little effort. Deployment of special-purpose middleboxes +are already prevalent in these environments, and then the inconvenience of +fragmentation tends to go away due to features such as packet reassembly. +Further, an attacker cannot trivially circumvent the edge of a network topology% +---especially not if aggregation takes place on an end-system: + all fragments are needed to reassemble a packet, which means that multi-path + fragmentation is no longer a threat. +If aggregation-based gossip is deployed on an end-system, STHs could be +hooked using other approaches than P4/XDP. For example, shim-layers that +intercept TLS certificates higher up in the networking stack were already +proposed by Bates~\emph{et~al.}~\cite{h1} and O'Neill~\emph{et~al.}~\cite{h2}. +In this setting, an end-system is viewed as the aggregating packet processor, +and it reports back to an off-path challenger that may be a local process +running on the same system or a remote entity, e.g., a TelCo could host +challengers that collect aggregated STHs from smartphones. + +While we looked at programming physical packet processors like routers, +STH aggregation could be approached in hypervisors and software +switches~\cite{pisces} to protect many virtual hosts. If CT-over-DNS is used to +fetch STHs, it would be promising to output DNS server caches to implement the +aggregation step. Similar to DNS servers, so called Tor exist relays also +operate DNS caches. In other words, P4 and XDP are only examples of how to +\emph{instantiate} the aggregation step. Depending on the used plaintext source, +packet processor, and network topology other approaches may be more suitable, +e.g., C for vendor-specific middleboxes. + +\subsection{Retroactive Gossip Benefits From Plaintext} +As opposed to an Internet core that only forwards IP packets, extra +functionality is often embedded which causes complex processing dependencies and +protocol ossification~\cite{TCPoss}. Many security and protocol issues were +found for middleboxes that provides extra +functionality~\cite{HTTPSintercept,langely-quic}, resulting in the mindset +that \emph{everything} should be encrypted~\cite{langely-quic}. +Our work is controversial because it goes against this mindset and advocates +that STHs should be communicated in plaintext. +We argue that this makes sense in the context of STHs due to the absence of +privacy concerns and because the entire point of gossip is to make STHs +\emph{available} (rather than end-to-end). +The idea of intentionally exposing information to the network is not new, e.g., +MPQUIC is designed to support traffic shaping~\cite{mpquic}. + +While we used CT-over-DNS as a plaintext source, there is a push towards +DNS-over-TLS~\cite{dot} and DNS-over-HTTPS~\cite{doh}. +Wide use of these approaches could undermine our gossip mechanism, but +ironically the security of TLS could be jeopardized unless gossip is deployed. +In other words, long term gossip is an essential component of CT and other +transparency logs to avoid becoming yet another class of trusted third-parties. +If proactive approaches such as witness cosigning are rejected in favour of +retroactive mechanisms, then ensuring that STHs are widely spread and easily +accessible is vital. An STH needs no secrecy if the appropriate measures are +taken to make it privacy-insensitive~\cite{ietf-gossip}. +While secure channels also provide integrity and replay protection, an STH is +already signed by logs and freshness is covered by MMDs, as well as issue +frequency to protect privacy. +A valid argument against exposing any plaintext to the network is protocol +ossification. We emphasize that our design motivates why packet processors +should fail open: + otherwise there is no aggregation indistinguishability. +Note that there are other plaintext sources than CT-over-DNS that could be +aggregated. However, if these sources require stream-reassembly it is +generally hard to process in languages such as P4 and XDP~\cite{ctga-thesis}. + +\subsection{Indistinguishability and Herd Immunity} \label{ctga:sec:discussion:herd} +An attacker that gains control over a CT log is bound to be more risk averse +than an attacker that compromises a CA. There is an order of magnitude fewer +logs than CAs, and client vendors are likely going to be exceptionally picky +when it comes to accepted and rejected logs. +We have already seen examples of this, including Google Chrome disqualifying +logs that made mistakes: + Izenpe used the same key for production and testing~\cite{izenpe}, and + Venafi suffered from an unfortunate power outage~\cite{venafi}. +Risk averse attackers combined with packet processors that are aggregation +indistinguishable may lead to \emph{herd immunity}: despite a significant +fraction of clients that lack aggregators, indirect protection may be provided +because the risk of eventual detection is unacceptable to many attackers. Hof +and Carle~\cite{hof-cross-logging} and Nordberg \emph{et~al.}~\cite{ietf-gossip} +discussed herd immunity~briefly~before~us. +While herd immunity is promising, it should be noted that aggregation +distinguishable packet processors at \emph{the edge of a network topology} may +be acceptable for some. In other words, if an aggregator cannot be circumvented +but it is detectable split-views would still be deterred against covered +clients if the challenger is off-path. diff --git a/summary/src/ctga/src/implementation.tex b/summary/src/ctga/src/implementation.tex new file mode 100644 index 0000000..9a35cfe --- /dev/null +++ b/summary/src/ctga/src/implementation.tex @@ -0,0 +1,82 @@ +\section{Distinguishability Experiments} \label{ctga:sec:implementation} +There are many different ways to implement the aggregation step. We decided to +use P4 and XDP because a large variety of programmable +packet processors support these languages (Section~\ref{ctga:sec:background:pdp}). +The aggregated plaintext source is assumed to be CT-over-DNS~\cite{ct-over-dns}, +which means that a client obtains STHs by fetching IN TXT resource records. +Since languages for programmable packet processors are somewhat restricted, +we facilitated packet processing by requiring that at most one STH is sent per +UDP packet. +This is reasonable because logs should only have one \emph{most recent} STH. +A DNS STH is roughly 170~bytes without any packet headers and +should normally not be fragmented, but to ensure that we do not miss any +intentionally fragmented STHs we aggregate every tiny fragment. We did not +implement the challenging component because it is relatively easy given +an existing off-path. Should any scalability issue arise for the challenger +there is nothing that prevents a distributed front-end that processes the +aggregated material before storage. Storage is not an issue because there are +only a limited amount of unique STHs per day and log + (one new STH per hour is a common policy, and browsers recognize $\approx 40$ + logs). +Further implementation details can be found +online~\cite{github,full-version}. + +\subsection{Setup} +We used a test-bed consisting of + a traffic generator, + a traffic receiver, and + an aggregating target in between. +The first target is a P4-enabled NetFPGA SUME board that runs an adapted version +of our P4 reference implementation. +The second target is a net-next kernel v4.17.0-rc6 Linux machine that runs XDP +on one core with + a 10~Gb SFP+ X520 82599ES Intel card, + a $3.6$~GHz Intel Core i7-4790 CPU, and + 16~GB of RAM at 1600~MHz (Hynix/Hyundai). +We would like to determine whether there are any aggregation distinguishers as +the fraction of STHs (experiment 1) and tiny fragments (experiment 2) in the +traffic is increased from 0--100\%, i.e., does performance degrade as a +function of STH-related rate? Non-fragmented STH packets are +411~bytes + (we used excessively large DNS headers to maximize the packet parsing + overhead), +and tiny fragments are 64~bytes. All background traffic have the same packet +sizes but is not deemed STH-related. + +\subsection{Results} +Figure~\ref{ctga:fig:perf-p4} shows throughput as a function of STH-related rate for +the P4-enabled NetFPGA. While we were unable to observe any distinguisher between +normal routing and the edge case of 100\% aggregation for +non-fragmented STH packets, there is a small constant throughput difference for +tiny fragments ($7.5$~Kbps). This is a non-negligible \emph{program +distinguisher} if a packet processor is physically isolated as in our benchmark, +i.e., something other than a routing program is running but it is not +necessarily an aggregator because performance does not degrade as a function +of increased STH-related rate. However, we found such degradation behaviour for the +single-core XDP case (Figure~\ref{ctga:fig:perf-xdp}). If line-speed is higher than +2~Gbps, STHs could be aggregated probabilistically or traffic could be load-% +balanced to \emph{overcome} this issue. +\begin{figure}[!t] + \centering + \begin{subfigure}[b]{.8\textwidth} + \includegraphics[width=\textwidth]{src/ctga/img/perf-netfpga} + \caption{P4 NetFPGA} + \label{ctga:fig:perf-p4} + \end{subfigure} + + \begin{subfigure}[b]{.8\textwidth} + \includegraphics[width=\textwidth]{src/ctga/img/perf-xdp} + \caption{XDP on a single core} + \label{ctga:fig:perf-xdp} + \end{subfigure} + \caption{% + Throughput as a function of STH-related traffic that is aggregated. + } + \label{ctga:fig:perf} +\end{figure} + +\subsection{Lessons Learned} +P4-NetFPGA provides aggregation indistinguishability regardless of STH load. +For XDP, it depends on the scenario: what is the line-rate criteria and how many +cores are available. For example, five cores support 10~Gbps aggregation +indistinguishability without probabilistic filtering or load balancing. diff --git a/summary/src/ctga/src/introduction.tex b/summary/src/ctga/src/introduction.tex new file mode 100644 index 0000000..248785e --- /dev/null +++ b/summary/src/ctga/src/introduction.tex @@ -0,0 +1,93 @@ +\section{Introduction} \label{ctga:sec:introduction} +The HyperText Transfer Protocol Secure (HTTPS) ecosystem is going through a paradigm shift. As opposed to blindly +trusting that Certificate Authorities (CAs) only issue certificates to the +rightful domain owners% + ---a model known for its weakest-link security~\cite{ca-ecosystem}---% +transparency into the set of issued certificates is incrementally being +required by major browser vendors~\cite{apple-ct,google-ct}. This transparency +is forced and takes the form of Certificate Transparency (CT) logs: + the idea is to reject any TLS certificate that have yet to be publicly logged, + such that domain owners can monitor the logs for client\mbox{-}accepted certificates + to \emph{detect} certificate mis-issuance \emph{after the fact}~\cite{ct}. +While the requirement of certificate logging is a significant improvement to the +HTTPS ecosystem, the underlying problem of trusting CAs cannot be solved by the +status quo of trusted CT logs (described further in +Section~\ref{ctga:sec:background:ct}). Therefore, it is paramount that nobody +needs to trust these logs once incremental deployments are matured. + +CT is formalized and cryptographically verifiable~\cite{ct-formal}, supporting +inclusion and consistency proofs. +This means that a client can verify whether a log is +operated correctly: + said certificates are included in the log, and + nothing is being removed or modified. +Despite the ability to cryptographically verify these two properties, there are +no assurances that everybody observes \emph{the same +log}~\cite{chuat-gossip,ct}. For example, certificate mis-issuance would +not be detected by a domain owner that monitors the logs if fraudulently issued +certificates are shown to the clients selectively. A log that serves different +versions of itself is said to present a \emph{split view}~\cite{ietf-gossip}. +Unless such log misbehaviour can be detected, we must trust it not to happen. + +The solution to the split viewing problem is a gossip mechanism which ensures +that everybody observes \emph{the same} consistent log~\cite{ct}. This +assumption is simple in theory but remarkably hard in practice due to + client privacy, + varying threat models, and + deployment challenges~\cite{ietf-gossip,cosi}. +While Google started on a package that supports + minimal gossip~\cite{minimal-gossip} and + the mechanisms of Nordberg \emph{et~al.}~\cite{ietf-gossip}, +there is ``next to no deployment in the wild''~\cite{little-or-no-gossip}. +To this end, we propose a gossip mechanism that helps detecting split-view +attacks retroactively based on the idea of packet processors, such as routers +and middleboxes, that \emph{aggregate} Signed Tree Heads (STHs)---succinct +representations of the logs' states---that are exposed to the network \emph{in +plaintext}. +The aggregated STHs are then used to challenge the logs to prove consistency +via an off-path, such that the logs cannot distinguish between challenges that +come from different aggregators. Given this indistinguishability assumption, it +is non-trivial to serve a consistent split-view to an unknown +location~\cite{mpaudit}. Thus, all aggregators must be on the same view, and +accordingly all clients that are covered by these aggregators must also be on +the same view \emph{despite not doing any explicit gossip themselves} because +gossip is provided as-a-service by the network. An isolated client (i.e., +untrusted network path to the aggregator) is notably beyond reach of any +retroactive gossip~\cite{cosi}. + +The premise of having STHs in plaintext is controversial given current trends to +encrypt transport protocols, which is otherwise an approach that combats +inspection of network traffic and protocol +ossification~\cite{HTTPSintercept,TCPoss}. We argue that keeping gossip +related material in plaintext to support aggregation-based gossip comes with few +downsides though: + it is easy to implement, + there are no major negative privacy impacts, and + it would offer significant protection for a large portion of the Internet + with a realistic threat model \emph{despite relatively small deployment + efforts}. +The three main limitations are + no protection against isolated clients, + reliance on clients that fetch STHs from the logs in plaintext, and + possible concerns surrounding protocol ossification~\cite{TCPoss}. +Our contributions are: +\begin{itemize} + \item Design and security considerations for a network-based gossip mechanism + that passively aggregates STHs to verify log consistency off-path + (Section~\ref{ctga:sec:design}). + \item Generic implementations of the aggregation step using P4~\cite{p4} and + XDP~\cite{xdp} for plaintext STHs, supporting line-speed packet + processing on systems that range from switches, routers, network interface + cards, and Linux (Section~\ref{ctga:sec:implementation}). + \item A simulation based on RIPE Atlas measurements that evaluate the impact + of deploying aggregation-based gossip at ASes and IXPs. Our evaluation shows + that incremental roll-out at well-connected locations would protect a + significant portion of all Internet clients from undetected split views + (Section~\ref{ctga:sec:measurements}). +\end{itemize} + +Besides the sections referenced above, the paper introduces necessary +background in Section~\ref{ctga:sec:background} and provides discussion, conclusion, +and future work in Sections~\ref{ctga:sec:related}--\ref{ctga:sec:conclusion}. +A full version with additional implementation details is available +online~\cite{full-version}. diff --git a/summary/src/ctga/src/measurements.tex b/summary/src/ctga/src/measurements.tex new file mode 100644 index 0000000..ee0ea89 --- /dev/null +++ b/summary/src/ctga/src/measurements.tex @@ -0,0 +1,85 @@ +\section{Estimated Impact of Deployment} \label{ctga:sec:measurements} +We conducted 20 daily traceroute measurements during spring 2018 on the RIPE +Atlas platform to evaluate the effectiveness of aggregation-based gossip. The +basic idea is to look at client coverage as central ASes and IXPs aggregate +STHs. If any significant client coverage can be achieved, the likelihood of +pulling off an undetected split-view will be small. + +\subsection{Setup} +We scheduled RIPE Atlas measurements from roughly 3500 unique ASes that +represent 40\% of the IPv4 space, trace-routing Google's authoritative +CT-over-DNS server and NORDUnet's CT log to simulate clients that fetch DNS STHs +in plaintext. Each traceroute result is a list of +traversed IPs, and it can be translated into the corresponding ASes and IXPs +using public data sets~\cite{pub-routeviews,pub-caida}. +In other words, traversed ASes and IXPs can be determined for each probe. Since +we are interested in client coverage as ASes and IXPs aggregate, each +probe is weighted by the IPv4 space of its AS. While an IP address is an +imperfect representation of a client, e.g., an IP may be unused or reused, it +gives a decent idea of how significant it is to cover a given probe. + +\subsection{Results} +Figure~\ref{ctga:fig:pl} shows AS/IXP path length and stability from the probes to +the targets. +If the AS path length is one, a single AS is traversed \emph{before reaching the +target}. It is evident that an AS path tends to be one hop longer +towards NORDUnet than Google because there is a rough off-by-one offset on the +x-axis. +A similar trend of greater path length towards NORDUnet can be observed for +IXPs. For example, + 74.0\% of all paths traversed no IXP towards Google, but + 58.5\% of all paths traversed a single IXP towards NORDUnet. +These results can be explained by infrastructural differences of our targets: + since Google is a worldwide actor an average path should be shorter than + compared to a region-restricted actor like NORDUnet. +We also observed that AS and IXP paths tend to be quite stable over 20~days + (the duration of our measurements). +I.e., if AS $a$ and $b$ are traversed it is unlikely to suddenly be +routed via AS~$c$. +\begin{figure}[!t] + \centering + \includegraphics[width=0.5\columnwidth]{src/ctga/img/pl}% + \includegraphics[width=0.5\columnwidth]{src/ctga/img/ps} + \caption{% + Path length and stability towards Google and NORDUnet. + } + \label{ctga:fig:pl} +\end{figure} + +Figure~\ref{ctga:fig:wcov} shows coverage of the RIPE Atlas network as $1...n$ actors +aggregate STHs. For example, 100\% and 50\% coverage means that at least 40\% +and 20\% of the full IPv4 space is covered. The aggregating ASes and IXPs were +selected based on the most commonly traversed vantage points in +our measurements (Pop), as well as CAIDA's largest AS ranking~\cite{caida}. +We found that more coverage is achieved when targeting +NORDUnet than Google. This is expected given that the paths tend to be longer. +If CAIDA's top-32 enabled aggregation, the coverage would be significant +towards Google (31.6\%)~and~NORDUnet~(58.1\%). + +\begin{figure}[!t] + \centering + \includegraphics[width=0.5\columnwidth]{src/ctga/img/wcov-goo}% + \includegraphics[width=0.5\columnwidth]{src/ctga/img/wcov-nor} + \caption{% + Coverage as a function of aggregation opt-in. + } + \label{ctga:fig:wcov} +\end{figure} + +\subsection{Lessons Learned} +A vast majority of all clients traverse \emph{at least} one AS that could +aggregate. It is relatively rare to traverse IXPs towards Google but not +NORDUnet. We also learned that paths tends to be stable, which means that the +time until split view detection would be at least 20 days \emph{if} it is +possible to find an unprotected client. This increases the importance of +aggregation indistinguishability. +Finally, we identified vantage points that are commonly traversed using Pop, and +these vantage points are represented well by CAIDA's independent AS ranking. +Little opt-in from ASes and IXPs provides significant coverage against an +attacker that is relatively close to a client + (cf.\ world-wide infrastructure of Google). +Although we got better coverage for NORDUnet, any weak attacker would approach +Google's coverage by renting infrastructure nearby. +Any weak attacker could also circumvent IXP aggregation by detecting the IXP +itself~\cite{ixp-detect}. As such, top-ranked AS aggregation should give +the best split-view protection. diff --git a/summary/src/ctga/src/ref.bib b/summary/src/ctga/src/ref.bib new file mode 100644 index 0000000..5aa2314 --- /dev/null +++ b/summary/src/ctga/src/ref.bib @@ -0,0 +1,573 @@ +@inproceedings{ixp-detect, + author = {George Nomikos and Xenofontas A. Dimitropoulos}, + title = {{traIXroute}: Detecting {IXPs} in traceroute paths}, + booktitle = {PAM}, + year = {2016}, +} + +@mastersthesis{ctga-thesis, + author = {Rasmus Dahlberg}, + title = {Aggregating {Certificate Transparency} Gossip Using Programmable Packet Processors}, + school = {Karlstad University}, + year = {2018}, + type = {Master Thesis}, +} + +@article{laurie, + author = {Ben Laurie}, + title = {{Certificate Transparency}}, + journal = {{ACM} Queue}, + volume = {12}, + number = {8}, + year = {2014}, +} + +@misc{minimal-gossip, + author = {David Drysdale}, + title = {Minimal Gossip}, + howpublished = {\url{https://github.com/google/certificate-transparency-go/blob/master/gossip/minimal}, accessed 2019-09-04}, +} + +@misc{google-ct, + author = {Devon O'Brien}, + title = {{Certificate Transparency} Enforcement in {Google Chrome}}, + howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!msg/ct-policy/wHILiYf31DE/iMFmpMEkAQAJ}, accessed 2019-09-04}, +} + +@misc{apple-ct, + author = {Apple Inc.}, + title = {Apple's {Certificate Transparency} Policy}, + howpublished = {\url{https://support.apple.com/en-us/HT205280}, accessed 2019-09-04}, +} + +@inproceedings{h2, + author = {Mark O'Neill and + Scott Heidbrink and + Scott Ruoti and + Jordan Whitehead and + Dan Bunker and + Luke Dickinson and + Travis Hendershot and + Joshua Reynolds and + Kent E. Seamons and + Daniel Zappala}, + title = {{TrustBase}: An Architecture to Repair and Strengthen Certificate-Based Authentication}, + booktitle = {USENIX Security}, + year = {2017}, +} + +@inproceedings{h1, + author = {Adam Bates and + Joe Pletcher and + Tyler Nichols and + Braden Hollembaek and + Dave Tian and + Kevin R. B. Butler and + Abdulrahman Alkhelaifi}, + title = {Securing {SSL} Certificate Verification through Dynamic Linking}, + booktitle = {CCS}, + year = {2014}, +} + +@inproceedings{catena, + author = {Alin Tomescu and Srinivas Devadas}, + title = {Catena: Efficient Non-equivocation via {Bitcoin}}, + booktitle = {IEEE S\&P}, + year = {2017}, +} + +@inproceedings{ct-pir, + author = {Wouter Lueks and Ian Goldberg}, + title = {Sublinear Scaling for Multi-Client Private Information Retrieval}, + booktitle = {FC}, + year = {2015}, +} + +@techreport{ct, + author = {Ben Laurie and Adam Langley and Emilia Kasper}, + title = {{Certificate Transparency}}, + type = {RFC}, + institution = {IETF}, + number = {6962}, + year = {2013}, +} + +@misc{vds, + author = {Adam Eijdenberg and Ben Laurie and Al Cutter}, + title = {Verifiable Data Structures}, + howpublished = {\url{https://github.com/google/trillian/blob/master/docs/VerifiableDataStructures.pdf}, accessed 2019-09-04}, +} + +@inproceedings{transparency-overlays, + author = {Melissa Chase and Sarah Meiklejohn}, + title = {Transparency Overlays and Applications}, + booktitle = {CCS}, + year = {2016}, +} + +@inproceedings{coniks, + author = {Marcela S. Melara and + Aaron Blankstein and + Joseph Bonneau and + Edward W. Felten and + Michael J. Freedman}, + title = {{CONIKS}: Bringing Key Transparency to End Users}, + booktitle = {USENIX Security}, + year = {2015}, +} + +@inproceedings{ca-ecosystem, + author = {Zakir Durumeric and + James Kasten and + Michael Bailey and + J. Alex Halderman}, + title = {Analysis of the {HTTPS} Certificate Ecosystem}, + booktitle = {IMC}, + year = {2013}, +} + +@inproceedings{little-or-no-gossip, + author = {Oliver Gasser and + Benjamin Hof and + Max Helm and + Maciej Korczynski and + Ralph Holz and + Georg Carle}, + title = {In Log We Trust: Revealing Poor Security Practices with {Certificate Transparency} Logs and Internet Measurements}, + booktitle = {PAM}, + year = {2018}, +} + +@techreport{ietf-gossip, + author = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter}, + title = {Gossiping in {CT}}, + number = {draft-ietf-trans-gossip-05}, + type = {Internet-draft}, + institution = {IETF}, + year = {2018}, +} + +@inproceedings{chuat-gossip, + author = {Laurent Chuat and + Pawel Szalachowski and + Adrian Perrig and + Ben Laurie and + Eran Messeri}, + title = {Efficient Gossip Protocols for Verifying the Consistency of + Certificate Logs}, + booktitle = {CNS}, + year = {2015}, +} + +@misc{ct-honey-bee, + author = {Andrew Ayer}, + title = {Lightweight Program that Pollinates {STHs} Between {Certificte + Transparency} Logs and Auditors}, + howpublished = {\url{https://github.com/SSLMate/ct-honeybee}, accessed 2019-09-04}, +} + +@article{hof-cross-logging, + author = {Benjamin Hof and Georg Carle}, + title = {Software Distribution Transparency and Auditability}, + journal = {CoRR}, + volume = {abs/1711.07278}, + year = {2017}, +} + +@techreport{ietf-cross-logging, + author = {Benjamin Hof}, + title = {{STH} Cross Logging}, + institution = {IETF}, + number = {draft-hof-trans-cross-00}, + type = {Internet-draft}, + year = {2017}, +} + +@misc{google-gossip, + author = {Ryan Sleevi and Eran Messeri}, + title = {{Certificate Transparency} in {Chrome}: Monitoring {CT} Logs consistency}, + howpublished = {\url{https://docs.google.com/document/d/1FP5J5Sfsg0OR9P4YT0q1dM02iavhi8ix1mZlZe_z-ls/edit?pref=2&pli=1}, accessed 2019-09-04}, +} + +@inproceedings{cosi, + author = {Ewa Syta and + Iulia Tamas and + Dylan Visher and + David Isaac Wolinsky and + Philipp Jovanovic and + Linus Gasser and + Nicolas Gailly and + Ismail Khoffi and + Bryan Ford}, + title = {Keeping Authorities ``Honest or Bust'' with Decentralized Witness Cosigning}, + booktitle = {IEEE S\&P}, + year = {2016}, +} + +@inproceedings{mpaudit, + author = {Lachlan J. Gunn and Andrew Allison and Derek Abbott}, + title = {Safety in Numbers: Anonymization Makes Keyservers Trustworthy}, + booktitle = {HotPETs}, + year = {2017}, +} + +@inproceedings{doublecheck, + author = {Mansoor Alicherry and Angelos D. Keromytis}, + title = {{DoubleCheck}: Multi-path Verification Against Man-in-the-Middle + Attacks}, + booktitle = {ISCC}, + year = {2009}, +} + +@inproceedings{perspectives, + author = {Dan Wendlandt and David G. Andersen and Adrian Perrig}, + title = {Perspectives: Improving {SSH}-Style Host Authentication with + Multi-Path Probing}, + booktitle = {USENIX ATC}, + year = {2008}, +} + +@misc{ct-over-dns, + author = {Ben Laurie}, + title = {{Certificate Transparency} Over {DNS}}, + howpublished = {\url{https://github.com/google/certificate-transparency-rfcs/blob/master/dns}, accessed 2019-09-04}, +} + +%%% Results: Characteristics of fragment traffic (ยง4c) +% Figures 12--13 show real-world measurements that __very__ few correct +% fragmentation series are less than 576 bytes. +% +% 93 series less than 256 bytes were observed, and all but two appeared to be +% errors. +% +% ``MTUs lower than 576 bytes are generally evidence of mistaken or misguided +% configuration''. +%%% +@article{frag-study-02, + author = {Colleen Shannon and David Moore and Kimberly C. Claffy}, + title = {Beyond Folklore: Observations on Fragmented Traffic}, + journal = {IEEE/ACM Trans.\ Netw.}, + volume = {10}, + number = {6}, + year = {2002}, +} + +%%% page 60 +% ``Since nearly all networks in the Internet currently support an MTU of 576 +% or greater, we strongly recommend the use of 576 for datagrams sent to +% non-local networks'' +%%% +@techreport{min-mtu, + author = {Robert Braden}, + title = {Requirements for {Internet} hosts---Communication Layers}, + institution = {IETF}, + type = {RFC}, + number = {1122}, + year = {1989}, +} + +@inproceedings{xdp, + author = {Toke H{\o}iland{-}J{\o}rgensen and + Jesper Dangaard Brouer and + Daniel Borkmann and + John Fastabend and + Tom Herbert and + David Ahern and + David Miller}, + title = {The eXpress data path: fast programmable packet processing in the operating system kernel}, + booktitle = {CoNEXT}, + year = {2018}, +} + +@inproceedings{TCPoss, + author = {Michio Honda and + Yoshifumi Nishida and + Costin Raiciu and + Adam Greenhalgh and + Mark Handley and + Hideyuki Tokuda}, + title = {Is it Still Possible to Extend {TCP}?}, + booktitle = {IMC}, + year = {2011}, +} + +@inproceedings{HTTPSintercept, + author = {Zakir Durumeric and + Zane Ma and + Drew Springall and + Richard Barnes and + Nick Sullivan and + Elie Bursztein and + Michael Bailey and + J. Alex Halderman and + Vern Paxson}, + title = {The Security Impact of {HTTPS} Interception}, + booktitle = {NDSS}, + year = {2017}, +} + +@inproceedings{mpquic, + author = {Quentin De Coninck and Olivier Bonaventure}, + title = {Multipath {QUIC}: Design and Evaluation}, + booktitle = {CoNEXT}, + year = {2017}, +} + +@inproceedings{tor, + author = {Roger Dingledine and Nick Mathewson and Paul F. Syverson}, + title = {Tor: The Second-Generation Onion Router}, + booktitle = {USENIX Security}, + year = {2004}, +} + +@inproceedings{androidlibs, + author = {Michael Backes and Sven Bugiel and Erik Derr}, + title = {Reliable Third-Party Library Detection in {Android} and its Security Applications}, + booktitle = {{CCS}}, + year = {2016}, +} + +@inproceedings{androidlibs2, + author = {Erik Derr and + Sven Bugiel and + Sascha Fahl and + Yasemin Acar and + Michael Backes}, + title = {Keep me Updated: An Empirical Study of Third-Party Library + Updatability on {Android}}, + booktitle = {CCS}, + year = {2017}, +} + +@inproceedings{langely-quic, + author = {Adam Langley and + Alistair Riddoch and + Alyssa Wilk and + Antonio Vicente and + Charles Krasic and + Dan Zhang and + Fan Yang and + Fedor Kouranov and + Ian Swett and + Janardhan R. Iyengar and + Jeff Bailey and + Jeremy Dorfman and + Jim Roskind and + Joanna Kulik and + Patrik Westin and + Raman Tenneti and + Robbie Shade and + Ryan Hamilton and + Victor Vasiliev and + Wan{-}Teh Chang and + Zhongyi Shi}, + title = {The {QUIC} Transport Protocol: Design and Internet-Scale Deployment}, + booktitle = {{SIGCOMM}}, + year = {2017}, +} + + +@article{sdn, + author = {Nick Feamster and + Jennifer Rexford and + Ellen W. Zegura}, + title = {The road to {SDN:} An intellectual history of programmable networks}, + journal = {CCR}, + volume = {44}, + number = {2}, + year = {2014}, +} + +@techreport{ipv6, + author = {Steve Deering and Robert Hinden}, + title = {Internet Protocol Version 6 ({IPv6}) specification}, + type = {RFC}, + institution = {IETF}, + number = {8200}, + year = {2017}, +} + +@inproceedings{ct-formal, + author = {Benjamin Dowling and + Felix G{\"{u}}nther and + Udyani Herath and + Douglas Stebila}, + title = {Secure Logging Schemes and {Certificate Transparency}}, + booktitle = {ESORICS}, + year = {2016}, +} + +@inproceedings{bpf, + author = {Steven McCanne and Van Jacobson}, + title = {The {BSD} Packet Filter: A New Architecture for User-level + Packet Capture}, + booktitle = {Usenix Winter Technical Conference}, + year = {1993}, +} + +@inproceedings{pisces, + author = {Muhammad Shahbaz and + Sean Choi and + Ben Pfaff and + Changhoon Kim and + Nick Feamster and + Nick McKeown and + Jennifer Rexford}, + title = {{PISCES:} A Programmable, Protocol-Independent Software Switch}, + booktitle = {{ACM} {SIGCOMM}}, + year = {2016}, +} + +@article{p4, + author = {Pat Bosshart and + Dan Daly and + Glen Gibb and + Martin Izzard and + Nick McKeown and + Jennifer Rexford and + Cole Schlesinger and + Dan Talayco and + Amin Vahdat and + George Varghese and + David Walker}, + title = {{P4}: Programming Protocol-independent Packet Processors}, + journal = {CCR}, + volume = {44}, + number = {3}, + year = {2014}, +} + +@inproceedings{rmt, + author = {Pat Bosshart and + Glen Gibb and + Hun{-}Seok Kim and + George Varghese and + Nick McKeown and + Martin Izzard and + Fernando A. Mujica and + Mark Horowitz}, + title = {Forwarding Metamorphosis: Fast Programmable Match-action Processing in + Hardware for {SDN}}, + booktitle = {ACM SIGCOMM}, + year = {2013}, +} + +@conference{p4netfpga, + author = {Gordon Brebner}, + title = {{P4} for an {FPGA} Target}, + booktitle = {P4 Workshop}, + year = {2015}, + note = {\url{https://p4workshop2015.sched.com/event/3ZQA/p4-for-an-fpga-target}, accessed 2019-09-04}, +} + +@misc{p4netronome, + title = {Programming {NFP} with {P4} and {C}}, + howpublished = {\url{https://www.netronome.com/media/redactor_files/WP_Programming_with_P4_and_C.pdf}, accessed 2019-09-04}, +} + +@misc{flexpipe, + title = {Intel Ethernet Switch {FM600} Series: 10/40 {GbE} Low Latency Switching Silicon}, + howpublished = {\url{https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ethernet-switch-fm6000-series-brief.pdf}, accessed 2019-09-04}, +} + +@misc{cavium, + title = {Cavium and {XPliant} Introduce a Fully Programmable Switch Silicon Family Scaling to 3.2 Terabits per Second}, + howpublished = {\url{https://cavium.com/newsevents-cavium-and-xpliant-introduce-a-fully-programmable-switch-silicon-family.html}, accessed 2019-09-04}, +} + +@misc{barefoot, + title = {Tofino: World's fastest {P4}-programmable Ethernet switch {ASICs}}, + howpublished = {\url{https://barefootnetworks.com/products/brief-tofino/}, accessed 2019-09-04}, +} + +@misc{p4bm, + title = {BEHAVIORAL MODEL REPOSITORY}, + howpublished = {\url{https://github.com/p4lang/behavioral-model}, accessed 2019-09-04}, +} + +@misc{p42ebpf, + author = {Mihai Budiu}, + title = {Compiling {P4} to {eBPF}}, + howpublished = {\url{https://github.com/iovisor/bcc/tree/master/src/cc/frontends/p4}, accessed 2019-09-04}, +} + +@misc{fbi-apple, + author = {EFF}, + title = {Apple Challenges {FBI}: All Writs Act Order ({CA})}, + howpublished = {\url{https://www.eff.org/cases/apple-challenges-fbi-all-writs-act-order}, accessed 2019-09-04}, +} + +@misc{ver-sth, + author = {Linus Nordberg}, + title = {{Re: [Trans] Providing} the history of {STHs} a log has issued (in 6962-bis)}, + howpublished = {\url{https://mailarchive.ietf.org/arch/msg/trans/JbFiwO90PjcYzXrEgh-Y7bFG5Fw}, accessed 2019-09-04}, +} + +@techreport{dot, + author = {Sara Dickinson and Dan Gillmor and Tirumaleswar Reddy}, + title = {Usage Profiles for {DNS} over {TLS} and {DNS} over {DTLS}}, + type = {RFC}, + institution = {IETF}, + number = {8310}, + year = {2016}, +} + +@techreport{doh, + author = {Paul Hoffman and Patrick McManus}, + title = {{DNS} Queries over {HTTPS (DoH)}}, + type = {RFC}, + institution = {IETF}, + number = {8484}, + year = {2018}, +} + +@misc{izenpe, + author = {Ryan Sleevi}, + title = {Upcoming {CT} Log Removal: {Izenpe}}, + howpublished = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/qOorKuhL1vA}, accessed 2019-09-04}, +} + +@misc{venafi, + author = {Ryan Sleevi}, + title = {Upcoming Log Removal: {Venafi CT} Log Server}, + note = {\url{https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/KMAcNT3asTQ}, accessed 2019-09-04}, +} + +@misc{caida, + author = {CAIDA}, + title = {{ARank}}, + note = {\url{http://as-rank.caida.org/}, accessed 2019-09-04}, +} + +@article{full-version, + author = {Rasmus Dahlberg and + Tobias Pulls and + Jonathan Vestin and + Toke H{\o}iland{-}J{\o}rgensen and + Andreas Kassler}, + title = {Aggregation-Based Gossip for Certificate Transparency}, + journal = {CoRR}, + volume = {abs/1806.08817}, + year = {2019}, +} + +@misc{pub-caida, + author = {CAIDA}, + title = {The {CAIDA UCSD IXPs} Dataset}, + howpublished = {\url{https://www.caida.org/data/ixps/}, accessed 2019-09-04}, + month = {February}, + year = {2018}, +} + +@misc{pub-routeviews, + title = {The {Routeviews MRT format RIBs and UPDATEs} Dataset}, + howpublished = {\url{http://archive.routeviews.org/bgpdata/2018.03/RIBS/}, accessed 2019-09-04}, + month = {March}, + year = {2018}, +} + +@misc{github, + title = {Paper artifact}, + year = {2018}, + howpublished = {\url{https://github.com/rgdd/ctga}}, +} diff --git a/summary/src/ctga/src/related.tex b/summary/src/ctga/src/related.tex new file mode 100644 index 0000000..15d7fad --- /dev/null +++ b/summary/src/ctga/src/related.tex @@ -0,0 +1,67 @@ +\section{Related Work} \label{ctga:sec:related} +Earlier approaches towards CT gossip are categorized as \emph{proactive} or +\emph{retroactive} in Figure~\ref{ctga:fig:related}. We consider an approach proactive +if gossip takes place \emph{before} SCTs and/or STHs reach the broader audience +of clients. +Syta \emph{et~al.} proposed proactive witness cosigning, in which an STH is +collectively signed by a \emph{large} number of witnesses and at most a fraction +of those can be faulty to ensure that a benevolent witness observed an +STH~\cite{cosi}. STH +cross-logging~\cite{minimal-gossip,ietf-cross-logging,hof-cross-logging} +is similar in that an STH must be proactively disclosed in +another transparency log to be trusted, avoiding any additional cosigning +infrastructure at the cost of reducing the size and diversity of the witnessing +group. +Tomescu and Devadas~\cite{catena} suggested a similar cross-logging scheme, +but split-view detection is instead reduced to the difficulty of forking the +Bitcoin blockchain + (big-O cost of downloading all block headers as a TLS client). +The final proactive approach is STH pushing, where a trusted third-party +pushes the same verified STH history to a base of clients~\cite{google-gossip}. +\begin{figure}[!t] + \centering + \input{src/ctga/img/related.tex} + \caption{% + A categorization of approaches towards CT gossip. + } + \label{ctga:fig:related} +\end{figure} + +We consider a gossip mechanism retroactive if gossip takes place \emph{after} +SCTs and/or STHs reach the broader audience of clients. +Chuat \emph{et~al.} proposed that TLS clients and TLS servers be modified to +pool exchanged STHs and relevant consistency proofs~\cite{chuat-gossip}. +Nordberg \emph{et~al.} continued this line of work, suggesting privacy-% +preserving client-server pollination of fresh STHs~\cite{ietf-gossip}. Nordberg +\emph{et~al.} also proposed that clients feedback SCTs and certificate chains on +every server revisit, and that trusted auditor relationships could be engaged if +privacy need not be protected. +The latter is somewhat similar to the formalized client-monitor gossip of +Chase and Meiklejohn~\cite{transparency-overlays}, as well as the CT honey bee +project where a client process fetches and submits STHs to a pre-% +compiled list of auditors~\cite{ct-honey-bee}. +Laurie suggested that a client can resolve privacy-sensitive SCTs to privacy-% +insensitive STHs via DNS (which are easier to gossip)~\cite{ct-over-dns}. +Private information retrievals could likely achieve something similar~\cite{ct-pir}. +Assuming that TLS clients are indistinguishable from one another, split-view +detection could also be implicit as proposed by Gunn \emph{et~al.} for the +verifiable key-value store CONIKS~\cite{mpaudit,coniks}. + +Given that aggregation-based gossip takes place after an STH is issued, it is a +retroactive approach. As such, we cannot protect an isolated client from split-% +views~\cite{cosi}. Similar to STH pooling and STH pollination, we rely on +client-driven communication and an existing infrastructure of packet processors +to aggregate. +Our off-path verification is +based on the same multi-path probing and indistinguishability assumptions as +Gunn \emph{et~al.}~\cite{doublecheck,mpaudit,perspectives}. Further, given that +aggregation is application neutral and deployable on hosts, it could provide +gossip \emph{for} the CT honey bee project (assuming plaintext STHs) and any +other transparency application like Trillian~\cite{vds}. Another benefit when +compared to browsing-centric and vendor-specific approaches is that a plethora +of HTTPS clients are covered, ranging from niche web browsers to command line +tools and embedded libraries that are vital to protect but yet lack the +resources of major browser vendors~\cite{androidlibs,androidlibs2}. +Our approach coexists well with witness cosigning and cross-logging due to +different threat models, but not necessarily STH pushing if the secure +channel is encrypted (no need to fetch what a trusted party provides). |