APM and sslstrip (man in the middle attack)

I'll add a few comments here:

1. There's been 5 years of browser/technology/security improvements since this presentation. That's a long time in IT, and modern browsers do not behave the same way they're described here. Properly implemented, the various browser will indeed "walk the chain" up to a trusted root CA. And if you inject something else in that path that isn't cryptographically correct, the user will most definitely get a warning.

    

2. But then that's really the basis of his entire presentation - that "most" Internet users aren't smart enough to validate the security of their transactions. We can inject an untrusted cert in the validation path and users will ignore it. We can strip HTTPS:// off of a site completely and users won't notice the difference. We can inject a favicon that looks like the security lock, and users will be none the wiser. In some respect, that may always be the case, no matter how much security you add to an application, but I earnestly believe that we're all smarter than we were 5 years ago.

    

3. Then again, if you can manage to get in the middle of a client and server and terminate and re-encrypt their SSL traffic without either party noticing, then there's not a lot you can do. The secure cookie flag helps, but if you can rewrite the Set-Cookie header, that's no use. I've actually seen some applications that actually generate URIs in JavaScript on the client side. The interesting thing here is that, if done correctly, a MITM wouldn't be able to manipulate this so the client side JavaScript could actually force HTTPS communications (or at least detect when it's not in use).

    

4. I would repeat that if you can get in the middle of a client and server, and terminate and re-encrypt their SSL session without either noticing, then your security posture is generally out the window. Coincidentally, using an LTM and iRules you could do absolutely everything described in the sslsniff and sslstrip functions, and forward proxy SSL functionality in 11.4 can indeed "forge" a server certificate (not by injecting a new cert in the existing path, but by replacing the path entirely). You could technically put an LTM VIP listening on HTTPS (port 443) in front of an APM VIP, listening on HTTP (port 80), set the secure cookie option in the access policy, and then drive traffic to the APM VIP through the LTM VIP with the virtual command, and APM would work just fine. This is a common use case for accessing multiple APM policies from a single "super VIP". The issue here isn't technology, but rather psychology, and admittedly the browser vendors have dampened many of their security alerts/features in the cause of convenience. What APM brings to the table is not an enhancement to SSL, but an enormous amount of flexibility in authentication strategies. If your site demands security and you need to be impervious to things like sslsniff, then consider client certificate authentication, where you simply cannot terminate and re-encrypt the SSL. And finally, word is OCSP stapling is coming, so that'll also (browser-willing) help to defend against these sorts of attacks.