TLS for the link handshakes/encryption
nickm at alum.mit.edu
Tue Sep 2 16:55:50 UTC 2003
On Tue, 2003-09-02 at 01:51, Roger Dingledine wrote:
> I think we should definitely look into tls for the OR link-level
> encryption/auth. Stunnel looks like it has some not-too-crazy code we
> could use (albeit gpl).
Or we can write it ourselves. We're already using OpenSSL, after all.
It's not so hard to do.
> On the other hand, doing all the ssl hoops looks like about as much (or
> more!) code as just doing the handshakes ourselves (that is, calling
> each step of the openssl library).
I don't believe this is so. There are a few magic words you need to
say, but those magic words are easily abstracted and not very hard to
do, so long as you don't take X.509 too seriously.
> I think much of the ssl calling
> overhead is for sessions, etc, which I don't think we need to worry
> about. Nick: you've got some experience with ssl/tls from minion --
> what's your impression here?
I'd say go for it, for the link encryption. TLS isn't hard to use, and
would give us a lot of what we want.
> Also, are there tls libs that play well
> with asynchronous systems, or do they demand a separate thread/process?
AFAIK, they *all* do fine with asynchronous systems. The three that I
know of are OpenSSL, GnuTLS, and NSS. I don't know much about the state
of GnuTLS. NSS is not an option until it supports the server side of
Diffie-Hellman key agreement.
> Which brings me to my next realization: we've been planning to split
> out a couple of cpu worker processes (threads on windows) to do the
> heavy crypto lifting, eg public key decryption. Rather than keeping our
> crazy asynchronous logic in connection_or.c, why not simply hand the
> newly accepted socket to a worker, and after a while he informs you
> that it's now in the 'open' state? (And he hands back the necessary
> crypto material.)
You can't pass sockets across processes. If we want to do that, we'll
need to become multithreaded even on Unix. Not impossible, but a little
dodgy considering the state of pthreads implementations on all the weird
hardware we may need to consider.
> Whether we use fullblown TLS or just the subset of it that we need,
> this is something worth considering.
IMO we need most of TLS, and we're better off using it than handrolling
a subset. On links, we want two-way authentication with ephemeral keys,
link encryption, data integrity, and occasional key rotation. The parts
of TLS we wouldn't necessarily need are ciphersuite negotiation,
sessions, support for octet-streams (since we only want cell-streams),
and all the weird corners of X.509.
More information about the tor-dev