I suggest you review how PKI works, and what TLS and SSL mean.
On Sat, Mar 30, 2013 at 9:23 PM, Tom Ritter <[email protected]> wrote: > 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 > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
