commit 903a65f6cc580c3652e1f44af101eaae16863848 Author: Karsten Loesing karsten.loesing@gmx.net Date: Thu Jun 28 14:20:19 2012 +0200
Fix some typos in proposal 203. --- proposals/203-https-frontend.txt | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/proposals/203-https-frontend.txt b/proposals/203-https-frontend.txt index f559d92..8d3c2e3 100644 --- a/proposals/203-https-frontend.txt +++ b/proposals/203-https-frontend.txt @@ -54,7 +54,7 @@ Goals and requirements: any particular HTTP or HTTPS implementation.
If we're replacing our own profile with that of an HTTPS service, we - should do so in a way that lets us use a the profile of a popular + should do so in a way that lets us use the profile of a popular HTTPS implementation.
Efficiency would be good: layering TLS inside TLS is best avoided if @@ -94,12 +94,12 @@ Design #1: TLS in Tor thoroughly.
To authenticate, we would need to take a hybrid approach, and begin - forwarding traffic to the webserver as soon as soon as a webserver + forwarding traffic to the webserver as soon as a webserver might respond to the traffic. This could be pretty complicated, since it requires us to have a model of how the webserver would respond to any given set of bytes. As a workaround, we might try relaying _all_ input to the webserver, and only replying as Tor in - the cases where the website hasn't replied. (This would likely to + the cases where the website hasn't replied. (This would likely create recognizable timing patterns, though.)
The authentication itself could use a system akin to Tor proposals @@ -137,9 +137,9 @@ Design #2: TLS in the web server subsystem at all.
The Tor client would need to connect and prove its status as a Tor - client. If the client uses some means other then AUTHORIZE cells, or + client. If the client uses some means other than AUTHORIZE cells, or if we want to do the authentication in a pluggable transport, and we - therefore decided to offload the responsibility TLS itself to the + therefore decided to offload the responsibility for TLS itself to the pluggable transport, that would scare me: Supporting pluggable transports that have the responsibility for TLS would make it fairly easy to mess up the crypto, and I'd rather not have it be so easy to @@ -166,7 +166,7 @@ Design #3: Reverse proxy called a "reverse proxy", so that's the term I'm using here.)
To avoid fingerprinting, we should choose a proxy that's already in - common use as a TLS frontend for webservers -- nginx, perhaps. + common use as a TLS front-end for webservers -- nginx, perhaps. Unfortunately, the more popular tools here seem to be pretty complex, and the simpler tools less widely deployed. More investigation would be needed. @@ -185,7 +185,7 @@ How to authenticate: The easiest way HTTP header, is an open problem that we should solve in proposals 190 and 191 and their successors. I'm calling it out-of-scope here; please see those proposals, their attendant discussion, and their - eventual successors + eventual successors.
How to authenticate: a slightly harder way