[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Crypto for hidden services [was: TorFaq on https]
- To: or-talk@xxxxxxxxxxxxx
- Subject: Crypto for hidden services [was: TorFaq on https]
- From: grarpamp <grarpamp@xxxxxxxxx>
- Date: Thu, 28 Oct 2010 22:06:03 -0400
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Thu, 28 Oct 2010 22:06:12 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=AypUgCpelwXPFBrTSvDgYQWSJQsVkjKtS6mxn8H1fUY=; b=otsUV6JRjayDzxEwaUkczktsMwcsrTUxsi3efBnaB4QU1j0bQTp5CvEyEUOcLNhOVH WKlyhu+78OcJWfFjR8Zil3SAEao/1E44Nrt/DdpEF+ZF7wZhWP9M8Ia2nmbOhdbyNQHS rO63Lae3ed2ZKOGL04c9E8hI4jas7XvWYWPno=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=uRaJQrELSDwjxkYhNvM5KVnhSQot0eBJZCPexPD3NOYNwzjTYO7X2AfBCcWGGB2iz1 2GLA3GuPA75uA6njiiaw6bE4A+RbEpLgf74elKU9y0OyBCkhAhxSfXWVq3qRS0SRdGKP ldG+wXCqvxGKdtBT9K46fNyvoSy6fX2y7Rjik=
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
>> or is it still the general recommodation to
>> run hidden services without https?
> I would recommend that hidden services not use HTTPS. The Tor hidden
> service protocol does an adequate job of authenticating servers and
> encrypting traffic to them.
In the hidden service context for all below...
Tor does NOT authenticate any particular underlying service [web, mail, etc],
nor does it encrypt traffic to/from them.
Tor merely authenticates and encrypts between two Tor daemons, one
as a client and one as a HS.
Give an elaborate setup behind a HS, perhaps tunneling the stream
off the server, across the net, to other parties who terminate it on some
daemon or cloud. Maybe some WikiLeaks form of submission/storage, or
joining anon systems, or just a clueless HS admin.
Or that someone is able to read the particular crypto Tor uses, but not
the crypto your tunnel uses.
Would you, or the provider of the intermediate or final services, not want
that extra layer of protection just in case? Your bank in it's internal cloud?
SSH/IRCS/SILC to behind a HS is an extra tunnel. It costs nothing. Were it
still available, no one in their right mind would use ssh -c none.
> In addition, it is unlikely that any CA
> that Firefox is configured to trust would issue a certificate for
> a .onion hostname.
Perhaps, and quite unfortunately, not. However, even though the
chain would break on the hostname, it would still be of supplementary
value if some dual-homed site of importance to the user ran with the
same cert [fingerprint] as on the internet. Especially given that the
prevalence of the below aside is presumed to be extremely low.
[aside: As DNSSEC is not global yet, multi-homing a non onion cert would be
on the same par as a bogus/stolen cert and mitm dns, for say your bank.]
>> is the server (hidden service)
>> privacy threatened by using https too in any way?
> I don't see any risk to the server.
Not particularly. Though it would add additional fingerprinting
oppurtunities beyond Tor and the service themselves. This is
the only one I can think of.
>> "These objections all apply to HTTPS, TLS, SSH, and generally all
>> cryptography over Tor, regardless of whether or not the destination
>> is a hidden service"
The whole, well we've got the anon system doing node to node
encryption/auth, why bother with TLS... sounds an awful lot like
why Johhny can't encrypt and why the internet still isn't encrypted.
As there doesn't appear to be any real reason NOT to use crypto
over top of any given anon system, might as well do it just in case.
Foregoing extra 0-day's in crypto libs as applied, and the above
fingerprinting... why pan it?
And PKI, even amongst the anon, can be very useful thing. Communuties
will be built, PKI will help. It's no different than the internet.
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/