SRV records and HKPS requests

Kristian Fiskerstrand kristian.fiskerstrand at
Sat Oct 6 17:48:56 CEST 2012


In relation to setting up a HKPS pool for[0] I've
encountered a scenario where some input would be appreciated.

In the process of trying to figure out a mechanism to not have to
disable certificate checking when using the pool (I quite like DKG's
approach in [1]) I set up nginx (which was a reverse proxy to my SKS
server for hkp requests already) to respond to SSL requests on port 11375.

Port 443 on this server is already used by Apache.  Normally I'd be able
to set up Apache with a ProxyPassReverse to use this as a shared
resource, but since migrating to mod_gnutls rather than mod_ssl , this
configuration directive seems somewhat non-trivial[2] (and since i'm not
using mod_proxy for anything else, debugging it isn't that much of a
priority), so for the purposes of this discussion, using port 443 for
this service is out of the question.

As 11375 is a non-default port I set up a SRV record as shown in
#Snippet 1# below. When trying to send a key request as shown in
#Snippet 2# below, however, a connection to port 443 is attempted. Am I
using the wrong SRV records for HKPS? When first introducing SRV records
in the pool, this was the one being pointed out[3].

Some background information on this particular pool: My crawler is now
trying to detect HKPS enabled servers by looking for this SRV record,
and if no such SRV record is found, attempting to connect and locate a
SKS stats page on port 443. Servers available on 443 are then included
as A, AAAA and SRV records, while other SSL-enabled servers are only
represented as SRV records, as shown in #Snippet 3#

Snippet 1:
kristianf at kristianf-precision-m4600:~$ dig +short srv any
10 10 11375
Snippet 2:
kristianf at kristianf-precision-m4600:~$ gpg2 --keyserver-options
no-check-cert,debug,verbose --keyserver hkps://
--recv-key 0x0B7F8B60E3EDFAE3
gpg: requesting key 0B7F8B60E3EDFAE3 from hkps server
gpgkeys: curl version = libcurl/7.22.0 GnuTLS/2.12.14 zlib/
libidn/1.23 librtmp/2.3
* About to connect() to port 443 (#0)
*   Trying 2001:16d8:ee30::4... * connected
*      server certificate verification SKIPPED
*      compression: NULL
*      cipher: AES-128-CBC
*      MAC: SHA1
> GET /pks/lookup?op=get&options=mr&search=0x0B7F8B60E3EDFAE3 HTTP/1.1
Accept: */*
Pragma: no-cache
Cache-Control: no-cache
Snippet 3:
kristianf at kristianf-precision-m4600:~$ dig +short srv
100 100 443
100 100 11375
100 100 443
100 100 443
100 100 443
100 100 443
100 100 443



Kristian Fiskerstrand
Twitter: @krifisk
"In politics stupidity is not a handicap."
(Napoleon Bonaparte)
This email was digitally signed using the OpenPGP
standard. If you want to read more about this
The book: Sending Emails - The Safe Way: An 
introduction to OpenPGP security is 
available in both Amazon Kindle and Paperback 
format at
Public PGP key 0xE3EDFAE3 at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20121006/affb71aa/attachment.pgp>

More information about the Gnupg-users mailing list