OpenSSL ClientHello Concerns
The TLS Protocol [RFC 2246] mandates that the Unix epoch time be used in the ClientHello handshake message. Unix epoch time (as presently implemented) will eventually reach a limit: the INT_MAX of 2147483647 defined in limits.h will occur at 2038-01-19 03:14:07 UTC. Without fixes to the time(3) subroutine, what happens? Will this affect TLS? Since this happens in 2038, will anyone care prior to, say, 2035?
OpenSSL 0.9.8d employs the following code in s3_clnt.c:
p=s->s3->client_random; Time=(unsigned long)time(NULL); /* Time */ l2n(Time,p); if (RAND_pseudo_bytes(p,SSL3_RANDOM_SIZE-4) <= 0) goto err;
C code that uses the same unsigned long cast is shown below. This code can be double checked by running perl -le 'print scalar time'.
#include <stdio.h> #include <time.h> main() { unsigned long Time; Time=(unsigned long)time(NULL); fprintf(stdout, "%u\n", Time); }
The unsigned long type offers greater range than the signed int used by time(3). Casting to this unsigned value prevents negative numbers from leaking into the ClientHello message, which indicates TLS should not be affected by the Unix epoch time problem.
Technorati Tags: coding, cryptography, Unix
However! I cannot test the exact effects by setting the clock forward, as OpenBSD prevents the clock from being set so far forward in sys/kern/kern_time.c:
/* * Don't allow the time to be set forward so far it will wrap * and become negative, thus allowing an attacker to bypass * the next check below. The cutoff is 1 year before rollover * occurs, so even if the attacker uses adjtime(2) to move * the time past the cutoff, it will take a very long time * to get to the wrap point. * * XXX: we check against INT_MAX since on 64-bit * platforms, sizeof(int) != sizeof(long) and * time_t is 32 bits even when atv.tv_sec is 64 bits. */ if (tv->tv_sec > INT_MAX - 365*24*60*60) { printf("denied attempt to set clock forward to %ld\n", tv->tv_sec); return (EPERM); }
While a good security feature, this prevents easy testing. Time to hack the kernel, or try a different flavor of Unix… (to be continued. 多分)