| Message ID | 1518006166-14285-1-git-send-email-steffan.karger@fox-it.com |
|---|---|
| State | Accepted |
| Headers |
Return-Path: <openvpn-devel-bounces@lists.sourceforge.net> Delivered-To: patchwork@openvpn.net Delivered-To: patchwork@openvpn.net Received: from director4.mail.ord1d.rsapps.net ([172.30.191.6]) by backend31.mail.ord1d.rsapps.net (Dovecot) with LMTP id 4U4nIP/velo+NQAAgoeIoA for <patchwork@openvpn.net>; Wed, 07 Feb 2018 07:24:31 -0500 Received: from proxy7.mail.ord1d.rsapps.net ([172.30.191.6]) by director4.mail.ord1d.rsapps.net (Dovecot) with LMTP id qVu2AP/velqYWgAAHDmxtw ; Wed, 07 Feb 2018 07:24:31 -0500 Received: from smtp1.gate.ord1d ([172.30.191.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) by proxy7.mail.ord1d.rsapps.net (Dovecot) with LMTP id lTHjKP/veloFOgAAMe1Fpw ; Wed, 07 Feb 2018 07:24:31 -0500 X-Spam-Threshold: 95 X-Spam-Score: 0 X-Spam-Flag: NO X-Virus-Scanned: OK X-Orig-To: openvpnslackdevel@openvpn.net X-Originating-Ip: [216.34.181.88] Authentication-Results: smtp1.gate.ord1d.rsapps.net; iprev=pass policy.iprev="216.34.181.88"; spf=pass smtp.mailfrom="openvpn-devel-bounces@lists.sourceforge.net" smtp.helo="lists.sourceforge.net"; dkim=fail (signature verification failed) header.d=sourceforge.net; dkim=fail (signature verification failed) header.d=sf.net; dmarc=none (p=nil; dis=none) header.from=fox-it.com X-Classification-ID: d94b316c-0c01-11e8-8653-5254002d775b-1-1 Received: from [216.34.181.88] ([216.34.181.88:16019] helo=lists.sourceforge.net) by smtp1.gate.ord1d.rsapps.net (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) (ecelerity 4.2.1.56364 r(Core:4.2.1.14)) with ESMTPS (cipher=DHE-RSA-AES256-GCM-SHA384) id C0/CE-20828-FFFEA7A5; Wed, 07 Feb 2018 07:24:31 -0500 Received: from localhost ([127.0.0.1] helo=sfs-ml-4.v29.ch3.sourceforge.com) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.89) (envelope-from <openvpn-devel-bounces@lists.sourceforge.net>) id 1ejOlG-0004m5-QQ; Wed, 07 Feb 2018 12:23:38 +0000 Received: from sfi-mx-4.v28.ch3.sourceforge.com ([172.29.28.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from <steffan.karger@fox-it.com>) id 1ejOlF-0004ln-Gg for openvpn-devel@lists.sourceforge.net; Wed, 07 Feb 2018 12:23:37 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject: CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Hxhrrvi9wNJ82PzayKFSyuLTNbaHakzFRnrfGj5bUQ4=; b=IxMPQCZQkwTukcLlDQOi+Nylo8 uz0juWrn/dj8rSLQJcIxcDhzslaxwUT6PVJdiirpW2aU8PbaH1B9Z+yblKGuPCyme5jEiRvTNKoyX aNmiV8gpot5wpEEBdvSb8cNqiXlSftdZsBZQFZs+VFuGNfcrrjRkGhKh+upRo6P1o0Ms=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Type:MIME-Version:Message-ID:Date:Subject:CC:To:From:Sender: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=Hxhrrvi9wNJ82PzayKFSyuLTNbaHakzFRnrfGj5bUQ4=; b=R Aqi9itetfbsKi/9IsSdMjS74KAVWUzxVd1kUtSjLB5UD8SdH74PJedj47sXzICfn1mSmFzssHvcOP NWV4sAppqttOcxe0y6Vp6Kd5FSm1BCYeBIwOWhm1DoCdBE3fghLuHn1cX9v+ZWg9iX4LfJIa+IZI0 4J10Vw4dMc8LGFNk=; Received: from ns2.fox-it.com ([178.250.144.131]) by sfi-mx-4.v28.ch3.sourceforge.com with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.89) id 1ejOlD-0000wM-Ma for openvpn-devel@lists.sourceforge.net; Wed, 07 Feb 2018 12:23:37 +0000 Received: from FOXDFT52.FOX.local (unknown [10.0.0.129]) by ns2.fox-it.com (Postfix) with ESMTPS id 9CC471AF7E9 for <openvpn-devel@lists.sourceforge.net>; Wed, 7 Feb 2018 13:23:29 +0100 (CET) Received: from steffan-fox.fox.local (10.0.3.178) by FOXDFT52.FOX.local (10.0.0.129) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Wed, 7 Feb 2018 13:23:29 +0100 From: Steffan Karger <steffan.karger@fox-it.com> To: <openvpn-devel@lists.sourceforge.net> Date: Wed, 7 Feb 2018 13:22:46 +0100 Message-ID: <1518006166-14285-1-git-send-email-steffan.karger@fox-it.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 X-ClientProxiedBy: FOXDFT52.FOX.local (10.0.0.129) To FOXDFT52.FOX.local (10.0.0.129) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1ejOlD-0000wM-Ma Subject: [Openvpn-devel] [PATCH] mbedtls: don't use API deprecated in mbed 2.7 X-BeenThere: openvpn-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: <openvpn-devel.lists.sourceforge.net> List-Unsubscribe: <https://lists.sourceforge.net/lists/options/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=unsubscribe> List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=openvpn-devel> List-Post: <mailto:openvpn-devel@lists.sourceforge.net> List-Help: <mailto:openvpn-devel-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/openvpn-devel>, <mailto:openvpn-devel-request@lists.sourceforge.net?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: openvpn-devel-bounces@lists.sourceforge.net X-getmail-retrieved-from-mailbox: Inbox |
| Series |
[Openvpn-devel] mbedtls: don't use API deprecated in mbed 2.7
|
|
Commit Message
Steffan Karger
Feb. 7, 2018, 1:22 a.m. UTC
The void-returning mbedtls_sha256() was deprecated in mbed TLS 2.7.
Use our own md_full() abstraction instead.
(The new function can theoretically fail, but only in case of highly
unlikely digest function failures. The personalisation on random using
the certificate is a best-effort measure, so we simply log a warning and
skip the personalisation if such highly unlikely errors occur.)
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
---
src/openvpn/ssl_mbedtls.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
Comments
Hi, On 07/02/18 20:22, Steffan Karger wrote: > - mbedtls_sha256(cert->tbs.p, cert->tbs.len, sha256_hash, false); > + if (0 != md_full(sha256_kt, cert->tbs.p, cert->tbs.len, sha256_hash)) Why not using mbedtls_sha256_ret() since we are already in mbedtls-specific code here? Any advantage in using a wrapper for another wrapper? :-P (mbedtls_sha256_ret() is also the suggested replacement for mbedtls_sha256()) Moreover, SHA256 is statically selected, therefore using mbedtls_sha256_ret() would also avoid the md_kt_t local variable. > + { > + msg(M_WARN, "WARNING: failed to personalise random"); > + } > + Since we now have a reason for the failure, may it make sense to print a proper description based on the return value? (even though I think mbedtls_sha256_ret() can't really return something different from 0) > if (0 != memcmp(old_sha256_hash, sha256_hash, sizeof(sha256_hash))) > { > mbedtls_ctr_drbg_update(cd_ctx, sha256_hash, 32); > Cheers,
Hi, Thanks for reviewing! On 23-02-18 10:17, Antonio Quartulli wrote: > On 07/02/18 20:22, Steffan Karger wrote: >> - mbedtls_sha256(cert->tbs.p, cert->tbs.len, sha256_hash, false); >> + if (0 != md_full(sha256_kt, cert->tbs.p, cert->tbs.len, sha256_hash)) > > Why not using mbedtls_sha256_ret() since we are already in > mbedtls-specific code here? > Any advantage in using a wrapper for another wrapper? :-P > > (mbedtls_sha256_ret() is also the suggested replacement for > mbedtls_sha256()) > > > Moreover, SHA256 is statically selected, therefore using > mbedtls_sha256_ret() would also avoid the md_kt_t local variable. This was the only place in the code where we took a (direct) dependency on functions from sha256.h. By using our internal wrapper, I could also do: @@ -60,7 +60,6 @@ #include <mbedtls/oid.h> #include <mbedtls/pem.h> -#include <mbedtls/sha256.h> Since reducing dependencies usually reduces maintenance burden, I prefer this solution. >> + { >> + msg(M_WARN, "WARNING: failed to personalise random"); >> + } >> + > > Since we now have a reason for the failure, may it make sense to print a > proper description based on the return value? (even though I think > mbedtls_sha256_ret() can't really return something different from 0) md_full returns true/false, but you're right we can improve error reporting. Are you satisfied if I add an mbed_ok() wrapper *inside* md_full() to print the internal mbed error? I think that should be sufficient information. -Steffan ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Hi, On 23/02/18 20:02, Steffan Karger wrote: > Since reducing dependencies usually reduces maintenance burden, I prefer > this solution. You're right here. Ok, let's keep md_full() then > >>> + { >>> + msg(M_WARN, "WARNING: failed to personalise random"); >>> + } >>> + >> >> Since we now have a reason for the failure, may it make sense to print a >> proper description based on the return value? (even though I think >> mbedtls_sha256_ret() can't really return something different from 0) > > md_full returns true/false, but you're right we can improve error > reporting. Are you satisfied if I add an mbed_ok() wrapper *inside* > md_full() to print the internal mbed error? I think that should be > sufficient information. Yeah, that would be nice. Thanks I guess this patch fine as it is then. The mbed_ok() can be introduced with another patch. Acked-by: Antonio Quartulli <a@unstable.cc> Cheers,
Your patch has been applied to the master and release/2.4 branch.
(release/2.4 due to "long term compatibility" reasoning)
Smoke-tested 2.4 vs. mbedTLS 2.7 on Gentoo ("works").
commit f22e89bd2311d3cab511e574746c6f82f1fa1a54 (master)
commit 7c913600105505bd7f539d6b4206d358b6811943 (release/2.4)
Author: Steffan Karger
Date: Wed Feb 7 13:22:46 2018 +0100
mbedtls: don't use API deprecated in mbed 2.7
Signed-off-by: Steffan Karger <steffan.karger@fox-it.com>
Acked-by: Antonio Quartulli <a@unstable.cc>
Message-Id: <1518006166-14285-1-git-send-email-steffan.karger@fox-it.com>
URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg16445.html
Signed-off-by: Gert Doering <gert@greenie.muc.de>
--
kind regards,
Gert Doering
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c index 2a1215d..3906cd5 100644 --- a/src/openvpn/ssl_mbedtls.c +++ b/src/openvpn/ssl_mbedtls.c @@ -60,7 +60,6 @@ #include <mbedtls/oid.h> #include <mbedtls/pem.h> -#include <mbedtls/sha256.h> static const mbedtls_x509_crt_profile openvpn_x509_crt_profile_legacy = { @@ -851,9 +850,14 @@ tls_ctx_personalise_random(struct tls_root_ctx *ctx) if (NULL != ctx->crt_chain) { + const md_kt_t *sha256_kt = md_kt_get("SHA256"); mbedtls_x509_crt *cert = ctx->crt_chain; - mbedtls_sha256(cert->tbs.p, cert->tbs.len, sha256_hash, false); + if (0 != md_full(sha256_kt, cert->tbs.p, cert->tbs.len, sha256_hash)) + { + msg(M_WARN, "WARNING: failed to personalise random"); + } + if (0 != memcmp(old_sha256_hash, sha256_hash, sizeof(sha256_hash))) { mbedtls_ctr_drbg_update(cd_ctx, sha256_hash, 32);