Assuming your code-signing tool is secure (e.g., does not suffer from buffer overflow exploits and the like), is there any reason to be concerned if a time-stamping service is not running over SSL? Obviously, a MITM attack could do slightly annoying things (e.g., provide a bad certificate), but SSL doesn't protect you from such attacks, since a MITM can already cause an SSL timestamp to fail (by blocking the request). Technically, a MITM could also provide a valid certificate under the MITM's control (allowing them to revoke it later).

Are there any realistic concerns when using a timestamping service over HTTP, rather than HTTPS?

  • I guess that as long as you can establish trust (beforehand) for the public key of the time stamp service, and as long as you perform verification, then using a time stamp server over an insecure line is OK. Commented Jul 3, 2014 at 21:57

1 Answer 1


Short answer: in general, no.

Long answer: the timestamp is a digitally signed data and it contains nothing that should be private on its own. It can't be reused and, as every other aspect of the system is properly conceived, cannot be counterfeit.

The critical element is that the timestamp comes from an authority that is trusted by both the initial signer and the final validator.

Now, there are edge cases where this timestamp element could lead to security issues if it is intercepted (for instance if the hash value contains in the timestamp can reveal important information about the data itself) but they almost all originate in other part of the system being broken (for instance, the use of a weak hash or the use of a hash in an insecure manner - like an anonymizer scheme).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .