In what scenario would an admin go through all this additional effort rather than just requiring HTTPS for his website?
If I understand correctly, this new system will only work when two conditions are met: 1) The admin of the webserver wants to enable encryption 2) The user has a browser that supports encryption But both of those conditions are *already* met by HTTPS. Can you explain the scenario this is intended to cover that isn't already covered by HTTPS? The only situation I can think of is if an admin wanted to leave it up to the browser whether or not to encrypt. But this seems both like an edge case, as well as more easily solved in other way (perhaps a Firefox extension that puts a "wants to encrypt" header in the HTTP request, which is picked up by Apache and redirects to the HTTPS version of the site.) Basically, generation 1 of Obfuscated TCP seemed sensible: upgrade the OS on both the client and server machine (or on both sides of the p2p connection) and all TCP connections get magically encrypted. I can see the differentiating value of that. But I don't the differentiation here, especially given that it doesn't address the P2P case. Sorry to be a downer, just trying to understand where to use this new tool in my toolbox! -david Adam Langley wrote: > Obfuscated TCP (which has surfaced on this list before) has now been > released in its third iteration[1]. For those who may remember it from > iterations past, much has changed[2]. > > Obfuscated TCP is intended to encourage opportunistic encryption for > all TCP connections, but concentrating on HTTP at first. The name is > historical now and a little of a misnomer since it is now entirely a > userspace concern. > > Brief summary: > > Public value are encoded in the CNAMEs of webservers (for example `dig > obstcp.imperialviolet.org`). The CNAME contains an "advert" which > encodes, along with the public value, an alternative port number. > Capable browsers can fetch the CNAME using the standard > gethostbyname(3) function and connect to the alternative port, sending > their own public value followed by an encrypted stream of data. The > public values are points on an elliptic curve and EC Diffie-Hellman is > used for key agreement. > > Status: > > The core library is working as described and stable, if a little > untested. Patches to Firefox and lighttpd are stable and functional. > Patches to Apache are functional, but less stable. > > Comments welcome, testing even more so. > > > Cheers > > AGL > > [1] http://code.google.com/p/obstcp/ > [2] http://code.google.com/p/obstcp/wiki/History > _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
