-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bill,
Bill Davidson wrote: | However today, I discovered door #3. Make the login servlet (which is | https) create and set the cookie as a non-secure cookie instead of letting | Tomcat create the JSESSIONID itself. This is a minor change to the code | and it seems to make everything work under Tomcat 6.0.16 as it did under | Tomcat 3.2.4. Did you change Tomcat code, or your own code? This was essentially my suggestion, except that I recommended doing it in a filter so you could modify the (effective) behavior of the Tomcat j_security_check handler to always use a non-secure cookie. | Wait, that sounds a lot like #3. :D Yup! | I didn't really do it as a filter though. The login servlet, after | verifying the | user's login and password, just creates and sets the cookie in the response | rather than letting Tomcat create the cookie. The cookie does not have | the secure flag set because the Cookie constructor doesn't set it by | default. Okay, so it sounds like you are using your own. Is there any particular reason you are not using the built-in container-based security mechanism? | Long term, I think we need to switch everything after the login to https | but I'm getting some resistance to that idea based upon performance | concerns. Those performance concerns are certainly valid. My experience has shown that most all-HTTPS sites have the SSL handshake as the most expensive part of the transaction -- sometimes even including (localhost, non-encrypted) database activity. There are ways to speed it up, but they are expensive. It's cheaper to buy more boxes ;) | Most of the app's pages don't have sensitive data so it has | been set up to only do https on pages that can contain sensitive data. Just remember that sending JSESSIONID cookies in the clear means that sessions can be hijacked. Actually, sessions can also be hijacked /without/ them being sent in the clear, but if they /are/ in the clear, then someone can actually observe a valid JSESSIONID and then hijack it, rather than having to guess at a bunch before they get lucky. You can provide countermeasures for that sort of brute-force attack, but you can't protect against a correctly-hijacked JSESSIONID without mandating a particular IP address for a session or other similar strategies. | I didn't design it. I just inherited it a few months ago. Keeping it | working | as users expect is of paramount importance so changing the way | everything is done cannot be done lightly. I totally understand. Just try to move to a more secure stance over time. It's the best you can do. Good luck, - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhO1gEACgkQ9CaO5/Lv0PBn9wCeIvWEfPUp4WUwYoiUsUGCpWJm pB8AoJiLTTq3R5r/uA+5+z2VfLtqsnwe =Qthr -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
