[tor-talk] FlashProxy and HTTPS

[Tom Ritter <tom@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk