What's the redirect port for in Tomcat?

Question

It's hard to make sense of tomcat documentation and looking at server.xml you will find a salad of ports that may be hard to understand because it's not really explained properly, or extensively, in the documentation.

For example, this line in the config file server.xml

<Connector port="8345" protocol="AJP/1.3" redirectPort="9875" />

And here you can find yet another redirect port:

<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" /> 

I understand what the connector port does. In the first case you use that to create a worker in apache and send it there, in the second you open a port to access tomcat directly. However when it comes to the redirectport things become fuzzy.

Here is the explanation given by tomcat documentation for ajp port:

If this Connector is supporting non-SSL requests, and a request is received for which a matching requires SSL transport, Catalina will automatically redirect the request to the port number specified here.

I always pick a random redirect port over 1024 and it works,

But when would this come into practice? How does it know when a request requires SSL transport?

I have a satellite server running a tomcat module. This module comes into effect by redirecting traffic to the ajp connector with apache from the main server and vice versa.

In the main server https is enforced in apache. Does this mean all requests are sent to the satellite server encrypted or in plain text? I know that if I access the satellite server via port 8080 it's not encrypted, but I am wondering if this applies to the traffic being redirected to the main server as well and where does this redirect port come into effect.

Solution

As it is defined in the documentation, the redirect port will come into picture when SSL request will come to the server and since http connector port cannot handle SSL requests it will redirect to the port defined. But their must be another section defined in server.xml file in which the defined redirect port will act as a connector port to handle SSL requests. For example, If you want http requests to be handled by port 80 and https request by port 443 the server.xml will look like this:

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="443" />

<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" SSLEnabled="true" scheme="https" secure="true" sslProtocol="TLS" keystoreFile="/path/to/kestorefile" keystorePass="my_keystore_password"/>

Keystorefile is the ssl certificate of your website.

If you don't configure the other section with redirect port as a connector port your requests will not be redirected to that port. For example if the website do not support ssl requests and you try to send https request to that website an error like Secure Connection Failed will be shown on the browser.

Comments

[Ulukai]

Fair enough. What about the configuration for ajp as opposed to http? Also is it a good idea to use ports under 1024 like you mention? That would mean running tomcat as root and that's not good.

[Gaurav Pundir]

I don't have much idea about ajp, but redirection must work same as http. About using ports under 1024, its totally up to you. 80 and 443 are default ports for https & https protocol, no need to mention them explicitly in the url. If you want to use non standard ports its up to you. Also running tomcat with root, it depends on the application deployed. If you don't trust your application with security perspective you must not run tomcat with root. Other way around is you can use apache or nginx as proxy to run on port 80 & 443 and redirect your request to the tomcat.

[Seldom 'Where's Monica' Needy]

I'll note that iptables also works nicely for redirecting traffic to Tomcat, among other approaches.

[luiscolorado]

This explanation is incomplete. If you are redirecting from non-SSL to a SSL port, It is not enough to include the target connector in server.xml. It is also necessary to configure the <security-constraint> section in web.xml. See stackoverflow.com/questions/9526425/…