Date: Mon, 12 Feb 2018 10:36:20 +0000
From: Kevin Chadwick <m8il1ists@gmail.com>
To: alpine-dev <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Proposed change: openssl 1.1 as default system
 openssl implementation
Message-ID: <20180212103620.5a55f6e3@mechanicum.chadwicks.me.uk>
In-Reply-To: <CA+T2pCF6z3AnaGw51=zdyJio9gdtmcyk=eyEAoU+j_2k0niEGA@mail.gmail.com>
References: <CA+T2pCGFeh30aEi43hAvJ3yoHBijABy_U62wfjhVmf3FmbNUUg@mail.gmail.com>
	<20180209211237.19ab8fda@ncopa-macbook.copa.dup.pw>
	<CA+T2pCGVM0jRKnh_2e=bi525uWdVpvUAK1U3Am0MipTYCCJmvQ@mail.gmail.com>
	<eaccb1de-0bfa-769f-34c6-f26a90bbb804@adelielinux.org>
	<20180210111715.144a571e@mechanicum.chadwicks.me.uk>
	<CA+T2pCEgTXECOav-gBdprCa3psJFSKt6vrgdD7fMHAzQGU+DcA@mail.gmail.com>
	<20180210141109.55695e19@mechanicum.chadwicks.me.uk>
	<CA+T2pCEC2fsiHh_iJ9FFcmSmhc+NsZoXX1WYkhEWB4KSj+VvJA@mail.gmail.com>
	<20180210154513.66fa5b3a@mechanicum.chadwicks.me.uk>
	<7f5961a9-e09e-8e1c-12b4-23ae56fce034@adelielinux.org>
	<20180210190646.38ab746f@mechanicum.chadwicks.me.uk>
	<CA+T2pCF6z3AnaGw51=zdyJio9gdtmcyk=eyEAoU+j_2k0niEGA@mail.gmail.com>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 10 Feb 2018 19:04:04 -0600

> 
> 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]
>

Why would you revert it before raising it with them. I haven't the time
to write this mail or follow the code properly and didn't even find goto
out, but it appears it may still fail for completely broken systems. IF
there is a practical security issue then you have a DUTY to raise it no
matter how few systems it affects!

Perhaps it is only done for RFC compliance and this corner case is
deemed as too much work where Linux should be doing things right but
atleast you tried to upstream it. Perhaps these systems are seen as
being dangeorous to deploy in any case for any important task and so
supporting it is the wrong thing (aiding deployers) as their software
could do unpredictable things with a broken OS. It would be better to
know!
 
> >
> >  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.
> 

I guess you missed the point

>> Alpine has been using privilege separation for years where possible
>> regardless of using LibreSSL or not.  Privilege separation would not
>> have prevented Heartbleed, as the unprivileged process would still
>> require a copy of the X509 objects in order to perform cryptographic
>> operations.  

> Cool, glad to hear it. My faith in Alpine is restored somewhat :)

> That depends on the design which is also why I said compilation
> wouldn't cut it.

> http://insanecoding.blogspot.co.uk/2014/05/protecting-private-keys.html
> https://marc.info/?l=openbsd-cvs&m=139879883203226&w=2

The Imsgs used here are not passing keys or sensitive x509 objects!


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---