https://bz.apache.org/bugzilla/show_bug.cgi?id=62371
--- Comment #14 from Mark Thomas <ma...@apache.org> --- 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 https://tools.ietf.org/html/draft-liman-tld-names-06#section-1 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 https://tools.ietf.org/html/draft-liman-tld-names-06#section-1 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: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
