Introduction

This is a community review of the (USA) Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) dated 2021-12-27 which can be browsed conveniently at this address:

https://www.stigviewer.com/stig/apache_tomcat_application_sever_9/2021-12-27/

Similar documents have been drafted in the past and various members of this community including project maintainers, users, and administrators have expressed frustration regarding many of the items both included and not included in these guides. This document is intended to be a community-sourced review of the latest (at the time of this writing) version of the STIG, including specific recommendations from this community's members for improvements and modifications to the STIG.

Recommendations and suggestions are welcome from any member of the community. We ask that if your recommended change is discussed and the group consensus is that no change should be recommended, please remove that suggestion from this document and do not bring it back up for discussion without some substantive change to the suggestion or the background/context of that suggestion. We ask this to avoid arguments raging in the history of this document. Feel free to have conversations on the various Tomcat-related mailing lists and post the results of those conversations into this document instead of using the document as a vehicle for communication.

This is a living document and changes can be made at any point, including changes that do not reflect any particular consensus of the Apache Tomcat Project Management Committee (PMC), the Apache Tomcat Security Team, etc. Any official recommendation made to DISA will be made for a specific version of this document which has supported consensus from one of more of the aforementioned groups.

Instructions

For anyone contributing to this review, please read the instructions below and participate in a constructive way. In order to coordinate our recommendations, it will be helpful if everyone follows a few simple rules:

  1. To recommend an improvement or modification to the STIG, please file your commentary under a sub-section of this document whose name is the same as the Finding ID, which is how STIGs are generally organized. Please keep these Finding IDs in alphanumeric order for easy identification.
  2. In a single short sentence, describe the overall change that is being recommended. For example "This finding is invalid," or "The instructions for identifying this finding are incomplete," etc.
  3. Provide appropriate background and context if appropriate. Remember that extraordinary claims require extraordinary evidence.
  4. Provide a specific recommendation or recommendations at the end of the section for the finding.


Recommendations

General Recommendations

No general recommendations at this point.

Modifications

V-222931

This finding contains multiple inaccuracies.

This finding claims that Apache Tomcat "currently operates only on JKS, PKCS11, or PKCS12 format keystores." Further, it claims that the finding only applies to JKS keystores. Finally, it claims that Tomcat will use a default password of "changeit" if the keystore was not created with a password.

Many of the above are factually incorrect. Apache Tomcat can use JKS and PKCS12 format keystores, but PKCS11 is another thing entirely which can be accessed in various ways. Apache Tomcat also supports the use of JCEKS keystores and PEM-encoded DER files which can include password-protected content similar to the other keystores.

In all of these cases, Apache Tomcat will use any password provided by the administrator in the appropriate position in the configuration file. Apache Tomcat will indeed use "changeit" as the default password if none is specified in the configuration to load the keys from a keystore. Apache Tomcat does not create keystores, and any administrator would have to explicitly specify "changeit" as the password used to protect a given keystore.

The recommendations should be made to protect the keystore with a password (and explicitly not to use "changeit" which is the commonly-used password in all Java-keystore-related HOWTOs and other guides) and has nothing to do really with Apache Tomcat's behavior at all. Furthermore, all keys should be recommended to be protected, not just those in JKS and PKCS12 key stores. JCEKS and PEM-encoded-DER files should be given the same prescription.

V-222950

This finding confuses HTTP TRACE and software application stack traces and recommends a course of action that does not provide any security benefit.

This finding claims that "stack tracing provides debugging information ... that could be used to compromise the system." The recommended mitigation is to set the allowTrace attribute of all <Connector> elements to "false". The claim is that by setting this attribute, application stack traces will be suppressed.

The claim is incorrect. While revealing stack traces may be helpful to a potential attacker, setting allowTrace="false" does not disable application stack traces. Instead, it disables the HTTP TRACE verb which provides little to no security benefit. Application stack traces, if they had been possible to generate by an attacker before the configuration change, are still entirely possible for an attacker to cause.

We recommend that V-222950 be completely removed from the STIG as it has no perceivable benefit.

Additions

No recommended additions at this point.