By default, allow SCT timestamps to be up to 5 minutes in the future

As requested in
https://github.com/openssl/openssl/pull/1554#issuecomment-246371575.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1554)

diff --git a/crypto/ct/ct_policy.c b/crypto/ct/ct_policy.c
index 1bc22749d3c2b222ff85196eae62f8cd750a7d61..adee331366ea5694628f624e9b36506acfb83867 100644 (file)
--- a/crypto/ct/ct_policy.c
+++ b/crypto/ct/ct_policy.c
@@ -17,6 +17,12 @@
 
 #include "ct_locl.h"
 
 
 #include "ct_locl.h"
 

+// Number of seconds in the future that an SCT timestamp can be, by default,
+// without being considered invalid. This is added to time() when setting a
+// default value for CT_POLICY_EVAL_CTX.epoch_time_in_ms.
+// It can be overridden by calling CT_POLICY_EVAL_CTX_set_time().
+static const time_t SCT_CLOCK_DRIFT_TOLERANCE = 300;
+

 CT_POLICY_EVAL_CTX *CT_POLICY_EVAL_CTX_new(void)
 {
     CT_POLICY_EVAL_CTX *ctx = OPENSSL_zalloc(sizeof(CT_POLICY_EVAL_CTX));
 CT_POLICY_EVAL_CTX *CT_POLICY_EVAL_CTX_new(void)
 {
     CT_POLICY_EVAL_CTX *ctx = OPENSSL_zalloc(sizeof(CT_POLICY_EVAL_CTX));


@@ -27,7 +33,7 @@ CT_POLICY_EVAL_CTX *CT_POLICY_EVAL_CTX_new(void)
     }
 
     // time(NULL) shouldn't ever fail, so don't bother checking for -1.
     }
 
     // time(NULL) shouldn't ever fail, so don't bother checking for -1.

-    ctx->epoch_time_in_ms = time(NULL) * 1000;
+    ctx->epoch_time_in_ms = (time(NULL) + SCT_CLOCK_DRIFT_TOLERANCE) * 1000;

     return ctx;
 }
 
     return ctx;
 }
 

diff --git a/doc/man3/CT_POLICY_EVAL_CTX_new.pod b/doc/man3/CT_POLICY_EVAL_CTX_new.pod
index e0fb7c1ebcbf16f38724ed57cecd30488ab2fae0..fedc58d08a92b8f7c66819cb39c9382ea37c1db1 100644 (file)
--- a/doc/man3/CT_POLICY_EVAL_CTX_new.pod
+++ b/doc/man3/CT_POLICY_EVAL_CTX_new.pod
@@ -68,8 +68,8 @@ CT_POLICY_EVAL_CTX.
 
 The SCT timestamp will be compared to this time to check whether the SCT was
 issued in the future. RFC6962 states that "TLS clients MUST reject SCTs whose
 
 The SCT timestamp will be compared to this time to check whether the SCT was
 issued in the future. RFC6962 states that "TLS clients MUST reject SCTs whose

-timestamp is in the future". By default, this will be set to the
-current time (obtained by calling time()) if possible.
+timestamp is in the future". By default, this will be set to 5 minutes in the
+future (e.g. (time() + 300) * 1000), to allow for clock drift.

 
 The time should be in milliseconds since the Unix epoch.
 
 
 The time should be in milliseconds since the Unix epoch.