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

[Alec Muffett <alec.muffett@xxxxxxxxx>]

On 10 August 2017 at 01:51, Dave Warren <davew@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk