You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Patrick Luby <Pa...@Sun.COM> on 2001/09/19 22:19:33 UTC
[PATCH] SSL how-to documentation
Hello,
I have attached 3 patches that patch the following 3 documentation files:
Attachment CVS File to Patch
---------- -----------------
server-noexamples.xml.config.patch
jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config
server.xml.patch jakarta-tomcat-4.0/catalina/src/conf/server.xml
jakarta-tomcat-4.0/catalina/src/conf
ssl-howto.xml.patch jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml
The only change to each of the following 3 files was to replace "keytool" with
"%JAVA_HOME%\bin\keytool" and "$JAVA_HOME/bin/keytool" in the documentation.
This change is necessary because the keytool in the same $JAVA_HOME as is used
by Tomcat must be used. Otherwise, keytool may fail.
Patrick
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Software Engineering Manager Phone: 408-863-3284
Sun Microsystems
901 San Antonio Road, UCUP01-103
Palo Alto, CA 94303-4900
_____________________________________________________________________
Re: [PATCH] SSL how-to documentation
Posted by Christopher Cain <cc...@mhsoftware.com>.
jean-frederic clere wrote:
>
> And the keystorePass is in server.xml but that is well know.
> We should avoid things like "security through obscurancy"
JF, I like you better and better every time you post :)
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/
Re: [PATCH] SSL how-to documentation
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Attila Szegedi wrote:
>
> A quick look inside the source code of sun.security.provider.JavaKeyStore reveals the following line in the getPreKeyedHash() method:
>
> md.update("Mighty Aphrodite".getBytes("UTF8"));
>
> Background: They're storing a MD5 hash of the password in the keystore to ensure the keystore was not tampered. To make the MD5 hash harder to crack (assuming the cracker is not smart enough to itself study JDK sources), it is pre-keyed with the above tribute to Woody Allen. As it appears nowhere in the specs, a cleanroom JDK could use another string to pre-key the hash (potentially it could even not pre-key it at all). In this case, a keystore created with Sun JDK would appear tampered when opened by a JDK that pre-keys the hash with "Everything You Always Wanted to Know About Sex".
And the keystorePass is in server.xml but that is well know.
We should avoid things like "security through obscurancy"
>
> Attila.
>
> > >
> > > Christopher Cain wrote:
> > > >
> > > > Hi Patrick. Could you explain this a little further? Actually creating
> > > a
> > > > keystore using keytool of course has nothing to do with Tomcat per se,
> > > so I
> > > > assume you mean that the keystore created might not work with Tomcat.
> > > Under
> > > > what conditions would a keystore generated by one JDK not work with
> > > another
> > > > JDK? In testing, I was able to generate a keystore on a Windoze box
> > > with JDK
> > > > 1.3.1, copy it over to a Linux box running 1.3.0, and successfully
> > > start up
> > > > Tomcat and access a page over SSL. If you have a properly-formatted
> > > JKS store,
> > > > why would it matter which JDK produced it?
> > > >
> >
> > > --
> > > _____________________________________________________________________
> > > Patrick Luby Email: patrick.luby@sun.com
> > > Software Engineering Manager Phone: 408-863-3284
> > > Sun Microsystems
> > > 901 San Antonio Road, UCUP01-103
> > > Palo Alto, CA 94303-4900
> > > _____________________________________________________________________
> > >
> >
> >
> >
> > - Christopher
> >
> > /**
> > * Pleurez, pleurez, mes yeux, et fondez vous en eau!
> > * La moitié de ma vie a mis l'autre au tombeau.
> > * ---Corneille
> > */
> >
Re: [PATCH] SSL how-to documentation
Posted by Attila Szegedi <sz...@freemail.hu>.
A quick look inside the source code of sun.security.provider.JavaKeyStore reveals the following line in the getPreKeyedHash() method:
md.update("Mighty Aphrodite".getBytes("UTF8"));
Background: They're storing a MD5 hash of the password in the keystore to ensure the keystore was not tampered. To make the MD5 hash harder to crack (assuming the cracker is not smart enough to itself study JDK sources), it is pre-keyed with the above tribute to Woody Allen. As it appears nowhere in the specs, a cleanroom JDK could use another string to pre-key the hash (potentially it could even not pre-key it at all). In this case, a keystore created with Sun JDK would appear tampered when opened by a JDK that pre-keys the hash with "Everything You Always Wanted to Know About Sex".
Attila.
> >
> > Christopher Cain wrote:
> > >
> > > Hi Patrick. Could you explain this a little further? Actually creating
> > a
> > > keystore using keytool of course has nothing to do with Tomcat per se,
> > so I
> > > assume you mean that the keystore created might not work with Tomcat.
> > Under
> > > what conditions would a keystore generated by one JDK not work with
> > another
> > > JDK? In testing, I was able to generate a keystore on a Windoze box
> > with JDK
> > > 1.3.1, copy it over to a Linux box running 1.3.0, and successfully
> > start up
> > > Tomcat and access a page over SSL. If you have a properly-formatted
> > JKS store,
> > > why would it matter which JDK produced it?
> > >
>
> > --
> > _____________________________________________________________________
> > Patrick Luby Email: patrick.luby@sun.com
> > Software Engineering Manager Phone: 408-863-3284
> > Sun Microsystems
> > 901 San Antonio Road, UCUP01-103
> > Palo Alto, CA 94303-4900
> > _____________________________________________________________________
> >
>
>
>
> - Christopher
>
> /**
> * Pleurez, pleurez, mes yeux, et fondez vous en eau!
> * La moitié de ma vie a mis l'autre au tombeau.
> * ---Corneille
> */
>
Re: [PATCH] SSL how-to documentation
Posted by Christopher Cain <cc...@mhsoftware.com>.
Ahh ... I see. It needs to be the same JDK where JSSE was installed in order to
specify RSA as the algorithm.
Applied the patches. Thanks!
Quoting Patrick Luby <pa...@sun.com>:
> Christopher,
>
> You are correct that this problem has nothing to do with Tomcat.
> Instead, it is a merely a problem that comes from having more than 1
> JDK
> installation on your local host.
>
> Specifically, the problem I described shows up on Unix platforms where
> your $PATH environment variable points to a different JDK installation
> than the installation that $JAVA_HOME is set to for building and running
> Tomcat.
>
> For example, on Solaris 8, /usr/bin contains all of the JDK 1.2.1
> tools
> including keytool. Since /usr/bin is, for most poeple, near the
> beginning of $PATH, invoking keytool will result in the JDK 1.2.1
> version being used. This does not cause a problem if I set $JAVA_HOME
> to
> /usr when building and running Tomcat. It only becomes a problem when
> you set $JAVA_HOME to a different JDK installation. In my case, my
> $JAVA_HOME is set to a separate JDK 1.3.1 installation.
>
> The problem in the above case is that, if I followed the Tomcat SSL
> setup instructions properly, I will have installed JSSE in my
> $JAVA_HOME
> JDK installation but I will end up invoking keytool from my JDK 1.2.1
> installation. Since I did not install JSSE in my JDK 1.2.1
> installation,
> keytool will be unable to generate a keystore with the RSA algorithm.
>
> Since this problem is merely an issue of invoking the correct keytool
> version, I changed the instructions from:
>
> execute "keytool"
>
> to:
>
> execute "$JAVA_HOME/bin/keytool"
>
> to ensure that the keytool is executed from the same JDK that you
> installed JSSE into.
>
> Hope that clears it up,
>
> Patrick
>
> Christopher Cain wrote:
> >
> > Hi Patrick. Could you explain this a little further? Actually creating
> a
> > keystore using keytool of course has nothing to do with Tomcat per se,
> so I
> > assume you mean that the keystore created might not work with Tomcat.
> Under
> > what conditions would a keystore generated by one JDK not work with
> another
> > JDK? In testing, I was able to generate a keystore on a Windoze box
> with JDK
> > 1.3.1, copy it over to a Linux box running 1.3.0, and successfully
> start up
> > Tomcat and access a page over SSL. If you have a properly-formatted
> JKS store,
> > why would it matter which JDK produced it?
> >
>
> --
> _____________________________________________________________________
> Patrick Luby Email: patrick.luby@sun.com
> Software Engineering Manager Phone: 408-863-3284
> Sun Microsystems
> 901 San Antonio Road, UCUP01-103
> Palo Alto, CA 94303-4900
> _____________________________________________________________________
>
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/
Re: [PATCH] SSL how-to documentation
Posted by Patrick Luby <pa...@sun.com>.
Christopher,
You are correct that this problem has nothing to do with Tomcat.
Instead, it is a merely a problem that comes from having more than 1 JDK
installation on your local host.
Specifically, the problem I described shows up on Unix platforms where
your $PATH environment variable points to a different JDK installation
than the installation that $JAVA_HOME is set to for building and running Tomcat.
For example, on Solaris 8, /usr/bin contains all of the JDK 1.2.1 tools
including keytool. Since /usr/bin is, for most poeple, near the
beginning of $PATH, invoking keytool will result in the JDK 1.2.1
version being used. This does not cause a problem if I set $JAVA_HOME to
/usr when building and running Tomcat. It only becomes a problem when
you set $JAVA_HOME to a different JDK installation. In my case, my
$JAVA_HOME is set to a separate JDK 1.3.1 installation.
The problem in the above case is that, if I followed the Tomcat SSL
setup instructions properly, I will have installed JSSE in my $JAVA_HOME
JDK installation but I will end up invoking keytool from my JDK 1.2.1
installation. Since I did not install JSSE in my JDK 1.2.1 installation,
keytool will be unable to generate a keystore with the RSA algorithm.
Since this problem is merely an issue of invoking the correct keytool
version, I changed the instructions from:
execute "keytool"
to:
execute "$JAVA_HOME/bin/keytool"
to ensure that the keytool is executed from the same JDK that you
installed JSSE into.
Hope that clears it up,
Patrick
Christopher Cain wrote:
>
> Hi Patrick. Could you explain this a little further? Actually creating a
> keystore using keytool of course has nothing to do with Tomcat per se, so I
> assume you mean that the keystore created might not work with Tomcat. Under
> what conditions would a keystore generated by one JDK not work with another
> JDK? In testing, I was able to generate a keystore on a Windoze box with JDK
> 1.3.1, copy it over to a Linux box running 1.3.0, and successfully start up
> Tomcat and access a page over SSL. If you have a properly-formatted JKS store,
> why would it matter which JDK produced it?
>
--
_____________________________________________________________________
Patrick Luby Email: patrick.luby@sun.com
Software Engineering Manager Phone: 408-863-3284
Sun Microsystems
901 San Antonio Road, UCUP01-103
Palo Alto, CA 94303-4900
_____________________________________________________________________
Re: [PATCH] SSL how-to documentation
Posted by Christopher Cain <cc...@mhsoftware.com>.
Hi Patrick. Could you explain this a little further? Actually creating a
keystore using keytool of course has nothing to do with Tomcat per se, so I
assume you mean that the keystore created might not work with Tomcat. Under
what conditions would a keystore generated by one JDK not work with another
JDK? In testing, I was able to generate a keystore on a Windoze box with JDK
1.3.1, copy it over to a Linux box running 1.3.0, and successfully start up
Tomcat and access a page over SSL. If you have a properly-formatted JKS store,
why would it matter which JDK produced it?
Quoting Patrick Luby <Pa...@Sun.COM>:
> Hello,
>
> I have attached 3 patches that patch the following 3 documentation
> files:
>
> Attachment CVS File to Patch
> ---------- -----------------
> server-noexamples.xml.config.patch
> jakarta-tomcat-4.0/catalina/src/conf/server-noexamples.xml.config
> server.xml.patch jakarta-tomcat-4.0/catalina/src/conf/server.xml
> jakarta-tomcat-4.0/catalina/src/conf
>
> ssl-howto.xml.patch jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml
>
> The only change to each of the following 3 files was to replace
> "keytool" with
> "%JAVA_HOME%\bin\keytool" and "$JAVA_HOME/bin/keytool" in the
> documentation.
> This change is necessary because the keytool in the same $JAVA_HOME as
> is used
> by Tomcat must be used. Otherwise, keytool may fail.
>
> Patrick
>
> _____________________________________________________________________
> Patrick Luby Email: patrick.luby@sun.com
> Software Engineering Manager Phone: 408-863-3284
> Sun Microsystems
> 901 San Antonio Road, UCUP01-103
> Palo Alto, CA 94303-4900
> _____________________________________________________________________
>
- Christopher
/**
* Pleurez, pleurez, mes yeux, et fondez vous en eau!
* La moitié de ma vie a mis l'autre au tombeau.
* ---Corneille
*/