Login page uses SSL, unencrypted pages don't see encrypted session cookie (Grails, Acegi)

Question

Setup: Grails 1.1, Acegi/Spring Security plug-in

I want users to log in over SSL, so I have '/login/**' in my channelConfig.secure[] list, but almost everything else is in channelConfig.insecure[]. Every request for /login gets redirected to https:// and every other request is redirected to http://.

My problem is that the login process sets the cookie to "Send over encrypted connections only," so when the login page redirects to /home, the home page doesn't see the cookie and redirects me back to the landing page. When I try to log in again, the login page sees the cookie and redirects me...etc.

I hunted through this page about SecurityConfig to see if there is an option to allow cookies created over SSL to be read over unencrypted HTTP, but I found nothing. Is there some option I can set to make my login cookie available to my unencrypted controllers?

Answer 1

This would be a vulnerability.

Any man-in-the-middle that can see the session cookie would be able to make requests as the user. This is almost as bad as the password being intercepted. The man-in-the-middle wouldn't be able to establish new sessions on his own, but he would be able to do anything the user can do once a user logs in.

---

Using SSL does a lot more than simply hiding the user name and password at login.

First, it provides confidentiality for all messages between the client and server. It's easy to recognize the password as sensitive data, but it might not be as obvious which application features use sensitive data as well. Protecting any user input and dynamically generated content is safer and easier than trying to carefully evaluate the privacy issues of each data field used in your application. Static content such as images, help pages, etc., probably isn't as sensitive, but by analyzing requests for that content, an attacker might get a good idea of what a user is doing on the site.

Second, SSL provides integrity for every request. This prevents an attacker from modifying or appending their own nefarious input to user requests, or modifying the results produced by the server.