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