On Sat, Feb 10, 2018 at 1:06 PM, Kevin Chadwick <m8il1ists_at_gmail.com> wrote:
> On Sat, 10 Feb 2018 12:16:18 -0600
>> I like how it was already pointed out, by you and possibly others, on
>> openbsd-misc *and* this list, that most people do not use the CA / SAN
>> verification routines correctly.
> Wasn't me!
It was in the form of your advocacy to use libtls instead. Nobody
disagrees with using libtls instead if it is appropriate for your
>> Then you mention that "well, invalid certs like that shouldn't be
> You missed the point entirely, he didn't ask the question.
> From the commit message I'm inclined to think it clamps the year for
> good or bad but I was just pointing out his argument was potentially
> obviously flawed.
> OpenSSL only started in 1998! and any trusted CA that issues a pre 1970
> cert is broken anyway. That was his assertion of it working that
> way and being insecure.
This is not about trusted CAs, it's about insufficient code safety.
Obviously no "trusted CA" (whatever that means) will sign a
certificate that expired prior to 1970. Unless they are using
LibreSSL on a 32-bit system, in which case, they will believe it
expires after 2038.
> The point wasn't that I knew but that he hadn't given LibreSSL the
> chance despite it's merits over OpenSSL. I assure you that LibreSSL
> devs know a lot more than us about LibreSSL. Not raising issue with
> them is arrogance.
I was the one who pushed for LibreSSL adoption in the first place,
despite the lack of ENGINE support, despite it being proven in the
field. So clearly I have given LibreSSL the chance and considered
it's merits over OpenSSL.
You assume that an issue has not been raised either, the 32-bit
problem caused by their date code removal was raised here:
Quoting Bob Beck in that thread:
> Does your platform only have a 32 bit time_t? In this case this is working
> as intended.
> Your platform is unable to deal with time_t after Y2038 - and so dealing
> with certificates after such a date is dangerous. LibreSSL defensively
> fails if time_t can not represent these times. So the safe thing is to
> actually fail.
> You need to actually fix this at the operating system level.
Which is a fine and correct position to take, but it means LibreSSL
cannot be used on 32-bit Linux systems because certificate chain
validation will fail.
Then they changed it later to use the clamp mechanism which makes it
accept any time_t overflow as valid, which is a completely unsafe hack
done for RFC 5280 conformance on 32-bit systems. As it stands, I am
inclined to revert that hack in our libressl packages because it is
worse than simply failing to validate: it means somebody can make a
fake CA root certificate and gets some bytes to play with since your
system won't correctly validate it when you install it by mistake.
What you do instead is what OpenSSL did: you convert the system time
into a format that is Y2038 safe and you do your validity checks in
that format. TAI64N being a safe format for this, for example.
> But yes, I use public key crypto not CA certificates for anything I
> implement, except a website where I hope letsencrypt start doing
> things properly and less traditionally.
> I actually don't care one bit aside from dev time wasted for a
> worse outcome. I simply saw a wrong
>> The problem with the OpenBSD community is not bluntness. Arrogance
>> and trolling are problems for me. And you know what? Honestly, I
>> don't find too many OpenBSD devs have that problem. Their users,
>> however...their users....
> Atleast you did enter some discussion and William might have learnt
> that passing imsgs can be more secure and protect the keys!
I have been isolating TLS code for over a decade. I did not learn
anything from you, other than that you're an arrogant prat.
Do not post here again.
: Actually, this is debatable. I am pretty sure Symantec could be
tricked into doing it, for example.
: Technically, OpenSSL converts ASN1 GMTTIME and GENERALIZEDTIME
into a structure that is functionally equivalent to TAI64N. By
conformant, I mean that it can safely handle >Y2038 dates; the
clamping method is not conformant. Eventually, somebody is going to
die because an intelligence agency managed to trick LibreSSL into
accepting a certificate it shouldn't have because of this code. When
looking at cryptographic code, I suggest always asking the question
"who will die when I screw this up?"
Received on Sat Feb 10 2018 - 19:04:04 UTC