[Top][All Lists]

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

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

From: Phil Pennock
Subject: Re: [Sks-devel] sks behind lighttpd reverse proxy
Date: Mon, 2 Dec 2013 16:21:33 -0500

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
    recon_address: 2a02:898:31:0:48:4558:73:6b73
    hkp_address: ::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:

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 \
        --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/1.1 200 OK
    Via: 1.1 (lighttpd)
    Server: sks_www/1.1.4


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

    < HTTP/1.1 200 OK
    < Via: 1.1 (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:`

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.


Attachment: pgp2rsa0TDgMG.pgp
Description: PGP signature

reply via email to

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