RE: FW: tomcat creating new ssl session id for same session
Highly Restricted - Confidential Hi Chris, Some more details added below. Please let me know id any more details needed. Thanks, Rekha MS -Original Message- From: Christopher Schultz Sent: Thursday, November 28, 2019 7:19 PM To: users@tomcat.apache.org Subject: Re: FW: tomcat creating new ssl session id for same session -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rekha, On 11/28/19 01:33, rekha...@dell.com wrote: > Thanks for your prompt reply. Please find my response inline. It seems you forgot to include any useful responses. > -Original Message- From: Christopher Schultz > Sent: Wednesday, November 27, 2019 > 11:15 PM To: users@tomcat.apache.org Subject: Re: FW: tomcat creating > new ssl session id for same session > > Rekha, > > On 11/27/19 05:15, rekha...@dell.com wrote: >> I am using javax.servlet.request.ssl_session_id for session >> validation. But tomcat creating new ssl session id and user session >> validation is failing. > > How are you performing the validation? > > Rekha MS: Ssl_session_id is used for validation. Yes... HOW, exactly? Rekha MS: ssl_session_id is validated with the previous ssl_sesion_id stored. For the same user session ,assumption is ssl_session_id is same for all requests. But now I am seeing ssl_session_id is changing for the same user session. > What is the order-of-events that you are observing? > > Rekha MS : Ssl_session_id is same for some requests and then it > changes after some time. That was clear from your original post. I'm asking for SPECIFICS. For example, the TLS handshake establishes an ssl_session_id and the the next request seems to change the session id. Or maybe the session id changes every 30 minutes? OR after you suspend the OS on the client and come out of sleep? Rekha MS: TLS handshake establishes an ssl_session_id and the next request in the same user session seems to change the session id Please give some details or nobody will be able to help you. > What version of Tomcat, and what kind of are you using? > > Rekha MS: Tomcat 8.5.15 , Nio connector(Http11NioProtocol to be > specific) That is a quite old version of Tomcat. Is there a reason you are 2.5-year-old version of Tomcat with published vulnerabilities and many many bug fixes? Rekha MS: I have upgraded to 9.0.21 version. Have you read the changelog? Perhaps there are interesting things in there related to your issue. Are you using OpenSSL or the pure-Java cryptographic provider? Rekha MS :Java cryptographic provider. >> Please let me know when tomcat creates new ssl session id and how by >> mandate it to use same ssl session id for same user session > > TLS session ids must change periodically when certain renegotiations > occur. This is actually a security feature. I'm not sure it is > possible to disable it entirely> Rekha MS: what triggers these > renegotiations? If anything about the connection must change -- such as the server requesting a client certificate -- a renegotiation occurs. The session id is not required to change, but it may change. The client or the server may request renegotiation at any time for any reason. AFAIK, Tomcat does not request renegotiation unless a client certificate is requested/required for authentication and the client didn't volunteer one during the handshake. Rekha MS: We do not have client certificate, does this cause renegotiations to happen. This was not happening before. From which release is such request renegotiation enforced. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f0GEACgkQHPApP6U8 pFgz0Q/+Ltbz35ZyHwGU1eupyP7K921l3FNVssH/PAbuX82aZhAZFVM19vaRXTDX vQJrAV4OBF8CSXZ45McjPVaBjensuK2cGbPc46LCXNtGEkB8hjoMH1EayCDc8K8k PaXgQKWczsitcd7dchjQOV6inK3CTwjD9yK93eUrAlJDbzjUbTOoMVf4Z1XmrOJw /k2Y1Om8140br9EkEgIELTQr72OcbGPsQTEl780Gq2kFv1PC8mxgbpNZbqCsvmPa YDMQLEstlmmaF+yztL46EGRVbVopxcJLT4kpkr4/Qk5Al6weVRlvZInaDyXJn9IJ t3k5cDHhAUG4Tv477zHche+aexDimmlsMA8FKclp30iV4h8383TCURXEQkGEmnm9 Y+Kx9lneWuwCIuNJvdInl7seao9iCaWuuYbekVhpBkk9sLLO++HzFe0+w4kSqZ8y qPV+ttmXt7kwkFbzXvlyrbs8GAEIX+H1m/vVa+OQghF27Qg8hnG2NiV6VsfU8/2i DCfUp9+EjD6w5V+mEuNjZTo9+Miz5Cxl42G2QmbcojE0HiPDZ073gRwT60qJJvxp APCmjIi5XT/yGjw/RUUR9Lxh4wNzdZF7uEduRyYJtkkc2pvVtiGW8ZWoW0UL3M/T nznBlddv7I0SqtvHGpnye+lMZXwhNEAm6sat0/UzxVfGeaLjlgY= =D24+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Carsten, > in all recent Tomcat versions the standard session implementation > declares authentication related fields as 'transient', so both the > session's authType as well as it's authenticated Principal is not > saved and restored across restarts. What's interesting is that GenericPrincipal, the only concrete Principal class provided by Tomcat, does not have transient fields for username and password. And, oddly, when serialized, a SerializablePrincipal object is swapped-out in its place. Seems strange to me. The SerializablePrincipal is private static to it's not intended to be an extension point for user code. > On those fields there is a comment that clearly describes that: > > /** * The authenticated Principal associated with this session, if > any. * IMPLEMENTATION NOTE: This object is not saved > and * restored across session serializations! */ protected > transient Principal principal = null; > > However, the comment does not say WHY that information is omitted > from serialization. > > It's fine to have session data persisted across restarts, however, > currently, a session is no longer authenticated after a restart > (at least with form login, with which credentials are not sent with > every request). > > Actually, at least for my mind, that draws session persistence > quite useless, because, after a restart, the client must re-login > prior to use any resources having a security constraint. > > That may be a security thing, but if, for example, passwords stored > in the GenericPrincipal instance are not serialized, I don't see a > security problem with persisting the session's principal. But they *would* be serialized along with the Principal object if no changes were made to the SerializedPrincipal class. Since it's private, it could be changed. > Do you have any ideas on that or do you know how to work around > this? Tomcat restarts are required from time to time. But it's > really a bad idea to kick out all currently logged-in users just > because Tomcat needs to be reconfigured, for example. I'm not sure why Tomcat needs to store the Principal's password (and I haven't checked to see if FormAuthenticator sets this value to the user's password, or null instead which would be way better), but serializing that to the disk would be Bad. There isn't any encryption being placed on those stored files which means that serializing them would be a security issue. Honestly, I think it's reasonable to (a) not store the password and (b) serialize the Principal, but it's not as simple as just "remove transient from the member declaration". I've been using another authentication mechanism for so long, I didn't realize that Tomcat worked this way. The same seems to be true for clustered sessions -- you have to re-login if you fail-over to another node in the cluster. That seems pretty inconvenient. If this could be configurable, it might be very nice to have, especially for the clustering use-case. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f144ACgkQHPApP6U8 pFgD2hAAkV25fJuasaBq+4ByaDWX6nhef228NhiErOiKhcAAyVUJIkxzcqMsCrtQ BOxc60NF2zzLK/IxvSQv0xg13162jCK3EWhYSVH7nyj+KI8k6P1V4HALY8gWwTYy ENGm2J906fBDXniGvKzeptfPb49wVAovbJ2JYZlCxnahTcfKOWI49KzaqR+bfgT8 tidKYmzGVYxn6mmS8fuFFW8xCwrLs3nJ0aK1qxuyjz9XBimkDGPAq/w0vviP2LCC Pwuo8vJMNYdVqu4q5UMuszg1+QOGKIE+yX2ZOS+xWQ6L9rsc6Vy9EJ40vN5juNZP AT8oajjJ5dtbPzUT8bDGrAaBtLLVEttIcuuHyi8wBa3hjy9y/BxJpTHDP5kpR/iJ HTmibiNqEub/OI4NCS7WNiwrgsWrZhqECNPkZrzt1PA/qfCz4BS0UTJqs4kceCBu /1LUc0BzNHkjY8gNaNlyymeerDQQm74TV0uiBqhZRpXp2UlyCXBM7SadWqMauht9 VxsnGv6k+VdDwlA/CRhpXh6Jcfi2k7SZy36yz2lZ+1U9qwiqCZMdzXBhyPcDIrmy Vn/RB/0D/a2X+XrTlVZv6HceFeP62J8i4zRnjxC6NS4QgrDTnvmiQNDljrAaKwqu /rfZdq3Ft9a1CKGWoV1dR4Dq/j8TH54Du7kbocQUHUFnN/lpYPE= =7/bk -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error after upgrading to Tomcat 9.0.29
On 28/11/2019 13:56, Juri Berlanda wrote: > Hi Mark, > > I have 2 good news: > > 1. The issue I've seen is fixed with your 9.0.30-dev build > 2. My PC did not catch fire while running your 9.0.30-dev build :) > > So I guess I'll just wait for the final 9.0.30 release and stay on > 9.0.27 until then. Thanks a lot for the quick help and solution. Great news on both counts ;) Many thanks for testing this. It is much appreciated. Mark > > Cheers, > > Juri > > On 11/27/19 1:08 PM, Mark Thomas wrote: >> On 26/11/2019 21:22, Juri Berlanda wrote: >>> Hi, >>> >>> I never built Tomcat from source, but I guess there is a first time for >>> everything :-) >>> >>> I'm out of office tomorrow, but I will give it a shot on Thursday and >>> let you know how it went. Where can I find the source with the fix? >> https://github.com/apache/tomcat >> (master branch) >> >> Alternatively, you can pick up a 9.0.30-dev build from: >> http://people.apache.org/~markt/dev/v9.0.30-dev/ >> >> Note: This is just to enable this fix to be tested. It isn't a formal >> release. Use it at your own risk. If you machine catches fire don't >> blame me ;) >> >> Thanks, >> >> Mark >> >> >>> Cheers, >>> >>> Juri >>> >>> On 11/26/19 7:01 PM, Mark Thomas wrote: On 26/11/2019 16:35, Mark Thomas wrote: > On 25/11/2019 19:17, Juri Berlanda wrote: >> Hi all, >> >> I post my Stacktrace again, as I mistakenly previously only sent >> it to >> Rémy Maucherat. >> >> I'll try to make it as short as possible: > Maybe a cariation of: > https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 > ? I think I have a fix for this. Are you able to build from source to test this once I commit the fix? If you aren't able to build from source, would it help if I provided a binary build? Mark - 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 >>> >> >> - >> 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: Error after upgrading to Tomcat 9.0.29
Hi Mark, I have 2 good news: 1. The issue I've seen is fixed with your 9.0.30-dev build 2. My PC did not catch fire while running your 9.0.30-dev build :) So I guess I'll just wait for the final 9.0.30 release and stay on 9.0.27 until then. Thanks a lot for the quick help and solution. Cheers, Juri On 11/27/19 1:08 PM, Mark Thomas wrote: On 26/11/2019 21:22, Juri Berlanda wrote: Hi, I never built Tomcat from source, but I guess there is a first time for everything :-) I'm out of office tomorrow, but I will give it a shot on Thursday and let you know how it went. Where can I find the source with the fix? https://github.com/apache/tomcat (master branch) Alternatively, you can pick up a 9.0.30-dev build from: http://people.apache.org/~markt/dev/v9.0.30-dev/ Note: This is just to enable this fix to be tested. It isn't a formal release. Use it at your own risk. If you machine catches fire don't blame me ;) Thanks, Mark Cheers, Juri On 11/26/19 7:01 PM, Mark Thomas wrote: On 26/11/2019 16:35, Mark Thomas wrote: On 25/11/2019 19:17, Juri Berlanda wrote: Hi all, I post my Stacktrace again, as I mistakenly previously only sent it to Rémy Maucherat. I'll try to make it as short as possible: Maybe a cariation of: https://bz.apache.org/bugzilla/show_bug.cgi?id=63964 ? I think I have a fix for this. Are you able to build from source to test this once I commit the fix? If you aren't able to build from source, would it help if I provided a binary build? Mark - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: FW: tomcat creating new ssl session id for same session
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Rekha, On 11/28/19 01:33, rekha...@dell.com wrote: > Thanks for your prompt reply. Please find my response inline. It seems you forgot to include any useful responses. > -Original Message- From: Christopher Schultz > Sent: Wednesday, November 27, 2019 > 11:15 PM To: users@tomcat.apache.org Subject: Re: FW: tomcat > creating new ssl session id for same session > > Rekha, > > On 11/27/19 05:15, rekha...@dell.com wrote: >> I am using javax.servlet.request.ssl_session_id for session >> validation. But tomcat creating new ssl session id and user >> session validation is failing. > > How are you performing the validation? > > Rekha MS: Ssl_session_id is used for validation. Yes... HOW, exactly? > What is the order-of-events that you are observing? > > Rekha MS : Ssl_session_id is same for some requests and then it > changes after some time. That was clear from your original post. I'm asking for SPECIFICS. For example, the TLS handshake establishes an ssl_session_id and the the next request seems to change the session id. Or maybe the session id changes every 30 minutes? OR after you suspend the OS on the client and come out of sleep? Please give some details or nobody will be able to help you. > What version of Tomcat, and what kind of are you > using? > > Rekha MS: Tomcat 8.5.15 , Nio connector(Http11NioProtocol to be > specific) That is a quite old version of Tomcat. Is there a reason you are 2.5-year-old version of Tomcat with published vulnerabilities and many many bug fixes? Have you read the changelog? Perhaps there are interesting things in there related to your issue. Are you using OpenSSL or the pure-Java cryptographic provider? >> Please let me know when tomcat creates new ssl session id and how >> by mandate it to use same ssl session id for same user session > > TLS session ids must change periodically when certain > renegotiations occur. This is actually a security feature. I'm not > sure it is possible to disable it entirely> Rekha MS: what triggers > these renegotiations? If anything about the connection must change -- such as the server requesting a client certificate -- a renegotiation occurs. The session id is not required to change, but it may change. The client or the server may request renegotiation at any time for any reason. AFAIK, Tomcat does not request renegotiation unless a client certificate is requested/required for authentication and the client didn't volunteer one during the handshake. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f0GEACgkQHPApP6U8 pFgz0Q/+Ltbz35ZyHwGU1eupyP7K921l3FNVssH/PAbuX82aZhAZFVM19vaRXTDX vQJrAV4OBF8CSXZ45McjPVaBjensuK2cGbPc46LCXNtGEkB8hjoMH1EayCDc8K8k PaXgQKWczsitcd7dchjQOV6inK3CTwjD9yK93eUrAlJDbzjUbTOoMVf4Z1XmrOJw /k2Y1Om8140br9EkEgIELTQr72OcbGPsQTEl780Gq2kFv1PC8mxgbpNZbqCsvmPa YDMQLEstlmmaF+yztL46EGRVbVopxcJLT4kpkr4/Qk5Al6weVRlvZInaDyXJn9IJ t3k5cDHhAUG4Tv477zHche+aexDimmlsMA8FKclp30iV4h8383TCURXEQkGEmnm9 Y+Kx9lneWuwCIuNJvdInl7seao9iCaWuuYbekVhpBkk9sLLO++HzFe0+w4kSqZ8y qPV+ttmXt7kwkFbzXvlyrbs8GAEIX+H1m/vVa+OQghF27Qg8hnG2NiV6VsfU8/2i DCfUp9+EjD6w5V+mEuNjZTo9+Miz5Cxl42G2QmbcojE0HiPDZ073gRwT60qJJvxp APCmjIi5XT/yGjw/RUUR9Lxh4wNzdZF7uEduRyYJtkkc2pvVtiGW8ZWoW0UL3M/T nznBlddv7I0SqtvHGpnye+lMZXwhNEAm6sat0/UzxVfGeaLjlgY= =D24+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
On 28/11/2019 08:03, Klein, Carsten wrote: > Hi there, > > in all recent Tomcat versions the standard session implementation > declares authentication related fields as 'transient', so both the > session's authType as well as it's authenticated Principal is not saved > and restored across restarts. It isn't just recent versions. It has been that way for 2 decades. All the way back to Tomcat 4.0.x > On those fields there is a comment that clearly describes that: > > /** > * The authenticated Principal associated with this session, if any. > * IMPLEMENTATION NOTE: This object is not saved and > * restored across session serializations! > */ > protected transient Principal principal = null; > > However, the comment does not say WHY that information is omitted from > serialization. > > It's fine to have session data persisted across restarts, however, > currently, a session is no longer authenticated after a restart (at > least with form login, with which credentials are not sent with every > request). > > Actually, at least for my mind, that draws session persistence quite > useless, because, after a restart, the client must re-login prior to use > any resources having a security constraint. Useless seems a bit strong. The session data is still there. Nothing is lost. But the user does have to re-enter their credentials to continue (if the authentication mechanism doesn't do it automatically). If re-entering the credentials is an issue, have you considered using an alternative authentication mechanism? > That may be a security thing, but if, for example, passwords stored in > the GenericPrincipal instance are not serialized, I don't see a security > problem with persisting the session's principal. User names and passwords are generally viewed as more sensitive that the Principal object which is generally viewed as more sensitive than the session ID. Where users draw the line between what is acceptable and unacceptable is going to vary. > Do you have any ideas on that or do you know how to work around this? > Tomcat restarts are required from time to time. But it's really a bad > idea to kick out all currently logged-in users just because Tomcat needs > to be reconfigured, for example. Re-entering credentials seems to be a major issue in this instance. Are you able to share what is driving that (with more information we might be able to identify a other solutions). There are various 3rd-party session managers available for Tomcat. One of those may well retain the Principal across restarts. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Apache Tomcat 8.5.49 - StackOverflowError when getting static resources
On 28/11/2019 07:59, jan.a...@seznam.cz wrote: > Hello Mark, > > no problem, thanks that I could test it also with 8.5 version. > > With your build Apache Tomcat/8.5.50-dev issue also disapeared. Thanks for the confirmation. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
Hi there, in all recent Tomcat versions the standard session implementation declares authentication related fields as 'transient', so both the session's authType as well as it's authenticated Principal is not saved and restored across restarts. On those fields there is a comment that clearly describes that: /** * The authenticated Principal associated with this session, if any. * IMPLEMENTATION NOTE: This object is not saved and * restored across session serializations! */ protected transient Principal principal = null; However, the comment does not say WHY that information is omitted from serialization. It's fine to have session data persisted across restarts, however, currently, a session is no longer authenticated after a restart (at least with form login, with which credentials are not sent with every request). Actually, at least for my mind, that draws session persistence quite useless, because, after a restart, the client must re-login prior to use any resources having a security constraint. That may be a security thing, but if, for example, passwords stored in the GenericPrincipal instance are not serialized, I don't see a security problem with persisting the session's principal. Do you have any ideas on that or do you know how to work around this? Tomcat restarts are required from time to time. But it's really a bad idea to kick out all currently logged-in users just because Tomcat needs to be reconfigured, for example. Regards Carsten -- Carsten Klein Lead Software Engineer DataGis GmbH Johann-Strauß-Str. 26 70794 Filderstadt T +49 7158 9490-106 F +49 7158 9490-111 E-Mail: c.kl...@datagis.com Internet: www.datagis.com Registergericht: Amtsgericht Stuttgart, HRB 225945 Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
