SSL fro hidden services

[Christian Beil]

Thanks guys for the speedy answers. I think I see now.
So there is not even one node which sees cleartext messages, not even 
the rendezvous point, because there is a DH handshake.
That means there is not really a need for another encryption layer.
And authentication of the hidden service doesn't make sense. You can 
already trust to be talking to this .onion, because you use its public key.
What would the benefit be that I can be sure to talk to some .onion.

Matthias Fischmann schrieb:

>On Thu, Oct 20, 2005 at 09:26:59AM -0400, Paul Syverson wrote:
>  
>
>>To: or-talk at freehaven.net
>>From: Paul Syverson <syverson at itd.nrl.navy.mil>
>>Date: Thu, 20 Oct 2005 09:26:59 -0400
>>Subject: Re: SSL fro hidden services
>>
>>It's unnecessary. All communication is over Tor circuits that are
>>    
>>
>
>this claim is true under the assumption that tor doesn't have another
>bug that invalidates it, or will ever have.
>
>especially if you use an ssl implementation for the hidden service
>that is different from the one used by tor (openssl.org), you will
>achieve higher *expected* security.  the additional workload of course
>is quite high for this marginal gain, but that's matter of taste.
>
>i believe that the overhead of double-ssl is shared between hidden
>service and the tor client machine, and nodes won't notice the
>difference.  (please correct me if i'm wrong.)
>
>cheers,
>matthias
>
>
>
>  
>
>>created at both ends of the communication which are mated at an
>>Introduction Point to establish contact and at a Rendezvous Point to
>>pass data. So even the edges of the communication (between client and
>>Tor network, and between hidden server and Tor network) are multiply
>>encrypted.
>>
>>-Paul
>>
>>On Thu, Oct 20, 2005 at 09:22:18AM -0400, Dan Mahoney, System Admin wrote:
>>    
>>
>>>On Thu, 20 Oct 2005, Christian Beil wrote:
>>>
>>>      
>>>
>>>>Is it possible to access hidden services using SSL? Does this make sense 
>>>>at all?
>>>>        
>>>>
>>>You can certainly use https, and port 443.
>>>
>>>That said, the certificate naming scheme may be way off, since there's no 
>>>concept of a valid certificate (I doubt verisign will want to sign one for 
>>>786237261871621.onion :)
>>>
>>>However, assuming the user installs your self-signed cert, it *should* 
>>>work the same unless there's something I'm missing.)
>>>
>>>Of course, you're really just protecting content from being sniffed 
>>>between the user and the entry node (usually, the same machine, but not 
>>>always), and the exit node and the hidden service (presumably, you control 
>>>both).
>>>
>>>This is my understanding of it -- if someone has a better one please step 
>>>on me without hesitation :)
>>>
>>>-Dan
>>>
>>>--
>>>
>>>"One...plus two...plus one...plus one."
>>>
>>>-Tim Curry, Clue
>>>
>>>--------Dan Mahoney--------
>>>Techie,  Sysadmin,  WebGeek
>>>Gushi on efnet/undernet IRC
>>>ICQ: 13735144   AIM: LarpGM
>>>Site:  http://www.gushi.org
>>>---------------------------
>>>      
>>>