Thank you.

I have applied the change to the latest LibreSSL portable tarball and  
tested it.

With the new define (SMALL_TIME_T) enabled, a 32-bit time_t build  
using "openssl s_client -connect" can successfully connect to a server  
and verify its certificate chain when one or more notAfter dates after  
2038 are present.

However, using "nc -c" fails to connect to the same server.

The reason being that libtls also needs to clamp the notAfter date.

Unfortunately the new ASN1_time_tm_clamp_notafter symbol is not public  
and is located in libcrypto which makes it unavailable to libtls.

Seems to me there are two approaches:

1) duplicate the ASN1_time_tm_clamp_notafter function in libtls

2) make the symbol public to avoid duplicating code and potentially  
creating an out-of-sync/maintenance problem

The two patches in this series take approach (2).  The first makes  
ASN1_time_tm_clamp_notafter public and the second calls it from the  
appropriate place in libtls.

A 32-bit time_t build including these two additional patches (and with  
SMALL_TIME_T defined) successfully connects using "nc -c" to servers  
with one or more notAfter dates after 2038.

These patches are submitted under the standard OpenBSD license.

--Kyle

On Aug 13, 2017, at 14:26, Bob Beck wrote:

> https://github.com/openbsd/src/commit/b943944faeecf3a978bf3f57df1b35335ffecbec
>
> On Sun, Aug 13, 2017 at 1:56 PM, Bob Beck <b...@obtuse.com> wrote:
>
>>
>> So. To summarize my take on this
>>
>> If you're still running OSX 9, I think you like peril.. for lots of
>> reasons.. Running OpenSSL is probably the least of your perils.
>>
>> Sadly, Linux Raspberry PI sucks, because 32 bit Linux still hasn't  
>> dealt
>> with this.
>>
>> RFC 5280 section 4.1.2.5 guarantees you may see these.
>>
>> So in the interest of allowing 32 bit linux to use LibreSSL, I've  
>> just
>> committed a change to that portable
>> can make use of.
>>
>> We will allow portable to clamp he notAfter field in a certificate  
>> to the
>> largest represntable 32 bit time
>> if a notafter field from a certificate is larger than that value.   
>> We do
>> not clamp any other times
>> in any other places (a larger than 32 bit notBefore, for example,  
>> would
>> continue to be not accepted.
>>
>> This will alllow RFC 5280 4.1.2.5 compliant certs, and certs with  
>> notAfter
>> dates after 2038 to
>> be accepted as if the notAfter date was 03:14:08 UTC on Tuesday, 19
>> January 2038.

Reply via email to