Re: [tor-talk] Ordering a .onion EV certificate from Digitcert

[Aymeric Vitte <vitteaymeric@xxxxxxxxx>]

Whether we follow the logic completely (all TLS with valid certificates)
and we have a solution for all cases, whether we don't, and currently
the W3C folks don't (WebRTC example) and forbid other things not
explaining clearly why.

I will not start a CA model discussion again, but the unanswered
question in the thread was: what can ws with https hurt exactly and why
are we obliged to use insecure http with ws? Knowing that the benefit of
wss over the Tor protocol is null and that the future of browsers is
certainly not to continue discussing with good old websites.

So the subsequent question was: what can we do for browsers to discuss
with entities that can't have valid certificates?

Maybe it's out of the scope of this discussion but if this "all TLS"
trend is confirmed flashproxy is going to have a problem too.

Le 16/12/2015 11:14, Ben Tasker a Ãcrit :
>> For what use exactly? ie why people should want a TLS certificate for a
>> .onion, which by definition is something not tied to an official
>> "domain", like anything that has no other choice than using self-signed
>> certificates?
> 
> The benefit of a publicly signed certificate over a snake-oil certificate
> is obvious,
> so I guess you're asking why a hidden service would want TLS?
> 
> There are a bunch of potential reasons an operator _might_ find it
> desirable,
> one of which you've alluded to in that thread.
> 
> - E2E encryption if the HS' tor client is running on a different box to the
> service
> - Additional confirmation that you're talking to the hidden service you
> expected to
> - An additional layer of encryption if that provided by Tor is ever found
> inadequate
> 
> But as time goes by, there's an additional reason - availability of
> features.
> 
> Mozilla announced a while back that certain features were going to be gated
> on
> https availability - i.e. a HTTP only onion won't be able to benefit from
> them.
> 
> https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
> 
> Personally, I think it's a bad idea, as (depending on the feature) it's
> effectively
> punishing the user for a decision taken by a website they have no control
> over. But
> it does mean in the future there may potentially be thinks a HS operator
> want's to
> take advantage of and can't.
> 
> 
> 
>> I personally think the CA mechanism is broken, so letsencrypt would be
> the better
>> choice of the bad ones.
> 
> The problem is, letsencrypt doesn't help with a lot of the issues I see
> coming from
> the broken CA structure. Your personal data has less exposure (because
> you're
> not giving it to them), but there's still no protection against a
> broken/compromised
> CA issuing a certificate for your domain, for example.
> 
> Worse, because letsencrypt insist on that 90 day renewal, things that could
> help defend
> against that scenario (like key pinning) aren't really an option because
> the windows
> are too tight. There are ways around that (like not regenerating keys) but
> it potentially
> opens you up to other things.
> 
> Letsencrypt addresses some of the issues with the CA model, but IMO they've
> also
> managed to effectively worsen some of the issues I'm more concerned about.
> 
> 
> 
> 
> 
> 
> 
> On Tue, Dec 15, 2015 at 9:24 PM, Aymeric Vitte <vitteaymeric@xxxxxxxxx>
> wrote:
> 
>> For what use exactly? ie why people should want a TLS certificate for a
>> .onion, which by definition is something not tied to an official
>> "domain", like anything that has no other choice than using self-signed
>> certificates?
>>
>> Something can be done to verify that someone owns the .onion "domain"
>> and probably we should study this (for letsencrypt for example) and get
>> rid of this notion of "domain" which is obsolete, please take a look at
>> this thread
>> http://lists.w3.org/Archives/Public/public-webapps/2015OctDec/0205.html
>> (follow the previous posts if you have time, this addresses the very
>> same problematic, including letsencrypt), still not convincingly
>> answered (despite of the fact that the W3C obviously does not follow its
>> security policy for WebRTC), since people there seem to find a kind of
>> funny the Tor protocol but, happier for the planet, succeeded to secure
>> it with a fb .onion certificate.
>>
>> Le 15/12/2015 17:09, Fabio Pietrosanti (naif) - lists a Ãcrit :
>>> Hello,
>>>
>>> we asked on Twitter to Digicert to provide a quick guide on how order an
>>> x509v3 certificate for TLS for a .onion, they've just published this
>>> small guide:
>>> https://blog.digicert.com/ordering-a-onion-certificate-from-digicert/
>>>
>>> Hopefully other CA will follow and at a certain point letsencrypt too.
>>>
>>
>> --
>> Get the torrent dynamic blocklist: http://peersm.com/getblocklist
>> Check the 10 M passwords list: http://peersm.com/findmyass
>> Anti-spies and private torrents, dynamic blocklist:
>> http://torrent-live.org
>> Peersm : http://www.peersm.com
>> torrent-live: https://github.com/Ayms/torrent-live
>> node-Tor : https://www.github.com/Ayms/node-Tor
>> GitHub : https://www.github.com/Ayms
>> --
>> 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
>>
> 
> 
> 

-- 
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
-- 
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