Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
Hi, thanks for the information; I have now updated my nginx configuration. :) Best regards, Tobias Frei Am 28.04.2014 18:25, schrieb Kristian Fiskerstrand: I've received reports that uploading some (large) keys to some of the keyservers in the pool (my test shows failure on 30 servers after trying to run against 115: These are listed in [A]) results in a gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large In this case the Content-Length is 1377406, seemingly exceeding the default nginx configuration. The fix for nginx is to set client_max_body_size 2m; (or larger) in the http context of nginx.conf. I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. gpg2 --send-key DE7AAF6E94C09C7F can be used to test. Please consider re-configuring the servers accordingly. [A] non-exhaustive list of servers affected sks.spodhuis.org zimmermann.mayfirst.org vm-keyserver.spline.inf.fu-berlin.de keyserver.mesh.deuxpi.ca sks.fidocon.de keys.exosphere.de keys.sflc.info pgpkeys.mallos.nl keyserver.uz.sns.it openpgp.andrew.kvalhe.im pgp.gmu.edu keyserver.compbiol.bio.tu-darmstadt.de keys2.alderwick.co.uk keys.alderwick.co.uk keyserver.advmapper.com sks.undergrid.net keys.jhcloos.com sks.alpha-labs.net pgpkey.org keys.indymedia.org pgp.freiwuppertal.de keyserver.linuxpro.nl keyserver.secure-u.de sks.stsisp.ro key.ip6.li keys-01.licoho.de key.adeti.org keys-02.licoho.de keyserver.durcheinandertal.ch keyserver.blupill.com -- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 Varitatio delectat Change pleases ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel smime.p7s Description: S/MIME Cryptographic Signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
[Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I've received reports that uploading some (large) keys to some of the keyservers in the pool (my test shows failure on 30 servers after trying to run against 115: These are listed in [A]) results in a gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large In this case the Content-Length is 1377406, seemingly exceeding the default nginx configuration. The fix for nginx is to set client_max_body_size 2m; (or larger) in the http context of nginx.conf. I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. gpg2 --send-key DE7AAF6E94C09C7F can be used to test. Please consider re-configuring the servers accordingly. [A] non-exhaustive list of servers affected sks.spodhuis.org zimmermann.mayfirst.org vm-keyserver.spline.inf.fu-berlin.de keyserver.mesh.deuxpi.ca sks.fidocon.de keys.exosphere.de keys.sflc.info pgpkeys.mallos.nl keyserver.uz.sns.it openpgp.andrew.kvalhe.im pgp.gmu.edu keyserver.compbiol.bio.tu-darmstadt.de keys2.alderwick.co.uk keys.alderwick.co.uk keyserver.advmapper.com sks.undergrid.net keys.jhcloos.com sks.alpha-labs.net pgpkey.org keys.indymedia.org pgp.freiwuppertal.de keyserver.linuxpro.nl keyserver.secure-u.de sks.stsisp.ro key.ip6.li keys-01.licoho.de key.adeti.org keys-02.licoho.de keyserver.durcheinandertal.ch keyserver.blupill.com - -- - Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - Varitatio delectat Change pleases -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTXoEGAAoJEPw7F94F4Tagyc0P/jKRdmXTAajPGdIDemTl0Nhi tCkghQqiwyIyVp0NVSBpE8Ohw8gRN4RiyFkR8T6bMz6Iu3bIEGwgwiYFZvn2dTNr WjucyQJ+Rf3WfQ0Nt0Zuv0hM8Ntm6S3zI5/Lyxd4QmczFPkPLcHI/XRR05bVYFid SdWxUqmQ6v7Mxs0h+pjZi9F11H0KYRra8H610iDdjg8mMdPgnQkUJxoGZ1y00Wsy nAA9UN3ygLzVNwhBkbj90H2VRNgZt3TOiQmXhH7D6qQW4dhVzW8B4EHmjj16fiaY 3mJTErAnzvN3wgizXD3GhZ2uo4h9IGjKFR8i2sGTZQTQP4/yl0AhTwqsOLQ6c82f lfBEvWmXi8OP26cK6INT88sBQOu3CK8cMFVMhDHgu9iTd8fvccwOwNB9iRXwpH8U AFq+NU8qpE19HispdEu0sAZLNuK+HKdwEXxyHvu1Bi/OCC1GMGUnApWYQMNhwK2x NwhCEVwyehzyOa0cJQiKmAMc8PUpXcPsMQO4Oz/XeNXRdAbdCGOJmBP2/VKnT7JY eHTHpECb737P7qhBi6o1dfeGxSf4AhioqoOcxd3dvY/DaU3pPUbV4b2skRtTT5Ux ajcTQHd5ZqtBonbISkX9IKXE+Bt84fzRabT9aT3S7Wb6BtGZq7iTSfcWLB8fOYpg JPYLKIVO3p0i6lh4pMZl =00Kr -END PGP SIGNATURE- ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. My 2 cents: It is not necessary to thest this attribute more than once a week. And servers passing the test need no more examination. Gabor ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
I don't know about the others on the list but my configuration follows the recommendations from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has never stated anything about this issue as long as I've been following it. Do we need to make changes to the documentation that's already out there? As to the key you selected to test with it's no surprising it's a large upload given that it's weasel's old 1024D Debian key with over 3K signatures and one of the strong set keys as he stays high in the WoT. His new 4096R key (62AF4031C82E0039) already have over 1K signatures on it. In that case where do we set a sane upper bound as it will only continue to grow on keys that make it into the strong set with thousands of signatures? On 04/28/2014 12:25 PM, Kristian Fiskerstrand wrote: I've received reports that uploading some (large) keys to some of the keyservers in the pool (my test shows failure on 30 servers after trying to run against 115: These are listed in [A]) results in a gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large In this case the Content-Length is 1377406, seemingly exceeding the default nginx configuration. The fix for nginx is to set client_max_body_size 2m; (or larger) in the http context of nginx.conf. I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. gpg2 --send-key DE7AAF6E94C09C7F can be used to test. Please consider re-configuring the servers accordingly. [A] non-exhaustive list of servers affected sks.spodhuis.org zimmermann.mayfirst.org vm-keyserver.spline.inf.fu-berlin.de keyserver.mesh.deuxpi.ca sks.fidocon.de keys.exosphere.de keys.sflc.info pgpkeys.mallos.nl keyserver.uz.sns.it openpgp.andrew.kvalhe.im pgp.gmu.edu keyserver.compbiol.bio.tu-darmstadt.de keys2.alderwick.co.uk keys.alderwick.co.uk keyserver.advmapper.com sks.undergrid.net keys.jhcloos.com sks.alpha-labs.net pgpkey.org keys.indymedia.org pgp.freiwuppertal.de keyserver.linuxpro.nl keyserver.secure-u.de sks.stsisp.ro key.ip6.li keys-01.licoho.de key.adeti.org keys-02.licoho.de keyserver.durcheinandertal.ch keyserver.blupill.com ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
On 2014-04-28 at 13:32 -0400, Jeremy T. Bouse wrote: I don't know about the others on the list but my configuration follows the recommendations from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has never stated anything about this issue as long as I've been following it. Do we need to make changes to the documentation that's already out there? Speaking as the primary author of that page: It's a wiki page. It is updated as and when we discover new operational issues which affect peering; one of the pieces of advice was also updated with something which affected general usability, despite not being a peering issue, because it's the closest thing we've got to an operational best practices document to cover known issues to beware of. It did affect whether or not the keyserver is fit to be included in pool definitions, as does this new discovery. Bitbucket's wiki controls mean that anyone can edit the page; the docs note that a bitbucket account isn't even needed. As to the key you selected to test with it's no surprising it's a large upload given that it's weasel's old 1024D Debian key with over 3K signatures and one of the strong set keys as he stays high in the WoT. His new 4096R key (62AF4031C82E0039) already have over 1K signatures on it. In that case where do we set a sane upper bound as it will only continue to grow on keys that make it into the strong set with thousands of signatures? There are a couple of issues here. The most severe is that _any_ limit means that someone malicious can block upload of updates of any key they like, simply by adding a large number of signatures to the key. Further, appropriate attribution data might be used to turn this into a steganographic storage pool, provided for free by keyserver operators, so we don't want to make it unlimited. For now, if it's taken 15 years for someone keen on key signings to reach a 1MB limit, then I think that 8MB, covering 120 years of activity at such a rate, is likely to be enough for most normal mortal human beings. It's certainly enough to set as a limit for now, while we hem and haw over whether or not we need to extend HKP to support partial upload concepts and whether we've finally reached the point where there's enough impetus for distributed key blacklists that someone volunteers code for a workable proposal which keyserver operators are willing to use. -Phil pgpp7InjP9TND.pgp Description: PGP signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
On 04/28/2014 02:07 PM, Phil Pennock wrote: For now, if it's taken 15 years for someone keen on key signings to reach a 1MB limit, then I think that 8MB, covering 120 years of activity at such a rate, is likely to be enough for most normal mortal human beings. It's certainly enough to set as a limit for now, I agree with Phil that this number is a reasonable limit for now, but i don't agree with his back-of-the-envelope math. in particular, many of the pre-existing OpenPGP certifications on an older key like weasel's were certifications made by 1024-bit DSA keys. I suspect the certifications made on weasel's new key will likely be made by 4096-bit RSA keys. DSA signatures are (much) smaller than RSA signatures even when of the same key length, and RSA signatures themselves scale with keysize. So i think 8MiB is likely to be fine for today, and we may need to update it sooner rather than later. (hopefully in 5 years from now we will all have started a move to stronger/shorter elliptic curve-based keys, but that transition is likely to take a while) Regards, --dkg signature.asc Description: OpenPGP digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
Dear all, On Mon, Apr 28, 2014 at 06:25:45PM +0200, Kristian Fiskerstrand wrote: I've received reports that uploading some (large) keys to some of the keyservers in the pool (my test shows failure on 30 servers after trying to run against 115: These are listed in [A]) results in a gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large [...] keys2.alderwick.co.uk keys.alderwick.co.uk Good catch, Kristian, and thanks for scanning my servers. I've fixed their config now. On Mon, Apr 28, 2014 at 07:05:00PM +0200, Gabor Kiss wrote: I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. My 2 cents: It is not necessary to thest this attribute more than once a week. And servers passing the test need no more examination. I was wondering if, separately to the automated checks, a script on the wiki would be helpful for new admins to test a server. I could have a bash at it, unless anyone knows of a testing script that already exists. Example output: $ ./sks-lint keys.alderwick.co.uk Testing keys.alderwick.co.uk... [ OK ] SKS version is 1.1.4 [ OK ] 3608500 keys in database [ OK ] lookup via port 80 supported [FAIL] lookup via hkps failed - SSL certificate is invalid - common name is ssl.alderwick.co.uk - see http://example.com/sni [FAIL] large key upload failed - server returned HTTP error 413 - see http://example.com/upload_size Such a script could come with switches for the admin to indicate if they're interested in being in all the pools, some of them, or merely checking that their config doesn't have any obvious flaws. Thanks, Andy signature.asc Description: Digital signature ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413
On Apr 28, 2014 7:36 PM, Jeremy T. Bouse jeremy.bo...@undergrid.net wrote: I don't know about the others on the list but my configuration follows the recommendations from https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has never stated anything about this issue as long as I've been following it. Do we need to make changes to the documentation that's already out there? Yes, we should once we determine an answer to your next question As to the key you selected to test with it's no surprising it's a large upload given that it's weasel's old 1024D Debian key with over 3K signatures and one of the strong set keys as he stays high in the WoT. Yup, Peter was the original source for investigating this issue His new 4096R key (62AF4031C82E0039) already have over 1K signatures on it. In that case where do we set a sane upper bound as it will only continue to grow on keys that make it into the strong set with thousands of signatures? This is indeed THE question, and the answer will potentially vary over time. Atm it needs to be at least 2MiB but an optimal size will require more analysis. On 04/28/2014 12:25 PM, Kristian Fiskerstrand wrote: I've received reports that uploading some (large) keys to some of the keyservers in the pool (my test shows failure on 30 servers after trying to run against 115: These are listed in [A]) results in a gpgkeys: HTTP post error 22: The requested URL returned error: 413 Request Entity Too Large In this case the Content-Length is 1377406, seemingly exceeding the default nginx configuration. The fix for nginx is to set client_max_body_size 2m; (or larger) in the http context of nginx.conf. I have not yet implemented an automated check for this in the pool (and a bit unsure how I'd do it without actually sending large amount of data to the server during the check, something I generally want to avoid), but might run a semi-manual / scripted check and add affected servers to the blacklist if the issue persists after some time. gpg2 --send-key DE7AAF6E94C09C7F can be used to test. Please consider re-configuring the servers accordingly. [A] non-exhaustive list of servers affected sks.spodhuis.org zimmermann.mayfirst.org vm-keyserver.spline.inf.fu-berlin.de keyserver.mesh.deuxpi.ca sks.fidocon.de keys.exosphere.de keys.sflc.info pgpkeys.mallos.nl keyserver.uz.sns.it openpgp.andrew.kvalhe.im pgp.gmu.edu keyserver.compbiol.bio.tu-darmstadt.de keys2.alderwick.co.uk keys.alderwick.co.uk keyserver.advmapper.com sks.undergrid.net keys.jhcloos.com sks.alpha-labs.net pgpkey.org keys.indymedia.org pgp.freiwuppertal.de keyserver.linuxpro.nl keyserver.secure-u.de sks.stsisp.ro key.ip6.li keys-01.licoho.de key.adeti.org keys-02.licoho.de keyserver.durcheinandertal.ch keyserver.blupill.com ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel ___ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
