--- Comment #14 from Mark Thomas <> ---
Generally, the tightening up of validation like this stems from a security
vulnerability report where mal-formed input results in unintended consequences.
Usually information disclosure of some form. In this case, the changes can be
traced back to CVE-2016-6816. That vulnerability report identified some gaps in
our validation of the request line. When we receive such a report, we don't
just fix the one issue identified in the report, we look more widely. The
reason we look more widely is that if one gap in validation can lead to a
security vulnerability then other gaps may do the same. Even if we can't see
how a validation gap could be exploited, we still fix it as we assume that an
attacker may find something we haven't. When we reviewed the request line
validation after CVE-2016-6816, we identified various gaps in the request line
validation and have been working on tightening them up over time. Host name
validation was one of these issues.

We recognise that clients do not always conform to the specifications. While
our default position is to implement the specs and that bugs in clients should
be fixed, we do recognise that this can take time.

The new host validation has been in 9.0.x since 9.0.2 (2017-11-30) where it
logged failures but took no other action. After fixing some edge cases reported
by users it was switched to rejecting invalid hosts in 9.0.5 (2018-02-11) and
we received no reports of problems as a result of enabling the validation.

The changes to request line validation have been causing other problems (again
due to specification non-compliant clients). See bug 62273 for the latest
information on this aspect. It was largely as a result of these issues that we
introduced the host validation in logging only mode first and only enabled it
once we thought all the issues had been ironed out. 

As a result of bug 62273, we wanted to back-port that enhancement to all
versions. The host validation was wrapped up in those changes and it was
difficult to untangle it. Since it had been running in 9.0.x without issue and
that it should not be possible to register an invalid host/domain name it was
felt that back-porting all validation changes - including the host validation -
would be safe.

It appears that some uses of Docker are FQDN being passed to to Tomcat that
include a '-' in the final segment.

Tomcat does not permit a '-' character to appear in the final segment of a
FQDN. This appears to be based on RFC 920 and/or

Ignoring the original report which requested better logging of these failures
(fixing that is in hand and should happen later today) the key question at this
point is whether or not '-' is valid in the final segment of a FQDN.

RFC 952 does allow '-' in the final segment. RFC 1123 does not change this.
Therefore it is is both possible and valid that '-' could appear in the final
segment of a intranet FQDN.

RFC 920 and are
also rather dated. The introduction of IDNA means that '-' can appear in the
final segment of an internet FQDN.

In light of the above, I am going to change Tomcat's host name validation to
allow '-' in the final segment. This change will be made at (roughly) the same
time as the additional logging.

Ideally, this issue would have been caught in one of the releases since 9.0.2.
Unfortunately it wasn't. Given the circumstances, back-porting the bug 62273
enhancement looked to be sufficiently low risk. This issue highlights that
Tomcat can always use more real-world testing and I would encourage folks to
download the release candidates as the votes are announced and test them in
their environments. The more folks that do this, the more issues like this we
will catch and the sooner we will catch them.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to