[tor-talk] Motivations for certificate issues for onion services

[Roger Dingledine]

On Wed, Aug 09, 2017 at 03:53:59PM -0700, Seth David Schoen wrote:
>   There was also
> a long-standard concern about cryptographic strength mismatch in the
> sense that the cryptography used by onion services was weaker than the
> cryptography that's now used in TLS.  (I think this concern was misplaced,
> but I believe it's served as one of the main rationales for distinguishing
> EV from DV.)

Right -- I used to buy their reasoning, thinking "you're right, 1024-bit
RSA is indeed not as good as modern TLS, let's wait for the newer onion
design", but then I realized that they're comparing the *authentication
about whether you control the domain* step. That is, they are saying that
1024-bit RSA is not as strong as unauthenticated DNS and unauthenticated
BGP. Which is just nonsense.

At HotPETS this year we had a live demonstration, right there while
we all watched, of a BGP hijack on the real Internet, which obtained
a Let's Encrypt certificate for the hijacked domain. Piece of cake.
I'd say needing to factor a 1024-bit RSA, or needing to generate 2^80
keys to find one that matches the onion address you're trying to attack,
is still a much much higher bar.

> So, there has been a suggestion that this issue might be revisted with
> the next generation onion services because they have stronger
> cryptographic primitives.

Can you help me understand why this is not just more of the same poor
reasoning? One of the reasons we want to use modern TLS, i.e. get real
HTTPS certs, is to use those stronger cryptographic primitives. Waiting
for the stronger onion names is like saying you shouldn't be able to get
an HTTPS cert because we can't trust the DNS system -- and I don't hear
any of the CA vendors saying that.

>  Apparently these have now been not only
> implemented but actually demonstrated:
> 
> https://blog.torproject.org/blog/new-and-improved-onion-services-will-premiere-def-con-25
> 
> I'd like to prepare to raise this issue with the CA/Browser forum in
> anticipation of a ballot there to have it be possible for DV certificates
> to be issued to onion services.  So I wanted to ask two things here:
> 
> (1) What's the status of onion services looking like now?

The v3 onion service code is in the code review stage. The relay
side and HSDir side have been in place since Tor 0.3.0, and Nick just
merged the service-side code into master last night. There is a branch
("dgoulet/ticket17242_032_02") that implements the client side.

If you grab that branch, build it, and stick the resulting tor binary
into Browser/TorBrowser/Tor/tor in your tor browser, then you'll have
a tor browser which can successfully visit
http://7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion/

>  I haven't seen Roger's DEF CON talk.  (Was it recorded?)

It was recorded, and the Defcon people tell me that the video will be
appearing sometime in October or November.

> (2) What reasons do people have for wanting certificates that cover
> onion names?  I think I know of at least three or four reasons, but I'm
> interested in creating a list that's as thorough as possible.

I like Alec's list. Here's the subset of his list I find most compelling:

* We've taught users that https is what they should see in their browser
tab. Browsers are heading towards not letting you do stuff unless the
url says https. We can't, and shouldn't, fight that trend.

* Admins should be able to run their Tor onion service at a different
location than their webserver. "End to end" in onion encryption means
"Tor client to Tor client", but "end to end" in web encryption means
"Browser to Webserver". You should be able to have both. Never forget
the phrase "SSL added and removed here"!

* People who write complicated web services should be able to have very
simple "if it's not https, don't allow it" rules, and asking them to
create an onion-sized hole in their security rules is foolish and harmful.

It seems to me that an onion address, where you actually have a private
key that proves that you "are" the onion address, is a slam dunk for
a Domain Validated (DV) situation. It's exactly what everybody should
have wanted for DV certs from the beginning.

(In fact, technically speaking, there's no particular need to have a
trusted central third party do the validation, since onion domains are
*self* validating. If we made a tool to generate a cert chain using the
onion private key to certify the traditional TLS key, and we taught Tor
Browser how to verify those cert chains... we wouldn't need the sham
that is a DV certificate authority. But that is a different discussion. :)

--Roger