tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: SSL, AJP13, and security related questions
Date Fri, 01 Dec 2000 23:22:53 GMT
Jonathan Eric Miller wrote:

> THIS LIST. I would like to be on the list, but, I can't handle getting all
> the email right now. I really wish there were a Usenet newsgroup for Tomcat
> to be honest.

As has been discussed before, a newsgroup would disenfranchise users behind
firewalls who are not allowed access to news servers.

Also, any competent mail reader will support message filters and folders.  I
have my filters set up to copy all incoming messages addressed to TOMCAT-USER to
a folder reserved for that purpose, and the same for all the other lists I
subscribe to.

> I'm using Tomcat 3.2 release with Apache 1.3.12, mod_ssl, and mod_jk. What I
> would like to be able to do is determine what cipher suite was negotiated
> between the Web server and client. It states that there is a variable named
> SSL_CIPHER in the tomcat-ssl-howto.html document. I'm trying to figure out
> how to access this variable. I'm wondering if someone could answer the
> following questions for me.
> 1. If the SSL_CIPHER variable is being passed to Tomcat, I should be able to
> call HttpServletRequest.getHeaderNames() and see that header, correct? If I
> don't see it, does that mean that something is configured incorrectly?

I'm not an expert on AJP13 by any means, but here's what it looks like from the

The SSL information is being passed, but not as headers.  Check the request
attributes under the following keys:

> 2. Do I have to use the AJP13 connector instead of the AJP12 connector in
> order to access the SSL_CIPHER variable?

That is my understanding.

> I'm using AJP13, but, it's still not working.  I added the AJP13 connector
> to the server.xml file. I'm also using a custom mod_jk.conf file which I
> used mod_jk.conf-auto as a template. In this file, I changed the root
> settings to use ajp13 instead of ajp12. I also added the commands that are
> listed in tomcat-ssl-howto.html with regard to setting JkExtractSSL On (just
> to be on the safe side even though in theory it's on by default). I disabled
> the AJP12 connector in server.xml to make sure that the ajp13 connector was
> being used. I then ran https://myhost/servlet/SnoopServlet. I would assume
> that I should see the SSL_CIPHER header in the Headers section of the
> output, but, it isn't there.
> 3. Why is the default connector still AJP12 if AJP13 is the recommended one
> to use?

Not being intimately familiar with either, I did not want to risk destabilizing
things that were working for everyone else who is not using SSL.

> 4. If I'm using Tomcat in stand alone mode with SSL enabled can I access the
> SSL_CIPHER variable? Or, is this variable specific to using Tomcat with
> Apache Web Server?

In Tomcat 3.2, I do not believe you can.  In Tomcat 4.0, the cipher suite is
available as a request attribute (as well as the key size), as described

> 5. When running Tomcat in stand alone mode with SSL enabled, is it possible
> to specify in a configuration file that only connections that support strong
> encryption will be accepted? i.e. 128 bit.

By default, all supported cipher suites are enabled.  There is no current
mechanism for configuring this, although you could modify your copy of the class to accomplish this.

> 6. Apache Web Server allows one to restrict access to a URL to a specific IP
> address or range of IP addresses. Is it possible to do this using Tomcat in
> stand alone mode?

In Tomcat 3.2, you would need to write a custom RequestInterceptor to do this.
Tomcat 4.0 includes a standard Valve that can implement this sort of thing for

> 7. Does Tomcat, or is it planned to in the future, support having user
> passwords crypt encrypted? i.e. like Apache Web Server.

There is some support for encrypted passwords in the JDBCRealm implementations
on the "3.3" development code base, and in Tomcat 4.0.

Of course, this doesn't do you much good if you're using BASIC or FORM-BASED
authentication on a non-SSL connection, because your username and password are
sent in clear text over the network ...

> Thanks in advance for answering any of the above questions that you might
> know the answers to,
> Jon

Craig McClanahan

View raw message