Re: [websec] HPKP & different encodings of the same public key
Jeffrey Walton <noloader@gmail.com> Sun, 15 May 2016 17:22 UTC
Return-Path: <noloader@gmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4F712D1EC for <websec@ietfa.amsl.com>; Sun, 15 May 2016 10:22:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Ch1Q1HXFNc for <websec@ietfa.amsl.com>; Sun, 15 May 2016 10:22:19 -0700 (PDT)
Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D92A12D1EA for <websec@ietf.org>; Sun, 15 May 2016 10:22:19 -0700 (PDT)
Received: by mail-io0-x244.google.com with SMTP id x35so22091211ioi.0 for <websec@ietf.org>; Sun, 15 May 2016 10:22:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-transfer-encoding; bh=v14HEvHt43f6f7GWZrWJgQJntxM5P/tIcaLkOi4I46o=; b=ABSmojQYXbgos4OMX8kYT2C2aNTnSqbzP23nssTgT7Knd4p1BjHT18G9woW5MnEqQZ EAGeN4GrXgXVrg1RXdKzRa4igzUvB3BxacBUaiMig5Yug0YLAtlW8n6iFuLRudLvO1Ei E7CnEn4nPjXHTjLfOeqlnncaV7zmRFi1ehv8+Q31U5NtjxZQ895GLImSgCd3a1O4hhyP 5LOPTGRu+pqLUOXVeFNRzA3QOtcCNC+aQCYVMA0W9aBUB3L08ZODcZEPePnTU8inXWMx 6qrJOUsqDBfvIty9kc6Q73n+r+QP7AzMoSa4HZYmzpZ/CWxklBYjm/u/2fKR9UgiN7nd MCVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-transfer-encoding; bh=v14HEvHt43f6f7GWZrWJgQJntxM5P/tIcaLkOi4I46o=; b=CN+Rdsbtol/R+FOYey7aW/0vhCDHg7Oe1jdq8sMYDeXHvOKaMQKgQhgC18mGLbD4Qz Utg4QlcKsC74ZQDcY8boiJR0A87b4Ktigw7xuhy/dUQYVNtnGW88eky8ghjueCeVO3m2 Yb7tsOH2Di5t1oPAsL1ZsVT4Vv9b47AzYV5dqYTybz+o+IjZ+q5kr/lBM2WmCD7gG6Cg x96XWMxexz+mGCJbgv03uKsHQDUlAvv03LaV0aa8U7ZpqgpM1zKsV7ke7FaPyeeII2KR sHqWX15oaARuMlcmavItVm4UEpzt0Ic5AUHVra+yM+rTkCVY9IVs1ShtFEFD07Vic5qs f73w==
X-Gm-Message-State: AOPr4FW98FNHheRO1xRZAhXa5h7Hgc7wWHnLrRtsLsDzhnhUrdoBrKl5WdibaaMcxCUxwLwDMgmS2nqku2OU2Q==
MIME-Version: 1.0
X-Received: by 10.36.252.199 with SMTP id b190mr1594580ith.2.1463332938910; Sun, 15 May 2016 10:22:18 -0700 (PDT)
Received: by 10.64.126.67 with HTTP; Sun, 15 May 2016 10:22:18 -0700 (PDT)
In-Reply-To: <CAME=j1=QZTFdxaMQ=_Egy296zhAiL--2hcW0_nc-3BLgz7z9XA@mail.gmail.com>
References: <CAME=j1=QZTFdxaMQ=_Egy296zhAiL--2hcW0_nc-3BLgz7z9XA@mail.gmail.com>
Date: Sun, 15 May 2016 13:22:18 -0400
Message-ID: <CAH8yC8=p=ZJnspy0q_uwhGa4+CCdRhEOKUOZC9k-Si8OsKD6gQ@mail.gmail.com>
From: Jeffrey Walton <noloader@gmail.com>
To: Jesse Wilson <jesse@swank.ca>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/websec/X9rsQtjIxhA5QWBnvOX0iJIVh6A>
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] HPKP & different encodings of the same public key
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: noloader@gmail.com
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 May 2016 17:22:22 -0000
On Sat, May 14, 2016 at 10:46 PM, Jesse Wilson <jesse@swank.ca> wrote: > I work on OkHttp, an Android HTTP client that implements HPKP-like > certificate pinning. We recently saw a problem where different versions of > Android returned different bytes for the ASN.1 encoding of the same > certificate. This is bad: the pins don’t match! > > The certificate of interest uses a named curve (secp521r1) with ECC. I used > der2ascii to view the SPKI ASN.1 bytes. > > Older versions of Android (which use BouncyCastle) embed the curve: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > SEQUENCE { > INTEGER { 1 } > SEQUENCE { > # prime-field > OBJECT_IDENTIFIER { 1.2.840.10045.1.1 } > INTEGER { `01ffffffffffffff...` } > } > SEQUENCE { > OCTET_STRING { `01ffffffffffffff...` } > OCTET_STRING { `0051953eb9618e1c...` } > } > OCTET_STRING { `0400c6858e06b704...` } > INTEGER { `01ffffffffffffff...` } > INTEGER { 1 } > } > } > BIT_STRING { `0004019519de800d...` } > } > > But new versions of Android (which use Conscrypt/OpenSSL) reference the > curve by name: > > SEQUENCE { > SEQUENCE { > # ecPublicKey > OBJECT_IDENTIFIER { 1.2.840.10045.2.1 } > # secp521r1 > OBJECT_IDENTIFIER { 1.3.132.0.35 } > } > BIT_STRING { `0004019519de800d...` } > } > > The original certificate embeds the curve. > > I believe my problem is that the Java APIs I’m using don’t return raw bytes > from the certificate. Instead Java decodes the certificate into a model and > re-encodes that when the bytes are requested. The original and roundtripped > SPKI bytes are not identical. > > Does anyone else do ASN.1 encoding in order to compute a certificate’s pin? > Or is it a uniquely Java problem?! > > The spec should warn that a single SPKI may have multiple conflicting > encodings. I suggest that only encoding in the certificate should be pinned. > TLS server administrators should also be careful to not inadvertently > re-encode their SPKIs when doing maintenance. This is kind of expected. The problem is because the first certificate (older version of Android) uses domain parameters; while the second certificate (Conscrypt/OpenSSL) uses a named curve rather than domain parameters. I've experienced similar problems with OpenSSL servers and clients. In fact, if a named curve is *not used*, then you will encounter an error "no shared ciphers" under some circumstances. Also see http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves. A certificate simply binds a public key to an identity through a trusted party's signature. Once you verify the signature on the certificate, you should canonicalize the certificate data and then pin the normalizedd data. Jeff
- [websec] HPKP & different encodings of the same p… Jesse Wilson
- Re: [websec] HPKP & different encodings of the sa… Yoav Nir
- Re: [websec] HPKP & different encodings of the sa… Jeffrey Walton
- Re: [websec] HPKP & different encodings of the sa… Yaron Sheffer
- Re: [websec] HPKP & different encodings of the sa… Jesse Wilson
- Re: [websec] HPKP & different encodings of the sa… Jeffrey Walton
- Re: [websec] HPKP & different encodings of the sa… Yoav Nir
- Re: [websec] HPKP & different encodings of the sa… Yaron Sheffer
- Re: [websec] HPKP & different encodings of the sa… Yoav Nir
- Re: [websec] HPKP & different encodings of the sa… Brian Smith
- Re: [websec] HPKP & different encodings of the sa… Jesse Wilson
- Re: [websec] HPKP & different encodings of the sa… Jeffrey Walton
- Re: [websec] HPKP & different encodings of the sa… Brian Smith
- Re: [websec] HPKP & different encodings of the sa… Jeffrey Walton
- Re: [websec] HPKP & different encodings of the sa… Alice Wonder