GWT over HTTPS and cache in IE and FF

[Tom C.]

Hi,

The purpose here is to let IE and FF run the host page over HTTPS ,
while being able to cache the *.cache.html files without giving mixed
secure/non-secure warning to user.

I noticed that by default IE cache the contents even over HTTPS (one
can confirm that by checking those files got from HTTPS in the C:
\Documents and Settings\[user name]\Local Settings\Temporary Internet
Files. So for IE, we can use https for all files.

On the other hand FF doesn't cache (to disk) the contents over HTTPS.
However FF doesn't give the mixed secure/non-secure warning, so it
seems that there's a way to get the host page over HTTPS, while
getting the *.cache.html over HTTP.

Is there a way to achieve the abovementioned approachs at the same
time?

[Reinier Zwitserloot]

If what you state is correct even for vanilla IE installs, then, yeah,
easy. GWT already browser sniffs to determine which of the 4 versions
to load (the IE version, the Opera version, the Firefox version, or
the Safari version, and there are a lot more versions if you also add
i18n).Adding to this a little caveat that loads off of HTTP for
everything except IE should not be difficult.

However, loading off of HTTP instead of HTTPS does open an attack
route to would be hackers. It's not a big attack route (see end of
post) but it certainly counts. Therefore, I don't think this act
should be automatic; it would have to be a setting (probably a new tag
or config thing in your .gwt.xml file). You also can't use Cookie:
secure=true anymore. I have a solution for this, but lets first review
why this is a problem before I show my solution:


SSL basically prevents / helps against the following, in order of
easyness:

1. Sniff the data out, getting your hands on cookies, passwords,
personal info, and more. This is the most frequent attack (just
checking a website at a conference when someone is sniffing the WiFi
packets and reviews the results later is enough), and either way this
is no problem because the only thing that is sent over HTTP is a
static js file with no compromising info in it. The actual traffic is,
I presume, XmlHttpRequest (GWT HttpRequest/GWT-RPC) over https.

2. Using DNS or other tricks to fake the browser's sense of direction.
Not a problem - main page is still accessed via SSL and any such
things should trigger a mismatched certificate warning.

3. Man-in-the-middle attack whereby the attacker actively changes the
data between user and webserver. Normally you are protected against
this, but if you load the GWT code from HTTP, *YOU ARE NOT* - the man
in the middle attacker can take the GWT code, analyse it, produce a
'rogue' version that uploads relevant data to his webserver (or even
just posts it in the clear to anywhere - he's sniffing the connection
after all, no need to implicate self), and serve it up instead. Your
browser will never know something is wrong, because that part of the
GWT code is being loaded without certificates and hashes that can be
checked.


That gives me an idea: I think there's a way to do this securely,
actually, even with secure=true for the cookies. Let the noncache
wrapper (which isn't being cached anyway in the first place)
XmlHttpRequest the big file in (over HTTP). It then checks the SHA256
(because SHA1 and MD5 are too easy to break, especially for code,
where there are loads of no-ops you can sprinkle in) of the downloaded
data, and if it matches, eval()s it. Your context is now https, so
cookies from secure=true are still readable to you, and there's no way
for the man-in-the-middle attacker to either change the GWT code
(because then the hashes would no longer match) or to change the hash
(because that bit is being loaded over SSL).

The issues with this approach: size, speed, and effort. to wit:

A. Size: now the nocache file needs to have a javascript SHA256
implementation. It's bound to be smaller than GWT itself, but it would
easily double the nocache.js file size. Adding it to every download
seems pointless, so we'd need a special nocache-ssl variant, or a flag
of some sort. It can't just 'work automatically' for everyone. We
already have a variant (-xs), so there is some precedent for it.

B. Speed: I'm not sure if evalling such large files is problematic.
Wasn't there an issue mentioned on GWT-Contributors about Firefox2
being extremely slow to eval() stuff? Perhaps it is possible to use
the DOM to create a script tag, fill it with the script, and add it to
the body? Would that work and parse as quick as GWT gets parsed now?
Even if this bit can be made to work as fast, the entirety of the GWT
code still has to be run through the SHA256 implementation.
Fortunately at least in IE this won't be neccessary if Tom C.'s
suggestion that IE caches https is correct.

C. Effort: This is not a trivial update. You'd need to find a SHA256
for javascript, compress it down to the smallest legal javascript you
can, set up the ssl variant, add the SHA256 implementation to it, add
the SHA256 results to the ssl variant (hardcoded), and completely
change (for the ssl variant only) how it bootstraps the real GWT code,
this time first hashing the lot, checking it against the hardcoded
hash, then running it.

[Tom C.]

Good point on the man-in-the-middle. I obviously overlooked that.

One major concern here is the speed, because the intention is to speed
up GWT on FF over HTTPS. If the time to eval the GWT code and run
through SHA256A is longer than loading again the GWT code, then the
approach doesn't do any good.

> > time?- Hide quoted text -
>
> - Show quoted text -