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

[Alec Muffett]

On 10 August 2017 at 01:51, Dave Warren  wrote:

> On 2017-08-09 16:53, Seth David Schoen wrote:
>
> Notably, it doesn't apply to certificate authorities that only issue DV
>> certificates, because nobody at the time found a consensus about how to
>> validate control over these domain names.
>>
>
> I don't completely understand this, since outside the Tor world it's
> possible to acquire DV certificates using verification performed on
> unencrypted (HTTP) channels.
>


I can explain this.

I don't agree with it, please don't argue with me, it was a CA/B-forum
argument, I am not a member of CA/B-forum, please don't blame me, etc...

Also: the argument is gonna be redundant real soon, so there's no point in
kicking a dead whale along the beach.

Seth has not quite framed the issue properly.

The CA/B-forum argument against issuing DV SSL Certificates to 80-bit
onions, goes like this:

- SHA1 is bad, m'kay?

- And Onion addresses are truncated SHA1

- So maybe someone could brute-force a collision, using bad SHA1, to
generate their own "facebookcorewwwi" onion certificate?

- And the thing about DV certificates is that they can be validated via a
simple HTTPS request loopback, m'kay? (eg: LetsEncrypt)

- So someone generates their own Facebook Onion certificate, sets up an
onion site, and requests and receives a DV certificate via some automated
process

- And ZOMG this means that SSL will be no longer be perceived as the
snow-white, unimpeachable source of trust that it currently is

- Therefore: force Onions to use the EV process so that the SSL Issuer *IS
REALLY SURE* that it is Facebook who is asking for the certificate, not
some SHA1-hacker

- And please: nobody point out that equivalent problem in the DNS namespace
means that the entirety of SSL's trustworthiness is (in truth) slaved to
the ability to revoke a DNS record when someone sets up a fake site.

That's it.

All of it.

Put sarcastically but accurately.

There's no point in arguing about it, as geeks so often enjoy.

It's over, we can move on, and - as Seth rightly points out - with Prop224
the root of this argument (the SHA1 dependence) simply vanishes, taking the
entire rest of the house of cards with it.



> Wouldn't the same be possible for a .onion, simply requiring that the
> verification service act as a Tor client? This would be at least as good,
> given that Tor adds a bit of encryption.


Like I say: it's past, we should all move on and be grateful for having got
here at all.  I know I am, and that I never want to have to deal with the
above argument ever again.

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Ben Tasker]

On Thu, Aug 10, 2017 at 2:53 AM, Roger Dingledine  wrote:

>
> * 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.
>
>
For me, this is a primary motivation in wanting a DV cert.

A number of my sites (for example https://www.bentasker.co.uk) are
dual-homed between the WWW and Tor (it's also at
http://6zdgh5a5e6zpchdz.onion/ ). I terminate the client's plain HTTP and
then use HTTPS for the backhaul to the webserver(s), which in principle
feels wrong

Of greater concern to me, though, is it means there are various things that
I either can't do or are fairly risky to do. Even down to simple things
like adding HSTS headers to the site - if I miss stripping just one on the
torified end then bad things are going to happen. It also means I can't
mark cookies as secure only (not such an issue on the site above, but can
be an issue elsewhere).

For my own site, I don't need the anonymity (it's plastered with my name,
so, yeah), I *could* get an EV, the barrier there is the price - it's just
not (IMO) worth it, especially when you start talking about multiple
different sites. But, the "cost" I'm paying at the moment is increased
complexity in my config and back-end, increasing the risk of me having made
a mistake somewhere in there. And that's for a fairly simple (functionality
wise) site with an off-the-shelf CMS as the backend. It can easily get more
complex (further raising the risk).

As Alec alluded too, there's also a trade-off. Either your tor endpoint
talks to the backend via HTTP, or (as I do) you use HTTPS for that
backhaul, but then have to monkey about in the back-end to have it know
that although the connection appears to be HTTPS there's a whole host of
things that you cannot use.


> - access to secure-locked protocols like WebRTC

This too, and as I understand it (unless things have changed), Firefox's
intention going forward is to increase the number of features that are
HTTPS only. Which isn't necessarily a bad thing, but it does mean that
useful features may increasingly become unavailable to hidden services. For
a multi-homed site, that's something of an issue because you then have to
decide whether to not use those features at all, or to further complicate
things by only using them on the non-Tor connections (and put up with user
complaints that X should be available via Tor too).




> 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.
>

When you look at the acceptable steps for proving control of a domain, on
the clearnet, yeah. Simply putting a specific file in a specific place is
sufficient for validation nowadays, despite the relative ease of messing
with DNS and BGP for long enough to pass the 'test'. In comparison, having
to have the correct key seems like a much higher burden of proof.




>
> (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
>
> --
> tor-talk mailing list - tor-talk@lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>



-- 
Ben Tasker
https://www.bentasker.co.uk
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Seth David Schoen]

Dave Warren writes:

> I don't completely understand this, since outside the Tor world it's
> possible to acquire DV certificates using verification performed on
> unencrypted (HTTP) channels.
> 
> Wouldn't the same be possible for a .onion, simply requiring that the
> verification service act as a Tor client? This would be at least as good,
> given that Tor adds a bit of encryption.

I think Roger's reply to my message addresses reasons why I think this
is a good argument, and I'm in agreement with you.  However, with
next-generation onion services, it should no longer be necessary to have
any form of this argument.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [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

-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Dave Warren]

On 2017-08-09 16:53, Seth David Schoen wrote:


Notably, it doesn't apply to certificate authorities that only issue DV 
certificates, because nobody at the time found a consensus about how to 
validate control over these domain names.


I don't completely understand this, since outside the Tor world it's 
possible to acquire DV certificates using verification performed on 
unencrypted (HTTP) channels.


Wouldn't the same be possible for a .onion, simply requiring that the 
verification service act as a Tor client? This would be at least as 
good, given that Tor adds a bit of encryption.


--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Alec Muffett]

(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.


Six to start with:

- not having to rewrite CMS code which assumes HTTPS, eg for secure
cookies; the Onion acts as a straight deployment on a new domain name

- corollary: not having to lobby browser manufacturers to pollute their
code to understand that http under this magical "onion" TLD is somehow
almost but not entirely treatable like https.

- access to secure-locked protocols like WebRTC

- protection of traffic for the link between Tor daemon (basically a
reverse-proxy) and the site load-balancer fanout in enterprise deployment

- user expectation for padlocks, consistency rather than special-snowflake
creeping featurism

- EV: attestation.

-alec
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

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

[Seth David Schoen]

Hi folks,

For a long time, publicly-trusted certificate authorities were not
clearly permitted to issue certificates for .onion names.  However, RFC
7686 and a series of three CA/Browser Forum ballots sponsored by Digicert
have allowed issuance of EV certificates (where the legal identity of
the certificate requester is verified offline before the certificate is
issued).  This has allowed Digicert to issue a number of such certificates
to interested (extremely non-anonymous!) onion service operators.

https://crt.sh/?Identity=%25.onion

So far Digicert is the only browser-trusted CA to have taken advantage of
this policy.  Notably, it doesn't apply to certificate authorities that
only issue DV certificates, because nobody at the time found a consensus
about how to validate control over these domain names.  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.)

So, there has been a suggestion that this issue might be revisted with
the next generation onion services because they have stronger
cryptographic primitives.  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?  I haven't
seen Roger's DEF CON talk.  (Was it recorded?)

(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.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk