1

I have a series of packets within a PCAP files, among them I'm getting packet with HTTP protocol.

starting from IP address I get the timestamp in GMT format and the time zone, for example:

Source IP: 95.172.94.24
http.date: "Sun, 14 Jun 2015 11:33:56 GMT",
time zone: Europe/London

Packet timestamp: 1434280757335 - sun 14 jun 2015 13:19:17 (local timestamp GMT +2)

so in this case http date matches with packet timestamp, but the question is: is there any case where I could find a gap between the two timestamps? (for example if the packet had been generated within TOR network)

Thanks in advance

CDominik
  • 157
  • 2
  • 6
  • As far as I know not, the timestamp represents the date in the packet. The packet just contains the timestamp and timezone which is the date in human readable form like you mentioned. – Daniel Ruf Nov 29 '15 at 15:35
  • Originating date and when the recipient received it can still differ. – Daniel Ruf Nov 29 '15 at 15:47
  • I'm not sure there is a security question here. Is there a security context? Otherwise, this is a network engineering question. – schroeder Nov 29 '15 at 16:12

1 Answers1

1

There is just one field for the date in the header.If it is missing the recipient adds one.Taken from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18
14.18 Date

The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in section 3.3.1; it MUST be sent in RFC 1123 [8]-date format.

Date = "Date" ":" HTTP-date

An example is

Date: Tue, 15 Nov 1994 08:12:31 GMT

Origin servers MUST include a Date header field in all responses, except in these cases:

  1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option. 2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date. 3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed.

A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. An HTTP implementation without a clock MUST NOT cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, SHOULD use a mechanism, such as NTP [28], to synchronize its clock with a reliable external standard.

Clients SHOULD only send a Date header field in messages that include an entity-body, as in the case of the PUT and POST requests, and even then it is optional. A client without a clock MUST NOT send a Date header field in a request.

The HTTP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.

Daniel Ruf
  • 1,682
  • 14
  • 18