Re: [Sks-devel] status page

[Simon Lange]

-----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 fails. then blame the script. otherwise declare exactly what you want to check and what you expect to get. a transparent proxy is still a proxy. the reason why a reverse proxy is "required" is, because some require additional "security" at the nodes. useless to tell, that its not their biz nor their construction site. anyhow, in my case i did provide a reverse proxy, which is listening exactly to that hostname i did provide too as gossip on this mailing list. ;) yesterday i learned i have to give up control who is using his domain with my services. :/

currently for :80 i do accept all for ^(.*)pool.sks-keyservers.net and if kristian or someone else wants to join the server for their pool to id recommend the same kindness as for gossip. tell them explicitly that you want to use their service so give them the chance to add their domain too not requiring allowing the whole world to user their all domains using our services. its a matter of respect AND security. its an optin feature not a optout. this is the same for the reverseproxy (11371). there is absolutely no reason for a via (which may exposes the used software) or a global allow to the whole world to use all existing FQDNs to use that specifiy service. dont allow anyone except fqdn which did ask before is far more secure. (e.g. i dont want any raccist website to advertise with MY services under THEIR domain, but because i cannot KNOW all such domains, its better to deny all and allow a few).

third. never mix technical documentation with ANY advertisement/pr texts just telling how cool how nice how fast how whatssoever the service is. an admin wants techdoc not PR. ;)

this is not a rant, but maybe sounds rude to some. hope i could explain what my point is. i like techdoc which explains the WHOLE process. i hate not having techdoc or incomplete techdoc and getting information waterdrop-wise. thats all.

best regards

Simon
PS: as the status page says its working now. if you want to put my tcp/11371 tcp/80 on your proxy/lb, tell me the fqdn you may use. i put them in. yes, i will disable the allow all setting in the next couple of days again.



Am 18.04.2014 19:50, schrieb Martin Papik:
>
> 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 with two other ways to detect
> a reverse proxy (other than the Via header). Maybe the Via header is
> important for some other part of the protocol I'm not aware of, i.e.
> for the client to detect and report who actually handled the request,
> but here goes.
>
> Method 1, request HEAD for the status page
>     lynx -mime_header -head -source
> 'http://xxxxxxx:11371/pks/lookup?op=stats'
>     A reverse proxy responds with 502 proxy error and lynx returns with
> no error (0), SKS cuts the connection without returning any headers
> (which causes the proxy error), in which case lynx exits with error (1).
>
> Method 2, intrusive, connect to port 11371, request status via a new
> connection and see if it completes.
>
> Method 2 is useless in practice, but method 1 might give additional
> information. Maybe distinguish between a well configured reverse proxy
> and a badly configured reverse proxy.
>
> Martin
>
> On 04/18/2014 02:30 PM, Tobias Frei wrote:
> > 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 17.04.2014 16:20, schrieb Simon Lange (BIT):
> >> well, but there IS a reverse proxy. ;)
> >>
> >> tcp        0      0 78.46.21.218:11371      0.0.0.0:*
> >>  LISTEN      8804/lighttpd tcp        0      0 127.0.0.1:11371
> >> 0.0.0.0:* LISTEN      10018/sks tcp6       0      0
> >> 2a01:4f8:201:22e3:11371 :::* LISTEN      8804/lighttpd
> >>
> >>
> >> Am 2014-04-17 15:56, schrieb Tobias Frei:
> >>> Hi,
> >>>
> >>> from the status page you've linked:
> >>>
> >>> "Latest status: Not OK Reason: Not running a reverse proxy"
> >>>
> >>>
> >>> Best regards, Tobias Frei
> >>>
> >>> Am 17.04.2014 01:13, schrieb Simon Lange:
> >>>> Hi,
> >>>>
> >>>> im a it supprised. i just stumbled over:
> >>>> https://sks-keyservers.net/status/info/keys.s-l-c.biz
> >>>>
> >>>> which says that my keyserver was last seen three days ago. im
> >>>> not enlisted anymore and the status page cannot even say what
> >>>> server im running etc etc
> >>>>
> >>>> im a bit wondered. why? i can reach it via 11370 11371 and
> >>>> 443
> >>>>
> >>>> proof? address@hidden:~$ gpg --keyserver
> >>>> hkp://keys.s-l-c.biz --search-key address@hidden gpg:
> >>>> searching for "address@hidden" from hkp server
> >>>> keys.s-l-c.biz (1)     Simon Lange <address@hidden> 2048
> >>>> bit RSA key BDD503BE, created: 2009-09-04 Keys 1-1 of 1 for
> >>>> "address@hidden".  Enter number(s), N)ext, or Q)uit >
> >>>>
> >>>> works like charme.
> >>>>
> >>>> via browser? see attachment (screenshot). works too. ;)
> >>>>
> >>>> recon works too 2014-04-17 01:12:04 Beginning recon as
> >>>> server, client: <ADDR_INET [162.243.102.241]:59001>
> >>>> 2014-04-17 01:12:04 Joining reconciliation 2014-04-17
> >>>> 01:12:04 Reconciliation complete 2014-04-17 01:12:04 2 hashes
> >>>> recovered from <ADDR_INET [162.243.102.241]:11371> 2014-04-17
> >>>> 01:12:04 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17
> >>>> 01:12:04 1177F736C69004B45FA475ACB149F894 2014-04-17 01:12:04
> >>>> Disabling gossip 2014-04-17 01:12:14 Requesting 2 missing
> >>>> keys from <ADDR_INET [162.243.102.241]:11371>, starting with
> >>>> 02D4107B2181C750E8EE7E18A96FBF61 2014-04-17 01:12:14 2 keys
> >>>> received
> >>>>
> >>>>
> >>>> so why is my server not enlisted anymore? what are the
> >>>> exactly port protocols you are checking?!
> >>>>
> >>>> id like to prevent such a status page although keyserver is
> >>>> still up n running. oO
> >>>>
> >>>> thanks for your help
> >>>>
> >>>> Simon
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________ Sks-devel
> >>>> mailing list address@hidden
> >>>> https://lists.nongnu.org/mailman/listinfo/sks-devel
> >>>>
> >>>
> >>>
> >>> _______________________________________________ Sks-devel
> >>> mailing list address@hidden
> >>> https://lists.nongnu.org/mailman/listinfo/sks-devel
> >>
>
>
>
> > _______________________________________________ Sks-devel mailing
> > list address@hidden
> > https://lists.nongnu.org/mailman/listinfo/sks-devel
>
>
>
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel

- --
________________________________________________________
Simon Lange Consulting  - Gaudystr. 6  - DE-10437 Berlin
Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160
- ----------------------------------------http://s-l-c.biz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 
iQEcBAEBAgAGBQJTUW34AAoJELCfvQa91QO+S5IIAJkOI/if2Re8p3TEkPY3Y04h
x4cdAeqHeZJi/jf4QAvPdhG4iZCzUmDCltr9ikElF+trCHfr1GVczaZ/7h5qqgg3
y6S7TU0wgodk/BxtwNYTKoUFKCUJjhD+IXm48J2ZAk9llFZJ6bz+zhxfb0PNtLar
z11kMC6C27TKr/tKMBxIJ6owwK2+TDunwdTHqV5WFnANuYlt4g9A33wa4gQsFhnx
dyt/gl1Ymp2xkcDJnEoX2CEz+gRFPdjH3blYvoEI7LhmsZ/+lyF7RzSDcvfL1w/F
SFrPNIA05U68ohZIqvG8a2egiO36WxZNoEctebG53kQSyL7OQyQ6CZvGMwjcoBI=
=JqcI
-----END PGP SIGNATURE-----