Title TLS hostname selection uses insecure SRV data
Priority bug Status resolved
Category gnupg Due Date
Version ExtLink  (go)
Superseder Nosy List dshaw, syscomet
Assigned To Topics  (help)

Created on 2012-10-08.21:06:40 by syscomet, last changed 2015-03-16.14:24:19 by werner.

msg6074 (view) Author: werner Date: 2015-03-16.14:24:18
Was fixed with commit 6b1f71055ebab36989e2089cfde319d2ba40ada7 for 2.0.
Was fixed with commit 5c557a51cdf37d9f50b3d5d7e11d17e6ea6bb2b8 for 1.4.
msg4485 (view) Author: dshaw Date: 2012-12-15.14:59:50
Note that this implies setting Host: properly as well
msg4473 (view) Author: werner Date: 2012-12-03.13:01:01
Note that the topic is currently under discussion on gnupg-devel.
msg4431 (view) Author: syscomet Date: 2012-10-08.22:12:13
Kristian has removed the SRV records at _pgpkey-https._tcp.hkps.sks-, so the explanation in step 3 might seem to not match reality, but 
that's a change, because of this Issue and Issue1446.

If you set up your own DNS pool for testing, I'm happy to send you a CSR for a new 
vhost to help with debugging.
msg4430 (view) Author: syscomet Date: 2012-10-08.21:06:39
This is a security-impacting bug relating to verification of keyserver TLS 

When chasing SRV records, in *insecure* DNS, GnuPG takes the hostname from the SRV 
lookup and uses that, for libcurl, as the hostname to:
 (1) pass in ServerNameIndication
 (2) use for certificate verification

For testing purposes, "" is up and running with two different TLS 
certificates available.  One is from my own CA (cert and trust-details on  That is used for a hostname of 
"" and _most_ hostnames.

The second cert is configured to be used for " *.pool.sks-" (and the cert itself is for with subjectAltName 

Using gnupg with "keyserver-options verbose,debug,ca-cert-file=..." and keyserver 
pointing to various hostnames, I can see:

 (1) using --keyserver=https://...anything... the path is dropped from the HTTP 
request :(
 (2) using --keyserver=hkps:// and ca-cert-file pointing to a file 
containing globnixCA3.crt, things work
 (3) using --keyserver=hkps:// the DNS SRV records are 
used; with resolver manipulation (unbound-control in my case):

% unbound-control local_data SRV 10 
10 443
% unbound-control local_data A

we have SRV being used (good!) but then passing as the hostname in 
the handshake, which (1) selects the wrong cert and (2) will be verifying the TLS 
cert against untrusted data, instead of the known-good hostname.

TLS certificate verification should not use untrusted data; a corollary is that the 
ServerNameIndication, used by the server to select a cert, should specify the same 
hostname than the client will be using for verification.
Date User Action Args
2015-03-16 14:24:19wernersetstatus: chatting -> resolved
messages: + msg6074
2015-03-16 14:22:04wernersetstatus: resolved -> chatting
messages: - msg6072
2015-03-16 14:21:45wernersetstatus: chatting -> resolved
messages: + msg6072
2012-12-15 14:59:50dshawsetmessages: + msg4485
2012-12-03 13:01:01wernersetmessages: + msg4473
2012-12-02 15:46:33dshawsetnosy: + dshaw
2012-10-08 22:12:13syscometsetstatus: unread -> chatting
messages: + msg4431
2012-10-08 21:06:40syscometcreate