X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f194.google.com (mail-qk0-f194.google.com [209.85.220.194]) by lists.alpinelinux.org (Postfix) with ESMTP id 598265C4E82 for ; Sun, 11 Feb 2018 01:04:05 +0000 (GMT) Received: by mail-qk0-f194.google.com with SMTP id c128so14580655qkb.4 for ; Sat, 10 Feb 2018 17:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=707fO47k3Bsk0fD/DXoQyjGtY9d+mtB1nNiC7qQLiHQ=; b=H+tYj/K+U/+M/aD0f4lddhUhGl9jQawnJ8+YCSmWIG/TAQx5PeAB5w56y9GzFtmRF5 ghCbAehofvc+hzYSDdBaI7jJxnsN2XpW4Jm35CWVCMXSNjjsr0+mTUd3owGOrenT5Y9d sCVHbMXc1Da7XuHK+ROP+TyWWPGBCiB4fv4Zl83SfBfIoKIGp6R40pATiks8HdA7QWq/ 7hajodsrcNgeoQwgmziIDAI26zNCv54r8E/O3OdWCf+45wf06i5V4nGwfWKTym+TdDtK 1+175Ejgg07V8EF3pkXaFxaCeoB60y2nngbQU81etyXm0XGFyoPf51DGkiD8VradwNaC GNrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=707fO47k3Bsk0fD/DXoQyjGtY9d+mtB1nNiC7qQLiHQ=; b=pAt95T4E5A74CABezai6YCvUYFI57hDAslr1+VP68gUw3DNKdV16anuOfTvcE/v3AZ XyJmdCyoZusWYoGOf3iJk8zOFmCC3jqQ5TmMb1CLq733xZ5qJ+6tVcXztO+7mtmhvEqP l247T4XTajY6trShilrJUYsthNBr34F22+/dtkKd3XUvlXDNTIOkPH4YStdOH/jSWQLN BA+JXgko657bq5DtKich/lUFVXKLk46z9Ts0xdwq2ioRk3h/WHh31fwUZc1CMfKRba/z 9J2GsqA7YxsSGy7PnMyet1owbax2SA01ZZclE3nadM4M4jqcP7YkaeUMSCP/9RkEPPIk cERQ== X-Gm-Message-State: APf1xPBWKh1i/FLBt+Od+ZTQezWZsyN03fX0z4Zrb6I895oKbq7eDEne 2EwUiTZ3iUVa1fHMBudl4HHSjpkzaTbNgyu9YLH1Q0YLQTU= X-Google-Smtp-Source: AH8x224iMk2TVrYpEqZ3IZz/270KhMbcIKDQnddJjhGMStS7xLVZeMuM8x/tgenBlOhPjESk6JxzHZ6xv41wt2szMvg= X-Received: by 10.55.191.65 with SMTP id p62mr11353037qkf.191.1518311044895; Sat, 10 Feb 2018 17:04:04 -0800 (PST) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Received: by 10.200.39.100 with HTTP; Sat, 10 Feb 2018 17:04:04 -0800 (PST) In-Reply-To: <20180210190646.38ab746f@mechanicum.chadwicks.me.uk> References: <20180209211237.19ab8fda@ncopa-macbook.copa.dup.pw> <20180210111715.144a571e@mechanicum.chadwicks.me.uk> <20180210141109.55695e19@mechanicum.chadwicks.me.uk> <20180210154513.66fa5b3a@mechanicum.chadwicks.me.uk> <7f5961a9-e09e-8e1c-12b4-23ae56fce034@adelielinux.org> <20180210190646.38ab746f@mechanicum.chadwicks.me.uk> From: William Pitcock Date: Sat, 10 Feb 2018 19:04:04 -0600 Message-ID: Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system openssl implementation To: Kevin Chadwick Cc: alpine-dev Content-Type: text/plain; charset="UTF-8" Hello, On Sat, Feb 10, 2018 at 1:06 PM, Kevin Chadwick 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 code. >> Then you mention that "well, invalid certs like that shouldn't be >> trusted". > > 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.[1] 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: https://github.com/libressl-portable/portable/issues/207#issuecomment-232543488 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.[2] > 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. William [1]: Actually, this is debatable. I am pretty sure Symantec could be tricked into doing it, for example. [2]: 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?" --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---