1
votes

Our team inherited a Web application from a vendor. The web app runs on Tomcat 7.0.41 (w/ OpenJDK 1.6 for now.) I looked at the Tomcat server xml and the Connector is configured as follows. Question is why is SSLEnabled set to false with scheme https and secure=true. TC docs say SSLEnabled should be "true" typically with scheme and secure are set as such. Also (important) the TC server sits behind a Load balancer. The app works fine it seems. Should i change SSLEnabled to true? any thoughts?

<Connector port="8443"
  protocol="HTTP/1.1"
  connectionTimeout="3000"
  redirectPort="443"
  SSLEnabled="false"
  scheme="https"
  secure="true" 
  useBodyEncodingForURI="true"
  enableLookups="false"
  maxThreads="400" 
  maxKeepAliveRequests="100"
  acceptorThreadCount="4"
  acceptCount="200"
  proxyPort="443"
  />
2

2 Answers

2
votes

If the tomcat is behind a loadbalancer that provides SSL translation to clear text, then the configuration is correct. You don't want or need SSLEnabled on tomcat unless you have a need for a secure direct connection (bypassing the load balancer) to the tomcat (eg administration)

In this case you need secure=true and scheme=https. If your tomcat sever app sends the client a redirect without a scheme like:

response.sendRedirect(response.encodeRedirectURL(contextPath + "/rareurl") );

the tomcat server will prepend http if you dont specify scheme=https.

Redirecting secure clients to an insecure URL, normally results in the next client request being made to http without the client's secure login session cookie. In that case you may end up creating an unnecessary new session, and possibly logging out your client on their next request.

If the client receiving the redirect isn't a real http client, it may not notice the switch from secure https to insecure http. In that case, they will likely broadcast their session cookie in clear text, making it easy for a bad guy to grab the login session.

If you dont have secure=true, then any cookies that tomcat adds to the response will not have the cookie "Secure" attribute "automatically" added in a case where a developer doesn't manually add it.

Also if the sever is coded to redirect http to https based on the secure attribute, then when it queries the request to see if the request is secure it will think it's insecure if you don't have secure=true. It could also cause an issue if a third-party jar queries the connection (eg Adobe Flash Gateway)

0
votes

Leave it. SSL will be terminated at the load balancer, which speaks plaintext HTTP to this connector.