Re: [tor-talk] Finally a Cloudflare captchas workaround thanks to next-gen onion services?

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Mon, Feb 20, 2017 at 10:19:23AM +0000, Alec Muffett wrote:
> On 20 February 2017 at 09:45, Georg Koppen <gk@xxxxxxxxxxxxxx> wrote:
> 
> > I don't think so as I don't see how next generation .onion services
> > solve the underlying problem.
> 

Griffin Boyce and I published a paper not quite a year ago with a
section addressing this topic.  It covers much of the same ground as
Alec's fine post (still included below), give or take a few points.
And it supports the statements of the OP about cryptographic strength
and onion addresses. As we note, I can't make sense of the objections
to DV certs even given the weaker cryptographic strengths prior to the
changes. They would still be an effective strengthening over the
status quo ante. In case it's useful, I'm including that short section
just below.

As to the main question asked about whether this could solve
issues/concerns with Cloudflare captchas, my guess is it's just a bit
early in these developments to do more than speculate.

aloha,
Paul

---------------------------------
An Onion by Any Other Name Would Cert as Sweet

So, why not just permit onion addresses to be used as names in
certificates? CA/Browser Forum discussions have raised two broad
classes of objections.  First, currently deployed onion addresses and
protocols rely on SHA-1 and RSA-1024, both of which have reached the
end of their effective cryptographic security. But Tor client and
relay software has transitioned in stable releases to SHA-256 and
ed25519, which are adequate for the foreseeable future. And Tor is
expected to transition onion services to these cryptographic
primitives within the year.  Therefore, any valid objections based on
this concern will be short-lived. More important, when combined, onion
protections can only add to TLS and certificate protections. Breaking
the private RSA-1024 key associated with an onion address that has an
appropriately stronger TLS key and certificate doesn't, by itself,
allow an attacker to subvert a certifed TLS session with the
onionsite. Conversely, MITM, cipher degradation, or other certificate
or TLS instance attacks aren't possible with onion addresses unless the
attacker also breaks the self-authentication.

Second, for various reasons, some individuals support a CA's ability
to link real-world identities to issued certificates, as occurs when
validating registered domain names. This is why only EV certificates
have been approved for onion addresses. But the described design
proposes that a DV certificate for an onion address be issued only when
it's fully bound to a registered domain name and validated by the same
process as for the registered domain name. Whatever benefits such
linking provides is supported as strongly for the onion address as for
the registered domain name alone.
---------------------------------

> 
> I believe they are referring to something which I have also heard from CA/B
> Forum, regards SSL certificates.
> 
> There's a general perception in industry - with some justification - that
> goes:
> 
>   SHA1 is bad.
>   And current Onion addresses are based on SHA1.
>   And they're only 80 bits, truncated SHA1.
>   So current onion addresses are bad, too.
>   Because a bad person could brute-force an 80 bit collision to hijack an
> onion address.
>   And that would be bad.
>   Also, it would be way easier** than (say) social-engineering a CA to
> issue a certificate to a fake or phishing site.
>   Because that never** happens.
> 
> So: industry thinks that 80-bit cryptographic addresses are
> brute-forceable, thus will not issue DV SSL certificates for them.  Instead
> they will only permit EV certificates to be issued.
> 
> After all, having trivially** collided an 80-bit hash and set up your fake
> Facebook Onion, you don't want some CA's automated
> "URL-secret-cookie-reachability"-based certificate generator to blindly
> issue an SSL certificate for the fake onion, thereby putting the SSL stamp
> of approval on the site;  that would be bad.
> 
> Hence EV, which requires a more intimate relationship with the requester,
> to mitigate this tremendous** security risk.
> 
> I suspect that the OP is pointing out that Prop224, with its 256-bit onion
> addresses, will be much more resistant to brute force and therefore may be
> more broadly acceptable to the trust/comms industry.
> 
>     -a
> 
> 
> ** your mileage may vary.
> 
> -- 
> 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
> 
-- 
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