[tor-dev] Design for onionsite certification and use with Let's Encrypt

[Paul Syverson]

Hi Alec, Seth, Peter, Mike, all,

I'm enthused about the progress Alec reported about the Onion RFC for
certs for onion addresses in recent tor-dev posts and elsewhere.

I wanted to further discuss a design for binding .onion addresses with
registered (route-insecure) addresses. This ties in to in-person
discussions had with Seth, Peter, and Mike back in June about how this
all dovetails with Let's Encrypt and Tor Browser, which is why I am
also addressing this message to them directly. I hope they can comment
on whether this design seems realistic in that regard and any major
caveats, stumbling blocks, etc.

I'll start with a description of goals and complementarity comments
about readability of onion addresses themselves, and other recent
tor-dev discussion topics. 

I did a partially related post to tor-assistants on one-sided onion
services back in June that covered perhaps too many alternatives
concerning onion services and too many goals and too much of the
motivation, and none of that adequately separated. I think it left
most scratching their heads. This is an attempt to be a bit narrower
and hopefully clearer. Those not interested in even the briefly
described motivations and background set out here can skip below to
the high-level design itself.

Goals, Caveats, Complementarity to other recently discussed related topics

A main goal is to give people a way to provide route-secure access
to their websites in somewhat the same way that the current
certificate and https protocol infrastructure lets them provide
data-secure access to their website.

I would really like to have a version of this be an offering as part
of obtaining a certificate from Let's Encrypt because I would like it
to encourage people to offer route-secure versions of their sites in
the same way that Let's Encrypt as currently put forth is meant to
encourage them to offer data-secure versions of their sites. Having
this built into something like Let's Encrypt should make it easy for
users to set up onionsites to provide security for their websites.

The design should to be neutral between double onion services
(services where connections involve a Tor circuit from the client and
a Tor circuit from the server, such as the currently deployed design)
and single onion services (basically just having a Tor circuit from
the client). There's a draft Tor Proposal by John Brooks, Roger
Dingeldine, and me on single onion services that I believe John
should be making available soon, but I want to leave such details
aside. I'm taking single onion services as the paradigmatic typical
case, but unless it creates a big problem I would like to assume both
single and double onion services will be compatible.

Obviously an onion service tied to a registered domain doesn't cover
many important uses of onion services, but it should cover many
existing use cases. Note also that wanting to offer network-location
protection for a service can be compatible with having a registered
domain name for that service (and whether or not there was any attempt
to obscure information about the registrant of the domain name). In
some cases it is not compatible, but not necessarily.

I think this is basically complementary to ways to make onion addresses
more readable, recognizable. I'm OK with whatever an address is that will be
acceptable to the RFC and that maintains the current self-authenticating
property (not getting into quibbles about computational strength of that
self-authentication), as long as it remains something that will fit
into a cert as described below.

I'm also leaving as an extension mentioned at the end below, offering
an onion service for someone's site but not associated with a domain
name she has registered.  (E.g. an onionsite tied to Mary's Wordpress
Blog, with, e.g., the goal being more about guarantees of binding to
Mary than about guarantees of binding Wordpress.) I think that is
another important and useful case, which we discussed in our W2SP
paper, but I'd like to mostly leave it aside for now.

High-level Design

Creating the DV Cert

At least the same DV level of checking should occur as for existing
registered domain names. So the email check should include the
onion name that is being bound as well as the route-insecure name(s).
For simplicity, I am assuming a single onion address and possibly
a small number of registered domain names, although I'm guessing doing
this for a similarly small number of onion addresses might be made to work
as well. (I'm assuming no wildcards, but maybe I'm not being ambitious
enough.)

Besides a check at the registered-domain name(s) a check should also
be made that the onionsite verifies association with the
registered-domain site(s). It is not as reasonable to assume
email infrastructure exists corresponding to the onion address is in
place. Instead a validation query protocol will be needed that simply
connects to the onionsite and asks if it is acceptable to certify
association of the onionsite with the registered-domain(s).
Only if all DV checks complete successfully should the CA be willing
to issue the Cert.

The cert obtained will have the onion address listed as a SAN
(subjectAltName) in the certificate.

Connecting to an onionsite by the client

I assume that the default HTTPS-everywhere ruleset will be updated to
include a direction of route-insecure addresses to onion addresses
for sites that hold appropriate certificates. It would be reasonable
to have this update occur initially along with the certification
process.  HTTPS-everywhere rules should differentiate whether they are
being requested by Tor Browser or another browser. 

If by Tor Browser, I assume(?) the redirection is straightforward:
If a Tor-Browser request is to connect to a route-insecure address,
HTTPS-everywhere should redirect this to an onion address.
At that point everything should proceed as normal for connecting to
an onion address.

If another browser it could be a setup config option whether clients
can choose to be redirected via tor2web or simply always sent to a
route-insecure address. I will assume for simplicity that all requests
for route-insecure addresses by other browsers simply send to a
route-insecure HTTPS address in the ruleset (if available). I'm going
to also assume that requests for onion addresses for other browsers
simply fail, although if the tor2web option was available and chosen
at the time of setup, then there is another question how to offer this
to the client, perhaps as an HTTPS Everywhere setting.  Comments on
the feasibility, usefulness, design etc. of the tor2web option would
be bonus, but of course I'm most wanting to know about the viability
of the most basic version of things.


If the Tor-Browser request is to connect to an onion address, proceed
as normal except that it can now be redirected by HTTPS Everywhere to
an https connection to the address. Certified connection to such an
onionsite should work and be indicated as normal for any site with a
DV Cert.

End basic description

Web of trust extension

W had suggested in the w2sp paper that people could bind their
route-insecure address to their onion address with a gpg key.  One
rationale is that there is an existing web of trust that can be
leveraged, and existing mechanisms to do the verification.  This would
allow not just securing of human-meaningful addresses and connections
but also certification by more human-meaningful trust relations than
the usual CA.

It also allows things like binding a wordpress blog to an onion
address as mentioned above so people need not have a registered domain
to have a human-meaningful address for a route-insecure site for which
they would like to offer a route-secure alternative.

Drawbacks include:

1. There is no simple automated significant infrastructure to support
this. The Monkeysphere plugin is out there, and would probably be
leveraged to support something like this, but...

2.  PGP/GPG remains something of a geek tool. That is possibly changing
slowly, but perhaps it would be better not to wait for that. Also,
it's yet another thing to learn about, so...

If onion keys could be themselves linked in a PGP-like web of trust,
then this could be more directly relevant and meaning to people
operating on the web, especially those unfamiliar with PGP-like
notions.  This would of course require things like the check and
indication being either built into the browser or as a plugin. And it
would similarly for people deciding when to sign another's key require
an easy interface and easy to understand criteria as well as mechanisms for
that to all happen securely. I think this holds more hope for successful
widespread web of trust to complement the X.509 type trust hierarchy
that the PGP plan would support. How to decide whether a site is trusted
depending what each of these trust mechanisms indicate would also need
to be worked out and might again be configurable with standard defaults.