On 10 August 2017 at 01:51, Dave Warren <da...@hireahit.com> 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
