GNU bug report logs - #35787
26.2; gnutls: accessing raw server certificate data

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35787 in the body.
You can then email your comments to 35787 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Julian Scheid <julians37 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2; gnutls: accessing raw server certificate data
Date: Sat, 18 May 2019 13:48:47 +1200

[Message part 1 (text/plain, inline)]

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.

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.

[Message part 2 (text/html, inline)]

Message #8 received at 35787 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Julian Scheid <julians37 <at> gmail.com>
Cc: 35787 <at> debbugs.gnu.org
Subject: Re: bug#35787: 26.2; gnutls: accessing raw server certificate data
Date: Tue, 09 Jul 2019 04:42:58 +0200

Julian Scheid <julians37 <at> gmail.com> 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

Message #11 received at 35787 <at> debbugs.gnu.org (full text, mbox):

From: Julian Scheid <julians37 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 35787 <at> debbugs.gnu.org
Subject: Re: bug#35787: 26.2; gnutls: accessing raw server certificate data
Date: Mon, 8 Jul 2019 22:20:46 -0600

[Message part 1 (text/plain, inline)]

On Mon, Jul 8, 2019 at 8:43 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Julian Scheid <julians37 <at> gmail.com> 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 <larsi <at> gnus.org> wrote:

> Julian Scheid <julians37 <at> gmail.com> 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
>

[Message part 2 (text/html, inline)]

Message #14 received at 35787 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Julian Scheid <julians37 <at> gmail.com>
Cc: 35787 <at> debbugs.gnu.org
Subject: Re: bug#35787: 26.2; gnutls: accessing raw server certificate data
Date: Tue, 09 Jul 2019 15:44:42 +0200

Julian Scheid <julians37 <at> gmail.com> writes:

> 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.

I think putting the signature itself in the process object (in addition
to all the details) makes some sense, but perhaps it's wastes
unnecessary memory...

There's gnutls-peer-status, and that could also be amended to return the
full certificate.  But, again, that's also called for virtually any TLS
connection.

Perhaps a new function to return the actual certificate?  And perhaps it
should just return the entire certificate chain?

Anybody got an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 35787 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Julian Scheid <julians37 <at> gmail.com>
Cc: 35787 <at> debbugs.gnu.org
Subject: Re: bug#35787: 26.2; gnutls: accessing raw server certificate data
Date: Tue, 24 Sep 2019 07:44:22 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> There's gnutls-peer-status, and that could also be amended to return the
> full certificate.  But, again, that's also called for virtually any TLS
> connection.

This has been added now in conjunction with the more extensive NSM
checks.  gnutls-peer-status now returns the entire certificate in Emacs
27.

(:certificates
 ((:version 3 :serial-number "01:a7:8a:7f:5e:bb:b7:ba:02:00:00:00:00:42:ff:ed" :issuer "C=US,O=Google Trust Services,CN=GTS CA 1O1" :valid-from "2019-09-05" :valid-to "2019-11-28" :subject "C=US,ST=California,L=Mountain View,O=Google LLC,CN=www.google.com" :public-key-algorithm "EC/ECDSA" :certificate-security-level "High" :signature-algorithm "RSA-SHA256" :public-key-id "sha1:11:9e:12:6c:be:0c:66:5e:8f:94:c4:61:7a:98:ae:e5:ba:7b:20:98" :certificate-id "sha1:e3:70:d8:55:59:f9:0b:64:da:d4:52:22:55:ac:c1:23:57:d4:a3:c6" :pem "-----BEGIN CERTIFICATE-----\nMIIEvjCCA6agAwIBAgIQAaeKf167t7oCAAAAAEL/7TANBgkqhkiG9w0BAQsFADBC\nMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMRMw\nEQYDVQQDEwpHVFMgQ0EgMU8xMB4XDTE5MDkwNTIwMjEyNFoXDTE5MTEyODIwMjEy\nNFowaDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcT\nDU1vdW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBMTEMxFzAVBgNVBAMTDnd3\ndy5nb29nbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFozpcPL0RPFq\nPdxpYCEudxkn/IWJU5JU81Dqp1psOvVqWHB8TcvLlscPbx04BNsJZsZaSSQF5Ky0\nSeJchxHrL6OCAlMwggJPMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEF\nBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSvLWUz0DGNZtkyyKkyvQ6rfHKS\nTDAfBgNVHSMEGDAWgBSY0fhuEOvPm+xgnxiQG6DrfQn9KzBkBggrBgEFBQcBAQRY\nMFYwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnBraS5nb29nL2d0czFvMTArBggr\nBgEFBQcwAoYfaHR0cDovL3BraS5nb29nL2dzcjIvR1RTMU8xLmNydDAZBgNVHREE\nEjAQgg53d3cuZ29vZ2xlLmNvbTAhBgNVHSAEGjAYMAgGBmeBDAECAjAMBgorBgEE\nAdZ5AgUDMC8GA1UdHwQoMCYwJKAioCCGHmh0dHA6Ly9jcmwucGtpLmdvb2cvR1RT\nMU8xLmNybDCCAQMGCisGAQQB1nkCBAIEgfQEgfEA7wB2AGPy283oO8wszwtyhCdX\nazOkjWF3j711pjixx2hUS9iNAAABbQNNrJ0AAAQDAEcwRQIgTSJms2pYhhK9fqeT\nFxFez+JhDdItCIQQWgzaBPkJv/oCIQCLfR4jtnTlM4Q+3DsnJkUpOLyVGe1+szyo\n3iGIVKtrnwB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAABbQNN\nrLoAAAQDAEYwRAIgTz5ZYxnof80pqG73hkNRX8ypL7Zhawts2vNE/rhOHIQCIAfn\nIxrHwf9Jx0DyD7A4cjtgaunpuAy8ICUjysICyQ16MA0GCSqGSIb3DQEBCwUAA4IB\nAQBEKhT92shr4RdM4Yc26VkNOxR4FjbDJHRltJkrxIu/VwFdyrsRfA3WtawRl7xM\n27C99PvwS2Z6XzqKM+GuxfS5qBRxV3RTQVFDeJYgXqkXwCT1YnpRo98cDcBcOlac\nrXz+3KzDWrz323xG8NyYSoqDtDUvUF5B0JttNYh2UuxVh3yqOmYjEQvH0kxp+Elc\nLV7Xq47alFBvD8nLARX9mqLFXjaiMNLPihX/Oo3AJd+kXuDeJz6igUsf9UeIcbRc\n4ZOLQk5ysB/+k9B8w3B2DIXMyy+UWt3XNX7pKMDVEhLm2esXAsjgMziu0n3UwLKG\n1KJj8WrPtP2Xvq/dixvp08ui\n-----END CERTIFICATE-----\n")
  (:version 3 :serial-number "01:e3:b4:9a:a1:8d:8a:a9:81:25:69:50:b8" :issuer "OU=GlobalSign Root CA - R2,O=GlobalSign,CN=GlobalSign" :valid-from "2017-06-15" :valid-to "2021-12-15" :subject "C=US,O=Google Trust Services,CN=GTS CA 1O1" :public-key-algorithm "RSA" :certificate-security-level "Medium" :signature-algorithm "RSA-SHA256" :public-key-id "sha1:02:8d:a9:cf:40:24:76:cc:18:27:6a:db:ac:85:c5:a3:e8:9d:66:a2" :certificate-id "sha1:df:e2:07:0c:79:e7:ff:36:a9:25:ff:a3:27:ff:e3:de:ec:f8:f9:c2" :pem "-----BEGIN CERTIFICATE-----\nMIIESjCCAzKgAwIBAgINAeO0mqGNiqmBJWlQuDANBgkqhkiG9w0BAQsFADBMMSAw\nHgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMjETMBEGA1UEChMKR2xvYmFs\nU2lnbjETMBEGA1UEAxMKR2xvYmFsU2lnbjAeFw0xNzA2MTUwMDAwNDJaFw0yMTEy\nMTUwMDAwNDJaMEIxCzAJBgNVBAYTAlVTMR4wHAYDVQQKExVHb29nbGUgVHJ1c3Qg\nU2VydmljZXMxEzARBgNVBAMTCkdUUyBDQSAxTzEwggEiMA0GCSqGSIb3DQEBAQUA\nA4IBDwAwggEKAoIBAQDQGM9F1IvN05zkQO9+tN1pIRvJzzyOTHW5DzEZhD2ePCnv\nUA0Qk28FgICfKqC9EksC4T2fWBYk/jCfC3R3VZMdS/dN4ZKCEPZRrAzDsiKUDzRr\nmBBJ5wudgzndIMYcLe/RGGFl5yODIKgjEv/SJH/UL+dEaltN11BmsK+eQmMF++Ac\nxGNhr59qM/9il71I2dN8FGfcddwuaej4bXhp0LcQBbjxMcI7JP0aM3T4I+DsaxmK\nFsbjzaTNC9uzpFlgOIg7rR25xoynUxv8vNmkq7zdPGHXkxWY7oG9j+JkRyBABk7X\nrJfoucBZEqFJJSPk7XA0LKW0Y3z5oz2D0c1tJKwHAgMBAAGjggEzMIIBLzAOBgNV\nHQ8BAf8EBAMCAYYwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBIGA1Ud\nEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFJjR+G4Q68+b7GCfGJAboOt9Cf0rMB8G\nA1UdIwQYMBaAFJviB1dnHB7AagbeWbSaLd/cGYYuMDUGCCsGAQUFBwEBBCkwJzAl\nBggrBgEFBQcwAYYZaHR0cDovL29jc3AucGtpLmdvb2cvZ3NyMjAyBgNVHR8EKzAp\nMCegJaAjhiFodHRwOi8vY3JsLnBraS5nb29nL2dzcjIvZ3NyMi5jcmwwPwYDVR0g\nBDgwNjA0BgZngQwBAgIwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly9wa2kuZ29vZy9y\nZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEAGoA+Nnn78y6pRjd9XlQWNa7H\nTgiZ/r3RNGkmUmYHPQq6Scti9PEajvwRT2iWTHQr02fesqOqBY2ETUwgZQ+lltoN\nFvhsO9tvBCOIazpswWC9aJ9xju4tWDQH8NVU6YZZ/XteDSGU9YzJqPjY8q3MDxrz\nmqepBCf5o8mw/wJ4a2G6xzUr6Fb6T8McDO22PLRL6u3M4Tzs3A2M1j6bykJYi8wW\nIRdAvKLWZu/axBVbzYmqmwkm5zLSDW5nIAJbELCQCZwMH56t2Dvqofxs6BBcCFIZ\nUSpxu6x6td0V7SvJCCosirSmIatj/9dSSVDQibet8q/7UK4v4ZUN80atnZz1yg==\n-----END CERTIFICATE-----\n"))
 :certificate
 (:version 3 :serial-number "01:a7:8a:7f:5e:bb:b7:ba:02:00:00:00:00:42:ff:ed" :issuer "C=US,O=Google Trust Services,CN=GTS CA 1O1" :valid-from "2019-09-05" :valid-to "2019-11-28" :subject "C=US,ST=California,L=Mountain View,O=Google LLC,CN=www.google.com" :public-key-algorithm "EC/ECDSA" :certificate-security-level "High" :signature-algorithm "RSA-SHA256" :public-key-id "sha1:11:9e:12:6c:be:0c:66:5e:8f:94:c4:61:7a:98:ae:e5:ba:7b:20:98" :certificate-id "sha1:e3:70:d8:55:59:f9:0b:64:da:d4:52:22:55:ac:c1:23:57:d4:a3:c6" :pem "-----BEGIN CERTIFICATE-----\nMIIEvjCCA6agAwIBAgIQAaeKf167t7oCAAAAAEL/7TANBgkqhkiG9w0BAQsFADBC\nMQswCQYDVQQGEwJVUzEeMBwGA1UEChMVR29vZ2xlIFRydXN0IFNlcnZpY2VzMRMw\nEQYDVQQDEwpHVFMgQ0EgMU8xMB4XDTE5MDkwNTIwMjEyNFoXDTE5MTEyODIwMjEy\nNFowaDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcT\nDU1vdW50YWluIFZpZXcxEzARBgNVBAoTCkdvb2dsZSBMTEMxFzAVBgNVBAMTDnd3\ndy5nb29nbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEFozpcPL0RPFq\nPdxpYCEudxkn/IWJU5JU81Dqp1psOvVqWHB8TcvLlscPbx04BNsJZsZaSSQF5Ky0\nSeJchxHrL6OCAlMwggJPMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEF\nBQcDATAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSvLWUz0DGNZtkyyKkyvQ6rfHKS\nTDAfBgNVHSMEGDAWgBSY0fhuEOvPm+xgnxiQG6DrfQn9KzBkBggrBgEFBQcBAQRY\nMFYwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnBraS5nb29nL2d0czFvMTArBggr\nBgEFBQcwAoYfaHR0cDovL3BraS5nb29nL2dzcjIvR1RTMU8xLmNydDAZBgNVHREE\nEjAQgg53d3cuZ29vZ2xlLmNvbTAhBgNVHSAEGjAYMAgGBmeBDAECAjAMBgorBgEE\nAdZ5AgUDMC8GA1UdHwQoMCYwJKAioCCGHmh0dHA6Ly9jcmwucGtpLmdvb2cvR1RT\nMU8xLmNybDCCAQMGCisGAQQB1nkCBAIEgfQEgfEA7wB2AGPy283oO8wszwtyhCdX\nazOkjWF3j711pjixx2hUS9iNAAABbQNNrJ0AAAQDAEcwRQIgTSJms2pYhhK9fqeT\nFxFez+JhDdItCIQQWgzaBPkJv/oCIQCLfR4jtnTlM4Q+3DsnJkUpOLyVGe1+szyo\n3iGIVKtrnwB1AHR+2oMxrTMQkSGcziVPQnDCv/1eQiAIxjc1eeYQe8xWAAABbQNN\nrLoAAAQDAEYwRAIgTz5ZYxnof80pqG73hkNRX8ypL7Zhawts2vNE/rhOHIQCIAfn\nIxrHwf9Jx0DyD7A4cjtgaunpuAy8ICUjysICyQ16MA0GCSqGSIb3DQEBCwUAA4IB\nAQBEKhT92shr4RdM4Yc26VkNOxR4FjbDJHRltJkrxIu/VwFdyrsRfA3WtawRl7xM\n27C99PvwS2Z6XzqKM+GuxfS5qBRxV3RTQVFDeJYgXqkXwCT1YnpRo98cDcBcOlac\nrXz+3KzDWrz323xG8NyYSoqDtDUvUF5B0JttNYh2UuxVh3yqOmYjEQvH0kxp+Elc\nLV7Xq47alFBvD8nLARX9mqLFXjaiMNLPihX/Oo3AJd+kXuDeJz6igUsf9UeIcbRc\n4ZOLQk5ysB/+k9B8w3B2DIXMyy+UWt3XNX7pKMDVEhLm2esXAsjgMziu0n3UwLKG\n1KJj8WrPtP2Xvq/dixvp08ui\n-----END CERTIFICATE-----\n")
 :key-exchange "ECDHE-RSA" :protocol "TLS1.3" :cipher "AES-256-GCM" :mac "AEAD" :encrypt-then-mac nil)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #24 received at 35787 <at> debbugs.gnu.org (full text, mbox):

From: Julian Scheid <julians37 <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 35787 <at> debbugs.gnu.org
Subject: Re: bug#35787: 26.2; gnutls: accessing raw server certificate data
Date: Tue, 24 Sep 2019 19:36:38 +1200

[Message part 1 (text/plain, inline)]

On Tue, Sep 24, 2019 at 5:44 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:

> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > There's gnutls-peer-status, and that could also be amended to return the
> > full certificate.  But, again, that's also called for virtually any TLS
> > connection.
>
> This has been added now in conjunction with the more extensive NSM
> checks.  gnutls-peer-status now returns the entire certificate in Emacs
> 27.
>

Amazing, thank you!

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.