Re: Bridge scanning resistance

[Christopher Davis <chrisd@xxxxxxxxxxx>]

On Sun, Mar 22, 2009 at 02:21:49PM -0400, Roger Dingledine wrote:
> On Thu, Mar 19, 2009 at 01:00:38AM +0000, Christopher Davis wrote:
> > I'm thinking of sending in a GSoC proposal for consideration by Tor/EFF
> > this year.
>
> Welcome!
>
> > I see in item #4 on your volunteer project list work involving
> > improvement of bridge scanning resistance, and it looks like it could be
> > an interesting project.
>
> Yes indeed. It's also a messy project -- rather than knowing what to
> build, you need to grapple with a lot of vague security requirements,
> along with a lot of potentially contradictory engineering requirements,
> and then choose the right balance of "protects well enough against
> the important attacks" vs "can be build and deployed without too many
> subtleties which induce bugs, and can be maintained afterwards". So
> that requires a lot of intuition; it's not a project for a beginner at
> this stuff.
>

It's definetly a big task to define this problem well enough to solve it
in a short amount of time, but I'll put down some ideas here before I forget
them...

> > It seems the trick in the bridge-as-webserver design is making it appear
> > as normal and boring as possible, while still accommodating bridge
> > clients. Clients would have to upload an authentication string to the
> > server in order to use it, but the server would have to take care in
> > reporting authentication failure, etc, to avoid alerting a scanner to its
> > true purpose.
>
> Yep. I haven't looked at TLS lately, and our variant where we do rekeying
> inside TLS:
> https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/130-v2-conn-protocol.txt
> but it seems contradictory to both a) authenticate that you're talking
> to the right relay, and b) not act funny until you've authenticated, if
> we need to demand rekeying (which is pretty odd) before we can see all
> the right certs. So there's definitely some design work involved here too.
>

I think I undertstand your point about the contradiction.

According to the design spec, Tor uses 3 keypairs:

1.	Long-term identity key
2.	Medium-term onion key
3.	Short-term connection key

#1 and #3 are applicable during the TLS handshake and verification.

This is how the handshake works now if I read things right:

1. 	Client connects to server.
2.	Server presents short-term connection cert (signed with identity
	key).
3.	Client requests renegotiation.
4.	Server sends both connection cert and identity cert, and requests
	the same from the client.
5.	Client verifies the connection.

The trouble is that the identity cert is needed to ID the server, and it's
not presented till after renegotiation, which, as you mention, is likely
problematic when considering scanning resistance.

I also did an experiment using openssl s_client to connect to a random
OR. Tor sets the commonName field of subject and issuer with random
hostnames. Tor also rotates the connection cert quite frequently. Upon
reconnecting with s_client to the same server after a few hours, there
was a new cert with different random hostnames.

A scanner could pick on some irregular things:

* The frequent rotations of the connection cert. SSL server certs are
usually issued for at least a few months at a time (cacert.org sets a
6mo expiry on its certs, IIRC). If I read tor_tls_create_certificate()
in tortls.c correctly, Tor doesn't lie about the notBefore and notAfter
times, so a scanner could connect, pluck those values from the cert, then
calculate how long the cert is likely to last without actually waiting
for the cert to be rotated.

* Invalid hostname on subject and issuer. This may not be big a problem,
I don't know. DNS lookups take time, etc. Self-signed/testing certs have
bogus information on them too, etc.

* Missing fields like "Organizational Unit", etc. To make a self-signed
cert, openssl asks for a few extra things in addition to the commonName.
Certs issued from a real CA will have more fields set on them, too.

Perhaps, in the end, it would be easier to avoid the hassle of messing
with the TLS handshake for the sake of scanning resistance by simply
delaying it until after the bridge client provides the (correct) password.
One tradeoff here is that the client can't ID the bridge before sending
the password, and communication would be in the clear. Perhaps there
could be some kind of hashing applied to the password in this case.

> > Also, there could be some application to having OR servers
> > respond to HTTP requests with an informational message, etc.
>
> Check out DirPortFrontPage in the man page.
>

Ok, got it.

> > Certain aspects of the TLS handshake could also clue in a scanner. Are
> > there any things about Tor's current implementation that could be
> > improved to make it seem more like a web server? If required, answering
> > this question could be one point of research in comparing Tor to
> > Apache's mod_ssl or other HTTPS servers.
>
> Yep. My current thought is that you'll never achieve bug-compatibility
> with Apache (consider for a moment how good nmap is at distinguishing
> OSes based on how they chose to implement TCP), so the only foolproof
> plan here is to intercept Tor connections and handle them as Tor, else
> pass the connection through to Apache.
>
> Of course, if you're "close enough to Apache", that may be good enough.
> Nobody has looked carefully enough to know how much work that would be.
>

I agree that adding the application part of the web server into Tor itself
is probably not the way to go, because it adds a lot of extra variables.
Forcing Tor to deliver web pages also limits the type of content that could
be delivered. From a scanning resistance point of view, perhaps the best
thing is to have the cover content be as diverse as possible. If you were
writing a scanner, wouldn't it be easier if you didn't have to worry about
any diversity, and you could count on the content being the same every
time? Relaying useful pages may be better than relaying apache test pages
and that sort of thing. The administrator of the bridge could choose what
to relay.

If bridges acted like stunnel or a circuit layer proxy (depending on
whether TLS is enabled first thing or not) before the client uploads the
password, there would be quite a bit of flexibility in relaying different
services. HTTP, SMTP, NNTP, POP3, etc could be made to work. If
the password authentication could be kept a simple process, the network
protocol for it could potentially be independant of the protocol of the
service that is being relayed.

> > Another part of the project is to address the specifics of bridge
> > authentication. The bridge user has to get a password from us, then they
> > would send it when they connect to the bridge. The web application to
> > advertise bridges would need to be updated.
>
> Yep. That wouldn't be so bad though -- the web application doesn't much
> care what its bridge lines look like. It's really the bridge descriptor
> that needs to get updated, so it includes the password that the bridge
> expects.
>
> Overall, this looks like one of those high-risk summer projects, where
> you might spend your whole time being dismayed at the number of confusing
> variables.
>
> --Roger
>
>

Thanks for the response and the advice,
--
Christopher Davis
Mangrin Remailer Admin
PGP: 0x0F8DA163