Hi,
maybe you need to send a correct Via: header to allow automatic
detection of the reverse proxy. If proxying is done completely
transparent, there is probably no way to see that there is actually a
proxy in front of sks. That's what I would assume, at least.
Best regards,
Tobias Frei
Am
Er, sorry, I see you already do that. Then maybe the automatic
detection failed for whatever reason.
And I just noticed that your status changed to OK. Weird^^
Best regards,
Tobias Frei
Am 18.04.2014 13:30, schrieb Tobias Frei:
Hi,
maybe you need to send a correct Via: header to allow
Hi,
On 04/17/2014 04:20 PM, Simon Lange (BIT) wrote:
well, but there IS a reverse proxy. ;)
tcp0 0 78.46.21.218:11371 0.0.0.0:* LISTEN
8804/lighttpd
If I remember right, the monitor checks for a 'VIA' header. See
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I don't know who maintains the monitor, but this email chain prompted
me to have a quick look at the differences between the responses
between a reverse proxy and SKS and I found a few differences and how
to detect a reverse proxy. I've come up
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
after directly communicating with Kristian via twitter i could enlight
the whole situation.
first. the whole process lacks of rudementary technical documentation.
second. if the requirement is a reverse proxy and there is one, but your
script
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/18/2014 09:24 PM, Simon Lange wrote:
yesterday i learned i have to give up control who is using his
domain with my services. :/
Please explain, I'm not aware of such a requirement and if there is
such I would like to know about it so I can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.04.2014 21:18, schrieb Martin Papik:
On 04/18/2014 09:24 PM, Simon Lange wrote:
yesterday i learned i have to give up control who is using his
domain with my services. :/
Please explain, I'm not aware of such a requirement and if there
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/18/2014 10:37 PM, Simon Lange wrote:
Ive been told that it is required to allow ALL incoming traffic to
the IP of my keyserver for port 11371 no matter what hostname is
requested. that would - of course - allow everyone on this planet
to
Hi,
sorry for my naivity, but I can't really think of a scenario where it
would be a problem that your PGP keyserver (and only that one,
keys.s-l-c.biz) is accessible under any other domain name.
If your keyserver is accessible at insert-racist-domain-name-here.tld,
so what? Does that make you a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.04.2014 22:10, schrieb Martin Papik:
Answering ALL host names just makes you willing to participate in any
pool by default, without extra maintenance. But again, AFAIK this
isn't a requirement. Am I misinformed?
im afraid gpg wont show that while using it. ;)
but for the webinterface its valid. ;)
but i see you understand now my problem. ;)
Simon
Am 18.04.2014 22:38, schrieb Tobias Frei:
Hi,
simply add this page is served by keys.s-l-c.biz; I am in no way
affiliated with other hostnames which might
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 04/18/2014 11:42 PM, Simon Lange wrote:
https://twitter.com/krifisk/status/456717051340791808 With a HTTP
Host header not belonging to the specific hostname? Note the -H
'Host.' , 11371 should allow ALL traffic through
Sounds more like a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-04-18 at 20:24 +0200, Simon Lange wrote:
the reason why a reverse proxy is required is, because some
require additional security at the nodes.
False.
The SKS software is single threaded and handles a single request at a
time. One
On 04/18/2014 04:42 PM, Simon Lange wrote:
bad ppl could pretend offering a public service using my machines they
dont own nor they administre nor they run. my machines would support
that passivly. think this is easy to understand. and also has some legal
implications. just imagine feds want
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.04.2014 23:16, schrieb Phil Pennock:
On 2014-04-18 at 20:24 +0200, Simon Lange wrote:
the reason why a reverse proxy is required is, because some
require additional security at the nodes.
False.
ehm. nope. thats is what ive been
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.04.2014 23:39, schrieb Martin Papik:
By the way, Phil's email explains why it's required, and now I
understand why it's a true requirement, at least for servers in the
pool. For non pool servers it doesn't matter.
since i only talked
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 18.04.2014 23:24, schrieb Daniel Kahn Gillmor:
On 04/18/2014 04:42 PM, Simon Lange wrote:
bad ppl could pretend offering a public service using my machines they
dont own nor they administre nor they run. my machines would support
that
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2014-04-19 at 02:21 +0200, Simon Lange wrote:
Am 18.04.2014 23:16, schrieb Phil Pennock:
-Phil
*PLONK*
Could someone please do me a kindness and pass on a message to Mr Lange?
Maintaining a keyserver peering requires the ability to
18 matches
Mail list logo
