On Sat, Feb 10, 2018 at 9:45 AM, Kevin Chadwick <m8il1ists_at_gmail.com> wrote:
> On Sat, 10 Feb 2018 08:31:26 -0600
>> For the n-th time, there is nothing to discuss, LibreSSL removed SAFE
>> date calculation code and replaced it with code that is only SAFE
>> under a specific precondition: 64-bit time_t. Then they made it
>> blindly accept ANY certificate that overflows the time_t if it's
>> smaller than 64-bit, which is COMPLETELY UNSAFE AND ARGUABLY A
>> SECURITY PROBLEM BECAUSE IT MEANS A CERT THAT EXPIRES BEFORE 1970 IS
>> NOW POTENTIALLY VALID. Don't believe me? Generate a certificate that
>> computes as 0xfffffff time_t on 32-bit and you win. Really, you do!
>> If they care about portability, they should revert this change.
> Yet there is no mention of TAI64N or this as far as I can see on the
> libressl mailing list. I cross posted because reluctance to communicate
> between Linux and OpenBSD devs is well known. OpenBSD devs are blunt
> but they don't have time to be anything else.
> I guess that issue PRE 1970 issue would not apply to OpenSSH but you
> would probably find that your argument about a CERT expiring before
> 1970 has been considered and found to be a red herring or they would
> help you but no YOU HAVEN'T EVEN DISCUSSED YOUR PROBLEM.
I described very clearly the problem: a certificate whose date
evaluates as 32-bit 0xffffffff due to overflow will be considered
valid, regardless of whether or not it is in the past or future.
> Where would they get a 1970 cert from that was trusted?
Who are "they"? It is trivial to generate the appropriate ASN.1
structure. Will an actual CA sign it? Probably not, but your local
sysadmin's CA might, since he doesn't care to look at what he is
signing. Point is, it's replacing coding that worked safely in all
circumstances with code that does not, which is the point. Code which
fails under certain preconditions is a security problem when it is
Received on Sat Feb 10 2018 - 18:39:20 UTC