Re: Tomcat 8.5.4 and LegacyCookieProcessor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Jared, On 5/18/17 1:24 PM, Jared Walker wrote: > Now, I know this is only a work around as the "spec" being used by > this client is ancient. We are considering using the legacy parser > as a stop-gap measure until we can update the external clients with > a new version. Others have answered your core question, but I have another point to add: you can fix these clients by changing your application slightly. Modify your application to re-write your cookie values with a value that does not require any spec-ambiguous decoding. Specifically, use something like base64 encoding so your cookie value is always clean. If a client sends you a cookie value that is not in the "new" format, re-issue the cookie value to them with the new format. Issue all new cookies in the new format (of course). They it doesn't matter whether or not the clients are properly spec-compliant. > 2. The header for LegacyCookieProcesor.java explicitly states: > "This class is not thread-safe." That is a note to direct consumers of the class. Tomcat's use of this class is safe (it would be a pretty bad bug if it were not used in a safe way). - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkfBVkACgkQHPApP6U8 pFhLmw/9Eh04el3+EiDtpaO1gMwpfdo8E0FJ8eA0A0Jz03rgfQpCNRtvFJOAVcaw 8sg1g+WFYgi5fASv48fVk3p6Bccm7GRNTfXayYh/n9KCaW4nJdhnB9qVDSRubhps K/sLG7Jc4+x6tHmBa4V2c6/70whb89nWnmKBxXZ27pO6Bbn1Vd3bj2uVJCRyzS2/ MGlimUpyeXCYHcZMly7VoKJSEdyh8FWevuBZq2L16LvWs6ncVQxkfgNUm4TmxE5o ZvSxy0ThlBtJxYPi0evozVmaqBhzEE9mX/ARqR/qSU0jnka8M1MH2VjtFCLjCQ1A kj5NKqiNIVoyJypDpdk3DSoHZT29wpSULbem0pna/VsFZE9qEwT7FkPt30MpWAls qCcFAI+o+g3tV5Hv1dPGxnHmvH/iXmxC5HkYSlI4igaQ56eSOeFd4NKd3p7UPC1q mR+N+DqjJDDjSXTufebB33bdKbBOVjpq+fc67BQgqXP1fJFuK355lPUpNvmTCUY2 2xiC9cUSuqKx1h1RM3KwOmfDw/g4hUnyLYjabyhoLSr5tIPCIKeVwTTuMd6SvGaY SqDjsex397u5UxdXWj3aIbCPmQXHCB9tFPAk6eHLZpj9y7pDQoeLWhkzRG+slhzE M5vTS9xYM+xXB3Nvh2cswQQVs7F5KV+yiAVEhvJNnmTpLroiuhY= =EA0s -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.4 and LegacyCookieProcessor
On 18/05/2017 19:12, Caldarale, Charles R wrote: From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On Behalf Of Jared Walker Subject: Tomcat 8.5.4 and LegacyCookieProcessor We are migrating to the version of tomcat identified in the subject Before exposing an almost year-old version to the nasty real world, you might want to look at this: http://tomcat.apache.org/security-8.html and then pick a newer level (hint: 8.5.15 would be good). Plus that version includes a fix for the problem the OP is seeing: https://bz.apache.org/bugzilla/show_bug.cgi?id=60627 1. What are the security and compatibility concerns when using the legacy processor Sorry, can't answer that one. Security concerns - none known (if there were we'd have fixed them) Compatibility - tends to play better with older browsers. Lots of config options to handle various edge cases. Mark 2. The header for LegacyCookieProcesor.java explicitly states: "This class is not thread-safe." Can someone here with background knowledge explain exactly whats not thread-safe about the processor? Does this mean you cannot use it for multiple simultaneous requests (pretty hindering for a server) or does this mean that you cannot have multiple threads parse the cookie contents of a request in parallel (which isn't a very normal thing to do)? It's neither, really; there is one instance of CookieProcessor per , and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the is initialized. Were you to dynamically reset the fields while requests were in progress, you could get in trouble. The fields are described here: http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Tomcat 8.5.4 and LegacyCookieProcessor
> From: jared.paul.wal...@gmail.com [mailto:jared.paul.wal...@gmail.com] On > Behalf Of Jared Walker > Subject: Tomcat 8.5.4 and LegacyCookieProcessor > We are migrating to the version of tomcat identified in the subject Before exposing an almost year-old version to the nasty real world, you might want to look at this: http://tomcat.apache.org/security-8.html and then pick a newer level (hint: 8.5.15 would be good). > 1. What are the security and compatibility concerns when using the > legacy processor Sorry, can't answer that one. > 2. The header for LegacyCookieProcesor.java explicitly states: "This > class is not thread-safe." > Can someone here with background knowledge explain exactly whats not > thread-safe about the processor? Does this mean you cannot use it for > multiple simultaneous requests (pretty hindering for a server) or does > this mean that you cannot have multiple threads parse the cookie > contents of a request in parallel (which isn't a very normal thing to > do)? It's neither, really; there is one instance of CookieProcessor per , and the fields within LegacyCookieProcessor that make it not thread-safe are only set (in Tomcat) when the is initialized. Were you to dynamically reset the fields while requests were in progress, you could get in trouble. The fields are described here: http://tomcat.apache.org/tomcat-8.5-doc/config/cookie-processor.html - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
