[cabfpub] Personal Certificates for ".onion"

Fri Nov 6 08:49:55 MST 2015

Alec,

Various design and security considerations went in to the choice of
proposing EV for .onion. It wasn't necessarily meant to be the only way to
obtain HTTPS certificates for .onion domains, but as a means of assuring
(CAs, relying public) the balance of risks.

While not fundamentally opposed to exposing .onion for all (including DV),
here's a set of considerations that went in to the design and discussion:

- At Google, we were (and are) concerned with the cryptographic strength of
the .onion naming scheme, which employs both SHA-1 and RSA-1024. While only
the TOR authors can properly mitigate these attacks on a long-term basis,
the TOR Service Descriptor extension, combined with Certificate
Transparency, can at least shed light onto these attacks, since if the SD
differs-but-still-validates, then it's proof of an attack on SHA-1, and if
an unauthorized-but-valid cert appears in the CT logs, then it's proof of a
factoring attack on SHA-1. If allowed for any other types of certs, at
present, then these mitigations would not necessarily be viable.

- Related to that first point, the choice of EV discourages attackers
making such cryptographic attacks against sites operating .onion sites, as
it requires some form of identity validation of who the attacker is, even
if they have the cryptographic resources to mount such an attack. The goal
of supporting those without linking real-world identities (such as via
Richochet) is admirable and entirely understandable within the goals of
TOR, yet it also significantly increases the risk for those who presently
have .onion certificates, as it would be easier and viable for attacks
against them to remain unattributed. I don't mean to suggest that EV is
perfect at a defense against this, but, and especially combined with the CT
requirement, subversion of a CA's process for issuing an EV cert would be a
serious blow to the credibility and trust of that CA, and potentially lead
to it becoming untrusted.

- While this is a position that we (Google) generally disagree with, many
CAs feel that it should be their responsibility to police subscriber's
content and revoke certificates whose content they (or their governments)
disagree with. In general, and thankfully, this has primarily been limited
to malware and phishing sites. Since CAs view this as a guarantee being
offered by SSL (that the site is 'safe', for some nuanced definition of
'safe'), allowing a wild world of unattributable certificates is
challenging to them. Note that some of these CAs have opposed DV at all, or
have looked for means to make DV non-desirable (such as through
restrictions on wildcards, shortened validity periods, or increased
requirements). All of this is captured in past minutes and discussions of
the Forum, and while I suspect there will be some disagreement on the
'intent', the effects of such proposals are clear. Because of this concern,
it's likely that .onion certificates for anything less than
strongly-validated corporate identities will be opposed on the principle of
'protect the users', an unfortunate mismatch for the guarantees that
SSL/TLS is meant to provide, but alas, a deeply held belief for some.

So in contemplating a solution of how to make HTTPS for .onion domains more
accessible - an entirely reasonable and extremely worthwhile goal - these
concerns must be taken into consideration and balanced. I don't believe
that an AV (I'm surprised to see that term; it's not in wide use) or IV
cert may necessarily or reasonably help balance those concerns, but
hopefully it provides further insight into the considerations and thoughts
behind the current support, so that yourself or others might be able to
provide a solution to thread those needles.

On Fri, Nov 6, 2015 at 7:24 AM, Ryan Sleevi <sleevi at google.com> wrote:

> Forward on behalf of Alec
>
> ---------- Forwarded message ----------
> From: Alec Muffett <alec.muffett at gmail.com>
> Date: Fri, Nov 6, 2015 at 7:20 AM
>
> Hi CA/Browser Forum!
>
> I'm a software engineer and one of the authors of RFC 7686[0]; since 2001
> I have maintained a personal blog[1] and it's overdue for a complete
> software refresh. I want to take advantage of Let's Encrypt[2] to provide
> normal HTTPS certificates for the blog, and I want a 100% HTTPS deployment
> when I am done.
>
> I intend also to provide my blog with an Onion Address, thus my question:
>
> On my blog I do not represent a company - I act purely as an individual; I
> expect to easily get a "normal" domain-related certificate from Let's
> Encrypt, but as an individual I will not be able to get an EV certificate
> for my Onion Site as mandated by CA/B Forum Ballot 144[3].
>
> This situation inhibits me from protecting my personal blog's Onion Site
> with some form of Onion HTTPS certificate.
>
> It further discriminates against my choice of software deployment as an
> individual.
>
> Perhaps I could run my blog as HTTP-over-Onion and HTTPS-over-Internet,
> but this breaks my goal of a 100% HTTPS deployment. Clients of my Onion
> Site would not have access to HTTPS-only "Secure" cookies and other
> functionality which browsers today (or will soon) restrict to HTTPS[4]
> sites, e.g. Camera & Microphone access. This would be an undesirable lack
> of consistency.
>
> It is not viable to hack the Tor Browser to support an "Onion-only" CA,
> because only some portion of Tor traffic uses the Tor Browser; non-browser
> apps which use Tor would not be able take advantage of such a kludge, and
> thereby would not see the benefit of SSL.
>
> In any case, ".onion" is now an official special-use TLD, and therefore
> should be supported by official means.
>
> After a hint from Ryan Sleevi - plus referring to the Mozilla CA
> glossary[5] - I did some research and think that I need either an AV
> (address validation) or an IV (individual validation) SSL Certificate for
> my personal blog's Onion Site.
>
> Discussing likely use cases with Runa Sandvik[6], we believe that people
> who use Tor desire (at least) all of privacy, anonymity and integrity. The
> option that seems most sympathetic to all of these requirements is the AV
> (address validation) certificate. An AV certificate would provide an Onion
> Address with an SSL certificate (and thus a form of persistent identity)
> corresponding simply to an RFC822 email address. This would appear
> extremely well-suited to users of Onion-backed instant messenger software,
> such as Ricochet[7], especially those communicating without reference to
> "real world" identities.
>
> The alternative of an IV (individual validation) certificate appears
> closer to the goals of the EV certificate, being a more expensive "absolute
> identity" certificate that would (per the Glossary) require "a Driving
> License, Passport, or National Identity Card" to get. This would be useful
> for instances where people wish to publicly attest to ownership of what
> they write / blog / post / publish, but would be less useful e.g. for
> whistleblowers operating in repressive regimes.
>
> Frankly I see a need for both, and would be (for this case in point) happy
> to get one of either, but am also open to other alternatives which would
> not require me to register a company to bootstrap.
>
> So, finally, the question: how may I go about obtaining a suitable,
> personal, Onion-capable SSL Certificate for my blog, please?
>
> - Alec Muffett, London
>
>
> [0] https://tools.ietf.org/html/rfc7686
> [1] http://dropsafe.crypticide.com/
> [2] https://letsencrypt.org/howitworks/
> [3]
> https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
> [4]
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> [5] https://wiki.mozilla.org/CA:Glossary
> [6] https://twitter.com/runasand/status/662341004373204993
> [7] https://ricochet.im/
>
> [ This e-mail is also posted at
> http://dropsafe.crypticide.com/article/11697 with additional context ]
> --
> http://dropsafe.crypticide.com/aboutalecm
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151106/21e00eab/attachment-0001.html 