[tor-talk] FlashProxy and HTTPS

[Gregory Disney]

I suggest you review how PKI works, and what TLS and SSL mean.


On Sat, Mar 30, 2013 at 9:23 PM, Tom Ritter <tom at ritter.vg> 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
> tor-talk at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>