curl / Mailing Lists / curl-library / Single Mail


Re: Adding a CURLOPT_SSL_OPTIONS value to disable date checking

From: Daniel Stenberg <>
Date: Wed, 21 Mar 2018 10:36:45 +0100 (CET)

On Wed, 21 Mar 2018, Tabor Kelly wrote:

> I'm not encouraging anyone to use this feature if they have an accurate
> system time. But if you have no idea what time it is, what does the date
> check mean? That is, even if it succeeds, it means nothing, right?

Right, but what does a certificate check mean at all without a valid time?
Certs are only valid during a certain window in time which is done on purpose
so that cert problems "automatically" fixes themselves at least when they
expire. Ignoring time, means ignoring those fixes.

I understand that *you* aren't necessarily encouraging anyone to use this
option, but if we introduce it in libcurl and we document it and there will
start to appear examples and stackoverflow answers using it, then the
"encouragement" is more implicit from us since we provide the option and why
would be provide an option you shouldn't use? We have this problem with the
options to disable cert verfications which both subsequently are widely
misunderstood and abused.

I want the subject properly thought through, analyzed, beaten with a stick and
then pushed into a corner and checked closely before we let it get merged and
supported to the end of time.

> let's say that you are going to ship an IoT product without a realtime
> clock.

There are plenty of ways to deal with this problem that don't add a new (TLS
backend specific) option to libcurl.

1. I would start out with arguing with the product management that using this
architecture seriously impacts this device's ability to do secure networking.
If nothing else, for future work.

2. If the device offers flash or other non-volitile storage, you can save the
"last known time" and use at boot until you get a chance to update the time
from a reliable time source. If you then fail a transfer with a certificate
problem before getting the time synced, you can event bisect time between the
"first possible time" until the "last possible time" (depending on how long
periods of shut-off you expect your device to have) and try again. When it
works, you can save that as "possible current time" until you get a more
reliable time. If it doesn't work at all, the certificate isn't to be trusted.

3. You can opt to disable certificate checking and only do certificate

4. Since you're using OpenSSL as TLS backend, you can write your own
certificate check in your application and make whatever trade-offs you want.

Received on 2018-03-21