Hi, I was thinking about proposal #203 (Avoiding censorship by impersonating an HTTPS server) and have a few thoughts. I'm not sure if I've understood how everything fits correctly but here goes:
For each bridge, we give their identity fingerprint and a shared secret along with their IP address and port. ie: bridge <ipaddress:port> <fingerprint> <shared_secret> The fingerprint allows the client to verify the identity of the bridge (via signed certificate) while a TLS connection is being set up. The shared secret allows the bridge to authorize clients after the TLS connection is set up. The shared secret could be sent using AUTHORIZE cells as proposed in #189 and #190. The AUTHORIZE cell could be wrapped in a HTTP GET request header. This should satisfy most goals. - A passive attacker wouldn't be able to distinguish between HTTPS->HTTPS traffic and Tor->Bridge. (Both use TLS) - An active attacker wouldn't be able to fool a client into thinking it was talking to a bridge. (Client would verify identity using fingerprint) - An active attacker wouldn't be able to fool a bridge into thinking it was a client. (No shared secret) To do the actual HTTPS impersonation, we could use Design #3 or #2 from #203. Nginx could be the reverse proxy, forwarding connections to the webserver or bridge as required. Depending on what the bridge is pretending to be, we could simply have nginx sitting in front of the bridge. I'm not sure what type of site the server should pretend to be. Some sort of blog? Maybe a login page? Or it could pretend to be a proxy service or perhaps web based ssh site? Could even be a combination of them I guess. Code changes would include - writing an nginx module to handle authentication - tor would need to handle AUTHORIZE/AUTHORIZED cell Thoughts? Did I miss anything? Thank you for your time, Rohit _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
