Consider HTTP 'Age' header field when calculating HTTP clock skew#2067
Merged
Consider HTTP 'Age' header field when calculating HTTP clock skew#2067
Conversation
… into Wahnes-fixhttpclockskew
* address my comments * add json fields HTTP_headerTime + HTTP_headerAge if they exists * output HTTP_AGE if it was detected * do stripping of line feeds closer to where variables were set
drwetter
added a commit
that referenced
this pull request
Dec 10, 2021
See #2032 / #2067, kudos @Wahnes. This is a backport for 3.0 Currently, when "HTTP clock skew" is calculated, this is taken to be the difference between the timestamp of the moment the HTTPS request was sent and the date given in the HTTP Date header. This does not yield valid results in case a HTTP cache is used, either on the client side or on the server side. According to the HTTP specs, the Date field will contain the timestamp the response was created, which may not be the timestamp the response was delivered. Consider the following example that queries the Varnish project's web server. Note that Varnish is a popular HTTP caching server, so HTTP caching will of course be used when serving HTTP responses from this project's web server. testssl.sh https://varnish-cache.org/ This will typically output a HTTP clock skew of some thousand seconds. The patch takes into account the HTTP Age header that caching servers add to the HTTP response to signal the response's freshness. As client-side caches normally do not cache HTTPS requests (except maybe for "enterprise" HTTP proxy caches that do MITM HTTPS proxying), this is mostly targeted to HTTPS websites that employ server side HTTP caching. Addtional polishing: * address my comments in #2032 * add JSON field HTTP_headerAge if they exists * output HTTP_AGE if it was detected * do stripping of line feeds closer to where variables were set
drwetter
added a commit
that referenced
this pull request
Dec 10, 2021
See #2032 / #2067, kudos @Wahnes. This is a backport for 3.0 Currently, when "HTTP clock skew" is calculated, this is taken to be the difference between the timestamp of the moment the HTTPS request was sent and the date given in the HTTP Date header. This does not yield valid results in case a HTTP cache is used, either on the client side or on the server side. According to the HTTP specs, the Date field will contain the timestamp the response was created, which may not be the timestamp the response was delivered. Consider the following example that queries the Varnish project's web server. Note that Varnish is a popular HTTP caching server, so HTTP caching will of course be used when serving HTTP responses from this project's web server. testssl.sh https://varnish-cache.org/ This will typically output a HTTP clock skew of some thousand seconds. The patch takes into account the HTTP Age header that caching servers add to the HTTP response to signal the response's freshness. As client-side caches normally do not cache HTTPS requests (except maybe for "enterprise" HTTP proxy caches that do MITM HTTPS proxying), this is mostly targeted to HTTPS websites that employ server side HTTP caching. Addtional polishing: * address my comments in #2032 * add JSON field HTTP_headerAge if they exists * output HTTP_AGE if it was detected * do stripping of line feeds closer to where variables were set
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
taken from #2032:
Currently, when "HTTP clock skew" is calculated, this is taken to be the difference between the timestamp of the moment the HTTPS request was sent and the date given in the HTTP Date header. This does not yield valid results in case a HTTP cache is used, either on the client side or on the server side. According to the HTTP specs, the Date field will contain the timestamp the response was created, which may not be the timestamp the response was delivered.
Consider the following example that queries the Varnish project's web server. Note that Varnish is a popular HTTP caching server, so HTTP caching will of course be used when serving HTTP responses from this project's web server.
testssl.sh https://varnish-cache.org/
This will typically output a HTTP clock skew of some thousand seconds.
The patch takes into account the HTTP Age header that caching servers add to the HTTP response to signal the response's freshness. As client-side caches normally do not cache HTTPS requests (except maybe for "enterprise" HTTP proxy caches that do MITM HTTPS proxying), this is mostly targeted to HTTPS websites that employ server side HTTP caching.
Polishing was done: