> In his 2010 talk "Everything you need to know about cryptography in 1 hour" (http://blip.tv/fosslc/everything-you-need-to-know-about-cryp...), Colin also recommends limiting SSL use to a confined area.

Doesn't this leave you vulnerable to session theft?

Yes and no. Depends on what you let open sessions do. For example, you can steal my Amazon cookies and dick with my wish list, or put a bunch of crap in my cart, or fill my recommendation list with weird stuff. But you can't buy anything because Amazon asks again for my password. (There does seem to be an option now to skip that, but I've never enabled it. Lets pretend I'm talking about the old Amazon.)

The session ID is encoded into each URL or Form, and the request is signed using an HMAC-SHA-256 signature.

UPDATE: Looking again at Amazon.com's current HTML, it does not appear that Amazon.com is securing all requests so it may be vulnerable.

Deploying SSL partially is very dangerous, because then you have to be _very_ careful that the session ID is not compromised. I'd go as far as to say that it's virtually impossible to do that securely (for the average web site, built by more than one person who are not security experts, maintained under pressure over a period of years, and so on).

Someone else here mentioned SSL stripping, which is another problem, which you can't avoid [with partial SSL] no matter how much you try.

If you're deploying SSL today and you're not using HTTP Strict Transport Security, you're doing it incorrectly.

Using encrypted tokens help mitigate stolen session IDs (https://owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF...).

And while HSTS helps protect against sslstrip, you're still vulnerable to MITM attacks due to issues with the CA system.

See moxie's 2011 talk "SSL and the Future of Authenticity" ( http://www.youtube.com/watch?v=Z7Wl2FW2TcA)

Encrypted tokens might help against CSRF, but if I have your session ID, it's game over. The best you can do is restrict the user agent used with the session, but that's an obstacle that can be overcome. You might try to restrict the IP address used with the session, too, but those change often even without attack that it's not practical, either.

The robustness of the public CA system is a legitimate problem, but it's not a concern for most of us. People like to complain that the public CA security model is not perfect, but we have to remember that the CA ecosystem was not designed for perfection; it was designed to enable ecommerce. We now have different goals (well, some of us) and have to change our approach accordingly.

MITM attacks using fraudulent certificates are very costly and make sense only against very high-value properties. If you're legitimately worried about them, you should consider using public key pinning, which effectively deals with the problem. (But, alas, only works in Chrome today.)

That's very convincing. What then is the advantage of only selectively using SSL, and why are some people recommending it?

Performance issues (I'd say most are imagined, but there is definitely an increase in latency) and higher cost of deployment with SSL (essentially more expensive CDNs). Some sites that rely on 3rd party services might struggle to deploy full SSL if not all services support it.

In my experience, most people are recommending partial SSL because they're not aware of the security issues. For example, many developers "know" that you're supposed to use SSL only to protect login credentials.

> For example, Amazon.com only uses only SSL when you log in, check out, or access "Your Account". Everywhere else Amazon.com uses HMAC request signatures over HTTP, similar to how AWS API requests are signed.

My main concern about a scheme like this is the vulnerability to SSL stripping.

I'm not sure what you can do mitigate it apart from have SSL on all the time, HSTS telling the browser that it should be using SSL and hoping that the first time a user comes to your site is via a https link.