Re: [VOTE] Release Apache Tomcat 7.0.52
2014-02-13 17:17 GMT+09:00 Violeta Georgieva : > The proposed Apache Tomcat 7.0.52 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.52/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1007/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_52/ > > The proposed 7.0.52 release is: > [ ] Broken - do not release > [X] Stable - go ahead and release as 7.0.52 Stable > > +1 Tested on my simple hand-made app.(use DeltaManager). > Regards > Violeta > > -- > Keiichi.Fujino
[Bug 56137] New: Change HTTPS connector example (protocol attribute) from "HTTP/1.1" to Http11NioProtocol
https://issues.apache.org/bugzilla/show_bug.cgi?id=56137 Bug ID: 56137 Summary: Change HTTPS connector example (protocol attribute) from "HTTP/1.1" to Http11NioProtocol Product: Tomcat 8 Version: trunk Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: ognjen.d.blagoje...@gmail.com HTTPS example connector in server.xml uses JSSE-specific attributes, but it also uses connector auto-selection using attribute protocol="HTTP/1.1". If a user follows the "Quick start" section of "SSL Configuration HOW-TO", and previously, or after that installs APR, HTTPS connector won't work. That breaks the principle of least astonishment. Proposal: in HTTPS example connector, change protocol="HTTP/1.1" to protocol="org.apache.coyote.http11.Http11NioProtocol". It is not as beautiful as "HTTP/1.1", but it will cause less trouble for novices. -Ognjen -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.52
On 2/13/2014, 3:17 AM, Violeta Georgieva wrote: The proposed Apache Tomcat 7.0.52 release is now available for voting. It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.52/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-1007/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_52/ The proposed 7.0.52 release is: [ ] Broken - do not release [X] Stable - go ahead and release as 7.0.52 Stable Tested jsr356 and native websocket API, Servlet 3.0 AsyncContext -- Jeanfrancois - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Special requirements on session id generator
I ran into a special requirement for the session id generator (uniqueness of session id for a longer time interval). While I think that the requirement needed isn't a useful general purpose extension, I stumbled over the fact, that the SessionIdGenerator class is not pluggable. Would it make sense to introduce a new interface for the session Id generation, probably including setJvmRoute(), setSessionIdLength() and generateSessionId(), letting the current implementation be the base implementation, probably switching getRandomBytes() to protected, and allowing to set the implementation class in ManagerBase - or the Manager interface (trunk)? I haven't worked it out in detail, but it looks easy to do and useful. WDYT? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
Hi FYI I had the same need in my previous company and needed to extends multiple things to be able to extend the generate method. WOuld be great to have an interface just with nextId(jvmroute) method or something like that Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 14:15 GMT+01:00 Rainer Jung : > I ran into a special requirement for the session id generator > (uniqueness of session id for a longer time interval). While I think > that the requirement needed isn't a useful general purpose extension, I > stumbled over the fact, that the SessionIdGenerator class is not pluggable. > > Would it make sense to introduce a new interface for the session Id > generation, probably including setJvmRoute(), setSessionIdLength() and > generateSessionId(), letting the current implementation be the base > implementation, probably switching getRandomBytes() to protected, and > allowing to set the implementation class in ManagerBase - or the Manager > interface (trunk)? > > I haven't worked it out in detail, but it looks easy to do and useful. > > WDYT? > > Regards, > > Rainer > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
On 14/02/2014 13:15, Rainer Jung wrote: > I ran into a special requirement for the session id generator > (uniqueness of session id for a longer time interval). While I think > that the requirement needed isn't a useful general purpose extension, I > stumbled over the fact, that the SessionIdGenerator class is not pluggable. > > Would it make sense to introduce a new interface for the session Id > generation, probably including setJvmRoute(), setSessionIdLength() and > generateSessionId(), letting the current implementation be the base > implementation, probably switching getRandomBytes() to protected, and > allowing to set the implementation class in ManagerBase - or the Manager > interface (trunk)? > > I haven't worked it out in detail, but it looks easy to do and useful. > > WDYT? I'm struggling to understand the use case. Are you saying the current implementation generates collisions? That would be bad given that SecureRandom is being used. Ignoring the previous question, why can't the requirement be met with a custom implementation of SecureRandom? If the requirement is to be certain that a duplicate session ID is not generated I'd use a custom Manager and check the returned ID against those currently in use request a new one in the highly unlikely event of a duplicate being returned. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
@Mark my use case was easier to understand maybe: we just needed to control and make not readable jvmroutes in urls Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-14 14:27 GMT+01:00 Mark Thomas : > On 14/02/2014 13:15, Rainer Jung wrote: >> I ran into a special requirement for the session id generator >> (uniqueness of session id for a longer time interval). While I think >> that the requirement needed isn't a useful general purpose extension, I >> stumbled over the fact, that the SessionIdGenerator class is not pluggable. >> >> Would it make sense to introduce a new interface for the session Id >> generation, probably including setJvmRoute(), setSessionIdLength() and >> generateSessionId(), letting the current implementation be the base >> implementation, probably switching getRandomBytes() to protected, and >> allowing to set the implementation class in ManagerBase - or the Manager >> interface (trunk)? >> >> I haven't worked it out in detail, but it looks easy to do and useful. >> >> WDYT? > > I'm struggling to understand the use case. Are you saying the current > implementation generates collisions? That would be bad given that > SecureRandom is being used. > > Ignoring the previous question, why can't the requirement be met with a > custom implementation of SecureRandom? > > If the requirement is to be certain that a duplicate session ID is not > generated I'd use a custom Manager and check the returned ID against > those currently in use request a new one in the highly unlikely event of > a duplicate being returned. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1568315 - /tomcat/trunk/build.properties.default
Author: markt
Date: Fri Feb 14 14:20:07 2014
New Revision: 1568315
URL: http://svn.apache.org/r1568315
Log:
Keep pace with DBCP 2
Modified:
tomcat/trunk/build.properties.default
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1568315&r1=1568314&r2=1568315&view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Fri Feb 14 14:20:07 2014
@@ -156,7 +156,7 @@ tomcat-native.win.2=${base-tomcat.loc.2}
#commons-dbcp.home=${base.path}/commons-dbcp-${commons-dbcp.version}-src
#commons-dbcp-src.loc.1=${base-commons.loc.1}/dbcp/source/commons-dbcp-${commons-dbcp.version}-src.tar.gz
#commons-dbcp-src.loc.2=${base-commons.loc.2}/dbcp/source/commons-dbcp-${commons-dbcp.version}-src.tar.gz
-commons-dbcp.version=2.0-20140213.113517-177
+commons-dbcp.version=2.0-20140214.133747-182
commons-dbcp.home=${base.path}/commons-dbcp2-2.0-SNAPSHOT-src
commons-dbcp-src.loc.1=https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2/2.0-SNAPSHOT/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
commons-dbcp-src.loc.2=https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2/2.0-SNAPSHOT/commons-dbcp2-${commons-dbcp.version}-src.tar.gz
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
On 14.02.2014 14:27, Mark Thomas wrote: > On 14/02/2014 13:15, Rainer Jung wrote: >> I ran into a special requirement for the session id generator >> (uniqueness of session id for a longer time interval). While I think >> that the requirement needed isn't a useful general purpose extension, I >> stumbled over the fact, that the SessionIdGenerator class is not pluggable. >> >> Would it make sense to introduce a new interface for the session Id >> generation, probably including setJvmRoute(), setSessionIdLength() and >> generateSessionId(), letting the current implementation be the base >> implementation, probably switching getRandomBytes() to protected, and >> allowing to set the implementation class in ManagerBase - or the Manager >> interface (trunk)? >> >> I haven't worked it out in detail, but it looks easy to do and useful. >> >> WDYT? > > I'm struggling to understand the use case. Are you saying the current > implementation generates collisions? Yes. But only over time, not concurrently. So some session ID used some time were again generated on later days. The rate was low, about one out of 100.000 IDs were generated again during the next 30 days. I don't see a problem here per se, but the application required the IDs to be unique over an extended period of time. > That would be bad given that > SecureRandom is being used. Not sure, whether the above rate is totally unexpected. It could have used /dev/urandom, so might depend on total system behavior. > Ignoring the previous question, why can't the requirement be met with a > custom implementation of SecureRandom? Just because I haven't thought of that :) Will check. One thing that comes to my mind is that the session id generator encodes the random bytes. Making IDs more unique for an extended period of time will end up replacing some of the random bytes by other data. That limits the randomness. I was hoping to compensate for that by using an extended setof characters to encode the ID instead of simply hex like it is now. So at the end, I can squeeze the additional info plus enough random bytes in it. AFAIR that changed encoding would mean I have to change the session id generator. > If the requirement is to be certain that a duplicate session ID is not > generated I'd use a custom Manager and check the returned ID against > those currently in use request a new one in the highly unlikely event of > a duplicate being returned. That's already done by our StandardManager. It is not about the ones currently in use but about ones that had been used during the last say 30 days. There's a database I could check against, but since very few "duplicates" seem acceptable I prefer to reduce the number of duplicates by adding time information to the custom session id shrinking the window of possible duplicates. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56139] New: "SeedGenerator Thread" warnings when running tests on Windows
https://issues.apache.org/bugzilla/show_bug.cgi?id=56139 Bug ID: 56139 Summary: "SeedGenerator Thread" warnings when running tests on Windows Product: Tomcat 8 Version: 8.0.3 Hardware: PC Status: NEW Severity: minor Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: knst.koli...@gmail.com Reviewing testsuite logs when running on Windows, I noted the following error messages: org.apache.catalina.loader.WebappClassLoader clearReferencesThreads SEVERE: The web application [/foo] appears to have started a thread named [SeedGenerator Thread] but has failed to stop it. This is very likely to create a memory leak. The above warning is from org.apache.catalina.authenticator.TestDigestAuthenticator, but there are other test cases that display it. This is observed when testing on Windows 7 using Tomcat 8.0.3 +Oracle Java 7u51 (32-bit) Tomcat 7.0.52 +Oracle Java 6u45 (32-bit) Tomcat 7.0.52 +Oracle Java 7u51 (32-bit) Googling by the thread name, I found openjdk7 source code for sun.security.provider.SeedGenerator class at [1] [1] http://www.docjar.com/html/api/sun/security/provider/SeedGenerator.java.html To reproduce on an usual Tomcat instance, on Windows: 1). Create bin/setenv.bat: set CATALINA_OPTS=-Djava.security.egd=file:/dev/./urandom 2). Start Tomcat. Note what web application was deployed and started first. In my case it is "docs". 3). Trigger reload or redeploy of the web application (touch its WEB-INF/web.xml, or rename docs -> docs1). After this, an "appears to have started a thread named [SeedGenerator Thread]" message is logged in catalina..log file. (It does not matter whether the application actually generates session ids. It matters that it was the first to start session id generator). My conclusion: === 1. This is triggered by the following setting in build.properties.default file: test.jvmarg.egd=-Djava.security.egd=file:/dev/./urandom If the file "/dev/urandom" is not readable (e.g. on Windows, may be on some unix systems as well), SeedGenerator fallbacks to an algorithm that creates that "SeedGenerator Thread" thread. 2. Workaround: Redefine this property in custom build.properties file. Using any 1 of the following 2 lines works. The message disappears from test logs. test.jvmarg.egd=-Djava.security.egd=file:/dev/urandom test.jvmarg.egd= (The "file:/dev/urandom" value is considered by SeedGenerator class as a special value, a marker to use native implementation of random seed generator). Possible fixes: 1. Document this effect in places where "java.security.egd" property is mentioned. A web application should not use such value of "java.security.egd" property when /dev/urandom is not readable. (I know two places: Migration guide, "FasterStartUp" wiki page) 2. Fix configuration of the tests. Maybe either document this in testing section of BUILDING.txt, or move this property definition into build.xml, making it conditional on . 3. Can JreMemoryLeakPreventionListener guard against this? Maybe it can, by creating a SecureRandom instance. Generally, I see no need for such guard there, because trying to use /dev/urandom on a system where such file is not readable is a blatant configuration error. 4. Can clearReferencesThreads turn a deaf ear to SeedGenerator thread? I think it should not. I think it is a read issue that pins TCCL in memory. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Special requirements on session id generator
Hi Rainer & Mark, > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, February 14, 2014 4:32 PM > To: Tomcat Developers List > Subject: Re: Special requirements on session id generator > > On 14.02.2014 14:27, Mark Thomas wrote: > > On 14/02/2014 13:15, Rainer Jung wrote: > >> I ran into a special requirement for the session id generator > >> (uniqueness of session id for a longer time interval). While I think > >> that the requirement needed isn't a useful general purpose extension, I > >> stumbled over the fact, that the SessionIdGenerator class is not > pluggable. > >> > >> Would it make sense to introduce a new interface for the session Id > >> generation, probably including setJvmRoute(), setSessionIdLength() and > >> generateSessionId(), letting the current implementation be the base > >> implementation, probably switching getRandomBytes() to protected, and > >> allowing to set the implementation class in ManagerBase - or the Manager > >> interface (trunk)? > >> > >> I haven't worked it out in detail, but it looks easy to do and useful. > >> > >> WDYT? > > > > I'm struggling to understand the use case. Are you saying the current > > implementation generates collisions? > > Yes. But only over time, not concurrently. So some session ID used some > time were again generated on later days. The rate was low, about one out > of 100.000 IDs were generated again during the next 30 days. I don't see > a problem here per se, but the application required the IDs to be unique > over an extended period of time. > > > That would be bad given that > > SecureRandom is being used. > > Not sure, whether the above rate is totally unexpected. It could have > used /dev/urandom, so might depend on total system behavior. I don't think that this is unexpected, even with a "secure" Random generator. My understanding is that a secure random generator is guaranteed to produce non-predictable output (so it is OK for security purposes like generating Session IDs), but that shouldn't mean anything about the "randomness" of the generated bytes, as e.g. the Javadoc says, most implementations are still pseudo-random, but use a true random seed. However, even with a true random generator, one can expect to get collisions over time, even with a 16 byte number (Session-ID). I think this is an application of the birthday problem / birthday paradox: If you chose 23 random people, then the likehood that two of them have the same birthday is > 50 % (when not considering the birth year). The Wikipedia article also talks about the cast as a collision problem [2]: "The birthday problem can be generalized as follows: given n random integers drawn from a discrete uniform distribution with range [1,d], what is the probability p(n;d) that at least two numbers are the same? (d=365 gives the usual birthday problem.)" In the case of a 16 byte session id, "d" would be 256^16 and "n" would be the number of generated Session-IDs which one wants to monitor for collisions (e.g. if the application produces 10 million session-IDs over 30 days, one could take 10 million for "n" to get the likehood of a collision of the session ID in 30 days). > > Ignoring the previous question, why can't the requirement be met with a > > custom implementation of SecureRandom? > > Just because I haven't thought of that :) Will check. One thing that > comes to my mind is that the session id generator encodes the random > bytes. Making IDs more unique for an extended period of time will end up > replacing some of the random bytes by other data. That limits the > randomness. I was hoping to compensate for that by using an extended > setof characters to encode the ID instead of simply hex like it is now. > So at the end, I can squeeze the additional info plus enough random > bytes in it. AFAIR that changed encoding would mean I have to change the > session id generator. >From my understanding, if you don't watch for collisions, then the number of >possible values for a session-ID (consisting of 16 random bytes) would be >256^16 at any time. However, if you would like to prevent collisions, then you >would need to memorize each previously generated session-ID, and remove them >from the pool of available session-IDs that can be generated. E.g., for the >first Session-ID, the amount of possible values is 256^16, for the second it's >(256^16-1), for the third it's (256^16-2) and so on, until you include some >older session-IDs back into the pool of available session-IDs. Can you explain what you mean with "using an extended setof characters to encode the ID instead of simply hex"? AFAIK, a Random Number generator produces random bytes (as the simplest random value is a bit, so it can produce a series of 2^n random bits). Using hex characters is just another way to describe those generated bytes. A simple way that I would use to prevent collisions between a number of generated session-IDs would be
svn commit: r1568348 - in /tomcat/tc7.0.x/trunk: BUILDING.txt build.xml
Author: kkolinko
Date: Fri Feb 14 16:50:00 2014
New Revision: 1568348
URL: http://svn.apache.org/r1568348
Log:
Correct a typo and add a note that the tests are run with Java 7.
Modified:
tomcat/tc7.0.x/trunk/BUILDING.txt
tomcat/tc7.0.x/trunk/build.xml
Modified: tomcat/tc7.0.x/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/BUILDING.txt?rev=1568348&r1=1568347&r2=1568348&view=diff
==
--- tomcat/tc7.0.x/trunk/BUILDING.txt (original)
+++ tomcat/tc7.0.x/trunk/BUILDING.txt Fri Feb 14 16:50:00 2014
@@ -333,6 +333,12 @@ If you are on Windows and want to test t
tcnative-1.dll file into ${tomcat.source}/bin/native/ and it will be copied
into the above directory when the build runs.
+* NOTE: If you configured the build to use a Java 7 JDK (if the
+"java.7.home" property has been defined) the tests will be run with Java 7.
+
+The version of Java that was actually used to run the tests is reported by
+"org.apache.catalina.util.TestServerInfo" test class.
+
(7.2) Running a single test
Modified: tomcat/tc7.0.x/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/build.xml?rev=1568348&r1=1568347&r2=1568348&view=diff
==
--- tomcat/tc7.0.x/trunk/build.xml (original)
+++ tomcat/tc7.0.x/trunk/build.xml Fri Feb 14 16:50:00 2014
@@ -1354,7 +1354,7 @@
-
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
Hi Konstantin, On 14.02.2014 17:19, Konstantin Preißer wrote: > Hi Rainer & Mark, > >> -Original Message- >> From: Rainer Jung [mailto:rainer.j...@kippdata.de] >> Sent: Friday, February 14, 2014 4:32 PM >> To: Tomcat Developers List >> Subject: Re: Special requirements on session id generator >> >> On 14.02.2014 14:27, Mark Thomas wrote: >>> On 14/02/2014 13:15, Rainer Jung wrote: I ran into a special requirement for the session id generator (uniqueness of session id for a longer time interval). While I think that the requirement needed isn't a useful general purpose extension, I stumbled over the fact, that the SessionIdGenerator class is not >> pluggable. Would it make sense to introduce a new interface for the session Id generation, probably including setJvmRoute(), setSessionIdLength() and generateSessionId(), letting the current implementation be the base implementation, probably switching getRandomBytes() to protected, and allowing to set the implementation class in ManagerBase - or the Manager interface (trunk)? I haven't worked it out in detail, but it looks easy to do and useful. WDYT? >>> >>> I'm struggling to understand the use case. Are you saying the current >>> implementation generates collisions? >> >> Yes. But only over time, not concurrently. So some session ID used some >> time were again generated on later days. The rate was low, about one out >> of 100.000 IDs were generated again during the next 30 days. I don't see >> a problem here per se, but the application required the IDs to be unique >> over an extended period of time. >> >>> That would be bad given that >>> SecureRandom is being used. >> >> Not sure, whether the above rate is totally unexpected. It could have >> used /dev/urandom, so might depend on total system behavior. > > I don't think that this is unexpected, even with a "secure" Random generator. > My understanding is that a secure random generator is guaranteed to produce > non-predictable output (so it is OK for security purposes like generating > Session IDs), but that shouldn't mean anything about the "randomness" of the > generated bytes, as e.g. the Javadoc says, most implementations are still > pseudo-random, but use a true random seed. > > However, even with a true random generator, one can expect to get collisions > over time, even with a 16 byte number (Session-ID). I think this is an > application of the birthday problem / birthday paradox: > If you chose 23 random people, then the likehood that two of them have the > same birthday is > 50 % (when not considering the birth year). > > The Wikipedia article also talks about the cast as a collision problem [2]: > "The birthday problem can be generalized as follows: given n random integers > drawn from a discrete uniform distribution with range [1,d], what is the > probability p(n;d) that at least two numbers are the same? (d=365 gives the > usual birthday problem.)" > > In the case of a 16 byte session id, "d" would be 256^16 and "n" would be the > number of generated Session-IDs which one wants to monitor for collisions > (e.g. if the application produces 10 million session-IDs over 30 days, one > could take 10 million for "n" to get the likehood of a collision of the > session ID in 30 days). Nice article. The table in the article says for 16 bytes and 50 session ids the probability of a duplicate is far below 10^-18. In my case they used 13 bytes, but even with only 8 bytes the table says the probability is between 10^-6 and 10^-9 so still pretty small. I expect the higher duplicate occurance on the target system being strongly influenced by the quality of /dev/urandom. But I must confess that I don't have enough data about the original situation. >>> Ignoring the previous question, why can't the requirement be met with a >>> custom implementation of SecureRandom? >> >> Just because I haven't thought of that :) Will check. One thing that >> comes to my mind is that the session id generator encodes the random >> bytes. Making IDs more unique for an extended period of time will end up >> replacing some of the random bytes by other data. That limits the >> randomness. I was hoping to compensate for that by using an extended >> setof characters to encode the ID instead of simply hex like it is now. >> So at the end, I can squeeze the additional info plus enough random >> bytes in it. AFAIR that changed encoding would mean I have to change the >> session id generator. > > From my understanding, if you don't watch for collisions, then the number of > possible values for a session-ID (consisting of 16 random bytes) would be > 256^16 at any time. However, if you would like to prevent collisions, then > you would need to memorize each previously generated session-ID, and remove > them from the pool of available session-IDs that can be generated. E.g., for > the first Session-ID, the amount of possible val
Re: Special requirements on session id generator
On 14/02/2014 16:57, Rainer Jung wrote: > Fortunately I don't have to prevent any long term collisions, just > reduce the rate without increasing session id length. Therefore I prefer > not to keep state for a long time including tomcat restarts, or do > remote (database) calls to check ids whenever a new one is generated. OK. I'm convinced. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.52
2014-02-13 12:17 GMT+04:00 Violeta Georgieva : > The proposed Apache Tomcat 7.0.52 release is now available for voting. > > It can be obtained from: > https://dist.apache.org/repos/dist/dev/tomcat/tomcat-7/v7.0.52/ > The Maven staging repo is: > https://repository.apache.org/content/repositories/orgapachetomcat-1007/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_52/ > > The proposed 7.0.52 release is: > [ ] Broken - do not release > [x] Stable - go ahead and release as 7.0.52 Stable > Smoke test and my apps are ok. Testsuite run on Win7 with 32-bit JDK 7u51 and 6u45, with BIO,NIO,APR connectors. Note that to run the tests with 6u45 you need to undefine "java.7.home". I added a comment on this in r1568348. Results: all tests OK (run once with all connectors x two JDKs), except the following ones. 1. org.apache.catalina.startup.TestHostConfigAutomaticDeployment fails consistently with all connectors when running with JDK 6u45. It runs successfully with 7u51. The failures: [[[ Testsuite: org.apache.catalina.startup.TestHostConfigAutomaticDeployment Tests run: 137, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 49,956 sec Testcase: testModifyXmlExtwarUpdateExtwar took 0,251 sec FAILED expected:<[stopstart]> but was:<[]> junit.framework.AssertionFailedError: expected:<[stopstart]> but was:<[]> at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1220) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyXmlExtwarUpdateExtwar(TestHostConfigAutomaticDeployment.java:1004) Testcase: testModifyWarUpdateWar took 0,196 sec FAILED expected not same junit.framework.AssertionFailedError: expected not same at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1222) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyWarUpdateWar(TestHostConfigAutomaticDeployment.java:966) Testcase: testModifyXmlWarUpdateWar took 0,195 sec FAILED expected:<[stopstart]> but was:<[]> junit.framework.AssertionFailedError: expected:<[stopstart]> but was:<[]> at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1220) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.doTestModify(TestHostConfigAutomaticDeployment.java:1079) at org.apache.catalina.startup.TestHostConfigAutomaticDeployment.testModifyXmlWarUpdateWar(TestHostConfigAutomaticDeployment.java:1046) ]]] 2. org.apache.tomcat.websocket.TestWsWebSocketContainer This was run with JDK 7u51. This showed a failure on the first run, and I rerun t 24 times. In 25 runs the following errors happened. These are rare and happened only once or twice. 1) With BIO connector it failed once, Tests run: 25, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 41,336 sec [[[ Testcase: testSmallTextBufferClientTextMessage took 0,199 sec Caused an ERROR java.util.concurrent.ExecutionException: java.io.IOException: Unable to write the complete message as the WebSocket connection has been closed java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: Unable to write the complete message as the WebSocket connection has been closed at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:219) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendString(WsRemoteEndpointImplBase.java:162) at org.apache.tomcat.websocket.WsRemoteEndpointBasic.sendText(WsRemoteEndpointBasic.java:37) at org.apache.tomcat.websocket.TestWsWebSocketContainer.doBufferTest(TestWsWebSocketContainer.java:258) at org.apache.tomcat.websocket.TestWsWebSocketContainer.testSmallTextBufferClientTextMessage(TestWsWebSocketContainer.java:157) Caused by: java.util.concurrent.ExecutionException: java.io.IOException: Unable to write the complete message as the WebSocket connection has been closed at org.apache.tomcat.websocket.FutureToSendHandler.get(FutureToSendHandler.java:102) at org.apache.tomcat.websocket.WsRemoteEndpointImplBase.sendPartialString(WsRemoteEndpointImplBase.java:214) Caused by: java.io.IOException: Unable to write the complete message as the WebSocket connection has been closed at org.apache.tomcat.websocket.WsSession.doClose(WsSession.java:423) at org.apache.tomcat.websocket.WsSession.close(WsSession.java:394) at org.apache.tomcat.websocket.WsFrameClient.close(WsFrameClient.java:82) at org.apache.tomcat.websocket.WsFrameClient.access$300(WsFrameClient.java:26) at org.apache.tomcat.websocket.WsFrameClien
Re: Special requirements on session id generator
2014-02-14 19:31 GMT+04:00 Rainer Jung : > On 14.02.2014 14:27, Mark Thomas wrote: >> On 14/02/2014 13:15, Rainer Jung wrote: >>> I ran into a special requirement for the session id generator >>> (uniqueness of session id for a longer time interval). While I think >>> that the requirement needed isn't a useful general purpose extension, I >>> stumbled over the fact, that the SessionIdGenerator class is not pluggable. >>> >>> Would it make sense to introduce a new interface for the session Id >>> generation, probably including setJvmRoute(), setSessionIdLength() and >>> generateSessionId(), letting the current implementation be the base >>> implementation, probably switching getRandomBytes() to protected, and >>> allowing to set the implementation class in ManagerBase - or the Manager >>> interface (trunk)? >>> >>> I haven't worked it out in detail, but it looks easy to do and useful. >>> >>> WDYT? >> >> I'm struggling to understand the use case. Are you saying the current >> implementation generates collisions? > > Yes. But only over time, not concurrently. So some session ID used some > time were again generated on later days. The rate was low, about one out > of 100.000 IDs were generated again during the next 30 days. I don't see > a problem here per se, but the application required the IDs to be unique > over an extended period of time. > Add a timestamp, current date, a counter or some UUID? 2014-02-14 17:15 GMT+04:00 Rainer Jung : > Would it make sense to introduce a new interface for the session Id > generation, probably including setJvmRoute(), setSessionIdLength() and > generateSessionId(), letting the current implementation be the base > implementation, probably switching getRandomBytes() to protected, and > allowing to set the implementation class in ManagerBase - or the Manager > interface (trunk)? > > I haven't worked it out in detail, but it looks easy to do and useful. > OK. Does it need to be "jvm route", or maybe just a prefix/suffix? Do you intend to set it programmatically, or via configuration? (A class name + maybe a set of prefixed properties like "socket." ones in AbstractEndpoint.setProperty(...)?). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
On 14.02.2014 18:48, Konstantin Kolinko wrote: > 2014-02-14 19:31 GMT+04:00 Rainer Jung : >> On 14.02.2014 14:27, Mark Thomas wrote: >>> On 14/02/2014 13:15, Rainer Jung wrote: I ran into a special requirement for the session id generator (uniqueness of session id for a longer time interval). While I think that the requirement needed isn't a useful general purpose extension, I stumbled over the fact, that the SessionIdGenerator class is not pluggable. Would it make sense to introduce a new interface for the session Id generation, probably including setJvmRoute(), setSessionIdLength() and generateSessionId(), letting the current implementation be the base implementation, probably switching getRandomBytes() to protected, and allowing to set the implementation class in ManagerBase - or the Manager interface (trunk)? I haven't worked it out in detail, but it looks easy to do and useful. WDYT? >>> >>> I'm struggling to understand the use case. Are you saying the current >>> implementation generates collisions? >> >> Yes. But only over time, not concurrently. So some session ID used some >> time were again generated on later days. The rate was low, about one out >> of 100.000 IDs were generated again during the next 30 days. I don't see >> a problem here per se, but the application required the IDs to be unique >> over an extended period of time. >> > > Add a timestamp, current date, a counter or some UUID? Timestamp is my plan. > 2014-02-14 17:15 GMT+04:00 Rainer Jung : >> Would it make sense to introduce a new interface for the session Id >> generation, probably including setJvmRoute(), setSessionIdLength() and >> generateSessionId(), letting the current implementation be the base >> implementation, probably switching getRandomBytes() to protected, and >> allowing to set the implementation class in ManagerBase - or the Manager >> interface (trunk)? >> >> I haven't worked it out in detail, but it looks easy to do and useful. >> > > OK. > > Does it need to be "jvm route", or maybe just a prefix/suffix? Could be prefix and suffix, but at the end I think there's no real benefit in more configurable flexibility in the base class itself. So I tend to keep it more minimalistic, and the abstract reason for the jvmRoute is supporting stateless stickyness in the load balancer. So "route" or "jvmRoute" isn't that bad as name and it would be up to the impl whether it puts it at the end or does something else with it. By the way there's an overlap with an idea of mine a few weeks ao, namely setting a jvmRoute per connector. If the session id generator gets an additional getSessionId(jvmRoute) method, that would be easier. And we coud end up supporting jvmRoute without configuration by passing them from the load balancer to Tomcat as part of the request. But that's another thing not directly related to pluggable session id generation. > Do you intend to set it programmatically, or via configuration? (A > class name + maybe a set of prefixed properties like "socket." ones in > AbstractEndpoint.setProperty(...)?). I thought about the typical className pattern. Haven't yet thought about possible configurations of the session id generator itself. I'll experiment a bit. It sounds as if it's worth trying this. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Special requirements on session id generator
Hi Rainer, > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, February 14, 2014 5:57 PM > Nice article. > > The table in the article says for 16 bytes and 50 session ids the > probability of a duplicate is far below 10^-18. Ah, thanks, I didn't notice the probability table when I first looked over the article. > In my case they used 13 > bytes, but even with only 8 bytes the table says the probability is > between 10^-6 and 10^-9 so still pretty small. I expect the higher > duplicate occurance on the target system being strongly influenced by > the quality of /dev/urandom. But I must confess that I don't have enough > data about the original situation. > > Can you explain what you mean with "using an extended setof characters > to encode the ID instead of simply hex"? AFAIK, a Random Number > generator produces random bytes (as the simplest random value is a bit, so it > can produce a series of 2^n random bits). Using hex characters is just another > way to describe those generated bytes. > > We have to encode the id as a cookie or url encoded value. The current > session id generator always does it using hex digits. In my case the > total length of the session id is limited to 26 encoded chars. So if I > have to remove some of them for the new additional data I want to add to > the ID, the remaining chars might be to few for good > randomness/security. If I instead of using hex digits use all chars > (lower plus upper case) and digits, I can encode 60 values in one byte > instead of only 16. Thus more randomness fits into the same encoded id > length. OK. > Fortunately I don't have to prevent any long term collisions, just > reduce the rate without increasing session id length. Therefore I prefer > not to keep state for a long time including tomcat restarts, or do > remote (database) calls to check ids whenever a new one is generated. While adding some information like the current time probably reduces the possibility for collisions, I'm concerned about the security implications. I understand that your requirement for avoiding collisions of session-IDs between 30 days is to ensure that a client that gets a specific session-id does not try to reuse it some time later and, by chance, hits a session that has been assigned to another user but uses the same session-ID. However, e.g., if some attacker knows that you add a time information to the session ID, he could just try to re-use the session-id and add some timestamp values, as the time value isn't a random value that cannot be predicted, so I don't see a security benefit here. (Maybe one could then run a hash function over this combination of random bytes + timestamp so that the attacker doesn't know the original session-ID, but this would probably cause some other problems.) Personally, the only secure way to avoid collisions over a period of time that I can think would be to store the generated IDs somewhere and check them when they are generated. However, one would need to increase the number of bytes that are used for the session-ID to ensure that the number of possible session values at any time is at least as high as when not checking for collisions. However, when viewing this from an wider perspective, I don't think that such collisions are a real problem - the client could just generate some random value by it self and try to use it for a request, to see if the session-ID is currently in use. More important would be that the number of bytes that is used for generating a Session-ID is so high that a client has a vanishing chance of hitting a valid session-ID, regardless of whether the value that he uses is one that the server generated previously, or one that is randomly generated by the client. (just my two cents, as Mark E. would say) Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
On 14.02.2014 19:14, Konstantin Preißer wrote: >> Fortunately I don't have to prevent any long term collisions, just >> reduce the rate without increasing session id length. Therefore I prefer >> not to keep state for a long time including tomcat restarts, or do >> remote (database) calls to check ids whenever a new one is generated. > > While adding some information like the current time probably reduces the > possibility for collisions, I'm concerned about the security implications. > I understand that your requirement for avoiding collisions of session-IDs > between 30 days is to ensure that a client that gets a specific session-id > does not try to reuse it some time later and, by chance, hits a session that > has been assigned to another user but uses the same session-ID. No, it is not about reuse and also not really about security. The session id is used in some back end as well and it does not allow the transaction to proceed if the same session id had been used during the last 30 days. Let's say it is a flaw in the back end system we have to work around. > However, e.g., if some attacker knows that you add a time information to the > session ID, he could just try to re-use the session-id and add some timestamp > values, as the time value isn't a random value that cannot be predicted, so I > don't see a security benefit here. (Maybe one could then run a hash function > over this combination of random bytes + timestamp so that the attacker > doesn't know the original session-ID, but this would probably cause some > other problems.) Right. That's why I don't want to reduce the number of random bits in the session id. The additional timestamping is just to increase the likelyness that the same id isn't used again, it is not about security/predictability. Since in my case we are a boit limited in the number of characters the id can have and adding a timestamp reduces the space available for the encoded random data, I want to switch from hex encoding to a more dense ascii encoding that allows the same amount of random bits in a shorter string. > Personally, the only secure way to avoid collisions over a period of time > that I can think would be to store the generated IDs somewhere and check them > when they are generated. However, one would need to increase the number of > bytes that are used for the session-ID to ensure that the number of possible > session values at any time is at least as high as when not checking for > collisions. Correct. > However, when viewing this from an wider perspective, I don't think that such > collisions are a real problem - the client could just generate some random > value by it self and try to use it for a request, to see if the session-ID is > currently in use. More important would be that the number of bytes that is > used for generating a Session-ID is so high that a client has a vanishing > chance of hitting a valid session-ID, regardless of whether the value that he > uses is one that the server generated previously, or one that is randomly > generated by the client. This is not about ids being currently in use :). It is about the same id being generated a second time by the id generator days after it was originally in use. And the goal is to reduce the rate with which this is happening without reducing the random part of the id to much. I'd do an impl of pluggable id generation in order to not have to switch the manager impl. I don't think that the replacement id generator used to scratch my itch is of general interest. Being able to plug another impl does sound reasonable though. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: Special requirements on session id generator
Hi Rainer, > -Original Message- > From: Rainer Jung [mailto:rainer.j...@kippdata.de] > Sent: Friday, February 14, 2014 11:07 PM > To: Tomcat Developers List > Subject: Re: Special requirements on session id generator > > On 14.02.2014 19:14, Konstantin Preißer wrote: > >> Fortunately I don't have to prevent any long term collisions, just > >> reduce the rate without increasing session id length. Therefore I prefer > >> not to keep state for a long time including tomcat restarts, or do > >> remote (database) calls to check ids whenever a new one is generated. > > > > While adding some information like the current time probably reduces the > possibility for collisions, I'm concerned about the security implications. > > I understand that your requirement for avoiding collisions of session-IDs > between 30 days is to ensure that a client that gets a specific session-id > does > not try to reuse it some time later and, by chance, hits a session that has > been assigned to another user but uses the same session-ID. > > No, it is not about reuse and also not really about security. The > session id is used in some back end as well and it does not allow the > transaction to proceed if the same session id had been used during the > last 30 days. Let's say it is a flaw in the back end system we have to > work around. OK, then I misunderstood your requirement, sorry. So appending timestamp should be OK for this, although I personally would prefer to use a counter value that increments by 1 for each generated session-ID. > > However, e.g., if some attacker knows that you add a time information to > the session ID, he could just try to re-use the session-id and add some > timestamp values, as the time value isn't a random value that cannot be > predicted, so I don't see a security benefit here. (Maybe one could then run > a hash function over this combination of random bytes + timestamp so that > the attacker doesn't know the original session-ID, but this would probably > cause some other problems.) > > Right. That's why I don't want to reduce the number of random bits in > the session id. The additional timestamping is just to increase the > likelyness that the same id isn't used again, it is not about > security/predictability. Since in my case we are a boit limited in the > number of characters the id can have and adding a timestamp reduces the > space available for the encoded random data, I want to switch from hex > encoding to a more dense ascii encoding that allows the same amount of > random bits in a shorter string. Ok. > > > Personally, the only secure way to avoid collisions over a period of time > that I can think would be to store the generated IDs somewhere and check > them when they are generated. However, one would need to increase the > number of bytes that are used for the session-ID to ensure that the number > of possible session values at any time is at least as high as when not > checking > for collisions. > > Correct. > > > However, when viewing this from an wider perspective, I don't think that > such collisions are a real problem - the client could just generate some > random value by it self and try to use it for a request, to see if the > session-ID > is currently in use. More important would be that the number of bytes that is > used for generating a Session-ID is so high that a client has a vanishing > chance > of hitting a valid session-ID, regardless of whether the value that he uses is > one that the server generated previously, or one that is randomly generated > by the client. > > This is not about ids being currently in use :). It is about the same id > being generated a second time by the id generator days after it was > originally in use. And the goal is to reduce the rate with which this is > happening without reducing the random part of the id to much. > > I'd do an impl of pluggable id generation in order to not have to switch > the manager impl. I don't think that the replacement id generator used > to scratch my itch is of general interest. Being able to plug another > impl does sound reasonable though. > > Regards, > > Rainer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Special requirements on session id generator
regardless of the use case, a debate whether to make something pluggable or extensible c(sh)ould be short. adding pluggability/extensibility that doesn't change default behavior can actually leave the exact use case out of the question. On Friday, February 14, 2014, Konstantin Preißer wrote: > Hi Rainer, > > > -Original Message- > > From: Rainer Jung [mailto:rainer.j...@kippdata.de ] > > Sent: Friday, February 14, 2014 11:07 PM > > To: Tomcat Developers List > > Subject: Re: Special requirements on session id generator > > > > On 14.02.2014 19:14, Konstantin Preißer wrote: > > >> Fortunately I don't have to prevent any long term collisions, just > > >> reduce the rate without increasing session id length. Therefore I > prefer > > >> not to keep state for a long time including tomcat restarts, or do > > >> remote (database) calls to check ids whenever a new one is generated. > > > > > > While adding some information like the current time probably reduces > the > > possibility for collisions, I'm concerned about the security > implications. > > > I understand that your requirement for avoiding collisions of > session-IDs > > between 30 days is to ensure that a client that gets a specific > session-id does > > not try to reuse it some time later and, by chance, hits a session that > has > > been assigned to another user but uses the same session-ID. > > > > No, it is not about reuse and also not really about security. The > > session id is used in some back end as well and it does not allow the > > transaction to proceed if the same session id had been used during the > > last 30 days. Let's say it is a flaw in the back end system we have to > > work around. > > OK, then I misunderstood your requirement, sorry. > > So appending timestamp should be OK for this, although I personally would > prefer to use a counter value that increments by 1 for each generated > session-ID. > > > > > However, e.g., if some attacker knows that you add a time information > to > > the session ID, he could just try to re-use the session-id and add some > > timestamp values, as the time value isn't a random value that cannot be > > predicted, so I don't see a security benefit here. (Maybe one could then > run > > a hash function over this combination of random bytes + timestamp so that > > the attacker doesn't know the original session-ID, but this would > probably > > cause some other problems.) > > > > Right. That's why I don't want to reduce the number of random bits in > > the session id. The additional timestamping is just to increase the > > likelyness that the same id isn't used again, it is not about > > security/predictability. Since in my case we are a boit limited in the > > number of characters the id can have and adding a timestamp reduces the > > space available for the encoded random data, I want to switch from hex > > encoding to a more dense ascii encoding that allows the same amount of > > random bits in a shorter string. > > Ok. > > > > > > Personally, the only secure way to avoid collisions over a period of > time > > that I can think would be to store the generated IDs somewhere and check > > them when they are generated. However, one would need to increase the > > number of bytes that are used for the session-ID to ensure that the > number > > of possible session values at any time is at least as high as when not > checking > > for collisions. > > > > Correct. > > > > > However, when viewing this from an wider perspective, I don't think > that > > such collisions are a real problem - the client could just generate some > > random value by it self and try to use it for a request, to see if the > session-ID > > is currently in use. More important would be that the number of bytes > that is > > used for generating a Session-ID is so high that a client has a > vanishing chance > > of hitting a valid session-ID, regardless of whether the value that he > uses is > > one that the server generated previously, or one that is randomly > generated > > by the client. > > > > This is not about ids being currently in use :). It is about the same id > > being generated a second time by the id generator days after it was > > originally in use. And the goal is to reduce the rate with which this is > > happening without reducing the random part of the id to much. > > > > I'd do an impl of pluggable id generation in order to not have to switch > > the manager impl. I don't think that the replacement id generator used > > to scratch my itch is of general interest. Being able to plug another > > impl does sound reasonable though. > > > > Regards, > > > > Rainer > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > Regards, > Konstantin Preißer > > > - > To unsubscribe, e-mail: dev-unsubscr...@tom
