X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by lists.alpinelinux.org (Postfix) with ESMTP id 1D1525C371B for ; Thu, 8 Feb 2018 23:43:32 +0000 (GMT) Received: by mail-qk0-f181.google.com with SMTP id m130so7916095qke.1 for ; Thu, 08 Feb 2018 15:43:32 -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=vGKFhP5uK5qNdicrb95FpMAczsFVWKbhwaj9GIxCSwY=; b=Ofq3magfzKU7uh5CWQBAGtve/ppGOw4PZKXK6Crvrbw+s+IZLT9RiBPPkFi4g28yt6 /QKohEQbPEq7AlQM1kGC0hkpnDqlsSbzxgQLW1UkDs/Le5QPnUvoVxz1JBhkoBDA2nzg kIRUuIRMfAoU/NWhvx/GLpj0ff0S/MmMx3KC/6qZfCiAOalcl+kiAFi6u4PN2M5cywcn hGNFEXPORFx6Feg5AyvJXKFpnrP0liK1uOzsjMQ6bNJV6Z+s6fFj5VdxCWF+8hjtXtI/ B4r/f4T2z4YzGEWwzBw9sFlsZAloASIMxCmU7BcTUSZRprWuf1HGfBhM9MUqnUfm0pka djIg== 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=vGKFhP5uK5qNdicrb95FpMAczsFVWKbhwaj9GIxCSwY=; b=fs+6kjOn5WceA2RAOyKLmGVKvB9jztZuZxCKN3XWe+2zBXP/hBLbnVGm9lo/Yjjr77 x/mwAs2eqf1zk7z1XG7ThhFxR459TN871OfCARyW/sCQN6h/b+AQYfrXYDVqMfqSNSHr UecfOQoMvlKiUmC1RlkdFBZ0n/ZHJGbSQejVQ3lQe/WWDpyroE4so7A/FYbZyQp38Aqk UMmFskzgyvz2iMXZaYVdRC6rpoGzJmR/+Mz0wknNq3GgjyWBDCmTQnPs51o1sHqz7tAj BiD2C26vQUlnXhGZ40A/1Se9pGgHZe6d+Fhe4atrfSBxup7n97MCzW+8ZGMqxn4yRBTQ ODbQ== X-Gm-Message-State: APf1xPCNcWCtNQLp6rQIWffCh2Ov3dFaBF0NF7eVqJJwrUCzPWEKHXlH nEfJCs8aHqDITOJtIowP7/uG5yg3g5Fsrzx2FgOlBQ== X-Google-Smtp-Source: AH8x226wgukpyDR+giIl9ryN6kuXx91Ziv39oC1EBWtnXLBK1Uft236Mc3iBXX1sEf6lhd236Ef8Xss/JqQc+cjE7/4= X-Received: by 10.55.44.4 with SMTP id s4mr1193104qkh.68.1518133411601; Thu, 08 Feb 2018 15:43:31 -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; Thu, 8 Feb 2018 15:43:31 -0800 (PST) In-Reply-To: <20180208224032.3942ce38@mechanicum.chadwicks.me.uk> References: <20180208180544.3ff19e66@mechanicum.chadwicks.me.uk> <20180208192207.7e0da20a@mechanicum.chadwicks.me.uk> <20180208224032.3942ce38@mechanicum.chadwicks.me.uk> From: William Pitcock Date: Thu, 8 Feb 2018 17:43:31 -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 Thu, Feb 8, 2018 at 4:40 PM, Kevin Chadwick wrote: >> > You clearly do not know about the extra protections and priviledge >> > separation in LibreSSL!!! >> >> You must be talking about Pledge, which allows LibreSSL to declare >> what system calls it will and will not be using. Of course, Pledge >> is only available in OpenBSD. > > No, Pledge is not priviledge seperation or even close to it, though it > does benefit from it! > > Buffer overflows are far less dangerous with priviledge separation > deployed and no the way you compile Alpine will not accomplish anything > like proper priviledge seperation. 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. Also, buffer overflows are different than buffer over-reads. An over-read is when a read goes past the end of a buffer, an overflow is when a write goes past the end of a buffer. Heartbleed is an example of an over-read, and the correct mitigation is to ensure that allocation sizes are correct and non-contiguous. > I guess you can see how with libtls then heartbleed would have had > much less affect. OpenBSD have been pioneering in depth use of > priviledge seperation with layers of security on top for years, No, I am pretty sure I don't see how libtls would have protected against Heartbleed (see above). > _______________________________________________________________________ > > As the OpenBSD 5.7 development effort comes to a close, so does the > LibreSSL 2.1.x branch. The next release will begin the 2.2.x development > branch. > > User-visible features: > > * Improvements to libtls: > - a new API for loading CA chains directly from memory instead of a > file, allowing verification with privilege separation in a chroot > without direct access to CA certificate files. > ________________________________________________________________________ This type of design is not provided by libtls itself, but libtls provides the primitives for it. It is also possible to accomplish this design through the OpenSSL 1.0.1g API using a series of SSL_CTX_add0_chain_cert() calls (which is essentially what libtls does internally), or just loading the certificate chain into X509 objects prior to calling fork(2). It is important to note that the isolated process still needs a copy of the X509 objects in memory in order to perform cryptographic operations with the certificates (such as setting up new TLS sessions), so the purpose of privilege separation here would not be to "protect the keys." They are needed in order to do cryptographic operations. William --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---