Re: [tor-dev] Thoughts on Proposal 203 [Avoiding censorship by impersonating a HTTPS server]

Hey Jeroen,

Thanks for your feedback, please see inline.

On 12 September 2013 09:03, Jeroen Massar <jeroen@xxxxxxxxx> wrote:

On 2013-09-12 09:25 , Kevin Butler wrote:

[generic 203 proposal (and similar http scheme) comments]

- HTTPS requires certificates, self-signed ones can easily be blocked
as they are self-signed and thus likely not important.
If the certs are all 'similar' (same CA, formatting etc) they can be
blocked based on that. Because of cert, you need a hostname too and
that gives another possibility of blocking

- exact fingerprints of both client (if going that route) and server
cert should be checked. There are too many entities with their own
Root CA, thus the chained link cannot be trusted, though should be
checked. (generation of a matching fingerprint for each hostname
still takes a bit and cannot easily be done quickly at connect-time)

I should have made my assumptions clearer. I am assuming the CA is compromised in this idea. I have assumed it is easy to make a counterfeit and valid cert from the root but it is hard(read infeasible) to generate one with the same fingerprint of the cert the server actually has.

This is the key point that I think helps against a MITM, if the fingerprint of the cert we recieved doesn't match with what the server sent us in the hmac'd value, then we assume MITM and do nothing.

[..]

> I think the best course of action is to use a webserver's core
> functionalities to our advantage. I have not made much consideration for
> client implementation.

Client side can likely be done similar to or using some work I am
working on which we can hopefully finalize and put out in the open soon.

Server side indeed, a module of sorts is the best way to go, you cannot
become a real webserver unless you are one. Still you need to take care
of headers set, responses given and response times etc.

I'm interested in the work you've mentioned, hope you get it finalized soon :)

> * The users Tor client (assuming they added the bridge), connects to

> the server over https(tls) to the root domain. It should also
> downloads all the resources attached to the main page, emulating a
> web browser for the initial document.

And that is where the trick lies, you basically would have to ask a real
browser to do so as timing, how many items are fetched and how,
User-Agent and everything are clear signatures of that browser.

As such, don't ever emulate. The above project would fit this quite well
(though we avoid any use of HTTPS due to the cert concerns above).

I was hoping we could do some cool client integration with selenium or firefox or something, but it's really out of scope of what I was thinking about.

[..some good stuff..]

> * So we have our file F, and a precomputed value Z which was the

> function applied Y times and has a hmac H. We set a cookie on the
> client base64("Y || random padding || H")

> o The server should remember which IPs which were given this Y
> value.

Due to the way that HTTP/HTTPS works today, limiting/fixing on IP is
near impossible. There are lots and lots of people who are sitting
behind distributed proxies and/or otherwise changing addresses. (AFTR is
getting more widespread too).

Also note that some adversaries can do in-line hijacking of connections,
and thus effectively start their own connection from the same IP, or
replay the connection etc... as such IP-checking is mostly out...

Yes, I was being generic in this, it seems like I deleted my additional comments on this, it's relatively trivial to add more data into the cookie to associate the cookie with an accepted Y value.

> This cookie should pretty much look like any session
> cookie that comes out of rails, drupal, asp, anyone who's doing
> cookie sessions correctly. Once the cookie is added to the
> headers, just serve the document as usual. Essentially this
> should all be possible in an apache/nginx module as the page
> content shouldn't matter.

While you can likely do it as a module, you will likely need to store
these details outside due to differences in threading/forking models of
apache modules (likely the same for nginx, I did not invest time in
making that module for our thing yet, though with an externalized part
that is easy to do at one point)

I'm hoping someone with more domain knowledge on this can comment here :) But yeah, I'm sure it's implementable.

[..]
> o When rotating keys we should be sure to not accept requests on

> the old handlers, by either removing them(404) or by 403ing
> them, whatever.

Better is to always return the same response but ignore any further
processing.

Note that you cannot know about pre-play or re-play attacks.
With SSL these become a bit less problematic fortunately.
But if MITMd they still exist.

Yes, we would obviously need to choose a single response option, I was just giving options. Hoping the MITM detection would prevent the client from ever making an action that could be replayable. But yes, mainly relying on determining if we're talking to the right server with the right cert and relying on TLS.

[..]
> o The idea here is that the webserver (apache/nginx) is working

> EXACTLY as a normal webserver should, unless someone hits these
> exact urls which they should have a negligable chance of doing
> unless they have the current shared secret. There might be a
> timing attack here, but in that case we can just add a million
> other handlers that all lead to a 403? (But either way, if
> someones spamming thousands of requests then you should be able
> to ip block, but rotating keys should help reduce the
> feasability of timing attacks or brute forcing?)

The moment you do a ratelimit you are denying possibly legit clients.
The only thing an adversary has to do is create $ratelimit amount of
requests, presto.

Hadn't considered that, Good point. We could rely on probabilities, but I would prefer some kinda hellban ability once a censors ip has been determined (act normal just dont let their actions ever do anything)

> * So, how does the client figure out the url to use for wss://? Using

> the cache headers, the client should be able to determine which file
> is F.

I think this is a cool idea (using cache times), though it can be hard
to get this right, some websites set nearly unlimited expiration times
on very static content. Thus you always need to be above that, how do
you ensure that?

I guess I should have outlined that clearer. F is determined by whatever file has the longest cache time of the document served normally, if they put it to 50 years, we use that one, if they put two to an equal time, then the client and server will just use the first one that appears in the document. We are not to generate our own files for the computation process as that will lead our servers to be identifiable. Plus remember we have the ability to change headers, so if they're setting everything to some invalid infinity option, we just change it to 10years on the fly, I don't see this being a blocker.

Also, it kind of assumes that you are running this on an existing
website with HTTPS support...

Yes, the website will need to support https, but these days you're being negligent to your users anyway if you're not allowing them https.

Does that clear any of your concerns at all?