diff options
Diffstat (limited to 'summary/src/sauteed')
| -rw-r--r-- | summary/src/sauteed/.gitignore | 9 | ||||
| -rw-r--r-- | summary/src/sauteed/img/onion-location.pdf | bin | 0 -> 17583 bytes | |||
| -rw-r--r-- | summary/src/sauteed/img/onion-search.pdf | bin | 0 -> 18261 bytes | |||
| -rw-r--r-- | summary/src/sauteed/main.tex | 64 | ||||
| -rw-r--r-- | summary/src/sauteed/src/abstract.tex | 22 | ||||
| -rw-r--r-- | summary/src/sauteed/src/acks.tex | 9 | ||||
| -rw-r--r-- | summary/src/sauteed/src/appendix.tex | 79 | ||||
| -rw-r--r-- | summary/src/sauteed/src/conc.tex | 16 | ||||
| -rw-r--r-- | summary/src/sauteed/src/intro.tex | 45 | ||||
| -rw-r--r-- | summary/src/sauteed/src/preliminaries.tex | 25 | ||||
| -rw-r--r-- | summary/src/sauteed/src/refs.bib | 325 | ||||
| -rw-r--r-- | summary/src/sauteed/src/related.tex | 62 | ||||
| -rw-r--r-- | summary/src/sauteed/src/sauteed.tex | 260 |
13 files changed, 916 insertions, 0 deletions
diff --git a/summary/src/sauteed/.gitignore b/summary/src/sauteed/.gitignore new file mode 100644 index 0000000..8bb88c8 --- /dev/null +++ b/summary/src/sauteed/.gitignore @@ -0,0 +1,9 @@ +main.pdf +*.blg +*.bbl +*.fls +*.fdb_latexmk +*.log +*.out +*.aux +*.swp diff --git a/summary/src/sauteed/img/onion-location.pdf b/summary/src/sauteed/img/onion-location.pdf Binary files differnew file mode 100644 index 0000000..21fde5f --- /dev/null +++ b/summary/src/sauteed/img/onion-location.pdf diff --git a/summary/src/sauteed/img/onion-search.pdf b/summary/src/sauteed/img/onion-search.pdf Binary files differnew file mode 100644 index 0000000..5867270 --- /dev/null +++ b/summary/src/sauteed/img/onion-search.pdf diff --git a/summary/src/sauteed/main.tex b/summary/src/sauteed/main.tex new file mode 100644 index 0000000..e0c7cda --- /dev/null +++ b/summary/src/sauteed/main.tex @@ -0,0 +1,64 @@ +\begin{kaupaper}[ + author={% + \textbf{Rasmus Dahlberg}, + Paul Syverson, + Linus Nordberg, and + Matthew Finkel + }, + title={% + Sauteed Onions: Transparent Associations from Domain Names to Onion Addresses + }, + reference={% + WPES (2022) + }, + summary={% + Many prominent websites are also hosted as Tor onion services. Onion + services are identified by their public keys and subject to onion routing, + thus offering self-authenticated connections and censorship resistance. + However, the non-mnemonic names are a limitation due to being hard to + discover and remember. We explore how certificates with onion addresses + may improve the status quo by proposing sauteed onions, \emph{transparent + associations from domain names to onion addresses} with the help of + Certificate Transparency logs. The idea is to extend a website's regular + certificate with an associated onion address. This makes it possible to + offer certificate-based onion location that is no less targeted than the + HTTPS connection facilitating the discovery, as well as name-to-onion + search engines that use the append-only logs for verifiable population of + their databases. The achieved goals are + consistency of available onion associations, + improved third-party discovery of onion associations, and + forward censorship-resistance. + To be discovered, sites must opt-in by obtaining a sauteed onion + certificate. Our prototypes for certificate-based onion location and + third-party search engines use an existing backward-compatible format. We + discuss this trade-off and note that a certificate extension may be used + in the future. + }, + participation={\vspace{-.25cm} + Paul, Linus, and I had the initial idea of exploring how onion addresses + fit into Certificate Transparency. Paul and I did most of the writing. I + implemented our monitor, Linus our search engine, Matt our web extension. + }, + label={ + paper:sauteed + }, +] + \maketitle + \begin{abstract} + \input{src/sauteed/src/abstract} + \end{abstract} + + \input{src/sauteed/src/intro} + \input{src/sauteed/src/preliminaries} + \input{src/sauteed/src/sauteed} + \input{src/sauteed/src/related} + \input{src/sauteed/src/conc} + \input{src/sauteed/src/acks} + + \bibliographystyle{plain} + \bibliography{src/sauteed/src/refs} + + \begin{appendices} + \input{src/sauteed/src/appendix} + \end{appendices} +\end{kaupaper} diff --git a/summary/src/sauteed/src/abstract.tex b/summary/src/sauteed/src/abstract.tex new file mode 100644 index 0000000..8bdcd81 --- /dev/null +++ b/summary/src/sauteed/src/abstract.tex @@ -0,0 +1,22 @@ +\noindent +Onion addresses offer valuable features such as lookup and routing +security, self-authenticated connections, and censorship resistance. +Therefore, many websites are also available as onionsites in Tor. The way +registered domains and onion addresses are associated is however a weak link. +We introduce \emph{sauteed onions}, \emph{transparent associations from domain +names to onion addresses}. +Our approach relies on TLS certificates to establish onion associations. It is +much like today's onion location which relies on Certificate Authorities (CAs) +due to its HTTPS requirement, but has the added benefit of becoming public for +everyone to see in Certificate Transparency (CT) logs. We propose and prototype +two uses of sauteed onions: + certificate-based onion location and + search engines that use CT logs as the underlying database. +The achieved goals are + \emph{consistency of available onion associations}, which mitigates attacks + where users are partitioned depending on which onion addresses they are + given, + \emph{forward censorship-resistance} after a TLS site has been configured + once, and + \emph{improved third-party discovery of onion associations}, which requires + less trust while easily scaling to all onionsites that opt-in. diff --git a/summary/src/sauteed/src/acks.tex b/summary/src/sauteed/src/acks.tex new file mode 100644 index 0000000..590558a --- /dev/null +++ b/summary/src/sauteed/src/acks.tex @@ -0,0 +1,9 @@ +\section*{Acknowledgments} +We would like to thank + Kushal Das, + Daniel Kahn Gillmor, + Silvio Rhatto, and + Tobias Pulls +for helpful discussions and comments. +Rasmus Dahlberg was supported by the Swedish Foundation for Strategic Research. +Paul Syverson was supported by ONR\@. diff --git a/summary/src/sauteed/src/appendix.tex b/summary/src/sauteed/src/appendix.tex new file mode 100644 index 0000000..7850d49 --- /dev/null +++ b/summary/src/sauteed/src/appendix.tex @@ -0,0 +1,79 @@ +\section{Onion Association Search Examples} \label{sauteed:app:search} +We host the search engine described in Section~\ref{sauteed:sec:search-engine} on a +Debian VM with 1GB RAM, 20GB SSD, and a single vCPU. It is available at +\texttt{api.sauteed-onions.o +rg} as well as +\texttt{zpadxxmoi42k45iifrzuktwqktihf5didbaec3xo4dhvlw2hj54 +doiqd.onion}. +Please note that we operate this prototype on a best-effort level until +December, 2022. + +An example for the \texttt{search} endpoint is provided in +Figure~\ref{sauteed:fig:search}, followed by extracting additional certificate +information using the \texttt{get} endpoint in Figure~\ref{sauteed:fig:get}. There are +many CT-logged certificates for the same onion association because certificates +are renewed periodically and typically submitted to multiple CT logs. + +\begin{sidewaysfigure}[!t] + \centering + \begin{lstlisting} + $ curl -s https://api.sauteed-onions.org/search?in=www.sauteed-onions.org | json_pp + [ + { + "identifiers" : [ + "2", + "3", + "24", + "25", + "28", + "29", + "37" + ], + "onion_addr" : "qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cyd.onion", + "domain_name" : "www.sauteed-onions.org" + } + ] + \end{lstlisting} + \caption{Find onion associations for \texttt{www.sauteed-onions.org}.} + \label{sauteed:fig:search} +\end{sidewaysfigure} + +\begin{sidewaysfigure}[!t] + \centering + \begin{lstlisting} + $ curl -s https://api.sauteed-onions.org/get?id=2 | json_pp + { + "onion_addr" : "qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cyd.onion", + "domain_name" : "www.sauteed-onions.org", + "log_id" : "b1N2rDHwMRnYmQCkURX/dxUcEdkCwQApBo2yCJo32RM=", + "log_index" : 582362461, + "cert_path" : "db/logs/Mammoth/582362461.pem" + } + $ curl -L https://api.sauteed-onions.org/db/logs/Mammoth/582362461.pem | \ + openssl x509 -text -noout + ... + \end{lstlisting} + \caption{Get further information relating to the certificate with identifier ``2''.} + \label{sauteed:fig:get} +\end{sidewaysfigure} + +\section{Configuration Example} \label{sauteed:app:setup} + +We used \texttt{certbot} to set up sauteed onions using Let's Encrypt and +\texttt{apache} on a Debian system. The difference when +compared to the usual \texttt{certbot} instructions is that the \texttt{-d} flag +must be specified to enumerate all SANs as a comma-separated +list~\cite{certbot}. The domain name with an associated onion address as a +subdomain also needs to be reachable via DNS for Let's Encrypt to perform domain +validation. Therefore, an appropriate A/AAAA or CNAME record is required. A +sanity-check for \texttt{www.sauteed-onions.org} would be to verify that + \texttt{dig qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cydonion + .www.sauteed-onions.org} +returns the same IP address as + \texttt{dig www.sauteed + -onions.org} +before running + \texttt{certbot --apache -d~www.sauteed-onions. + org,qvrbktnwsztjnbga6yyjbwzsdjw7u5a6vsyzv6hkj75clog4pdvy4cydo + nion.www.sauteed-onions.org}. +See \texttt{crt.sh} for an example certificate~\cite{sauteed-onion-cert}. diff --git a/summary/src/sauteed/src/conc.tex b/summary/src/sauteed/src/conc.tex new file mode 100644 index 0000000..2b26a56 --- /dev/null +++ b/summary/src/sauteed/src/conc.tex @@ -0,0 +1,16 @@ +\section{Conclusion} \label{sauteed:sec:conclusion} +Sauteed onions declare unidirectional associations from domain names to onion +addresses. These onion associations are established in CA-issued and CT-logged +TLS certificates, thereby making them public for everyone to see. We propose +two immediate applications: + certificate-based onion location and + more automated verifiable search. +Both applications are opt-in for domain owners, and rely on similar assumptions +as today's onion location. The added benefit is more transparency, which +facilitates a higher degree of consistency between found onion associations as +well as more censorship-resistance for TLS sites after setup. Configuration of +sauteed onions requires one more DNS record and a domain-validated certificate +from any CA (such as Let's Encrypt). In the future, the additional DNS record +may be replaced by an X.509v3 extension. We leave it as a fun exercise to find +the onion address of a TLS site that is intentionally being censored by us: +\texttt{blocked.sauteed-onions.org}. diff --git a/summary/src/sauteed/src/intro.tex b/summary/src/sauteed/src/intro.tex new file mode 100644 index 0000000..bfad238 --- /dev/null +++ b/summary/src/sauteed/src/intro.tex @@ -0,0 +1,45 @@ +\section{Introduction} \label{sauteed:sec:intro} +Onion addresses are domain names with many useful properties. For example, an +onion address is self-authenticated due to encoding its own public key. It +also makes integral use of the anonymity network Tor to provide secure and +private lookups as well as routing~\cite{tor-design}. A major usability concern +is that onion addresses are random-looking strings; they are difficult to +discover, update, and remember~\cite{winter}. Existing solutions approach these +limitations in different ways, e.g., ranging from setting onion addresses in +HTTP headers over HTTPS with so-called \emph{onion +location}~\cite{onion-location} and bookmarking found results to making use of +manually curated third-party +lists~\cite{muffet-onions,onion-service-overview,h-e-securedrop} as well as +search engines like DuckDuckGo or \texttt{ahmia.fi}~\cite{nurmi,winter}. + +Herein we refer to the unidirectional association from a domain name to an onion +address as an \emph{onion association}. The overall goal is to facilitate +transparent discovery of onion associations. To achieve this we rely on the +observation that today's onion location can be implemented in certificates +issued by Certificate Authorities (CAs). This is not an additional dependency +because onion location already requires HTTPS~\cite{onion-location}. The main +benefit of transitioning from HTTP headers to TLS certificates is that all such +onion associations become signed and sequenced in tamper-evident Certificate +Transparency (CT) logs~\cite{ct/a,ct-rfc}, further tightening the relation +between CAs and onion keys~\cite{cab-ballot144,cab-onion-dv,secdev19} as well as +public CT logging and Tor~\cite{ctor-popets,muffet-onions}. + +Our first contribution is to make onion associations identical for all Tor +users, and otherwise the possibility of inconsistencies becomes public via CT. +Consistency of available onion associations mitigates the threat of users +being partitioned without anyone noticing into subsets according to which +onion address they received during onion association. +Our second contribution is to construct a search engine that allows Tor users to +look up onion associations without having to trust the service provider +completely. Other than being helpful to validate onion addresses as +authentic~\cite{winter}, such discovery can continue to work \emph{after} a TLS +site becomes censored. + +Section~\ref{sauteed:sec:preliminaries} briefly covers CT preliminaries. +Section~\ref{sauteed:sec:trans} describes \emph{sauteed onions}, an approach that makes +discovery of onion associations more transparent and censorship-resistant +compared to today. Section~\ref{sauteed:sec:related} discusses related work. +Section~\ref{sauteed:sec:conclusion} concludes the paper. +Appendix~\ref{sauteed:app:search} contains query examples for our search engine. +Appendix~\ref{sauteed:app:setup} outlines an example setup. +All artifacts are online~\cite{sauteed-onion-artifacts}. diff --git a/summary/src/sauteed/src/preliminaries.tex b/summary/src/sauteed/src/preliminaries.tex new file mode 100644 index 0000000..f01aeba --- /dev/null +++ b/summary/src/sauteed/src/preliminaries.tex @@ -0,0 +1,25 @@ +\section{Certificate Logging Preliminaries} \label{sauteed:sec:preliminaries} +CT is a system of public append-only logs that store TLS certificates issued by +trusted CAs~\cite{ct/a,ct-rfc}. If web browsers add the criterion that a +certificate must be logged before accepting it as valid, certificate issuance +practices by CAs effectively become transparent so that mistakes and malfeasance +can be detected by anyone that observes the logs. These observers are +called \emph{monitors} because they download every certificate from all logs. +One can self-host a monitor, or use a third-party service like +\texttt{crt.sh}, or follow other models based on +subscriptions~\cite{lwm,li}. To avoid introducing more parties that are trusted +blindly as in the CA ecosystem, CT stands on a cryptographic foundation that +permits efficient verification of inclusion (a certificate is in the log) and +the append-only property (no certificate has been removed or +modified)~\cite{ct-foundation}. A party engaging in verification of these +(logarithmic) proofs is called an \emph{auditor}. + +In practice, CT has been rolled-out gradually to not break the +web~\cite{does-ct-break-the-web}. One facilitating factor has been the +introduction of Signed Certificate Timestamps (SCTs). An SCT is a log's +\emph{promise} to include a certificate within a certain amount of time; +typically 24~hours. This guarantees low-latency certificate issuance so that +CAs can \emph{embed} SCTs in certificates to keep web servers oblivious to CT. +Google Chrome and Apple's Safari require SCTs before accepting a certificate as +valid, and steps towards further SCT verification have been taken +recently~\cite{ct-in-chrome}. Tor Browser does not require CT yet~\cite{ctor-popets}. diff --git a/summary/src/sauteed/src/refs.bib b/summary/src/sauteed/src/refs.bib new file mode 100644 index 0000000..876fed4 --- /dev/null +++ b/summary/src/sauteed/src/refs.bib @@ -0,0 +1,325 @@ +@misc{ahmia.fi, + author = {Ahmia}, + title = {Indexing and crawling}, + howpublished = {\url{https://ahmia.fi/documentation/indexing/}, accessed 2022-08-01}, +} + +@misc{sauteed-onion-artifacts, + title = {Paper artifact}, + howpublished = {\url{https://gitlab.torproject.org/tpo/onion-services/sauteed-onions}}, + year = {2022} +} + +@inproceedings{le, + author = {Josh Aas and Richard Barnes and Benton Case and Zakir Durumeric and Peter Eckersley and Alan Flores{-}L{\'{o}}pez and J. Alex Halderman and Jacob Hoffman{-}Andrews and James Kasten and Eric Rescorla and Seth D. Schoen and Brad Warren}, + title = {{Let's Encrypt}: An Automated Certificate Authority to Encrypt the Entire Web}, + booktitle = {{CCS}}, + year = {2019}, +} + +@inproceedings{le-multi-path, + author = {Henry Birge{-}Lee and Liang Wang and Daniel McCarney and Roland Shoemaker and Jennifer Rexford and Prateek Mittal}, + title = {Experiences Deploying Multi-Vantage-Point Domain Validation at {Let's Encrypt}}, + booktitle = {{USENIX} Security}, + year = {2021}, +} + +@Misc{cab-ballot144, + author = {\relax{{CA}/Browser Forum}}, + title = {Ballot 144 -- Validation rules for .onion names}, + howpublished = {\url{https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/}, accessed 2022-08-01}, +} + +@misc{cab-onion-dv, + author = {\relax{{CA}/Browser Forum}}, + title = {Ballot SC27v3: Version 3 Onion Certificates}, + howpublished = {\url{https://cabforum.org/2020/02/20/ballot-sc27v3-version-3-onion-certificates/}, accessed 2022-08-01}, +} + +@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}, +} + +@inproceedings{lwm, + author = {Rasmus Dahlberg and Tobias Pulls}, + title = {Verifiable Light-Weight Monitoring for {Certificate Transparency} Logs}, + booktitle = {NordSec}, + year = {2018}, +} + +@inproceedings{smt, + author = {Rasmus Dahlberg and Tobias Pulls and Roel Peeters}, + title = {Efficient Sparse {Merkle} Trees - Caching Strategies and Secure (Non-)Membership Proofs}, + booktitle = {NordSec}, + year = {2016}, +} + +@article{ctor-popets, + author = {Rasmus Dahlberg and Tobias Pulls and Tom Ritter and Paul Syverson}, + title = {Privacy-Preserving \& Incrementally-Deployable Support for {Certificate Transparency} in {Tor}}, + journal = {PETS}, + volume = {2021}, + number = {2}, +} + +@misc{digicert-onion, + author = {\relax{DigiCert Inc.}}, + title = {Ordering a .onion certificate from {DigiCert}}, + howpublished = {\url{https://www.digicert.com/blog/ordering-a-onion-certificate-from-digicert}, accessed 2022-08-01}, +} + +@inproceedings{tor-design, + title = {Tor: The Second-Generation Onion Router}, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + booktitle = {USENIX Security}, + year = {2004}, +} + +@inproceedings{ct-foundation, + 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}, +} + +@misc{vds, + author = {Adam Eijdenberg and Ben Laurie and Al Cutter}, + title = {Verifiable Data Structures}, + howpublished = {\url{https://github.com/google/trillian/blob/111e9369ab032e493a2f19f9be6d16c4f78ccca5/docs/papers/VerifiableDataStructures.pdf}, accessed 2022-08-01}, +} + +@misc{certbot, + key = {EFF}, + title = {Changing a Certificate's Domain}, + howpublished = {\url{https://eff-certbot.readthedocs.io/en/stable/using.html\#changing-a-certificate-s-domains}, accessed 2022-08-01}, +} + +@misc{fink, + author = {Alex Fink}, + title = {Mnemonic .onion {URLs}}, + howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/194-mnemonic-urls.txt}, accessed 2022-08-01}, +} + +@techreport{dangerous-labels, + author = {Daniel Kahn Gillmor}, + title = {{Dangerous Labels in DNS and E-mail}}, + type = {Internet-Draft}, + number = {draft-dkg-intarea-dangerous-labels-01}, + institution = {IETF}, + year = {2022}, +} + +@misc{chrome-logs, + title = {{Google LLC.}}, + key = {Known Logs}, + howpublished = {\url{https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md}, accessed 2022-08-01}, +} + +@misc{harica-onion, + author = {\relax{Harica}}, + title = {{DV} certificates for Onion websites}, + howpublished = {\url{https://news.harica.gr/article/onion_announcement/}, accessed 2022-08-01}, +} + +@misc{kadianakis, + author = {George Kadianakis and Yawning Angel and David Goulet}, + title = {A Name System {API} for {Tor} Onion Services}, + howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt}, accessed 2022-08-01}, +} + +@article{ct/a, + author = {Ben Laurie}, + title = {Certificate transparency}, + journal = {CACM}, + volume = {57}, + number = {10}, + year = {2014}, +} + +@misc{trans-laurie, + title = {{Re: [Trans] Mozilla's} basic take on Binary Transparency}, + author = {Ben Laurie}, + howpublished = {\url{https://mailarchive.ietf.org/arch/msg/trans/1FxzTkn4LVxU6KN2P3YfbVsKpho/}, accessed 2022-08-01}, +} + +@techreport{ct-rfc, + author = {Ben Laurie and Adam Langley and Emilia Kasper}, + title = {{Certificate Transparency}}, + type = {RFC}, + number = {6962}, + institution = {IETF}, + year = {2013}, +} + +@inproceedings{li, + author = {Bingyu Li and Jingqiang Lin and Fengjun Li and Qiongxiao Wang and Qi Li and Jiwu Jing and Congli Wang}, + title = {{Certificate Transparency} in the Wild: Exploring the Reliability of Monitors}, + booktitle = {{CCS}}, + year = {2019}, +} + +@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}, +} + +@misc{russia-blocks, + author = {Simon Migliano and Samuel Woodhams}, + title = {Websites Blocked in {Russia} Since {Ukraine} Invasion}, + howpublished = {\url{https://www.top10vpn.com/research/websites-blocked-in-russia/}, accessed 2022-08-01}, +} + +@misc{vanity-address, + title = {mkp224o---vanity address generator for ed25519 onion services}, + howpublished = {\url{https://github.com/cathugger/mkp224o}, accessed 2022-08-01}, +} + +@misc{mozilla-bt, + author = {Mozilla}, + title = {Security/Binary Transparency}, + howpublished = {\url{https://wiki.mozilla.org/Security/Binary_Transparency}, accessed 2022-08-01}, +} + +@misc{muffet-onions, + author = {Alec Muffett}, + title = {Onion {Certificate Transparency} Log}, + howpublished = {\url{https://github.com/alecmuffett/real-world-onion-sites}, accessed 2022-08-01}, +} + +@misc{sooc, + author = {Alec Muffett}, + title = {Same Origin Onion Certificates}, + howpublished = {\url{https://crt.sh/?id=6819596552}, accessed 2022-08-01}, +} + +@misc{namecoin, + title = {Namecoin}, + howpublished = {\url{https://www.namecoin.org/}, accessed 2022-08-01}, +} + +@misc{nordberg-tor, + author = {Linus Nordberg}, + title = {{Tor} Consensus Transparency}, + howpublished = {\url{https://gitweb.torproject.org/torspec.git/tree/proposals/267-tor-consensus-transparency.txt}, accessed 2022-08-01}, +} + +@phdthesis{nurmi, + author = {Nurmi, Juha}, + title = {Understanding the Usage of Anonymous Onion Services}, + year = {2019}, + school = {Tampere University, Finland}, +} + +@Misc{haroi-tor-dev, + author = {nusenu}, + title = {{HAROI}: Human Readable Authenticated Relay Operator Identifier}, + howpublished = {\url{https://lists.torproject.org/pipermail/tor-dev/2021-December/014688.html}, accessed 2022-08-01}, +} + +@misc{onion-location, + author = {Tor Project}, + title = {Onion-Location}, + howpublished = {\url{https://community.torproject.org/onion-services/advanced/onion-location/}, accessed 2022-08-01}, +} + +@misc{onion-service-overview, + author = {Tor Project}, + title = {Onion Services}, + howpublished = {\url{https://community.torproject.org/onion-services/}, accessed 2022-08-01}, +} + +@misc{rhatto, + author = {Silvio Rhatto}, + title = {Sauteed Week {API} Backend}, + howpublished = {\url{https://gitlab.torproject.org/rhatto/sauteed-week/-/blob/main/docs/api.md}, accessed 2022-08-01}, +} + +@misc{sauteed-onion-cert, + title = {Sauteed Onion Certificate}, + howpublished = {\url{https://crt.sh/?id=5957691193}, accessed 2022-08-01}, +} + +@inproceedings{onion-dns, + author = {Nolen Scaife and Henry Carter and Patrick Traynor}, + title = {{OnionDNS}: A seizure-resistant top-level Domain}, + booktitle = {{CNS}}, + year = {2015}, +} + +@article{ct-in-chrome, + author = {Emily Stark and Joe DeBlasio and Devon O'Brien and Davide Balzarotti and William Enck and Samuel King and Angelos Stavrou}, + title = {{Certificate Transparency} in {Google Chrome}: Past, Present, and Future}, + journal = {{IEEE} Secur. Priv.}, + volume = {19}, + number = {6}, + year = {2021}, +} + +@inproceedings{does-ct-break-the-web, + author = {Emily Stark and Ryan Sleevi and Rijad Muminovic and Devon O'Brien and Eran Messeri and Adrienne Porter Felt and Brendan McMillion and Parisa Tabriz}, + title = {Does {Certificate Transparency} Break the Web? {Measuring} Adoption and Error Rate}, + booktitle = {{IEEE S\&P}}, + year = {2019}, +} + +@inproceedings{once-and-future, + author = {Paul Syverson}, + title = {The Once and Future Onion}, + booktitle = {ESORICS}, + year = {2017}, +} + +@inproceedings{onion-discovery-attacks, + author = {Paul Syverson and Matt Finkel and Saba Eskandarian and Dan Boneh}, + title = {Attacks on Onion Discovery and Remedies via Self-Authenticating Traditional Addresses}, + booktitle = {WPES}, + year = {2021}, +} + +@inproceedings{secdev19, + author = {Paul Syverson and Matt Traudt}, + title = {Self-Authenticating Traditional Domain Names}, + booktitle = {{SecDev}}, + year = {2019}, +} + +@misc{plex, + title = {How {Plex} is doing {HTTPS} for all its users}, + author = {Filippo Valsorda}, + howpublished = {\url{https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/}, accessed 2022-08-01}, +} + +@Misc{h-e-securedrop, + author = {SecureDrop}, + title = {Getting an Onion Name for Your {SecureDrop}}, + howpublished = {\url{https://securedrop.org/faq/getting-onion-name-your-securedrop/}, accessed 2022-08-01}, +} + +@article{onio-ns, + author = {Jesse Victors and Ming Li and Xinwen Fu}, + title = {The Onion Name System}, + journal = {PETS}, + volume = {2017}, + number = {1}, +} + +@inproceedings{winter, + author = {Philipp Winter and Anne Edmundson and Laura M. Roberts and Agnieszka Dutkowska{-}Zuk and Marshini Chetty and Nick Feamster}, + title = {How Do {Tor} Users Interact With Onion Services?}, + booktitle = {{USENIX} Security}, + year = {2018}, +} + +@techreport{nordberg-gossip, + author = {Linus Nordberg and Daniel Kahn Gillmor and Tom Ritter}, + title = {Gossiping in {CT}}, + type = {Internet-draft}, + number = {draft-ietf-trans-gossip-05}, + institution = {IETF}, + year = {2018}, +} diff --git a/summary/src/sauteed/src/related.tex b/summary/src/sauteed/src/related.tex new file mode 100644 index 0000000..d772d0d --- /dev/null +++ b/summary/src/sauteed/src/related.tex @@ -0,0 +1,62 @@ +\section{Related Work} \label{sauteed:sec:related} +The CA/B forum accepts certificates with \texttt{.onion} +addresses~\cite{cab-ballot144,cab-onion-dv}. DigiCert supports extended +validation of \texttt{.onion} addresses~\cite{digicert-onion}, and HARICA domain +validation~\cite{harica-onion}. Muffett proposed same-origin onion certificates +that permit clients to omit verification of the CA trust chain for +onionsites~\cite{sooc}. Sauteed onions help Tor users \emph{discover} +domain names with associated onion addresses. Therefore, it is a +complement to approaches that bring HTTPS to onionsites. + +Syverson suggested that traditional domain names and \texttt{.onion} addresses +can be glued into a single registered domain~\cite{once-and-future}. Nusenu +proposed long-term Tor relay identifiers based on domain names to retrieve lists +of relevant public keys via HTTPS~\cite{haroi-tor-dev}. Sauteed onions may be +used for such associations with the benefit of transparency, and it is further a +\emph{lighter} version of Syverson and Traudt's self-authenticated traditional +addresses which favors early deployment over properties like bidirectional onion +associations, guaranteed timeliness of revocation, and addressing all known +threats~\cite{onion-discovery-attacks,secdev19}. + +Winter~\emph{et al.} studied how users engage with onion services~\cite{winter}. +A gist is that Tor users have a hard time discovering onion addresses and +verifying them as authentic. Common discovery mechanisms that are associated +with human-meaningful identifiers include + personal communication, + webpage links, + onion-location redirects~\cite{onion-location}, + third-party lists~\cite{onion-service-overview}, and + search engines like DuckDuckGo. +Prior work has also focused on enumerating onion addresses without any +associated identity, e.g., through CT-logged certificates with \texttt{.onion} +addresses~\cite{muffet-onions} and crawling~\cite{ahmia.fi,nurmi}. +Sauteed onions enhance onion location by making the claimed associations +transparent in CT, and facilitate third-party solutions with less blind trust +and without assumptions about TLS sites not becoming blocked in the future. + +Several ideas were proposed that mitigate or bypass the problem of +random-looking onion addresses. Some sites generate vanity addresses that, +e.g., start with a prefix and have other memorable traits~\cite{vanity-address}. +Fink sketched out how to map onion addresses to a set of words~\cite{fink}. +Kadianakis~\emph{et al.} defined a common API to hook into alternative +naming systems that give onion addresses pet names~\cite{kadianakis}. +SecureDrop Onion Names is one such example that is, however, +implemented directly +in Tor Browser as an HTTPS Everywhere ruleset for selected news sites. Other +alternative naming systems include Namecoin~\cite{namecoin} and +OnioNS~\cite{onio-ns}. Sauteed onions is also an alternative naming system, but +one that relies on CAs and CT logs. +It may be possible to construct sauteed onions via DNSSEC, but then relying on +the DNS hierarchy without transparency logging. +Scaife~\emph{et~al.}~\cite{onion-dns} proposed the \texttt{.o} TLD as an +onionsite with DNSSEC. + +Nordberg connected transparency logs and the consensus mechanism that Tor +uses~\cite{nordberg-tor}. Dahlberg~\emph{et~al.} proposed CT in Tor for all +certificate validations~\cite{ctor-popets}. We only check signatures of +embedded SCTs in relation to onion location, and our search engine is +a simple application of CT monitoring. +There is a large body of orthogonal work that improve CAs and CT. For example, +multi-path domain-validation makes it harder to hijack onion +associations~\cite{le-multi-path}, and deployment of gossip would harden our +CT log assumptions~\cite{chuat-gossip,nordberg-gossip}. diff --git a/summary/src/sauteed/src/sauteed.tex b/summary/src/sauteed/src/sauteed.tex new file mode 100644 index 0000000..06a581c --- /dev/null +++ b/summary/src/sauteed/src/sauteed.tex @@ -0,0 +1,260 @@ +\section{Saut\'{e} Onions Until Discovery is Transparent and Confection is Firm} \label{sauteed:sec:trans} + +\subsection{System Goals} \label{sauteed:sec:system-goals} +Let an onion association be unidirectional from a traditional domain name to an +onion address. Three main system goals are as follows: + +\begin{description} + \item[Privacy-Preserving Onion Associations] Users should discover the same + onion associations, and otherwise the possibility of an + inconsistency must become public knowledge. + \item[Forward Censorship Resistance] Unavailability of a TLS + site must not impede discovery of past onion associations. + \item[Automated Verifiable Discovery] Onion association search should be + possible without requiring blind trust in third-parties. It must be hard to + fabricate non-empty answers, and easy to automate the setup for scalability + and robustness. +\end{description} + +For comparison, today's onion location~\cite{onion-location} does not assure a +user that the same HTTP header is set for them as for everyone else. Classes of +users that connect to a domain at different times or via different +links can be given targeted redirects to distinct onion addresses +without detection~\cite{onion-discovery-attacks}. Onion location also +does not work if a regular site becomes unavailable due to censorship. +The \emph{search engine approach} is further a frequent ask by Tor +users~\cite{winter}. The solutions that exist in practice rely on +manually curated +lists~\cite{muffet-onions,onion-service-overview,h-e-securedrop}, notably with +little or no retroactive accountability. As specified above, we aim for a +similar utility but with a setup that can be automated for all onion +associations and without the ability to easily fabricate non-empty answers +without trivial detection. We sketch out how these security properties are +achieved in Section~\ref{sauteed:sec:security-sketch}. + +\subsection{Threat Model and Scope} \label{sauteed:sec:threat-model} +We consider an attacker that wants to trick a user into visiting a targeted +onionsite without anyone noticing the possibility of such behavior. Users are +assumed to know the right traditional domain name that is easy to remember (such +as \texttt{torproject.org}), but not its corresponding onion address. We +further assume that the attacker either controls a trusted CA sufficiently to +issue certificates or is able to deceive them sufficiently during certificate +issuance to obtain a valid certificate +from that CA\@. Any misbehavior is however assumed to be detectable in CT. So, +the certificate ecosystem is treated as a \emph{building block} that we make no +attempt to improve. + +We permit the attacker to make TLS sites unavailable after setup, but +we assume it is difficult to censor the CT log ecosystem because it can +be mirrored by anyone. Also, as part of the Internet authentication +infrastructure, adversaries may have equities conflicts in blocking CT logs, +and if concerned at all about appearance would have a +harder time justifying such a block versus, e.g., a political, +journalism, or social media site. +Similar to CT, we do not attempt to solve certificate revocation and +especially not in relation to certificates that are connected to +discovery of onion associations. This is consistent with Tor Browser's existing +model for revocation with onion location, which similarly depends on the +certificate for the redirecting domain. There is no formal counterpart to revoke +a result in a search engine, but we outline future work related to this. + +Our threat model includes countries that block direct access to HTTPS +sites~\cite{russia-blocks}. +This is arguably a capable attacker, as no country is currently known to +completely block indirect access via the Tor network (though in some places +Tor bridges and/or obfuscated transport is needed). Our threat model also +considers the plethora of blindly trusted parties that help users discover onion +addresses with little or no retroactive +accountability~\cite{ahmia.fi,muffet-onions,onion-service-overview,h-e-securedrop}. +In other words, it is in-scope to pave the path towards more accountability. + +\subsection{Description of Sauteed Onions} \label{sauteed:sec:sauteed-onions} +An observation that inspired work on sauteed onions is that onion +location requires HTTPS~\cite{onion-location}. This means that +discovery of onion associations \emph{already} relies on the CA ecosystem. By +incorporating the use of CT, it is possible to add accountability to CAs and +other parties that help with onion address discovery while also raising the bar +for censoring sites and reducing anonymity. The name sauteed onions is a cooking pun; +the association of an onion address with a domain name becomes transparent for +everyone to see in CT logs. + +For background, a CA-issued certificate can contain both a traditional domain +name and a \texttt{.onion address}~\cite{cab-ballot144,cab-onion-dv}. This can +be viewed as a mutual association because the issuing CA must verify the +traditional domain name \emph{and} the specified onion address. An immediate +problem is that this would be ambiguous if there are multiple domain names; +which one (if any) should be associated with an onion address with such +certificate coalescence? A more appropriate path forward would therefore be to +define an X.509v3 extension for sauteed onions which clearly \emph{declares that +a domain-validated name wants to be associated with an onion address}. + +We describe two uses of sauteed onions that achieve our goals; first assuming it +is easy to get CA-issued certificates that contain associated onion addresses +for domain-validated names, and then a short-term roll-out approach that +could make it a reality now. A sauteed onion is simply a CT-logged certificate +that claims \texttt{example.com} wants to be associated with +\texttt{<addr>.onion} but not necessarily the other way around, i.e., a +unidirectional association. + +\subsubsection{Onion Location} \label{sauteed:sec:onion-location} +Figure~\ref{sauteed:fig:onion-location} illustrates onion location that uses +certificates. A user establishes a TLS connection to a site as usual. Upon +encountering a certificate that is CT-logged with an associated onion address +for the visited site \texttt{example.com}, an onion-location prompt becomes +available in Tor Browser or the onion site is visited automatically. This is the same type +of redirect behavior as today's onion location~\cite{onion-location}, except +that the possibility of such a redirect is disclosed in public CT logs. +Attempts at targeted redirects would thus be visible to site owners and +independent third-parties. A redirect to someone else's onion address would +also be visible to the respective site owners. Notably the ability to detect +inappropriate redirects acts as a deterrence while also being the first step +towards remediation, e.g., if users bookmarked onion addresses~\cite{winter} +to achieve trust on first use or to avoid visiting a regular site \emph{and} an +onionsite in a way that might reduce a user's anonymity set. + +\begin{figure}[!t] + \centering + \includegraphics[width=.6\columnwidth]{src/sauteed/img/onion-location} + \caption{Onion location based on a CT-logged certificate.} + \label{sauteed:fig:onion-location} +\end{figure} + +A key observation is that onion location has always been a feature +facilitated by TLS. By implementing it in certificates rather than HTTP +headers that are delivered via HTTPS connections, TLS applications that are ``not +web'' can use it too without rolling their own mechanisms. The addition of +requiring CT to follow onion-location redirects is also an improvement compared +to today, although one that could be achieved with an HTTP-based approach as +well (or more ambitiously, for all Tor Browser certificate +validations~\cite{ctor-popets}). + +We prototyped the above in a web extension that is free and open +source~\cite{sauteed-onion-artifacts}. The criterion for CT logging is at least +one embedded SCT from a log in the policy used by Google +Chrome~\cite{chrome-logs}. If an onion-location redirect is followed, the +path of the current webpage is preserved, similar to a typical configuration of +today's HTTP-based onion location header that instead lists a complete +URL~\cite{onion-location}. + +\subsubsection{Search Engine} \label{sauteed:sec:search-engine} +A significant challenge for third-parties that help users discover TLS sites +that are available as onion services is to gain confidence in the underlying +dataset at scale. For example, SecureDrop onion names are scoped to news +sites~\cite{h-e-securedrop}; the list by Muffett is scoped as ``no sites for tech +with less than (arbitrary) 10,000 users''~\cite{muffet-onions}; and +\texttt{ahmia.fi} does not even attempt to give onion addresses human-meaningful +names~\cite{nurmi}. To make matters worse, solutions based on manually curated +lists and third-party search are currently implemented with little or no +accountability. + +Figure~\ref{sauteed:fig:search-engine} shows what our approach brings to the table. +All CT logs can be monitored by a third-party to discover sauteed onions. +A search API can then be presented to users for the resulting dataset, similar +to existing monitoring services but scoped specifically for discovery of onion +associations. The utility of such a search API is: +``\emph{what onion addresses are available for \texttt{www.example.com}}''. + +\begin{figure}[!t] + \centering + \includegraphics[width=.6\columnwidth]{src/sauteed/img/onion-search} + \caption{Verifiable domain name to onion address search.} + \label{sauteed:fig:search-engine} +\end{figure} + +The expected behavior of the search API is that an answer can not be fabricated +without controlling a CA or hijacking certificate issuance, and any CA +malfeasance should further be caught by CT\@. This +means that no party can fabricate inappropriate answers without detection. +This is a major improvement compared to the alternative of no verifiability at +all, although one that in and of itself does not prevent \emph{false negatives}. +In other words, available answers could trivially be omitted. This is a +limitation with the authenticated data structure in CT that can be fixed; see +security sketch in Section~\ref{sauteed:sec:security-sketch} for an intuition of how to +work around it. + +We specified an HTTP REST API that facilitates search using a domain name; the +API also makes available additional information like the actual certificate and +its exact index in a CT log. In total there are two endpoints: \texttt{search} +(list of matches with identifiers to more info) and \texttt{get} (more info). The +complete API specification is available online together with our implementation, +which is free and open source~\cite{sauteed-onion-artifacts}. An independent +implementation from Tor's hack week is also available by Rhatto~\cite{rhatto}. +Our prototype runs against all CT logs in Google Chrome for certificates +logged after July 16, 2022. A few query examples are available in +Appendix~\ref{sauteed:app:search}. + +\subsubsection{Certificate Format} \label{sauteed:sec:cert-format} +Until now we assumed that a sauteed onion is easily set up, e.g., using an +X.509v3 extension. The bad news is that such an extension does not exist, and +it would likely be a long journey to standardize and see deployment by CAs. +Therefore, our prototypes rely on a backwards-compatible approach that encodes +onion addresses as subdomains~\cite{once-and-future}. To declare that +\texttt{example.com} wants to be associated with \texttt{<addr>.onion}, one can +request a domain-validated certificate that contains both \texttt{example.com} +and \texttt{<addr>onion.example.com}~\cite{secdev19}. The inclusion of +\texttt{example.com} ensures that such a setup does not result in a dangerous +label~\cite{dangerous-labels}. The \emph{hack to encode an onion address as a +subdomain} makes it part of the certificate without requiring changes to CAs. +Appendix~\ref{sauteed:app:setup} details the necessary setup-steps further. The gist +is the addition of a subdomain DNS record and using the \texttt{-d} option in +\texttt{certbot}~\cite{certbot}. + +Although the subdomain approach is easy to deploy right now, it is by +no means a perfect solution. An X.509v3 extension would not require +the configuration of an +additional DNS record. In other words, the unidirectional sauteed onions +property works just as well if the subdomain is not domain-validated. The +important part is that the CA validates \texttt{example.com}, and that the +associated onion address can be declared somewhere in the issued certificate +without an ambiguous intent. +Another imperfection that goes hand-in-hand with backwards-compatibility is that +CAs would have to \emph{opt-out} from sauteed onions, unlike site owners +that instead have to \emph{opt-in}. + +To avoid recommending a pattern that is discouraged by CAs, the Tor Project +should at least have a dialog with Let's Encrypt which issues the most +certificates~\cite{le}. Somewhat similar subdomain hacks related to CAs exist, +but then with explicit negotiations~\cite{plex}. +Subdomain hacks without a relation to CAs and TLS were discouraged in the +past~\cite{trans-laurie}. We argue that sauteed onions is related because +CA-validated names are at the heart of our approach. For example, this is +unlike Mozilla's binary transparency idea that just wanted to reuse a public +log~\cite{mozilla-bt}. Sauteed onions also do not result in more issued +certificates; it is just the number of domain-validated names that increase by +one for TLS sites that do the setup. + +\subsubsection{Security Sketch} \label{sauteed:sec:security-sketch} +Our threat model disallows the attacker to tamper with CT and to make the log +ecosystem unavailable. Onion location as described in +Section~\ref{sauteed:sec:onion-location} therefore ensures that a redirect becomes +public, achieving detectability as defined in our privacy-preserving onion +association goal. The search engine in Section~\ref{sauteed:sec:search-engine} +trivially achieves the same goal because onion associations are \emph{found} +via CT. Blocking a TLS site is additionally \emph{too late} if an association +is already in a CT log, thus achieving forward censorship resistance. +Our search engine approach further makes it hard to forge non-answers without +detection because it requires control of a CA and defeating the tamper-evidence +of CT logs. While it is possible to omit available answers, this can be +mitigated by having multiple search APIs, domains that check the integrity of +their own onion associations similar to the proposed verification pattern in +CONIKS~\cite{coniks}, or to represent the sauteed onion dataset as a sparse +Merkle tree to get a verifiable log-backed map that additionally supports +efficient non-membership proofs that CT lacks~\cite{smt,vds}. + +\subsection{Future Work} +It would be valuable to implement proofs of no omissions as well as native +lookups in a web extension or Tor Browser to verify everything before showing +the user a result (certificates, proofs of logging, etc). The entire or +selected parts of the sauteed onion dataset may further be delivered to Tor +Browser similar to SecureDrop onion names~\cite{h-e-securedrop}. The difference +would be that the list is automated using a selection criteria from CT logs +rather than doing it manually on a case-by-case basis. A major benefit is that +the sauteed onion dataset can then be queried locally, completely avoiding +third-party queries and visits to the regular site. Another approach to explore +is potential integration of the sauteed onion dataset into Tor's DHT: a +cryptographic source of truth for available onion associations is likely a +helpful starting point so that there is \emph{something to distribute}. It +would also be interesting to consider other search-engine policies than +\emph{show everything} as in our work, e.g., only first association or last +association. (These policies can be verified with \emph{full +audits}~\cite{vds}.) |