[Sks-devel] SRV records and HKPS requests

[Phil Pennock]

On 2012-12-05 at 23:32 -0500, David Shaw wrote:
> It's working, it's just misleading since the SRV replacement happens
> after the debug logging so the actual URL that is hit is not the one
> that is being logged.  If you look at netstat, you can see it's
> connecting to the right port.

Sorry for the delay getting back to you.

> Try this new patch (by itself, not on top of an earlier one) - it logs
> before and after the SRV replacement so it's clear what is going on.

Using Curl:

So, I do see the correct port being used (bug 1446), I don't see the
correct hostname (bug 1447)

----------------------------8< cut here >8------------------------------
% gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key
gpg: requesting key 0x403043153903637F from hkp server keytest.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
Host:           keyserver.spodhuis.org
Port:           11374
Command:        GET
* About to connect() to keyserver.spodhuis.org port 11374 (#0)
*   Trying 2a02:898:31:0:48:4558:73:6b73...
* connected
* Connected to keyserver.spodhuis.org (2a02:898:31:0:48:4558:73:6b73) port 11374 (#0)
> GET /pks/lookup?op=get&options=mr&search=0x403043153903637F HTTP/1.1
Host: keyserver.spodhuis.org:11374
Accept: */*
Pragma: no-cache
Cache-Control: no-cache

* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 200 OK
< Date: Fri, 07 Dec 2012 07:26:05 GMT
< Content-Type: application/pgp-keys; charset=UTF-8
< Content-Length: 63475
< Connection: keep-alive
< Server: sks_www/1.1.4
< Cache-Control: no-cache
< Pragma: no-cache
< Expires: 0
< X-HKP-Results-Count: 1
< Content-disposition: attachment; filename=gpgkey.asc
< Via: 1.1 keyserver.spodhuis.org:11374 (nginx)
<
* Connection #0 to host keyserver.spodhuis.org left intact
* Closing connection #0
[gpg output for key]
----------------------------8< cut here >8------------------------------

Without Curl:

The diagnostics confuse as to what is actually going to be sent; if you
know the code well enough to know where the messages come from, I'm
confident it's clear, but myself?  I had to use tcpdump to satisfy
myself that the "Host:" line coming _before_ the "original" line was
what actually got sent.

But it looks as though the non-Curl case is now fixed for both bugs 1446
& 1447.

Interesting that the HTTP request itself got split into two packets.

----------------------------8< cut here >8------------------------------
% gpg2 --keyserver-options debug,verbose --keyserver hkp://keytest.spodhuis.org/ --recv-key $gpg_key
gpg: requesting key 0x403043153903637F from hkp server keytest.spodhuis.org
gpgkeys: curl version = GnuPG curl-shim
Host:           keytest.spodhuis.org
Command:        GET
* HTTP proxy is "null"
* Original HTTP URL is "http://keytest.spodhuis.org:11371/pks/lookup?op=get&options=mr&search=0x403043153903637F"
* SRV tag is "pgpkey-http": URL may be overridden
* HTTP auth is "null"
* HTTP method is GET
* HTTP host:port post-SRV is "keyserver.spodhuis.org:11374"
----------------------------8< cut here >8------------------------------

----------------------------8< cut here >8------------------------------
02:35:22.942405 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 136) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: P, cksum 0x131c (correct), 1:105(104) ack 1 win 32844 <nop,nop,timestamp 3873907875 991822204>
	0x0000:  6009 380b 0088 0640 2a02 0898 0031 0000  `.8....@*....1..
	0x0010:  0048 4558 0073 6b73 2a02 0898 0031 0000  .HEX.sks*....1..
	0x0020:  0048 4558 0073 6b73 ffa4 2c6e e223 9b76  .HEX.sks..,n.#.v
	0x0030:  1ab3 cf49 8018 804c 131c 0000 0101 080a  ...I...L........
	0x0040:  e6e7 24a3 3b1e 017c 4745 5420 2f70 6b73  ..$.;..|GET./pks
	0x0050:  2f6c 6f6f 6b75 703f 6f70 3d67 6574 266f  /lookup?op=get&o
	0x0060:  7074 696f 6e73 3d6d 7226 7365 6172 6368  ptions=mr&search
	0x0070:  3d30 7834 3033 3034 3331 3533 3930 3336  =0x4030431539036
	0x0080:  3337 4620 4854 5450 2f31 2e30 0d0a 486f  37F.HTTP/1.0..Ho
	0x0090:  7374 3a20 6b65 7974 6573 742e 7370 6f64  st:.keytest.spod
	0x00a0:  6875 6973 2e6f 7267 3a31 3133 3731 0d0a  huis.org:11371..
02:35:22.942487 IP6 (flowlabel 0x9380b, hlim 64, next-header TCP (6) payload length: 77) 2a02:898:31:0:48:4558:73:6b73.65444 > 2a02:898:31:0:48:4558:73:6b73.11374: FP, cksum 0xe48f (correct), 105:150(45) ack 1 win 32844 <nop,nop,timestamp 3873907875 991822204>
	0x0000:  6009 380b 004d 0640 2a02 0898 0031 0000  `.8..M.@*....1..
	0x0010:  0048 4558 0073 6b73 2a02 0898 0031 0000  .HEX.sks*....1..
	0x0020:  0048 4558 0073 6b73 ffa4 2c6e e223 9bde  .HEX.sks..,n.#..
	0x0030:  1ab3 cf49 8019 804c e48f 0000 0101 080a  ...I...L........
	0x0040:  e6e7 24a3 3b1e 017c 4361 6368 652d 436f  ..$.;..|Cache-Co
	0x0050:  6e74 726f 6c3a 206e 6f2d 6361 6368 650d  ntrol:.no-cache.
	0x0060:  0a50 7261 676d 613a 206e 6f2d 6361 6368  .Pragma:.no-cach
	0x0070:  650d 0a0d 0a                             e....
----------------------------8< cut here >8------------------------------

Regards,
-Phil