You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2017/03/19 20:55:41 UTC
Host header validation
Hi,
r1787662 adds Host header validation along with a fair number of unit tests.
It includes a performance test which indicates - on my machine at least
- that the performance impact is in the noise. I'd like to see better
performance for full IPv6 addresses but the current code looks to be
acceptable.
The validation is not yet integrated into the request processing. My
primary reason for not integrating it is that it will trigger a 400
response if the header is invalid and I don't want to incorrectly reject
valid headers. Therefore I have a request. Please try and break these
new parsers. Please commit any values you test with.
Once we are happy with the quality of these parsers, I'll integrate them
into the request processing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Host header validation
Posted by Mark Thomas <ma...@apache.org>.
On 22/03/17 14:13, Konstantin Kolinko wrote:
> 2017-03-21 18:01 GMT+03:00 Mark Thomas <ma...@apache.org>:
>> On 21 March 2017 14:14:19 GMT+00:00, Christopher Schultz <ch...@christopherschultz.net> wrote:
>>>
>>> How about an option to disable the validity-checking, in case someone
>>> in the field finds a case they need to support, or if they don't care
>>> about hostname-checking and want their "performance back"?
>>
>> I'm not too concerned about performance. The checks are at most 1% of the current processing time for a trivial servlet accessed over localhost. For real use cases it will be less.
>>
>> Some form of transition could work (eg log only) but I'm reluctant to an an option that effectively bypasses spec compliance.
>
> This needs a definition of "spec".
>
> I am afraid that DNS spec may evolve over time.
>
>
> 1) https://tools.ietf.org/html/rfc7230
> RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
>
> Host = uri-host [ ":" port ] ; Section 2.7.1
>
> uri-host = <host, see [RFC3986], Section 3.2.2>
>
>
> 2) https://tools.ietf.org/html/rfc3986
> RFC 3986 URI Generic Syntax January 2005
>
> Updated by: 6874, 7320
>
> host = IP-literal / IPv4address / reg-name
>
> IP-literal = "[" ( IPv6address / IPvFuture ) "]"
>
> but RFC 6874 updates the syntax and changes "IP-literal" into
>
> IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"
>
> ZoneID = 1*( unreserved / pct-encoded )
>
> IPv6addrz = IPv6address "%25" ZoneID
>
>
> reg-name = *( unreserved / pct-encoded / sub-delims )
>
> pct-encoded = "%" HEXDIG HEXDIG
>
>
> DomainParseState in r1787662 is more strict and I see no support for
> pct-encoded characters there.
>
> IPv6addrz is not supported
> (I mentioned in my previous e-mail, and above is the formal syntax for it)
>
> IPvFuture address - I think it is too early to implement it,
> but it can be a reason to have a flag to turn off this check,
>
>
> An example of IPvFuture address with HTTPd, and its response (400):
> https://bz.apache.org/bugzilla/show_bug.cgi?id=55362
>
> So apparently Apache HTTP Server already has some validation of Host header.
I'll take a look at the spec references you quoted. The ideal would be
if we could apply a general rule now and make it more specific over
time. Not sure how possible that would be.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Host header validation
Posted by Konstantin Kolinko <kn...@gmail.com>.
2017-03-21 18:01 GMT+03:00 Mark Thomas <ma...@apache.org>:
> On 21 March 2017 14:14:19 GMT+00:00, Christopher Schultz <ch...@christopherschultz.net> wrote:
>>
>>How about an option to disable the validity-checking, in case someone
>>in the field finds a case they need to support, or if they don't care
>>about hostname-checking and want their "performance back"?
>
> I'm not too concerned about performance. The checks are at most 1% of the current processing time for a trivial servlet accessed over localhost. For real use cases it will be less.
>
> Some form of transition could work (eg log only) but I'm reluctant to an an option that effectively bypasses spec compliance.
This needs a definition of "spec".
I am afraid that DNS spec may evolve over time.
1) https://tools.ietf.org/html/rfc7230
RFC 7230 HTTP/1.1 Message Syntax and Routing June 2014
Host = uri-host [ ":" port ] ; Section 2.7.1
uri-host = <host, see [RFC3986], Section 3.2.2>
2) https://tools.ietf.org/html/rfc3986
RFC 3986 URI Generic Syntax January 2005
Updated by: 6874, 7320
host = IP-literal / IPv4address / reg-name
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
but RFC 6874 updates the syntax and changes "IP-literal" into
IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture ) "]"
ZoneID = 1*( unreserved / pct-encoded )
IPv6addrz = IPv6address "%25" ZoneID
reg-name = *( unreserved / pct-encoded / sub-delims )
pct-encoded = "%" HEXDIG HEXDIG
DomainParseState in r1787662 is more strict and I see no support for
pct-encoded characters there.
IPv6addrz is not supported
(I mentioned in my previous e-mail, and above is the formal syntax for it)
IPvFuture address - I think it is too early to implement it,
but it can be a reason to have a flag to turn off this check,
An example of IPvFuture address with HTTPd, and its response (400):
https://bz.apache.org/bugzilla/show_bug.cgi?id=55362
So apparently Apache HTTP Server already has some validation of Host header.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Host header validation
Posted by Mark Thomas <ma...@apache.org>.
On 21 March 2017 14:14:19 GMT+00:00, Christopher Schultz <ch...@christopherschultz.net> wrote:
>Mark,
>
>On 3/19/17 4:55 PM, Mark Thomas wrote:
>> Hi,
>>
>> r1787662 adds Host header validation along with a fair number of
>> unit tests.
>>
>> It includes a performance test which indicates - on my machine at
>> least - that the performance impact is in the noise. I'd like to
>> see better performance for full IPv6 addresses but the current code
>> looks to be acceptable.
>>
>> The validation is not yet integrated into the request processing.
>> My primary reason for not integrating it is that it will trigger a
>> 400 response if the header is invalid and I don't want to
>> incorrectly reject valid headers. Therefore I have a request.
>> Please try and break these new parsers. Please commit any values
>> you test with.
>>
>> Once we are happy with the quality of these parsers, I'll integrate
>> them into the request processing.
>
>How about an option to disable the validity-checking, in case someone
>in the field finds a case they need to support, or if they don't care
>about hostname-checking and want their "performance back"?
I'm not too concerned about performance. The checks are at most 1% of the current processing time for a trivial servlet accessed over localhost. For real use cases it will be less.
Some form of transition could work (eg log only) but I'm reluctant to an an option that effectively bypasses spec compliance.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Host header validation
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 3/19/17 4:55 PM, Mark Thomas wrote:
> Hi,
>
> r1787662 adds Host header validation along with a fair number of
> unit tests.
>
> It includes a performance test which indicates - on my machine at
> least - that the performance impact is in the noise. I'd like to
> see better performance for full IPv6 addresses but the current code
> looks to be acceptable.
>
> The validation is not yet integrated into the request processing.
> My primary reason for not integrating it is that it will trigger a
> 400 response if the header is invalid and I don't want to
> incorrectly reject valid headers. Therefore I have a request.
> Please try and break these new parsers. Please commit any values
> you test with.
>
> Once we are happy with the quality of these parsers, I'll integrate
> them into the request processing.
How about an option to disable the validity-checking, in case someone
in the field finds a case they need to support, or if they don't care
about hostname-checking and want their "performance back"?
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJY0TU7AAoJEBzwKT+lPKRYK+cP/jVu+waZHfEL7s8LrTwC8+v/
+5le9Lo8vM9T5zSAYl/xbNuOx0uVkFAz1lVMxL0Jy2pG/HhntdBRmcAyP8Ms2/Ci
bdqRYtKb+ZrTZNQkFKjmKrZYOrB/IgwzTrGLQ0JewbKOd7doHtN3gsa2ekzQ5h7l
D9D6w6tflVzlByPgJLQ9VbqD5MxQsmxkaFBkSzfnpKYbzsXqrHF18R9p/234PLqD
hxUuHhPm39AtrfeNpXUcVLxUrcGbDlzeP9pUDxgZHM69Yi82cHdoCi65VCMysges
BCSnkbP2CBdkT2/aSfZa73RplOFT2XMk6OQOMSJv6SEXRdqS58A3m/Grnjj9LCX5
EtwYuy8q+Edd8JMPV6mOO980EaiQ4nha1HgrZa8Vsmbtn2xzp017lrYJPO19Cvoc
cGEiCvQVTlmtUhdPV1SdogBvIhHGpMORj7+eSRPlBmCopjzSIYfeWCoecWzyRKfj
6xZ/hSVH/IufbHolRBNWIcZWQI1Oo1VkuYLQ9xM26CcodYjFcQfm9JaD4ixCXhDW
81f4erOxGVkGRrrXVQwxJ1sdXyAbB5FHbdBj5CTSv8U3LnZK26Qk/e0PcvlXTaHm
CAhelcMpplkD78Dc5Chb38t3PZk41WfwRFF1km5+XhXxfGVokFhjDMNP5SuF+1EM
LkYsnfIDFyApXSyq27/S
=LRYA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org