To me, this looks like a really nice development. We need more of this! Some comments...
Adam Langley wrote: > On Tue, Oct 7, 2008 at 4:36 PM, David Barrett <[EMAIL PROTECTED]> wrote: >> 1) The admin of the webserver wants to enable encryption >> 2) The user has a browser that supports encryption > > Correct. > >> 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? > >> 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. > > I'll agree that the probably the value of the system has decreased as > the generations progressed. This makes me sad, but I haven't stopped > trying. > > (Although there are advantages to moving out of kernel space however) Definately :) Follows from below logic; the kernel has only limited chances to guess at a useful security model. All good security is end-to-end. That rules out the kernel. Accept nothing less! > The aim is to increase the currently tiny amount of encrypted traffic > over the Internet. HTTPS has ubiquitous support, and yet it's just not > used. There are several reasons why not: I once counted 98 reasons why HTTPS is not used :) > * Getting a certificate isn't too hard, but it's still quite a speed > bump. They cost and they have to be renewed. Yup. Some CAs give free certs, but they have their issues as well (I am involved and conflicted so I will say no more!). > Self-signed certs are > possible, but I support Firefox in its efforts to discourage them. There is a fairly long literature and extensive practice that supports self-signed certs, non-cert keys, user-accepted keys and the like. Both SSH and Skype use these models, and it works *better* for them than HTTPS ever worked for the web. The Firefox guys are now working on what they call Key Continuity Management. Support them in that! This would help with phishing enourmously. > I > don't think we can present to the average user any shades of gray. "Shades of grey" would depend on who's eyeballs, what location we are looking from, general weather conditions.... The view that self-signed certs are "not perfect" is strictly predicated on the assumption that the developers know what the one true security model is for the user. This is a daft view, as the developers can't see the user, don't know her, are not even sure what country she is in, let alone any view at all as to what the application is. (Recall that browsers are used for *everything* these days.) As it happens, the user often has strange and contrary security models, which cannot be served by a one-size-fits-all. E.g., some security models require identity, some require the complete opposite. E.g., if you go to an online bank, using a client cert might be helpful. If you go to a sex help service, you want KCM and no client certs, and definately no identity.... > HTTPS should be the gold standard and everything else should be > suspect. HTTPS is like democracy for the web, it is a really awful thing, but it's still better than the next best thing, which would be nothing. > * Users just don't type HTTPS most of the time. Yea, you can > redirect, but the latency (another 3 RTT) is a real pain. Yup, known bug. Asking users whether they want security is a little like asking someone if they want to avoid pregnancy and diseases. If you knew enough to ask the question, you should already know the answer. > * Hosting sites can't deploy HTTPS for their clients by default, > because of the certificate issues. And TLS/SNI. The httpd team may deliver it this next release. If you know someone over at Apache, vote for TLS/SNI. > * HTTPS is expensive to serve. Partly that's due to the default > configuration of OpenSSL which ends up using astronomically expensive > suites like DHE-RSA-AES256-SHA, partly because TLS is aiming higher. > > I would dearly like the deployment for servers to be easier. There is one barrier that can be blasted away quite simply: ask the server teams to implement TLS/SNI. The browsers already have it, and have had it for years ... it is the server side that lacks. TLS/SNI puts TLS on the same level within the vhosts, so one IP number and one httpd and one config can all use TLS. It means that the 1,000,000 LAMPs people out there that serve a handful of websites can stop making decisions about saving IP#s and turn on TLS for all their websites. (They still have to aquire some certs ... one step at a time ... possibly from the free places I delined to mention :) > That can > be done with connection memory, although it suffers from mild privacy > concerns (you need to keep a hash of the hostnames that you visit in > the browser) and that the first connection isn't secure. The code to > do this is already written, just disabled at the moment. This is more or less what the Firefox people call Key Continuity Management. Also see petnames, which is a good way of managing the keys. There is a Petnames Toolbar for Firefox. > In addition to the ObsTCP information in the DNS advert, I also want > to support a TLS port so that browsers will transparently use TLS and > will accept self signed certs without comment when they do. That may > turn out to be more useful since people don't have to patch their > servers. If you could put the cert into the DNS advert, that would solve a lot of woes! That would work for the self-signed as well as the CA-signed. iang
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
