X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f196.google.com (mail-qk0-f196.google.com [209.85.220.196]) by lists.alpinelinux.org (Postfix) with ESMTP id 2290A5C41F5 for ; Sun, 11 Feb 2018 00:39:21 +0000 (GMT) Received: by mail-qk0-f196.google.com with SMTP id i184so3461918qkf.10 for ; Sat, 10 Feb 2018 16:39:21 -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=MX3VbSVkRDK9E6sn2558Qb+W+6ZRHScP/0GiYfYgrPU=; b=yj1fMmECCRjwtIwRYsFNMbP/n7IvCWKDkbL01Hb7gdCgOgK98GOMau44OK48m2sY7+ BBtG5WAq5nRFCYCAXvU7/80oqFX7sJU5RaHvsClMU2p365en04DTRMWtN1xiZ0wEFF7P AompRfLNfP7LgootOMX5yDqXGBjjmxBtAq7p3/vjwSBQmCvoINTxewnzDYVyaZ9lIjHm UX4po/7Y7l61ketqjO7HdysazRKq91dyJu9ldktB9ELOPoOVSzhh+qpydDKxJvAhH/hW S6nmiFmERrz6Fb3Wcql54RNlfmtH5rL2OmkmcukcFeOB6XN4n0xin2u/0HIKtytWi63t PIow== 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=MX3VbSVkRDK9E6sn2558Qb+W+6ZRHScP/0GiYfYgrPU=; b=W3GPyqoBqgsJfG4Hk9hbfRPnmnDpUNueU+zEgf8qJ4CQSLsR7L8bXWHhC5vWOJ6o// u+DMJXI6as53zd/PZYY5hV+8PkVWU/46ZRorbKvxUYeXkXvnMeIVrQXzHfnMl1QtEpbT +5ABxGcolgOofFq/BlzPwJxGJlHrCcikIrECIrHvewvVJqGAf/lVA3LFLwYcLZvjhSbn zjgFZ0Gxzlqfb46Jf73awbk8bOdVfOAEzGsH35C/1LivZ1rIRbZwoy+52O72xljvWmih hH4G6Lmp/u0Q4Wuzr26/EVrDTG3QVrmvr2747InCTxpqrl2yVsyj86FEMh5eeb7xl06C PwyQ== X-Gm-Message-State: APf1xPClf71iOYgb2BLXmuh3Zt6NxmryMTtDlX+lUaw6ZacZpBKJSHLI KtklGmkEvxAMroxNCn009/2M9POC9wraM7HHNUlPiGdZ X-Google-Smtp-Source: AH8x2254r28mSf1wZnvE4fVtY+oAyfbmruVSNJTGwN444LzjiQ/NsVeyFVq8bZL/udoNApoikOiewh9qOyADiT/Mxa4= X-Received: by 10.55.44.4 with SMTP id s4mr10941724qkh.68.1518309560776; Sat, 10 Feb 2018 16:39:20 -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 16:39:20 -0800 (PST) In-Reply-To: <20180210154513.66fa5b3a@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> From: William Pitcock Date: Sat, 10 Feb 2018 18:39:20 -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 9:45 AM, Kevin Chadwick 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 security code. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---