I finally watched the recent FlashProxy talk, and the bit about "Not working on HTTPS" intrigued me. I looked into it, and had two initial ideas.
====================== Mixed Content. This isn't great, but it's something that might work for now. Chrome and FF do not block an HTTP iframe on an HTTPS site. Chrome26 displays a different icon, and logs to console. Chrome Canary (28) did the same FF9.0.2 allows and has no indication IE9 blocks So putting the badge on a page in an iframe could allow a webmaster to deploy it on a HTTPS site. That frame would be on a different domain, to get protections via Same Origin Policy ====================== Root Cert. This one is more than a bit crazy, but I don't believe in discounting crazy out of hand. Basically, if you accept that the TLS connection provides *no security whatsoever*, that is - it does not provide authenticity, and therefore should not be assumed to provide confidentiality - but you want to use it as an opportunistic layer (hey maybe this will help, it can't hurt), or to enable it working on HTTPS sites, or as an anti-fingerprinting tool (now they have to look at the handshake/certificate instead of te traffic) it becomes acceptable. Create a FlashProxy Root Cert, with a critical NameConstraint extension. The Name Constraint would be something like ".entire-internet.flashproxy.com". Because it's Name Constrained, and critical, no client will accept a cert for a domain like paypal.com chaining to your root. IIRC the only desktop client that does not support NameConstraints is Safari - BUT because it's critical, Safari will outright reject the certificate. Mobile Clients should behave the same way. A group of CA's and Browser vendors are working to document the veracity of those claims, but I'm pretty confident in them because they recently, to great consternation of the IETF, said "we're going to allow non-critical NameConstraint extensions, because if we don't, we'd break Safari". So you've got the root cert. Folks who want to run FlashProxies install it in their browser or OS. (The NameConstraints give them confidence you're not going to, nor can you, mess with them.) Now when a client wants to have a FlashProxy connect to them, they talk to the facilitator or another facilitator like system, and they receive a Root-CA signed cert for 127.0.0.1.entire-internet.flashproxy.com (substitute 127.0.0.1 for the client's actual IP) that's valid for a short window, say 30 minutes. Now, when the FlashProxy connects to the client, they do so using wss:// and receive the FlashProxy Root-signed certificate, and the browser lets the SSL handshake succeed. There's a lot of downsides here: - NameConstraints are not rock-solid in the sense that we've taken them for long test drives, but no one's subjected them to 20 years of continual use. When the value of the system attacked is greater than the cost, the attack happens. What's the cost for an attack on Name Constraints? We don't know. - It requires the FlashProxy user to install a root cert (e.g. do more than just open a webpage) - The requirements for the client -> facilitator communication channel go up: it must now be bi-directional and support up to 1K of data or so. - The signing of certificates would introduce a DOS channel. This can be mitigated in some sense by rejecting requests for an IP if you've signed a cert for that IP in the last validity_window / 2, and preventing the IPfrom being spoofed (free if done over TCP, difficult otherwise) -tom _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk