Crypto for hidden services [was: TorFaq on https]

[Robert Ransom]

On Thu, 28 Oct 2010 22:06:03 -0400
grarpamp <grarpamp at gmail.com> wrote:

> >>                            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.

Tor verifies that the hidden service's descriptor is signed by a private
key whose public key's truncated hash matches the hidden service
hostname.  For an HTTPS connection, your browser merely verifies that
some CA which the browser's developers have been paid to make users
‘trust’, whether directly or indirectly, has signed a certificate
claiming that the server's public key can be ‘trusted’ to serve a
particular hostname.  Tor's authentication of hidden services is better
than anything HTTPS can do.


> 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.

A clueless HS admin can publish all requests which reach his server
onto the Internet.  A malicious HS admin can forward all requests to
NSA, CIA, FBI, Mossad, GCHQ, and whatever other entities are out to get
you.


> Or that someone is able to read the particular crypto Tor uses, but not
> the crypto your tunnel uses.

I'm slightly worried about this, but I currently don't see any tunnel
software in use that uses cryptographic algorithms that I consider
stronger than Tor's.


> 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.

HTTPS to behind a HS costs the user rather a lot of effort, for
minimal, if any, benefit.  Thus, I would recommend that hidden services
not use HTTPS.


> > 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.]

I don't expect most users to verify SSL certificate fingerprints out of
band, whether ‘out-of-band’ means on the non-Tor Internet, over the
telephone network, or through the mythical DNSSEC.


> >>                                    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.

I thought of this, but the hidden service private key would be enough
of a giveaway.  Having a second private key around is no easier or
harder to hide than having the first private key around.


> >>   "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?

There is no real reason not to use another layer of cryptography on top
of Tor hidden services.  Using HTTPS, and convincing users to use
HTTPS, is far harder than merely using another layer of cryptography,
and provides no real benefit.


> 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.

We have a PKI for hidden services already, designed into the protocol.
I do not expect piling HTTPS on top of that PKI to add any security at
this time.


Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20101028/aae90617/attachment.pgp>