<div dir="ltr">Hey Jeroen, <div><br></div><div>Thanks for your feedback, please see inline.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 September 2013 09:03, Jeroen Massar <span dir="ltr"><<a href="mailto:jeroen@massar.ch" target="_blank">jeroen@massar.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2013-09-12 09:25 , Kevin Butler wrote:<br>
<br>
[generic 203 proposal (and similar http scheme) comments]<br>
<br>
- HTTPS requires certificates, self-signed ones can easily be blocked<br>
as they are self-signed and thus likely not important.<br>
If the certs are all 'similar' (same CA, formatting etc) they can be<br>
blocked based on that. Because of cert, you need a hostname too and<br>
that gives another possibility of blocking<br>
<br>
- exact fingerprints of both client (if going that route) and server<br>
cert should be checked. There are too many entities with their own<br>
Root CA, thus the chained link cannot be trusted, though should be<br>
checked. (generation of a matching fingerprint for each hostname<br>
still takes a bit and cannot easily be done quickly at connect-time)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[..]<br>
<div class="im">> I think the best course of action is to use a webserver's core<br>
> functionalities to our advantage. I have not made much consideration for<br>
> client implementation.<br>
<br>
</div>Client side can likely be done similar to or using some work I am<br>
working on which we can hopefully finalize and put out in the open soon.<br>
<br>
Server side indeed, a module of sorts is the best way to go, you cannot<br>
become a real webserver unless you are one. Still you need to take care<br>
of headers set, responses given and response times etc.<br></blockquote><div><br></div><div>I'm interested in the work you've mentioned, hope you get it finalized soon :)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> * The users Tor client (assuming they added the bridge), connects to<br>
<div class="im">> the server over https(tls) to the root domain. It should also<br>
> downloads all the resources attached to the main page, emulating a<br>
> web browser for the initial document.<br>
<br>
</div>And that is where the trick lies, you basically would have to ask a real<br>
browser to do so as timing, how many items are fetched and how,<br>
User-Agent and everything are clear signatures of that browser.<br>
<br>
As such, don't ever emulate. The above project would fit this quite well<br>
(though we avoid any use of HTTPS due to the cert concerns above).<br>
<br></blockquote><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[..some good stuff..]<br>
<br>
> * So we have our file F, and a precomputed value Z which was the<br>
<div class="im">> function applied Y times and has a hmac H. We set a cookie on the<br>
> client base64("Y || random padding || H")<br>
</div>> o The server should remember which IPs which were given this Y<br>
> value.<br>
<br>
Due to the way that HTTP/HTTPS works today, limiting/fixing on IP is<br>
near impossible. There are lots and lots of people who are sitting<br>
behind distributed proxies and/or otherwise changing addresses. (AFTR is<br>
getting more widespread too).<br>
<br>
Also note that some adversaries can do in-line hijacking of connections,<br>
and thus effectively start their own connection from the same IP, or<br>
replay the connection etc... as such IP-checking is mostly out...<br>
<div class="im"><span style="color:rgb(34,34,34)"></span></div></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)"> </span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> This cookie should pretty much look like any session<br>
> cookie that comes out of rails, drupal, asp, anyone who's doing<br>
> cookie sessions correctly. Once the cookie is added to the<br>
> headers, just serve the document as usual. Essentially this<br>
> should all be possible in an apache/nginx module as the page<br>
> content shouldn't matter.<br>
<br>
</div>While you can likely do it as a module, you will likely need to store<br>
these details outside due to differences in threading/forking models of<br>
apache modules (likely the same for nginx, I did not invest time in<br>
making that module for our thing yet, though with an externalized part<br>
that is easy to do at one point)<br></blockquote><div>I'm hoping someone with more domain knowledge on this can comment here :) But yeah, I'm sure it's implementable.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[..]<br>
> o When rotating keys we should be sure to not accept requests on<br>
<div class="im">> the old handlers, by either removing them(404) or by 403ing<br>
> them, whatever.<br>
<br>
</div>Better is to always return the same response but ignore any further<br>
processing.<br>
<br>
Note that you cannot know about pre-play or re-play attacks.<br>
With SSL these become a bit less problematic fortunately.<br>
But if MITMd they still exist.<br></blockquote><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[..]<br>
> o The idea here is that the webserver (apache/nginx) is working<br>
<div class="im">> EXACTLY as a normal webserver should, unless someone hits these<br>
> exact urls which they should have a negligable chance of doing<br>
> unless they have the current shared secret. There might be a<br>
> timing attack here, but in that case we can just add a million<br>
> other handlers that all lead to a 403? (But either way, if<br>
> someones spamming thousands of requests then you should be able<br>
> to ip block, but rotating keys should help reduce the<br>
> feasability of timing attacks or brute forcing?)<br>
<br>
</div>The moment you do a ratelimit you are denying possibly legit clients.<br>
The only thing an adversary has to do is create $ratelimit amount of<br>
requests, presto.<br></blockquote><div>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)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> * So, how does the client figure out the url to use for wss://? Using<br>
<div class="im">> the cache headers, the client should be able to determine which file<br>
> is F.<br>
<br>
</div>I think this is a cool idea (using cache times), though it can be hard<br>
to get this right, some websites set nearly unlimited expiration times<br>
on very static content. Thus you always need to be above that, how do<br>
you ensure that?<br></blockquote><div>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. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also, it kind of assumes that you are running this on an existing<br>
website with HTTPS support...<br></blockquote><div>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. </div><div><br></div><div>
Does that clear any of your concerns at all? </div></div><br></div></div>