* bug#35787: 26.2; gnutls: accessing raw server certificate data
@ 2019-05-18 1:48 Julian Scheid
2019-07-09 2:42 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Julian Scheid @ 2019-05-18 1:48 UTC (permalink / raw)
To: 35787
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1076 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35787: 26.2; gnutls: accessing raw server certificate data
2019-05-18 1:48 bug#35787: 26.2; gnutls: accessing raw server certificate data Julian Scheid
@ 2019-07-09 2:42 ` Lars Ingebrigtsen
2019-07-09 4:20 ` Julian Scheid
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-09 2:42 UTC (permalink / raw)
To: Julian Scheid; +Cc: 35787
Julian Scheid <julians37@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35787: 26.2; gnutls: accessing raw server certificate data
2019-07-09 2:42 ` Lars Ingebrigtsen
@ 2019-07-09 4:20 ` Julian Scheid
2019-07-09 13:44 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Julian Scheid @ 2019-07-09 4:20 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 35787
[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]
On Mon, Jul 8, 2019 at 8:43 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
>
> Julian Scheid <julians37@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@gnus.org> wrote:
> Julian Scheid <julians37@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
>
[-- Attachment #2: Type: text/html, Size: 3387 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35787: 26.2; gnutls: accessing raw server certificate data
2019-07-09 4:20 ` Julian Scheid
@ 2019-07-09 13:44 ` Lars Ingebrigtsen
2019-09-24 5:44 ` Lars Ingebrigtsen
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-07-09 13:44 UTC (permalink / raw)
To: Julian Scheid; +Cc: 35787
Julian Scheid <julians37@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35787: 26.2; gnutls: accessing raw server certificate data
2019-07-09 13:44 ` Lars Ingebrigtsen
@ 2019-09-24 5:44 ` Lars Ingebrigtsen
2019-09-24 7:36 ` Julian Scheid
0 siblings, 1 reply; 6+ messages in thread
From: Lars Ingebrigtsen @ 2019-09-24 5:44 UTC (permalink / raw)
To: Julian Scheid; +Cc: 35787
Lars Ingebrigtsen <larsi@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
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#35787: 26.2; gnutls: accessing raw server certificate data
2019-09-24 5:44 ` Lars Ingebrigtsen
@ 2019-09-24 7:36 ` Julian Scheid
0 siblings, 0 replies; 6+ messages in thread
From: Julian Scheid @ 2019-09-24 7:36 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 35787
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
On Tue, Sep 24, 2019 at 5:44 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Lars Ingebrigtsen <larsi@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!
[-- Attachment #2: Type: text/html, Size: 838 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-09-24 7:36 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-05-18 1:48 bug#35787: 26.2; gnutls: accessing raw server certificate data Julian Scheid
2019-07-09 2:42 ` Lars Ingebrigtsen
2019-07-09 4:20 ` Julian Scheid
2019-07-09 13:44 ` Lars Ingebrigtsen
2019-09-24 5:44 ` Lars Ingebrigtsen
2019-09-24 7:36 ` Julian Scheid
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).