[Replying to or-dev with permission from Paul.]
On Wed, Feb 28, 2007 at 07:24:55PM -0500, Paul Syverson wrote:
> Since we now also use entry guards, a client will typically always
> have a circuit open to one or more of its guards. If guards are up and
> stable, this could mean that my client could have a Tor circuit open
> through each of them persistently for an extended period.
>
> My first question is:
> If a client has an existing circuit open to a node, does it open a new
> TLS connection to open a new circuit through that node or does it
> multiplex over the old one.
It uses the same TLS connection.
> If the latter, then even if I press my
> nifty "new identity" key on my Vidalia, I am still potentially relying
> on protection from the same old TLS that might have been up for what?
> weeks?
There's a constant in main.c called TIME_BEFORE_OR_CONN_IS_OBSOLETE.
After that time, we mark a TLS connection as "obsolete" and we don't
attach any more circuits to it. Once the last circuit has closed, the
connection dies too.
I can't find this in behavior the spec, though. Maybe it's in there;
maybe there needs to be a patch to add it.
Also, the current value of TIME_BEFORE_OR_CONN_IS_OBSOLETE is one
week; this could reasonably be cranked down a bit.
In practice, though, it's very rare that a TLS connection will stay
open that long without a live stream on some circuit using that
connection. Since clients don't attach streams to any circuit in use
for longer than MaxCircuitDirtiness (10 min default), and close any
TLS connection that has gone for KeepalivePeriod (5 min default)
without an open circuit on it, it follows that absent a long-lived
stream, you'll close your connection to any entry node soon after you
pick a different entry for the next circuit.
This suggests, in fact, that we might want to go in the _other_
direction, and work to keep TLS connections from closing and
re-opening quite so frequently. We don't use TLS sessions right now,
so the CPU load spent by servers doing TLS handshakes is significant.
(Of course, this isn't something to do for the 0.1.2.x series, much as
I'd like to reduce our crypto load.)
> My second question is:
> And of course there just is no PFS for CREATE_FAST exchanges because
> the actual keying material was sent over the the TLS connection rather
> than doing a DH exchange. There is still PFS for the other hops in
> the circuit, but none for the first hop. That's right yes?
That would be true for arbitrary TLS, but we only use TLS ciphersuites
that include a DH exchange of their own. From tor-spec.txt, section
2:
Tor uses TLS for link authentication and encryption. All
implementations MUST support the TLS ciphersuite
"TLS_EDH_RSA_WITH_DES_192_CBC3_SHA", and SHOULD support
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA" if it is available.
Implementations MAY support other ciphersuites, but MUST NOT
support any suite without ephemeral keys, symmetric keys of at
least KEY_LEN bits, and digests of at least HASH_LEN bits.
The "ephemeral keys" bit means IIUC that there has to be a DH-style
key exchange.
[...]
yrs,
--
Nick Mathewson
Attachment:
pgpAl4JAgCtaS.pgp
Description: PGP signature