100% SSL or selective SSL, JSONP ... and no errors?

Question

I would like to invite your considered opinion to help me decide between the following two origin policies for my Ajax app:

1. Load all my assets from HTTPS: //www.mydomain.com
Plus: Ajax is easy. No problems with Same Origin Policy.
Plus: PUT method offers large payloads.
Plus: Network error messages can be fed back to the user.
Minus: Server needs to sweat more to encrypt all that dross that makes up a web site. Browser needs to sweat more decrypting it all. Overall slower user experience.
2. Load most of the dross via HTTP: //www.mydomain.com and use HTTPS: //www.mydomain.com only for sensitive data exchanges.
Plus: Faster user experience as browser and, more importantly, my server do less cryptography. Plus: Ajax still easy via JSONP work-around to SOP (*).
Minus: GET method on JSONP limits payload to 2K - may become an issue.
BIG Minus: Cannot find any way to grab status response from header following network errors (of whatever kind). User information cannot extend beyond "My bad".

Any thoughts?

(*) BTW, I would really appreciate if someone could give me an example of a security vulnerability brought on by a switch of protocol on the same domain. I understand that these are different servers, but so what? They are on my domain. I control them. I do not understand the concern.

Answer 1

Use SSL. Did you benchmark the performance loss for SSL? In general, modern computers are fast and SSL encryption/ decryption overhead is negligible. See http://stackoverflow.com/questions/548029/how-much-overhead-does-ssl-impose for some discussion on the subject.

Not having to use JSONP, being able to use HTTP PUT, and all the other benefits you outlined are worth more than a few cpu cycles in my book.

Answer 2

Regarding the vulnerability, I've put examples in another answer:

It doesn't seem desirable to maintain session between HTTP and HTTPS using the same cookie or URL token.

Imagine the case where you're user is logged on, with a given cookie (or URL token) passed back and forth for every request/response in an e-commerce website. If someone in the middle is able to read that cookie, he can then log on to the HTTP or HTTPS variant of the site with it. Even if whatever the legitimate user is then doing is over HTTPS, the attacker will still be able to access that session (because he too will have the legitimate cookie). He could see pages like the cart, the payment method, perhaps change the delivery address.

It makes sense to pass some form of token between the HTTP session and the HTTPS session (if you're using sessions), but treating them as one and the same would cause some vulnerability. Creating a one-off token in the query parameter just the transition could be a solution. You should however treat them as two separate authenticated sessions.

This vulnerability can happen sometimes with websites that use mixed HTTP and HTTPS content (certain browsers such as Firefox will give you a warning when that happens, although most people tend to disable it the first time it pops up). You could have your HTTPS session cookie for the main page, but that page contains images for the company logo, over plain HTTP. Unfortunately, the browser would send the cookie for both (so the attacker would be able the cookie then). I've seen it happen, even if the image in question wasn't even there (the browser would send the request with the cookie to the server, even if it returned a 404 not found).

Regarding the overhead of using SSL/TLS, this article by Google engineers should be of interest, more specifically:

SSL/TLS is not computationally expensive any more.