Re: [Sks-devel] sks behind lighttpd reverse proxy

[Phil Pennock]

On 2013-12-02 at 09:08 +0100, Simon Lange wrote:
> if u put it behind a lighttpd reverse proxy for ports 11370 and 11371 it
> wont work anymore.
> 11370 (recon) isnt operational anymore. communication is broken.

Recon is not HTTP, so an HTTP proxy in the middle will break things.

Ideally you run SKS 11371 on localhost, use the HTTP proxy to expose
that to the outside world, but leave 11370 directly connected.  It's a
different process, so stalls affect your peering but don't interfere
with serving.

For me, my `sksconf` file contains:

    membership_reload_interval: 1
    initial_stat:
    recon_address: 94.142.241.93 2a02:898:31:0:48:4558:73:6b73
    hkp_address: 127.0.0.1 ::1

> 11371 almost same. gpg client does not work anymore. a keysearch with
> gpg wont find ANYTHING anymore as long the lighttpd reverse proxy is
> between. only via browser (firefox, chrome, IE, ...) it works. same for
> 443 reverseproxy to 11371.

The configuration in:

  https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering

was contributed, and worked for the person who provided it to us.

> any help is welcome

When I connect using:

    % gpg --keyserver-options debug,verbose --keyserver keys.s-l-c.biz \
        --recv-key 0x4D1E900E14C1CC04

I get a response from lighttpd, but nothing indicating that the request
was sent to SKS as the actual backend.  Compare and contrast:

    % curl -i 'http://keys.s-l-c.biz:11371/pks/lookup?op=stats'
    HTTP/1.1 200 OK
    Via: 1.1 keys.s-l-c.biz:11371 (lighttpd)
    Server: sks_www/1.1.4
    [...]

vs:

    % gpg [...]
    [...]
    > GET /pks/lookup?op=get&options=mr&search=0x4D1E900E14C1CC04
    > HTTP/1.1
    Host: keys.s-l-c.biz:11371
    Accept: */*
    Pragma: no-cache
    Cache-Control: no-cache

    < HTTP/1.1 200 OK
    < Via: 1.1 keys.s-l-c.biz:11371 (lighttpd)
    < Content-Length: 0
    < Connection: close
    < Date: Mon, 02 Dec 2013 21:05:08 GMT
    * Server lighttpd/1.4.30 is not blacklisted
    < Server: lighttpd/1.4.30

So in a request for the _stats_ page, the `Server:` header is being set
by SKS, but in a request for the keys, the `Server:` header is being
generated by lighttpd itself.

I can reproduce this with curl(1) if I suppress sending a `User-Agent:`
header.

So I think that you have some anti-abuse filter in place which rejects
requests with no `User-Agent:` header.  The GnuPG folks have so far been
philosophically opposed to setting such a header.

Remove that filter for port 11371 and you should be good.  If you can
let us know which setting it was, we can update the Peering wiki page
with a cautionary note.

-Phil

pgp2rsa0TDgMG.pgp
Description: PGP signature