From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Julian Scheid Newsgroups: gmane.emacs.bugs Subject: bug#35787: 26.2; gnutls: accessing raw server certificate data Date: Mon, 8 Jul 2019 22:20:46 -0600 Message-ID: References: <87r270dj2l.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002b6318058d37e3f6" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="255408"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35787@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 09 06:22:16 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hkhdu-0014Fd-Uc for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Jul 2019 06:22:15 +0200 Original-Received: from localhost ([::1]:46652 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkhdt-0006yM-AD for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Jul 2019 00:22:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37896) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hkhdk-0006yF-GH for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 00:22:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hkhdi-0001IL-Oe for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 00:22:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51361) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hkhdh-0001He-Pv for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 00:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hkhdh-0005sc-Jn for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 00:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Julian Scheid Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2019 04:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35787 X-GNU-PR-Package: emacs Original-Received: via spool by 35787-submit@debbugs.gnu.org id=B35787.156264606822542 (code B ref 35787); Tue, 09 Jul 2019 04:22:01 +0000 Original-Received: (at 35787) by debbugs.gnu.org; 9 Jul 2019 04:21:08 +0000 Original-Received: from localhost ([127.0.0.1]:60182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkhcq-0005rW-5d for submit@debbugs.gnu.org; Tue, 09 Jul 2019 00:21:08 -0400 Original-Received: from mail-io1-f52.google.com ([209.85.166.52]:33748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hkhcl-0005qg-AA for 35787@debbugs.gnu.org; Tue, 09 Jul 2019 00:21:06 -0400 Original-Received: by mail-io1-f52.google.com with SMTP id z3so25296319iog.0 for <35787@debbugs.gnu.org>; Mon, 08 Jul 2019 21:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U2/6/gCHqaSvDL6AMf3VnFmuM8prLsVaK4I1cpE4KwE=; b=ZPGVfsvhKcHChFYX3iP04nD35c8dpr5bCnmt0bg9uv/HY/sYWCU0ORLqTtcwgzUUXy ayp+DSKmZX0bb6GPz+QnZHcc+o7qvTW5ybCPpkbXhOYLKWiiSxNADFKyMgbIT+Oh+4w2 25BHI3CbFNBRiLqNHnb/nAdsfaU/jzHveGXonAiR4QVyolkgK9J4zFBc6Ekjhe7GcJVB xMecmn+p8nK70x7tm9fbSR0pzOjoiWWX7aZo44Ia+BmzsQGW8tFwcWoI0tCS60YLad7g HICVPYw82EOHif2uDT/NIujAZ9NXBLNO8Olxqg37Y0m8FHyzSdPoL2l8bbTMBSEcw1cn FfFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U2/6/gCHqaSvDL6AMf3VnFmuM8prLsVaK4I1cpE4KwE=; b=cltz9qZRts0GocSzaiYgKh9fQjoRVcrOz6b8IRg7DPZaJhdDfFckEBQblmFFlI4XJF tXvfyDuXA5GQbOryn/ZSeB8dlMF7v6tCAhbqDSsipFwj6l9ws/rFKn+0fzkixMcf3Lmb AxFFUaSpzBPYtoK3vXB8VcqoUUXlIK/c8UsuoVeoKuMw8IYwlIu7shlvV+6/+h9p8FJi YvbvCad+dMDJW+EFcVl00NXp2FIJvq6aXR6uuIUbf7dPsGaXFMt4JOnOf6yzRL9PNbeS gaFFHn1Dr1xjbgTK4OqiqPOcAvkNneY6lGdsXrsPg5DKhKdgOHiGGFsFx7uhzWEIhqqb ZJug== X-Gm-Message-State: APjAAAUdBKZMed71aYs2n/4XX/OxiWDTttStBLloyIYbznJpu6v1f+AM BFt2fC1xRz13HzuJXx9P0PnhjPacXLM5zqWNl5M= X-Google-Smtp-Source: APXvYqwZ8ozLGz62ej/fDMdV+ZahSDn81u8VC+Iu8CzHQwGHHFDnuWp9dR5ACTrfEmJijQ5khLDSYLqJnybztwbqqnc= X-Received: by 2002:a5d:87da:: with SMTP id q26mr23227026ios.193.1562646057540; Mon, 08 Jul 2019 21:20:57 -0700 (PDT) In-Reply-To: <87r270dj2l.fsf@mouse.gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162432 Archived-At: --0000000000002b6318058d37e3f6 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 8, 2019 at 8:43 PM Lars Ingebrigtsen wrote: > > Julian Scheid writes: > > Currently, `gnutls-peer-status' only allows accessing high-level > > information extracted from the certificate, such as the issuer, but not > > the certificate data itself. > > Other details are returned in the process object, like > gnutls_x509_crt_get_fingerprint of the certificate. Thanks for pointing this out, but it appears to be hardwired to use SHA-1 when RFC 5929 requires the hash to use signatureAlgorithm, or SHA-256 when signatureAlgorithm is MD5 or SHA-1. > Does this hash relate in any way to gnutls_x509_crt_get_fingerprint? I _think_ gnutls_x509_crt_get_fingerprint could be used here, although I haven't verified yet that it satisfies the following requirement from RFC 5929: > The hash of the TLS server's certificate [RFC5280] as it appears, > octet for octet, in the server's Certificate message. I would assume that it does, though. So, to make this work it looks like I'd need either 1) the fingerprint, but using the hash function as required by the RFC, or 2) the certificate as a binary blob. Thanks again, Julian On Mon, Jul 8, 2019 at 8:43 PM Lars Ingebrigtsen wrote: > Julian Scheid writes: > > > Hello, I would like to request a feature: accessing the raw certificate > > of a server connected to via `gnutls-negotiate' (or such). > > > > Currently, `gnutls-peer-status' only allows accessing high-level > > information extracted from the certificate, such as the issuer, but not > > the certificate data itself. > > Other details are returned in the process object, like > gnutls_x509_crt_get_fingerprint of the certificate. > > > Access to the raw certificate data would allow implementing the > > `tls-server-endpoint' channel binding type as per > > https://tools.ietf.org/html/rfc5929#section-4.1 , which requires > >> [t]he hash of the TLS server's certificate [RFC5280] as it > >> appears, octet for octet, in the server's Certificate message. Note > >> that the Certificate message contains a certificate_list, in which > >> the first element is the server's certificate. > > Does this hash relate in any way to gnutls_x509_crt_get_fingerprint? > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > --0000000000002b6318058d37e3f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 8, 2019 at 8:43 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> = Julian Scheid <julians37@gmail.co= m> writes:
> > Currently, `gnutls-peer-status' only all= ows accessing high-level
> > information extracted from the certif= icate, such as the issuer, but not
> > the certificate data itself= .
>
> Other details are returned in the process object, like> gnutls_x509_crt_get_fingerprint of the certificate.

Thanks for= pointing this out, but it appears to be hardwired to use
SHA-1 when RFC= 5929 requires the hash to use signatureAlgorithm,
or=C2=A0SHA-256 when= signatureAlgorithm is MD5 or SHA-1.

> Does this hash relate in = any way to gnutls_x509_crt_get_fingerprint?

I _think_ gnutls_x5= 09_crt_get_fingerprint could be used here, although
I haven't verifi= ed yet that it satisfies the following requirement
from RFC 5929:
> The hash of the TLS server's certificate [RFC5280] as it appears,=
> octet for octet, in the server's Certificate message.

I= would assume that it does, though.

So, = to make this work it looks like I'd need either

1) the fingerpri= nt, but using the hash function as required by the RFC, or
2) the certif= icate as a binary blob.

Thanks again,

Julian


On Mon, Jul 8, 2019 at 8:= 43 PM Lars Ingebrigtsen <larsi@gnus.or= g> wrote:
Julian Scheid <julians37@gmail.com> writes:

> Hello, I would like to request a feature: accessing the raw certificat= e
> of a server connected to via `gnutls-negotiate' (or such).
>
> Currently, `gnutls-peer-status' only allows accessing high-level > information extracted from the certificate, such as the issuer, but no= t
> the certificate data itself.

Other details are returned in the process object, like
gnutls_x509_crt_get_fingerprint of the certificate.

> Access to the raw certificate data would allow implementing the
> `tls-server-endpoint' channel binding type as per
> https://tools.ietf.org/html/rfc5929#section-4.1<= /a> , which requires
>> [t]he hash of the TLS server's certificate [RFC5280] as it
>> appears, octet for octet, in the server's Certificate message.= =C2=A0 Note
>> that the Certificate message contains a certificate_list, in which=
>> the first element is the server's certificate.

Does this hash relate in any way to gnutls_x509_crt_get_fingerprint?

--
(domestic pets only, the antidote for overdose, milk.)
=C2=A0 =C2=A0bloggy blog: http://lars.ingebrigtsen.no
--0000000000002b6318058d37e3f6--