socket.setSendBufferSize(int) support?
Hi, As part of a webapp, I'm abusing tomcat as as high-performance static file download service over high bandwidth long latency network links. Here, tuning TCP windows sizes can make a drastic difference. Is there any support in tomcat-4.1 to configure the socket SO_SNDBUF, to be set via http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#setSendBufferSize(int) For more background on why these things matter, see, for example: http://www-didc.lbl.gov/tcp-wan-perf.pdf Wolfgang. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATH] for problems with HTTPS and client certs
Starting TC 4.0 with
CATALINA_OPTS="$CATALINA_OPTS
-Djavax.net.ssl.trustStore=$CATALINA_BASE/conf/spitfire-cacerts.jks
-Djavax.net.ssl.trustStorePassword=changeit"
and using non-{Verisign,Thawte} cacerts, i am not seeing your problem with
the standard SSLServerSocketFactory. Why does your patch fix the problem?
Wolfgang.
>Hey,
>
>here are the changes to get the HTTPS connector doing 'clientAuth' with
>CA certs other than the ones from Verisign and Thawte. I tested it with
>Netscape 4.77 as client and with certificates created by my own CA.
>
>please consider integration into Tomcat 4 source code.
>
>thanks
>
>Stefan
>
>
>--- SSLServerSocketFactory.java.origWed Oct 17 13:25:14 2001
>+++ SSLServerSocketFactory.java Wed Oct 17 13:28:05 2001
>@@ -139,7 +139,7 @@
> /**
> * The trust manager factory used with JSSE 1.0.1.
> */
>-//TrustManagerFactory trustManagerFactory = null;
>+TrustManagerFactory trustManagerFactory = null;
>
>
> // -
>Properties
>@@ -474,13 +474,12 @@
> keyManagerFactory.init(keyStore, keystorePass.toCharArray());
>
> // Create the trust manager factory used for checking
>certificates
>-/*
>- trustManagerFactory =
>TrustManagerFactory.getInstance(algorithm);
>- trustManagerFactory.init(keyStore);
>-*/
>+trustManagerFactory =
>TrustManagerFactory.getInstance(algorithm);
>+trustManagerFactory.init(keyStore);
>
> // Initialize the context with the key managers
>-context.init(keyManagerFactory.getKeyManagers(), null,
>+context.init(keyManagerFactory.getKeyManagers(),
>+ trustManagerFactory.getTrustManagers(),
> new java.security.SecureRandom());
>
> // Create the proxy and return
>
>
Re: [PATCH] SSLServerSocketFactory.java
Noticed that in the catalina.bat patch it should of course read REM instead of # (gotcha). Here the fixed patch. The other 2 patches are fine. Wolfgang. --- catalina.bat.orig Mon Aug 27 21:10:25 2001 +++ catalina.batTue Sep 11 10:45:13 2001 @@ -65,6 +65,11 @@ rem - Set Up The Runtime Classpath set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar + +rem add CATALINA_SYSTEM_CLASSPATH custom jars to classpath. For example define +rem set CATALINA_SYSTEM_CLASSPATH=\path\to\jsse\lib\jsse.jar;\path\to\jsse\lib\jnet.jar;\path\to\jsse\lib\jcert.jar +set CP=%CP%;%CATALINA_SYSTEM_CLASSPATH% + set CLASSPATH=%CP% echo Using CATALINA_BASE: %CATALINA_BASE% echo Using CATALINA_HOME: %CATALINA_HOME% catalina.bat.diff
[PATCH] SSLServerSocketFactory.java
It itched me a lot that to enable SSL in TC4 a standard JDK has to be modified
(copy JSSE libs into jdk/jre/lib/ext and add
security.provider.3=com.sun.net.ssl.internal.ssl.Provider).
This was not necessary in TC 3.2.x because of different class loading
semantics.
In our environment jdks cannot well be modified due to separate JDKs/archs,
TCs, JSSEs, etc on shared read-only filesystems.
So here are three TC4 patches (against the latest CVS) that allow JSSE to
be picked up from anywhere on the filesystem.
Patches are along the lines Craig suggested yesterday.
1) Modify catalina.sh and catalina.bat as indicated below to be able to add
external jars to the system classpath (new env var CATALINA_SYSTEM_CLASSPATH).
2) Modify
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java
to dynamically add the com.sun.net.ssl.internal.ssl.Provider provider
In case you don't like 1) because it allows external things to be added,
then 2) is still of value because people don't need to write their own
SSLServerSocketFactory
Hope someone wants to try this out and commit before 4.0 FCS.
Wolfgang.
--- SSLServerSocketFactory.java.origFri Sep 7 20:39:08 2001
+++ SSLServerSocketFactory.java Mon Sep 10 15:31:16 2001
@@ -386,6 +386,14 @@
Security.addProvider(new sun.security.provider.Sun());
Security.addProvider(new
com.sun.net.ssl.internal.ssl.Provider());
*/
+// even if jsse provider is already installed it can't hurt to
make sure
+// and we do need to install it here if it isn't hard-wired in
jdk/jre/lib/security/java.security
+try {
+
java.security.Security.addProvider(((java.security.Provider)
Class.forName("com.sun.net.ssl.internal.ssl.Provider").newInstance()));
+}
+catch (IllegalAccessException exc) {}
+catch (ClassNotFoundException exc) {}
+catch (InstantiationException exc) {}
// Create an SSL context used to create an SSL socket factory
SSLContext context = SSLContext.getInstance(protocol);
--- jakarta-tomcat-4.0/catalina/src/bin/catalina.sh.origSat Sep 8
12:13:28 2001
+++ jakarta-tomcat-4.0/catalina/src/bin/catalina.sh Mon Sep 10 16:28:25 2001
@@ -70,6 +70,12 @@
CP=$CP:"$JAVA_HOME/lib/tools.jar"
fi
+# add CATALINA_SYSTEM_CLASSPATH custom jars to classpath. For example define
+# export
CATALINA_SYSTEM_CLASSPATH=/path/to/jsse/lib/jsse.jar:/path/to/jsse/lib/jnet.jar:/path/to/jsse/lib/jcert.jar
+if [ ! -z "$CATALINA_SYSTEM_CLASSPATH" ] ; then
+ CP=$CP:$CATALINA_SYSTEM_CLASSPATH
+fi
+
# convert the existing path to windows
if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then
CP=`cygpath --path --windows "$CP"`
--- jakarta-tomcat-4.0/catalina/src/bin/catalina.bat.orig Mon Aug 27
21:10:25 2001
+++ jakarta-tomcat-4.0/catalina/src/bin/catalina.batMon Sep 10 16:16:43 2001
@@ -65,6 +65,11 @@
rem - Set Up The Runtime Classpath
set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar
+
+# add CATALINA_SYSTEM_CLASSPATH custom jars to classpath. For example define
+# set
CATALINA_SYSTEM_CLASSPATH=\path\to\jsse\lib\jsse.jar;\path\to\jsse\lib\jnet.jar;\path\to\jsse\lib\jcert.jar
+set CP=%CP%;%CATALINA_SYSTEM_CLASSPATH%
+
set CLASSPATH=%CP%
echo Using CATALINA_BASE: %CATALINA_BASE%
echo Using CATALINA_HOME: %CATALINA_HOME%
SSLServerSocketFactory.diff
catalina.sh.diff
catalina.bat.diff
[TC4] Which classloader loads SSLServerSocketFactory?
It itches that a standard JDK needs to modified to get SSL working. I'm trying to use bootclasspaths, etc. to pick up jsse from a dir outside the JDK. So far no luck (worked fine with TC 3.2.x). Can anyone tell me which classloader loads org.apache.catalina.net.SSLServerSocketFactory plus, which TC dir would be best suited to stuff jsse jars into? Thanks, Wolfgang.
Re: New SSL HOWTOs
At 17:28 23/8/01 -0600, Christopher Cain wrote: >Wolfgang Hoschek wrote: > > > > Sorry, I am posting to tomcat-dev although not subscribed... > > > > Two suggestions: > > > > - Perhaps it is a good idea to also describe in the SSL HOWTO ways to > > configure SSL without stuffing libs into jre/lib/ext. Some sites run > > multiple versions/vendors of jdks, TC, JSSE, et al from (secure) read-only > > shared file systems. In such an environment products and versions are > > delibarately kept separate from each other in order to avoid having to > > maintain countless permutations. Startup scripts "link" everything together > > via env vars. This is also convenient to test different permutations. The > > jre/lib/ext mechanism is not an option, due too the read-only nature. > >Hmmm ... that's interesting. It's true that the JSSE libs don't >necessarily have to be an installed extension, and it's easy enough to >include a quick phrase about the classpath instead. I'm reluctant to >encourage users to put them into the internal Tomcat classloader >directories, since that is a rather sketchy configuration (someone will >eventually add JSSE to the classpath as well, which will cause Tomcat to >fail on startup unless the internal versions are removed). > >So in your environment, it sounds like you would be simply specifying >the JSSE jars in classpath passed to TC, yes? Exactly.
Re: New SSL HOWTOs
Sorry, I am posting to tomcat-dev although not subscribed...
Two suggestions:
- Perhaps it is a good idea to also describe in the SSL HOWTO ways to
configure SSL without stuffing libs into jre/lib/ext. Some sites run
multiple versions/vendors of jdks, TC, JSSE, et al from (secure) read-only
shared file systems. In such an environment products and versions are
delibarately kept separate from each other in order to avoid having to
maintain countless permutations. Startup scripts "link" everything together
via env vars. This is also convenient to test different permutations. The
jre/lib/ext mechanism is not an option, due too the read-only nature.
- The other point: I recall a discussion some time ago about the sluggish
performance of session id generation and the idea of using /dev/random to
speed this up. The cryptix JCE CryptixRandom provider can be useful here
(see below a conversation with a sun security engineer).
Wolfgang.
>Brad, thanks for the *fast* reponse.
>
>The point is that developing an application has to make sense in the first
>place.
>10 secs SecureRandom start up time for client side command line apps means
>that such an app will never be used.
>If an application is never used it is irrelevant how secure it is, except
>for academic discourse.
>0.5 secs is the pain limit for client side command line apps.
>Plus, /dev/random is more than secure enough for many apps.
>
>Just for the record, with the help of the cryptix JCE CryptixRandom
>provider (www.cryptix.org) I finally figured out how to do this
>effectively. Perhaps others may find the solution helpful as well:
>
>java.security.Security.insertProviderAt(
>(java.security.Provider)
> Class.forName("cryptix.jce.provider.CryptixRandom").newInstance(), 1);
>java.security.Security.addProvider(
>((java.security.Provider)
> Class.forName("com.sun.net.ssl.internal.ssl.Provider").newInstance()));
>com.sun.net.ssl.SSLContext ctx =
>com.sun.net.ssl.SSLContext.getInstance("SSL"); // JSSE 1.0.2
>//javax.net.ssl.SSLContext ctx =
>javax.net.ssl.SSLContext.getInstance("SSL"); // JDK 1.4
>ctx.init(null, null, java.security.SecureRandom.getInstance("DevRandom"));
>factory = ctx.getSocketFactory();
>sock = factory.getSocket(...)
>
>Now on a 2x600 Mhz PentiumIII, Linux
>
>ctx.init() takes 0.2 secs using the /dev/random algo (compared to 10 secs
>using the default SecureRandom algo).
>
>Cheers,
>Wolfgang.
>
> >com.sun.net.ssl.SSLContext.getInstance("SSL").init(null, null, new
> >java.security.SecureRandom(new byte [] {25,13,32,5}));
> >
> >to no effect. Perhaps I need to store the SSLContext somewhere. If so,
> where?
>
>Again, doing anything like you describe with Random or preseeding with
>a fixed byte array is a *VERY BAD* idea in a production system. It's
>ok for testing, but you'll seriously limit your security
>effectiveness. I can't stress this enough.
>
>As to your immediate question, please have a look at the JSSE API's,
>especially those that deal with getting SocketFactories from the
>initialized SSLContexts. You use the new socketfactories created by
>the SSLContext to create sockets, and you can set these socket
>factories in HttpsURLConnection.
>
>Brad
>
> >Sorry I'm a newbie and am also seeing the same unacceptable startup delay
> >(13 secs) - in a command line tool.
> >I realize I don't understand much about JCA. The only thing I want to
> >achieve is that a third party library (or even better, the entire JDK) uses
> >an algorithm that meets performance needs. /dev/random or even
> >java.util.Random would in many cases be preferable to secure but
> >unfortunately unusable algos.
> >
> >Now I can't see any difference by trying the suggestions below.
> >
> >For example, the line
> >
> >sr = new SecureRandom(new byte [] {25,13,32,5});
> >
> >does not make anything faster. Perhaps needs to passed to some method?
> >
> >com.sun.net.ssl.SSLContext.init(null, null, sr)
> >
> >can only be called if one already has a context in hand. Where and how do I
> >get a context?
> >
> >I tried
> >
> >com.sun.net.ssl.SSLContext.getInstance("SSL").init(null, null, new
> >java.security.SecureRandom(new byte [] {25,13,32,5}));
> >
> >to no effect. Perhaps I need to store the SSLContext somewhere. If so,
> where?
> >Obviously I am missing out on something here.
> >Help, anyone?
> >
> >(I see that in JDK1.4 the java.security file can be configured to use
> >/dev/random. But we are still 1 year away from using 1.4 in a production
> >environment)
> >
> >Wolfgang.
> >
> >> >Will be there a faster version of JSSE ?
> >> >I am using JSSE 1.0.1 and it is very slow (especially the handshake,
> >> >which lasts round 30 seconds).
> >> >
> >> >Thanks in advance for your answer.
> >>
> >>
> >>
> >>Hello Pierre and Jonathan (and other viewers of the java-security
> >>archives):
> >>
> >>Pierre and Jonathan have both noticed that JSSE/SSL connections can
> >>take a long time to negotiate initially.
> >>
> >>As Jonathan guessed, the reason i
