sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] sks-keyservers.net New HKPS subpool added


From: Phil Pennock
Subject: Re: [Sks-devel] sks-keyservers.net New HKPS subpool added
Date: Mon, 8 Oct 2012 13:49:32 -0700

On 2012-10-08 at 22:12 +0200, Kristian Fiskerstrand wrote:
> Lovely! Must admit my setup is a tad more plain than that (just using
> nginx in front of SKS) :) Will be interesting to see how that goes.

Mine too.

So, the TLS handshake comes in, it contains SNI information; sks looks
through the server config blocks, to find a server_name which matches
SNI, then uses that block.

In my nginx.conf I now have two near-identical blocks: the one which
handles sks.spodhuis.org and the one which handles
*.pool.sks-keyservers.net, and they are equivalent, differing only in
server_name, ssl_certificate and ssl_certificate_key.

(Pedantically, taking into account implementation details: I have three
blocks, sks.spodhuis.org, the sks-keyservers.net and one for "all other
pools"; this is because I have redirects to canonical server to make
sure that non-/pks/ paths all work reliably, while proxying anything
under /pks/.  So the sks-keyservers.net block differs from the
all-other-pools config only by the three directives I cited above).

With this all in place ...

My server name:
----------------------------8< cut here >8------------------------------
% gpg --keyserver-options debug --refresh-key $gpg_key 
gpg: refreshing 1 key from https://sks.spodhuis.org
gpg: requesting key 0x403043153903637F from https server sks.spodhuis.org
gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22 
libssh2/1.4.1 librtmp/2.3
Scheme:         https
Host:           sks.spodhuis.org
Path:           /
Command:        GET
* About to connect() to sks.spodhuis.org port 443 (#0)
*   Trying 2a02:898:31:0:48:4558:73:6b73...
* connected
* Connected to sks.spodhuis.org (2a02:898:31:0:48:4558:73:6b73) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* SSL connection using ECDHE-RSA-AES128-SHA256
* Server certificate:
*        subject: C=NL; ST=Noord Holland; O=GlobNIX Systems; 
CN=sks.spodhuis.org; address@hidden
*        start date: 2011-08-10 04:59:54 GMT
*        expire date: 2013-05-01 04:59:54 GMT
*        subjectAltName: sks.spodhuis.org matched
*        issuer: C=US; O=GlobNIX Systems; OU=Certification Authority; 
CN=GlobNIX Certificate Authority 3; address@hidden
*        SSL certificate verify ok.
> GET / HTTP/1.1
----------------------------8< cut here >8------------------------------

The pool:
----------------------------8< cut here >8------------------------------
% unbound-control local_data hkps.pool.sks-keyservers.net A 94.142.241.93
ok
% gpg --keyserver-options debug --refresh-key $gpg_key 
gpg: refreshing 1 key from https://hkps.pool.sks-keyservers.net
gpg: requesting key 0x403043153903637F from https server 
hkps.pool.sks-keyservers.net
gpgkeys: curl version = libcurl/7.24.0 OpenSSL/1.0.1c zlib/1.2.3 libidn/1.22 
libssh2/1.4.1 librtmp/2.3
Scheme:         https
Host:           hkps.pool.sks-keyservers.net
Path:           /
Command:        GET
* About to connect() to hkps.pool.sks-keyservers.net port 443 (#0)
*   Trying 94.142.241.93...
* connected
* Connected to hkps.pool.sks-keyservers.net (94.142.241.93) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /home/phil/.gnupg/CA/sks-keyservers.netCA.pem
  CApath: none
* SSL connection using ECDHE-RSA-AES128-SHA256
* Server certificate:
*        subject: C=NL; O=GlobNIX Systems; OU=PGP Keyserver; CN=sks.spodhuis.org
*        start date: 2012-10-08 20:18:12 GMT
*        expire date: 2013-10-08 20:18:12 GMT
*        subjectAltName: hkps.pool.sks-keyservers.net matched
*        issuer: C=NO; ST=Oslo; O=sks-keyservers.net CA; CN=sks-keyservers.net 
CA
*        SSL certificate verify ok.
> GET / HTTP/1.1
Host: hkps.pool.sks-keyservers.net
----------------------------8< cut here >8------------------------------

So, assuming that GnuPG is also doing the right thing with SRV-based
lookups, I think that the certificate side of things is working.

Unfortunately, with an https: keyserver, GnuPG is sending a request for
"/" instead of "/pks/lookup?..." :(

If I do:
% unbound-control local_data
% _pgpkey-https._tcp.hkps.pool.sks-keyservers.net SRV 10 10 443 sks.spodhuis.org
ok

and specify "keyserver hkps://hkps.pool.sks-keyservers.net" in
~/.gnupg/gpg.conf, then I find that GnuPG has a security bug!

Given an SRV lookup, using insecure DNS (I don't have DNSSEC deployed),
GnuPG sends a hostname of "sks.spodhuis.org", derived from the untrusted
DNS, instead of the hostname it received from the trusted source (the
config file).

If DNSSEC were in the mix, perhaps the GnuPG current behaviour would be
correct, but right now it's not.  :(

-Phil

Attachment: pgpeC9fGtRxmk.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]