Re: [Sks-devel] pool.sks-keyservers.net issues (was: Questions about OpenPGP best practices)

[Niels Laukens]

Apologies for cross-posting to both mailing lists, but since I got
replies via both ways I feel this is the easiest way to sync them.

On 2013-02-26 10:21, address@hidden wrote:
> I would indeed like to get more feedback on the pools. My first 
> question is whether you notice the same behavior when using the 
> geographical pools (eu,na,oc,sa) that are optimized based on the
> methods described in the PDF article linked in the overview of pools.
> This typically works better due to lower network roundtrip and also
> takes into account reverse proxies in assigning weights.

I've retried, summary:
$ gpg2 --keyserver pool.sks-keyservers.net --keyserver-option debug
--recv-key 08ab4849  # tcpdump shows it used 198.101.208.160
(ranger.ky9k.org)
gpg: requesting key 08AB4849 from hkp server pool.sks-keyservers.net
gpgkeys: curl version = GnuPG curl-shim
* HTTP proxy is "null"
* HTTP URL is
"http://pool.sks-keyservers.net:11371/pks/lookup?op=get&options=mr&search=0x08AB4849";
* HTTP auth is "null"
* HTTP method is GET
gpgkeys: HTTP fetch error 7: couldn't connect: End of file
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0


and with eu.pool.sks-keyservers.net I get:
193.17.17.6 (no PTR record) - works
62.48.53.90 (lorien.prato.linux.it) - works
46.19.90.99 (solaria.planetcyborg.de) - fails
130.133.110.62 (gpg.spline.inf.fu-berlin.de) - fails
130.206.1.8 (gozer.rediris.es) - fails
109.230.243.93 (ts3.rowa.us) - fails

So the problem does not seem to go away with using a geographically
close pool.


On 2013-02-26 22:41, address@hidden wrote:
> The hkps pool should be used with the hkps:// prefix and default to
> port 443 not 11371 unless a record telling otherwise is found in SRV

I was trying to debug keyserver problems, so my first debug-step was to
remove the TLS-layer. All tests in thes mail are with the generic pool,
not the hkps-pool.



On 2013-02-26 22:53, Daniel Kahn Gillmor wrote:
> This line says that you're using the "curl-shim", which actually means
> you're not using CURL at all -- it's a less-full-featured http client
> built into gpg itself, as a shim for systems which do not have libcurl
> installed or available.

I'm on MacOSX, so I can't use `apt-get`. However, libcurl seems to be
installed (/usr/lib/libcurl.dylib is present and `curl` works). I'm
using gpg from the GPGTools package (was MacGPG)
Either way, I suppose that the curl-shim-client should work as well?



On 2013-02-26 23:17, Phil Pennock wrote:
> When things fail, the request has been sent to the server in two
> packets, "GET" & "Host:" in the first, "Cache-Control:" and "Pragma:"
> (and trailing blank line) in the second.  The server replies with two
> ACKs and no payload; the second ACK contains a FIN flag, so I see the
> *server* closing the connection first.

I've made a pcap (attached as failed.pcap) showing (stripped version):
10:38:33.673911 IP C > S: Flags [S], seq _, length 0
10:38:33.703464 IP S > C: Flags [S.], seq _, ack _, length 0
10:38:33.703560 IP C > S: Flags [.], ack 1, length 0
10:38:33.703715 IP C > S: Flags [P.], seq 1:103, ack 1, length 102
10:38:33.703799 IP C > S: Flags [FP.], seq 103:148, ack 1, length 45
10:38:33.732821 IP S > C: Flags [.], ack 103, length 0
10:38:33.732861 IP C > S: Flags [F.], seq 148, ack 1, length 0
10:38:33.734806 IP S > C: Flags [F.], seq 1, ack 149, length 0
10:38:33.734924 IP C > S: Flags [.], ack 2, length 0
10:38:33.760471 IP S > C: Flags [.], ack 149, length 0

So in my case, it's the Client that initiates the FIN. But this is fine
according to the TCP specs, since it will only leave the TCP connection
in a half-open state. The server is still free to send the answer.
However, it doesn't and closes the connection without sending a single byte.


> When things succeed, there is one packet sent, "GET", "Host:",
> "Accept:", "Pragma:" and "Cache-Control:" (and trailing blank line) in
> that packet.

I disagree. I have a capture (attached as success.pcap):
10:38:21.900869 C > S: Flags [S], seq _, length 0
10:38:21.934897 S > C: Flags [S.], seq _, ack _, length 0
10:38:21.934993 C > S: Flags [.], ack 1, length 0
10:38:21.935145 C > S: Flags [P.], seq 1:103, ack 1, length 102
10:38:21.935230 C > S: Flags [FP.], seq 103:148, ack 1, length 45
10:38:21.965068 S > C: Flags [.], ack 103, length 0
10:38:21.965170 C > S: Flags [F.], seq 148, ack 1, length 0
10:38:21.994654 S > C: Flags [.], ack 149, length 0
10:38:21.994701 C > S: Flags [.], ack 1, length 0
10:38:22.026966 S > C: Flags [.], seq 1:1437, ack 149, length 1436
...<more data>...

With the same split of headers (and a different server).


> I can only see a problem when the GET and the first header are in one
> packet and the later headers in the next, which I can't duplicate with
> telnet(1)

I do agree here. I haven't seen a failed scenario with a single segment
containing the complete GET-request. But then again, I haven't seen a
single segment containing the complete GET-request at all...


Hope this info helps.

failed.pcap
Description: Binary data

success.pcap
Description: Binary data