From Daniel.Heldt at cryptovision.com Fri Feb 7 16:14:21 2014 From: Daniel.Heldt at cryptovision.com (Heldt, Daniel) Date: Fri, 7 Feb 2014 15:14:21 +0000 Subject: [mod_gnutls-devel] PSK support Message-ID: <5B23F33B7CE0FA45B95D6088B9F41E699BAE@daedalus> Dear list, does mod_gnutls enable Apache to make use of the PSK_* cipher-suites, which gnutls supports? I found a hint, that Apache with mod_ssl seems to have some PSK-support (ie some !PSK-specifications, but I did not find a way, how to set up a list of ( identity, psks) -pairs within mod_ssl and or mod_gnutls! Could you give me a hint, if / how this works? And if it does not work, is there a technical reason why it does not trace the corresponding ssl capabilities of gnutls ? Thanks a lot! With kind regards, Daniel heldt From BenBE at geshi.org Wed Feb 12 22:03:14 2014 From: BenBE at geshi.org (Benny Baumann) Date: Wed, 12 Feb 2014 22:03:14 +0100 Subject: [mod_gnutls-devel] [PATCH] Include GnuTLS version as additional version component in Server string Message-ID: <1392238994-2965-1-git-send-email-BenBE@geshi.org> It would be nice if mod_gnutls could add the used (runtime) version of GnuTLS as an additional version component. The below patch will add this information while falling back to using the static version string (plus an indication) if the dynamic version could not be constructed. Regards, BenBE. --- src/gnutls_hooks.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c index 8e9a035..1006b34 100644 --- a/src/gnutls_hooks.c +++ b/src/gnutls_hooks.c @@ -452,6 +452,16 @@ int mgs_hook_post_config(apr_pool_t * p, apr_pool_t * plog, apr_pool_t * ptemp, ap_add_version_component(p, "mod_gnutls/" MOD_GNUTLS_VERSION); + { + char* gnutls_version = apr_psprintf(p, "GnuTLS/%s", gnutls_check_version(NULL)); + if( !gnutls_version ) { + // In case we could not create the above string go for the static version instead + ap_add_version_component(p, "GnuTLS/" GNUTLS_VERSION "-static"); + } else { + ap_add_version_component(p, gnutls_version); + } + } + return OK; } -- 1.8.3.2 From dkg at fifthhorseman.net Thu Feb 13 22:07:06 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 13 Feb 2014 16:07:06 -0500 Subject: [mod_gnutls-devel] [PATCH] Include GnuTLS version as additional version component in Server string In-Reply-To: <1392238994-2965-1-git-send-email-BenBE@geshi.org> References: <1392238994-2965-1-git-send-email-BenBE@geshi.org> Message-ID: <8738jmyb5x.fsf@alice.fifthhorseman.net> On Wed 2014-02-12 16:03:14 -0500, Benny Baumann wrote: > It would be nice if mod_gnutls could add the used (runtime) version of > GnuTLS as an additional version component. > > The below patch will add this information while falling back to using > the static version string (plus an indication) if the dynamic version > could not be constructed. > > Regards, > BenBE. > > --- > src/gnutls_hooks.c | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c > index 8e9a035..1006b34 100644 > --- a/src/gnutls_hooks.c > +++ b/src/gnutls_hooks.c > @@ -452,6 +452,16 @@ int mgs_hook_post_config(apr_pool_t * p, apr_pool_t * plog, apr_pool_t * ptemp, > > ap_add_version_component(p, "mod_gnutls/" MOD_GNUTLS_VERSION); > > + { > + char* gnutls_version = apr_psprintf(p, "GnuTLS/%s", gnutls_check_version(NULL)); > + if( !gnutls_version ) { > + // In case we could not create the above string go for the static version instead > + ap_add_version_component(p, "GnuTLS/" GNUTLS_VERSION "-static"); > + } else { > + ap_add_version_component(p, gnutls_version); > + } > + } > + > return OK; > } > Thanks, this looks good to me. Applied and pushed. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From BenBE at geshi.org Mon Feb 17 08:44:15 2014 From: BenBE at geshi.org (Benny Baumann) Date: Mon, 17 Feb 2014 08:44:15 +0100 Subject: [mod_gnutls-devel] Initial development for OCSP support Message-ID: <5301BDCF.5070901@geshi.org> Hi guys, as some of you might have noticed in the IRC channel I did some work on implementing basic OCSP support in mod_gnutls the last few days and after some trouble I have the first working patches for it. The patches are currently highly experimental as they eat memory, kittens and your mom. DO NOT MERGE upstream. I'll do a rework of the series once all the major issues have been resolved which will have much cleaner patches than the current proof of concept. But anyways it would be nice if you could review and test the current status of the patches which can be found in my Github Repo[1] or checked out from [2] on branch stapling. Please send me your feedback, comments, improvements. Patches in Git Format preferred. Short note on how to activate the new functions: 1. Setup normal VHost with mod_gnutls as usual 2. Set GnuTLSUseStapling on 3. Make sure your certificate file contains at least your leaf (end user certificate) as well as its issuer (in this order). Debug output is logged to error.log on level debug as well as some more critical messages as warnings. Looking forward hearing from you, BenBE. [1] https://github.com/BenBE/mod_gnutls/tree/stapling [2] https://github.com/BenBE/mod_gnutls.git -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From BenBE at geshi.org Tue Feb 18 09:59:26 2014 From: BenBE at geshi.org (Benny Baumann) Date: Tue, 18 Feb 2014 09:59:26 +0100 Subject: [mod_gnutls-devel] Certificates not always exported to environment Message-ID: <530320EE.9070400@geshi.org> Hi, while skimming through the code I noticed a minor bug (which I currently could not yet trigger due to lack of a sufficiently large certificate (and getting such one shouldn't be too hard) which causes mod_gnutls to fail exporting the server and client certificate when the PEM encoding of the certificate is more than 10 KiB. The reason: mod_gnutls uses a static buffer to hold the encoded certificate information and thus will fail to put the encoded certificate into the buffer. What happens: If you supply a certificate large enough to not fit into the buffer (about 7KiB, which should possible to do with a well-crafted 16kRSA key with non-standard exponent) or 40k RSA with standard exponent OR a CA putting LOTS of extensions in you can cause mod_gnutls to skip exporting this certificate to a client process like fcgi. If the client process relies on the certificate to be present it will see that a certificate was supplied (by the means of the ther variables in the environment) but wont see the actual certificate and thus might fail authentication or other functions relying on the presence of the exported certificate. What should happen: Use a dynamic buffer which is allocated using the size returned by the function exporting the certificate so that the buffer is always large enough. Implications: The current buffer is allocated on stack and thus might be an attack vector if the GnuTLS routine used was prone to a buffer overrun. Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From BenBE at geshi.org Tue Feb 18 10:06:09 2014 From: BenBE at geshi.org (Benny Baumann) Date: Tue, 18 Feb 2014 10:06:09 +0100 Subject: [mod_gnutls-devel] Initial development for OCSP support In-Reply-To: <5301BDCF.5070901@geshi.org> References: <5301BDCF.5070901@geshi.org> Message-ID: <53032281.6050505@geshi.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi guys, I found (and fixed locally) one issue regarding OCSP response validation that could be used to supply us with stale responses if they were still valid. The fix I implemented locally ensures that the response we accept into the cache ALWAYS holds the same nonce as we just requested from the server. The fix will be pushed to GitHub later today. This check IS missing in the OCSP client sample of the GnuTLS documentation as it is absolutely NO magic to do but avoids realworld attacks on implementations based on that sample. Regards, BenBE. P.S.: @dkg: Could you forward this request to the GnuTLS people? TIA. Am 17.02.2014 08:44, schrieb Benny Baumann: > Hi guys, > > as some of you might have noticed in the IRC channel I did some work on > implementing basic OCSP support in mod_gnutls the last few days and > after some trouble I have the first working patches for it. > > The patches are currently highly experimental as they eat memory, > kittens and your mom. DO NOT MERGE upstream. I'll do a rework of the > series once all the major issues have been resolved which will have much > cleaner patches than the current proof of concept. > > But anyways it would be nice if you could review and test the current > status of the patches which can be found in my Github Repo[1] or checked > out from [2] on branch stapling. > > Please send me your feedback, comments, improvements. Patches in Git > Format preferred. > > Short note on how to activate the new functions: > 1. Setup normal VHost with mod_gnutls as usual > 2. Set GnuTLSUseStapling on > 3. Make sure your certificate file contains at least your leaf (end user > certificate) as well as its issuer (in this order). > > Debug output is logged to error.log on level debug as well as some more > critical messages as warnings. > > Looking forward hearing from you, > BenBE. > > [1] https://github.com/BenBE/mod_gnutls/tree/stapling > [2] https://github.com/BenBE/mod_gnutls.git > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQIcBAEBCgAGBQJTAyJ/AAoJEPHTXLno4S6tADsQAMawqdB49JdEW4kP5ABQ3Ws7 SCZ/0WoB8qZWHJiKCpc1PQhjNFI3sscr5AaSb7Xk1O94pbzgqC+nw2/owTEzNvsw Mv5YqJHITyOP7z2zXl5dtWFwMY0rr976QKEsSlbOU6QQ7+UUKdubOAY8LwDleWX8 QLf6Bg423nKReir3HmoPNarLHiciQwQ+PlVuZSz8W2kHfUDIZM+8fOSh1IMkc/7E Mc+cYgFfEIs32+t19khrM4/2eNYiDpsaIT/pujzjT4usEVXhdmnvvMBN8UeByvwE owg2pebeov4ie0/JDvdubbEm3E1SKwIPCybhfUipgrYwxo55Q92KxsHqyWESjdI3 BjfbufZRDXz2Nr12F0qGwFlu0EDOStEJWLWVoy4jb5rm3rFBzLrraqmX0D/FK44w hozIbNLQ9vmiA94f2+/H7GuqU26JZXDijdqxhShYyLvIufYZBccFutkOJQKpabU5 v6r2I8myT/W6Nwes+Z5kPvgJOGuyw9COzLaSsDOIK+qUD6tiPajf4UUR1x0nvFnd OsiV9Lc4WrWCUfo+sxj/NbBUSC2ww3j0dVMiCUD4/1q2B1s+IthBRZ6+i/dQCYi7 4eGnQ8+qIyzSmZ2ln5R7KP0yhfLhndIhGLAmdo04Tl7JA0jCHuPYWIdRgh6f0O80 hdN3iIGmAMa/rOn5Jcpy =MqyM -----END PGP SIGNATURE----- From nmav at gnutls.org Tue Feb 18 15:58:33 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 18 Feb 2014 15:58:33 +0100 Subject: [mod_gnutls-devel] Initial development for OCSP support In-Reply-To: <53032281.6050505@geshi.org> References: <5301BDCF.5070901@geshi.org> <53032281.6050505@geshi.org> Message-ID: On Tue, Feb 18, 2014 at 10:06 AM, Benny Baumann wrote: > Hi guys, > I found (and fixed locally) one issue regarding OCSP response validation > that could be used to supply us with stale responses if they were still > valid. The fix I implemented locally ensures that the response we accept > into the cache ALWAYS holds the same nonce as we just requested from the > server. > This check IS missing in the OCSP client sample of the GnuTLS > documentation as it is absolutely NO magic to do but avoids realworld > attacks on implementations based on that sample. > P.S.: @dkg: Could you forward this request to the GnuTLS people? TIA. Thanks, I saw it and I'll update the documentation. regards, Nikos From BenBE at geshi.org Thu Feb 20 09:28:13 2014 From: BenBE at geshi.org (Benny Baumann) Date: Thu, 20 Feb 2014 09:28:13 +0100 Subject: [mod_gnutls-devel] [PATCH] Make Apache 2.4 display the correct module in error logs Message-ID: <1392884893-28237-1-git-send-email-BenBE@geshi.org> --- src/gnutls_cache.c | 4 ++++ src/gnutls_config.c | 4 ++++ src/gnutls_hooks.c | 4 ++++ src/gnutls_io.c | 4 ++++ 4 files changed, 16 insertions(+) diff --git a/src/gnutls_cache.c b/src/gnutls_cache.c index ca88c36..7b5f538 100644 --- a/src/gnutls_cache.c +++ b/src/gnutls_cache.c @@ -44,6 +44,10 @@ #define ap_unixd_config unixd_config #endif +#ifdef APLOG_USE_MODULE +APLOG_USE_MODULE(gnutls); +#endif + char *mgs_session_id2sz(unsigned char *id, int idlen, char *str, int strsize) { char *cp; diff --git a/src/gnutls_config.c b/src/gnutls_config.c index ddcf1aa..bff6b4c 100644 --- a/src/gnutls_config.c +++ b/src/gnutls_config.c @@ -19,6 +19,10 @@ #include "mod_gnutls.h" +#ifdef APLOG_USE_MODULE +APLOG_USE_MODULE(gnutls); +#endif + static int load_datum_from_file(apr_pool_t * pool, const char *file, gnutls_datum_t * data) { apr_file_t *fp; diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c index 1006b34..69f156d 100644 --- a/src/gnutls_hooks.c +++ b/src/gnutls_hooks.c @@ -26,6 +26,10 @@ #include #endif +#ifdef APLOG_USE_MODULE +APLOG_USE_MODULE(gnutls); +#endif + #if !USING_2_1_RECENT extern server_rec *ap_server_conf; #endif diff --git a/src/gnutls_io.c b/src/gnutls_io.c index 67e8733..02d2e77 100644 --- a/src/gnutls_io.c +++ b/src/gnutls_io.c @@ -19,6 +19,10 @@ #include "mod_gnutls.h" +#ifdef APLOG_USE_MODULE +APLOG_USE_MODULE(gnutls); +#endif + /** * Describe how the GnuTLS Filter system works here * - Basicly the same as what mod_ssl does with OpenSSL. -- 1.8.3.2 From dkg at fifthhorseman.net Thu Feb 20 17:22:39 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Feb 2014 11:22:39 -0500 Subject: [mod_gnutls-devel] [PATCH] Make Apache 2.4 display the correct module in error logs In-Reply-To: <1392884893-28237-1-git-send-email-BenBE@geshi.org> References: <1392884893-28237-1-git-send-email-BenBE@geshi.org> Message-ID: <8761o9wy7k.fsf@alice.fifthhorseman.net> On Thu 2014-02-20 03:28:13 -0500, Benny Baumann wrote: > --- > src/gnutls_cache.c | 4 ++++ > src/gnutls_config.c | 4 ++++ > src/gnutls_hooks.c | 4 ++++ > src/gnutls_io.c | 4 ++++ > 4 files changed, 16 insertions(+) thanks, applied. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Thu Feb 20 17:26:39 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 20 Feb 2014 11:26:39 -0500 Subject: [mod_gnutls-devel] 0.6 released Message-ID: <8738jdwy0w.fsf@alice.fifthhorseman.net> hi folks-- I tagged mod_gnutls 0.6 a little while ago, but haven't gotten around to some of the bookkeeping work that i'd like to do to make it more visible on the project web site. Hopefully i can streamline the release process so it's possible for the project to "release early, release often". I plan on trying to kick the debian packaging into shape as well over the next couple days, and will be reviewing the patches Benny Baumann has pushed already in the hopes of making a 0.7 release sooner rather than later. You can find the mod_gnutls/0.6 tag at the usual git repo (https://mod.gnutls.org/git/mod_gnutls), or you can fetch a tarball made From that tag at https://mod.gnutls.org/downloads/ --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From dkg at fifthhorseman.net Fri Feb 21 08:54:49 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Feb 2014 02:54:49 -0500 Subject: [mod_gnutls-devel] 0.6 released In-Reply-To: References: <8738jdwy0w.fsf@alice.fifthhorseman.net> Message-ID: <53070649.9040002@fifthhorseman.net> On 02/21/2014 02:48 AM, mort pheus wrote: > what about bz2 xz archives? :) For what purpose? The tarball is quite small already at < 70KiB, and we know that everyone has gzip. If this were a huge project, i'm happy to use a stronger compression mechanism, but it doesn't seem neecessary right now, afaict. Do you know of downstream projects that use .xz or .bz2 that can't use .gz? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Feb 21 11:35:53 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Feb 2014 05:35:53 -0500 Subject: [mod_gnutls-devel] Certificates not always exported to environment In-Reply-To: <530320EE.9070400@geshi.org> References: <530320EE.9070400@geshi.org> Message-ID: <53072C09.8030907@fifthhorseman.net> Hi Benny-- On 02/18/2014 03:59 AM, Benny Baumann wrote: > while skimming through the code I noticed a minor bug (which I currently > could not yet trigger due to lack of a sufficiently large certificate > (and getting such one shouldn't be too hard) which causes mod_gnutls to > fail exporting the server and client certificate when the PEM encoding > of the certificate is more than 10 KiB. hm, i see the concern. thanks for bringing this up. > What happens: If you supply a certificate large enough to not fit into > the buffer (about 7KiB, which should possible to do with a well-crafted > 16kRSA key with non-standard exponent) or 40k RSA with standard exponent > OR a CA putting LOTS of extensions in you can cause mod_gnutls to skip > exporting this certificate to a client process like fcgi. If the client > process relies on the certificate to be present it will see that a > certificate was supplied (by the means of the ther variables in the > environment) but wont see the actual certificate and thus might fail > authentication or other functions relying on the presence of the > exported certificate. fwiw, the buffer is 10KiB, which is quite a lot: char cert_buf[10 * 1024]; 16Kib RSA keys are quite large and expensive to use. There is a point of diminishing returns with RSA: as the keys get larger, the resistance to an attacker doesn't scale proportionally. Note that a 16Kib RSA public key itself (regardless of the certificate around it) takes up 2KiB, which doesn't even fit in a normal TCP packet (the typical MTU is ~1.5KB). And the key signature (for DHE key exchanges) or encrypted premaster secret (for RSA-style key exchanges) will be just as large as the key itself; so we're talking at least several packets just to transmit these parts of the handshake. if the CA that issued the cert also uses a 16Kibit key, then the cert size doubles (because a cert contains both a pubkey and a signature), and then the intermediate CA's cert itself is a contributing large factor. So the handshakes here could get very very large. as another point of reference: using GnuTLS's certtool, the configuration "--sec-param ULTRA" only generates 15Kib keys. > What should happen: Use a dynamic buffer which is allocated using the > size returned by the function exporting the certificate so that the > buffer is always large enough. I don't think we want to allow a client with an arbitrary-sized certificate to exhaust the RAM of the server. There needs to be a limit somewhere based on reasonable criteria. What do you think the limit should be? > Implications: The current buffer is allocated on stack and thus might be > an attack vector if the GnuTLS routine used was prone to a buffer overrun. Overrunning a dynamic buffer on the heap is also potentially an issue (though i grant that stack smashing has a richer history); we need to rely on GnuTLS to not overrun a buffer if we tell it the size of the buffer, i think. All that said, I'm open to concrete suggestions that don't open the module to a RAM exhaustion attack; arbitrarily dropping a 10KiB buffer on the stack definitely seems a little weird. What do you think? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From BenBE at geshi.org Fri Feb 21 17:58:57 2014 From: BenBE at geshi.org (Benny Baumann) Date: Fri, 21 Feb 2014 17:58:57 +0100 Subject: [mod_gnutls-devel] Certificates not always exported to environment In-Reply-To: <53072C09.8030907@fifthhorseman.net> References: <530320EE.9070400@geshi.org> <53072C09.8030907@fifthhorseman.net> Message-ID: <530785D1.1030608@geshi.org> Hi Daniel, Am 21.02.2014 11:35, schrieb Daniel Kahn Gillmor: > Hi Benny-- > > On 02/18/2014 03:59 AM, Benny Baumann wrote: > >> while skimming through the code I noticed a minor bug (which I currently >> could not yet trigger due to lack of a sufficiently large certificate >> (and getting such one shouldn't be too hard) which causes mod_gnutls to >> fail exporting the server and client certificate when the PEM encoding >> of the certificate is more than 10 KiB. > hm, i see the concern. thanks for bringing this up. I somehow have a hand to find such limits in software. >> What happens: If you supply a certificate large enough to not fit into >> the buffer (about 7KiB, which should possible to do with a well-crafted >> 16kRSA key with non-standard exponent) or 40k RSA with standard exponent >> OR a CA putting LOTS of extensions in you can cause mod_gnutls to skip >> exporting this certificate to a client process like fcgi. If the client >> process relies on the certificate to be present it will see that a >> certificate was supplied (by the means of the ther variables in the >> environment) but wont see the actual certificate and thus might fail >> authentication or other functions relying on the presence of the >> exported certificate. > fwiw, the buffer is 10KiB, which is quite a lot: > > char cert_buf[10 * 1024]; > > 16Kib RSA keys are quite large and expensive to use. There is a point > of diminishing returns with RSA: as the keys get larger, the resistance > to an attacker doesn't scale proportionally. Note that a 16Kib RSA > public key itself (regardless of the certificate around it) takes up > 2KiB, which doesn't even fit in a normal TCP packet (the typical MTU is > ~1.5KB). And the key signature (for DHE key exchanges) or encrypted > premaster secret (for RSA-style key exchanges) will be just as large as > the key itself; so we're talking at least several packets just to > transmit these parts of the handshake. if the CA that issued the cert > also uses a 16Kibit key, then the cert size doubles (because a cert > contains both a pubkey and a signature), and then the intermediate CA's > cert itself is a contributing large factor. So the handshakes here > could get very very large. > > as another point of reference: using GnuTLS's certtool, the > configuration "--sec-param ULTRA" only generates 15Kib keys. I'm currently using 8K RSA keys which equals a handshake footprint of about 7.5 KiB without and 9.5KiB with OCSP stapling (server to client). The client in both cases gives another 0.5 to 1KiB - although here the number of packets is more interesting. >> What should happen: Use a dynamic buffer which is allocated using the >> size returned by the function exporting the certificate so that the >> buffer is always large enough. > I don't think we want to allow a client with an arbitrary-sized > certificate to exhaust the RAM of the server. There needs to be a limit > somewhere based on reasonable criteria. What do you think the limit > should be? What about allowing the admin to choose but defaulting to 64KiB on the server if not set. Furthermore you should be aware that by the time you ask to export the certificate you already have it loaded by GnuTLS in memory. Therefore resulting in a "memory usage amplification attack" with factor ~2.4 which requires the client to send you megabytes of data beforehand. I'm not sure of the record structure of TLS regarding the Client and Server Hello frames, but IIRC they might be limited in size - and thus probably mitigating the attack forreally big certificates. >> Implications: The current buffer is allocated on stack and thus might be >> an attack vector if the GnuTLS routine used was prone to a buffer overrun. > Overrunning a dynamic buffer on the heap is also potentially an issue > (though i grant that stack smashing has a richer history); we need to > rely on GnuTLS to not overrun a buffer if we tell it the size of the > buffer, i think. Granted. And if we really wouldn't trust the underlaying implementation we still could create red-zones in the allocated buffer. > > All that said, I'm open to concrete suggestions that don't open the > module to a RAM exhaustion attack; arbitrarily dropping a 10KiB buffer > on the stack definitely seems a little weird. > > What do you think? Suggestion: Ask for required size for export, check against (per-vhost) setting for the maximum exportable size, allocate a buffer large enough to hold the exported value and export a value indicating size restriction violation otherwise. That way all the initially raised concerns should be properly addressed. > > --dkg > BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Fri Feb 21 20:09:54 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 21 Feb 2014 14:09:54 -0500 Subject: [mod_gnutls-devel] Certificates not always exported to environment In-Reply-To: <530785D1.1030608@geshi.org> References: <530320EE.9070400@geshi.org> <53072C09.8030907@fifthhorseman.net> <530785D1.1030608@geshi.org> Message-ID: <5307A482.6030504@fifthhorseman.net> On 02/21/2014 11:58 AM, Benny Baumann wrote: > I'm currently using 8K RSA keys which equals a handshake footprint of > about 7.5 KiB without and 9.5KiB with OCSP stapling (server to client). > The client in both cases gives another 0.5 to 1KiB - although here the > number of packets is more interesting. yep, that's a lot of data to push back and forth. You'll get into more significant delays as the number of packets exceeds the TCP congestion window since it incurs more round-trips. latency is probably more of an issue than bandwidth in many cases, since bandwidth is getting larger, but the speed of light has stayed pretty much the same, :P > What about allowing the admin to choose but defaulting to 64KiB on the > server if not set. I think this is reasonable. My proposal is to change the config directive GnuTLSExportCertificates. currently this directive takes either "off" or "on". I propose to add a third option, which would be a number of kibibytes (or just bytes? not sure which would be preferable, but i tend to think that kibibyte granularity is roughly the right scale to be thinking of this). So "off" would mean "no certificates exported", "on" would mean certificates exported to a maximum of 16 KiB each, and N would mean certificates exported to a maximum of N KiB each. I think 64KiB is unreasonably high for a default because of the cost in terms of round-trips for such a series of connections, but i'm willing to support it for admins who require it and want to change the setting. In the event that a certificate is not exported, we can also expose that to the CGI process explicitly (by setting the environment variable to a fixed string like "GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED"), in addition to logging the error as we currently do. > Furthermore you should be aware that by the time you ask to export the > certificate you already have it loaded by GnuTLS in memory. Therefore > resulting in a "memory usage amplification attack" with factor ~2.4 > which requires the client to send you megabytes of data beforehand. I'm > not sure of the record structure of TLS regarding the Client and Server > Hello frames, but IIRC they might be limited in size - and thus probably > mitigating the attack forreally big certificates. right, there does need to be mitigation earlier in general; but we shouldn't allow the memory amplification by default anyway. > Suggestion: Ask for required size for export, check against (per-vhost) > setting for the maximum exportable size, allocate a buffer large enough > to hold the exported value and export a value indicating size > restriction violation otherwise. That way all the initially raised > concerns should be properly addressed. I think what i've proposed above aligns with your suggestion. Does it meet your concerns? i'll try to get the test suite fleshed out to cover these cases too. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From BenBE at geshi.org Sat Feb 22 15:55:40 2014 From: BenBE at geshi.org (Benny Baumann) Date: Sat, 22 Feb 2014 15:55:40 +0100 Subject: [mod_gnutls-devel] Certificates not always exported to environment In-Reply-To: <5307A482.6030504@fifthhorseman.net> References: <530320EE.9070400@geshi.org> <53072C09.8030907@fifthhorseman.net> <530785D1.1030608@geshi.org> <5307A482.6030504@fifthhorseman.net> Message-ID: <5308BA6C.6000308@geshi.org> Hi, Am 21.02.2014 20:09, schrieb Daniel Kahn Gillmor: > On 02/21/2014 11:58 AM, Benny Baumann wrote: >> I'm currently using 8K RSA keys which equals a handshake footprint of >> about 7.5 KiB without and 9.5KiB with OCSP stapling (server to client). >> The client in both cases gives another 0.5 to 1KiB - although here the >> number of packets is more interesting. > yep, that's a lot of data to push back and forth. You'll get into more > significant delays as the number of packets exceeds the TCP congestion > window since it incurs more round-trips. latency is probably more of an > issue than bandwidth in many cases, since bandwidth is getting larger, > but the speed of light has stayed pretty much the same, :P That's too unfortunate. Couldn't we just invent faster light? >> What about allowing the admin to choose but defaulting to 64KiB on the >> server if not set. > I think this is reasonable. My proposal is to change the config > directive GnuTLSExportCertificates. > > currently this directive takes either "off" or "on". I propose to add a > third option, which would be a number of kibibytes (or just bytes? not > sure which would be preferable, but i tend to think that kibibyte > granularity is roughly the right scale to be thinking of this). > > So "off" would mean "no certificates exported", "on" would mean > certificates exported to a maximum of 16 KiB each, and N would mean > certificates exported to a maximum of N KiB each. I think 64KiB is > unreasonably high for a default because of the cost in terms of > round-trips for such a series of connections, but i'm willing to support > it for admins who require it and want to change the setting. What's the default unit for Apache settings to specify sizes in? IIRC most settings are given in bytes. If this isn't too hard to implement I'd go for this. But given the maximum amount as a number and treating on using a default sounds fine to me. 16KiB looks fine too. > > In the event that a certificate is not exported, we can also expose that > to the CGI process explicitly (by setting the environment variable to a > fixed string like "GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED"), in addition > to logging the error as we currently do. Seems fine to me. >> Furthermore you should be aware that by the time you ask to export the >> certificate you already have it loaded by GnuTLS in memory. Therefore >> resulting in a "memory usage amplification attack" with factor ~2.4 >> which requires the client to send you megabytes of data beforehand. I'm >> not sure of the record structure of TLS regarding the Client and Server >> Hello frames, but IIRC they might be limited in size - and thus probably >> mitigating the attack forreally big certificates. > right, there does need to be mitigation earlier in general; but we > shouldn't allow the memory amplification by default anyway. Ack. >> Suggestion: Ask for required size for export, check against (per-vhost) >> setting for the maximum exportable size, allocate a buffer large enough >> to hold the exported value and export a value indicating size >> restriction violation otherwise. That way all the initially raised >> concerns should be properly addressed. > I think what i've proposed above aligns with your suggestion. Does it > meet your concerns? i'll try to get the test suite fleshed out to cover > these cases too. > > --dkg > Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Sun Feb 23 19:15:22 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 23 Feb 2014 13:15:22 -0500 Subject: [mod_gnutls-devel] [PATCH 1/2] GnuTLSExportCertificates should control maximum size of exported certs In-Reply-To: <5307A482.6030504@fifthhorseman.net> References: <5307A482.6030504@fifthhorseman.net> Message-ID: <1393179323-10830-1-git-send-email-dkg@fifthhorseman.net> The server administrator should be able to control the maximum size of the exported certificate environment variables. This will be done via the existing GnuTLSExportCertificates environment variable. This patch adds documentation of intended new feature and a test for support. The test currently fails because the feature is not implemented. --- docs/mod_gnutls_manual.mdwn | 31 +++++++++++++++++++++----- t/tests/17_cgi_vars_large_cert/apache.conf | 22 ++++++++++++++++++ t/tests/17_cgi_vars_large_cert/gnutls-cli.args | 4 ++++ t/tests/17_cgi_vars_large_cert/input | 3 +++ t/tests/17_cgi_vars_large_cert/output | 14 ++++++++++++ 5 files changed, 68 insertions(+), 6 deletions(-) create mode 100644 t/tests/17_cgi_vars_large_cert/apache.conf create mode 100644 t/tests/17_cgi_vars_large_cert/gnutls-cli.args create mode 100644 t/tests/17_cgi_vars_large_cert/input create mode 100644 t/tests/17_cgi_vars_large_cert/output diff --git a/docs/mod_gnutls_manual.mdwn b/docs/mod_gnutls_manual.mdwn index eecf5b1..4c333df 100644 --- a/docs/mod_gnutls_manual.mdwn +++ b/docs/mod_gnutls_manual.mdwn @@ -372,14 +372,26 @@ achieve maximum compatibility (some broken mobile clients need this). Export the PEM encoded certificates to CGIs - GnuTLSExportCertificates [on|off] + GnuTLSExportCertificates [off|on|SIZE] Default: `off`\ Context: server config, virtual host -This directive enables exporting the full certificates of the server and -the client to CGI scripts. The exported certificates will be PEM-encoded -(if X.509) or ASCII-armored (if OpenPGP). +This directive configures exporting the full certificates of the +server and the client to CGI scripts via the `SSL_SERVER_CERT` and +`SSL_CLIENT_CERT` environment variables. The exported certificates +will be PEM-encoded (if X.509) or ASCII-armored (if OpenPGP) up to the +size given. The type of the certificate will be exported in +`SSL_SERVER_CERT_TYPE` and `SSL_CLIENT_CERT_TYPE`. + +SIZE should be an integer number of bytes, or may be written with a +trailing `K` to indicate kibibytes. `off` means the same thing as +`0`, in which case the certificates will not be exported to the +environment. `on` is an alias for `16K`. If a non-zero size is +specified for this directive, but a certificate is too large to fit in +the buffer, then the corresponding environment variable will contain +the fixed string `GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED`. + With GnuTLSExportCertificates enabled, `mod_gnutls` exports the same environment variables to the CGI process as `mod_ssl`. @@ -670,16 +682,23 @@ The algorithm used for the signature in server's certificate. The public key algorithm in server's certificate. -`SSL_SERVER1_CERT` +`SSL_SERVER_CERT` ------------------ -The PEM-encoded server certificate. +The PEM-encoded (X.509) or ASCII-armored (OpenPGP) server certificate +(see the `GnuTLSExportCertificates` directive). `SSL_SERVER_CERT_TYPE` ---------------------- The certificate type can be `X.509` or `OPENPGP`. +`SSL_CLIENT_CERT` +------------------ + +The PEM-encoded (X.509) or ASCII-armored (OpenPGP) client certificate +(see the `GnuTLSExportCertificates` directive). + `SSL_CLIENT_CERT_TYPE` ---------------------- diff --git a/t/tests/17_cgi_vars_large_cert/apache.conf b/t/tests/17_cgi_vars_large_cert/apache.conf new file mode 100644 index 0000000..d4cfd2b --- /dev/null +++ b/t/tests/17_cgi_vars_large_cert/apache.conf @@ -0,0 +1,22 @@ +Include ${PWD}/../../base_apache.conf + +LoadModule cgi_module /usr/lib/apache2/modules/mod_cgi.so + +AddHandler cgi-script .cgi + +GnuTLSCache dbm cache/gnutls_cache + + + Options +ExecCGI + + + + ServerName ${TEST_HOST} + GnuTLSEnable On + GnuTLSCertificateFile server/x509.pem + GnuTLSKeyFile server/secret.key + GnuTLSPriorities NORMAL + GnuTLSClientCAFile authority/x509.pem + GnuTLSClientVerify request + GnuTLSExportCertificates 512 + diff --git a/t/tests/17_cgi_vars_large_cert/gnutls-cli.args b/t/tests/17_cgi_vars_large_cert/gnutls-cli.args new file mode 100644 index 0000000..ce71607 --- /dev/null +++ b/t/tests/17_cgi_vars_large_cert/gnutls-cli.args @@ -0,0 +1,4 @@ +--x509certfile=../../client/x509.pem +--x509keyfile=../../client/secret.key +--x509cafile=../../authority/x509.pem +--priority=NORMAL:-KX-ALL:+DHE-RSA diff --git a/t/tests/17_cgi_vars_large_cert/input b/t/tests/17_cgi_vars_large_cert/input new file mode 100644 index 0000000..623c4ef --- /dev/null +++ b/t/tests/17_cgi_vars_large_cert/input @@ -0,0 +1,3 @@ +GET /dump.cgi HTTP/1.1 +Host: __HOSTNAME__ + diff --git a/t/tests/17_cgi_vars_large_cert/output b/t/tests/17_cgi_vars_large_cert/output new file mode 100644 index 0000000..e4cf184 --- /dev/null +++ b/t/tests/17_cgi_vars_large_cert/output @@ -0,0 +1,14 @@ +----Certificate:---- +GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED + +----Verification Status:---- +SUCCESS + +----SubjectAltName:---- +RFC822NAME:test0 at modgnutls.test + +DH prime bits: 2048 + +0 + +- Peer has closed the GnuTLS connection -- 1.8.5.3 From dkg at fifthhorseman.net Sun Feb 23 19:15:23 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 23 Feb 2014 13:15:23 -0500 Subject: [mod_gnutls-devel] [PATCH 2/2] implement GnuTLSExportCertificates control over max exported cert size In-Reply-To: <1393179323-10830-1-git-send-email-dkg@fifthhorseman.net> References: <5307A482.6030504@fifthhorseman.net> <1393179323-10830-1-git-send-email-dkg@fifthhorseman.net> Message-ID: <1393179323-10830-2-git-send-email-dkg@fifthhorseman.net> This patchset implements the proposed modification to GnuTLSExportCertificates, allowing server administrators to choose the maximum size of the exported certs. Some advantages: * avoids large buffers on the stack * more configurable for server admins who expect to use larger certs * better visibilty for users when a too-large-cert is encountered This also increases the default maximum exported size from 10KiB to 16KiB. --- include/mod_gnutls.h.in | 4 +-- src/gnutls_config.c | 23 ++++++++---- src/gnutls_hooks.c | 94 +++++++++++++++++++++++++++++++------------------ src/mod_gnutls.c | 4 +-- 4 files changed, 80 insertions(+), 45 deletions(-) diff --git a/include/mod_gnutls.h.in b/include/mod_gnutls.h.in index 57aa52e..8aa4162 100644 --- a/include/mod_gnutls.h.in +++ b/include/mod_gnutls.h.in @@ -126,7 +126,7 @@ typedef struct { /* Is the module enabled? */ int enabled; /* Export full certificates to CGI environment: */ - int export_certificates_enabled; + int export_certificates_size; /* GnuTLS Priorities */ gnutls_priority_t priorities; /* GnuTLS DH Parameters */ @@ -359,7 +359,7 @@ const char *mgs_set_keyring_file(cmd_parms * parms, void *dummy, const char *mgs_set_enabled(cmd_parms * parms, void *dummy, const char *arg); -const char *mgs_set_export_certificates_enabled(cmd_parms * parms, void *dummy, +const char *mgs_set_export_certificates_size(cmd_parms * parms, void *dummy, const char *arg); const char *mgs_set_priorities(cmd_parms * parms, void *dummy, const char *arg); diff --git a/src/gnutls_config.c b/src/gnutls_config.c index bff6b4c..3300854 100644 --- a/src/gnutls_config.c +++ b/src/gnutls_config.c @@ -18,6 +18,7 @@ */ #include "mod_gnutls.h" +#include "apr_lib.h" #ifdef APLOG_USE_MODULE APLOG_USE_MODULE(gnutls); @@ -553,15 +554,23 @@ const char *mgs_set_enabled(cmd_parms * parms, void *dummy, return NULL; } -const char *mgs_set_export_certificates_enabled(cmd_parms * parms, void *dummy, const char *arg) { +const char *mgs_set_export_certificates_size(cmd_parms * parms, void *dummy, const char *arg) { mgs_srvconf_rec *sc = (mgs_srvconf_rec *) ap_get_module_config(parms->server->module_config, &gnutls_module); if (!strcasecmp(arg, "On")) { - sc->export_certificates_enabled = GNUTLS_ENABLED_TRUE; + sc->export_certificates_size = 16 * 1024; } else if (!strcasecmp(arg, "Off")) { - sc->export_certificates_enabled = GNUTLS_ENABLED_FALSE; + sc->export_certificates_size = 0; } else { - return - "GnuTLSExportCertificates must be set to 'On' or 'Off'"; + char* endptr; + sc->export_certificates_size = strtol(arg, &endptr, 10); + while (apr_isspace(*endptr)) endptr++; + if (*endptr == '\0' || *endptr == 'b' || *endptr == 'B') { + ; + } else if (*endptr == 'k' || *endptr == 'K') { + sc->export_certificates_size *= 1024; + } else { + return "GnuTLSExportCertificates must be set to a size (in bytes) or 'On' or 'Off'"; + } } return NULL; @@ -637,7 +646,7 @@ static mgs_srvconf_rec *_mgs_config_server_create(apr_pool_t * p, char** err) { sc->priorities = NULL; sc->dh_params = NULL; sc->proxy_enabled = GNUTLS_ENABLED_UNSET; - sc->export_certificates_enabled = GNUTLS_ENABLED_UNSET; + sc->export_certificates_size = -1; sc->client_verify_method = mgs_cvm_unset; /* this relies on GnuTLS never changing the gnutls_certificate_request_t enum to define -1 */ @@ -666,7 +675,7 @@ void *mgs_config_server_merge(apr_pool_t *p, void *BASE, void *ADD) { gnutls_srvconf_merge(enabled, GNUTLS_ENABLED_UNSET); gnutls_srvconf_merge(tickets, GNUTLS_ENABLED_UNSET); gnutls_srvconf_merge(proxy_enabled, GNUTLS_ENABLED_UNSET); - gnutls_srvconf_merge(export_certificates_enabled, GNUTLS_ENABLED_UNSET); + gnutls_srvconf_merge(export_certificates_size, -1); gnutls_srvconf_merge(client_verify_method, mgs_cvm_unset); gnutls_srvconf_merge(client_verify_mode, -1); gnutls_srvconf_merge(srp_tpasswd_file, NULL); diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c index aee7b86..6f15f28 100644 --- a/src/gnutls_hooks.c +++ b/src/gnutls_hooks.c @@ -42,8 +42,8 @@ static gnutls_datum_t session_ticket_key = {NULL, 0}; static int mgs_cert_verify(request_rec * r, mgs_handle_t * ctxt); /* use side==0 for server and side==1 for client */ -static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, int side, int export_full_cert); -static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t cert, int side, int export_full_cert); +static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, int side, int export_cert_size); +static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t cert, int side, int export_cert_size); static const char* mgs_x509_construct_uid(request_rec * pool, gnutls_x509_crt_t cert); static int mgs_status_hook(request_rec *r, int flags); @@ -372,8 +372,8 @@ int mgs_hook_post_config(apr_pool_t * p, apr_pool_t * plog, apr_pool_t * ptemp, sc->enabled = GNUTLS_ENABLED_FALSE; if (sc->tickets == GNUTLS_ENABLED_UNSET) sc->tickets = GNUTLS_ENABLED_TRUE; - if (sc->export_certificates_enabled == GNUTLS_ENABLED_UNSET) - sc->export_certificates_enabled = GNUTLS_ENABLED_FALSE; + if (sc->export_certificates_size < 0) + sc->export_certificates_size = 0; if (sc->client_verify_mode == -1) sc->client_verify_mode = GNUTLS_CERT_IGNORE; if (sc->client_verify_method == mgs_cvm_unset) @@ -817,9 +817,9 @@ int mgs_hook_fixups(request_rec * r) { apr_table_setn(env, "SSL_SESSION_ID", apr_pstrdup(r->pool, tmp)); if (gnutls_certificate_type_get(ctxt->session) == GNUTLS_CRT_X509) { - mgs_add_common_cert_vars(r, ctxt->sc->certs_x509_chain[0], 0, ctxt->sc->export_certificates_enabled); + mgs_add_common_cert_vars(r, ctxt->sc->certs_x509_chain[0], 0, ctxt->sc->export_certificates_size); } else if (gnutls_certificate_type_get(ctxt->session) == GNUTLS_CRT_OPENPGP) { - mgs_add_common_pgpcert_vars(r, ctxt->sc->cert_pgp, 0, ctxt->sc->export_certificates_enabled); + mgs_add_common_pgpcert_vars(r, ctxt->sc->cert_pgp, 0, ctxt->sc->export_certificates_size); } return rv; @@ -893,12 +893,12 @@ int mgs_hook_authz(request_rec * r) { /* @param side is either 0 for SERVER or 1 for CLIENT * - * @param export_full_cert (boolean) export the PEM-encoded - * certificate in full as an environment variable. + * @param export_cert_size (int) maximum size for environment variable + * to use for the PEM-encoded certificate (0 means do not export) */ #define MGS_SIDE ((side==0)?"SSL_SERVER":"SSL_CLIENT") -static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, int side, int export_full_cert) { +static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, int side, int export_cert_size) { unsigned char sbuf[64]; /* buffer to hold serials */ char buf[AP_IOBUFSIZE]; const char *tmp; @@ -912,16 +912,29 @@ static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, in apr_table_t *env = r->subprocess_env; _gnutls_log(debug_log_fp, "%s: %d\n", __func__, __LINE__); - if (export_full_cert != 0) { - char cert_buf[10 * 1024]; - len = sizeof (cert_buf); - - if (gnutls_x509_crt_export(cert, GNUTLS_X509_FMT_PEM, cert_buf, &len) >= 0) - apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), - apr_pstrmemdup(r->pool, cert_buf, len)); - else - ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, - "GnuTLS: Failed to export X.509 certificate to environment"); + if (export_cert_size > 0) { + len = 0; + ret = gnutls_x509_crt_export(cert, GNUTLS_X509_FMT_PEM, NULL, &len); + if (ret == GNUTLS_E_SHORT_MEMORY_BUFFER) { + if (len >= export_cert_size) { + apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), + "GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED"); + ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, + "GnuTLS: Failed to export too-large X.509 certificate to environment"); + } else { + char* cert_buf = apr_palloc(r->pool, len + 1); + if (cert_buf != NULL && gnutls_x509_crt_export(cert, GNUTLS_X509_FMT_PEM, cert_buf, &len) >= 0) { + cert_buf[len] = 0; + apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), cert_buf); + } else { + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, + "GnuTLS: failed to export X.509 certificate"); + } + } + } else { + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, + "GnuTLS: dazed and confused about X.509 certificate size"); + } } len = sizeof (buf); @@ -1036,10 +1049,10 @@ static void mgs_add_common_cert_vars(request_rec * r, gnutls_x509_crt_t cert, in /* @param side 0: server, 1: client * - * @param export_full_cert (boolean) export the PEM-encoded - * certificate in full as an environment variable. + * @param export_cert_size (int) maximum size for environment variable + * to use for the PEM-encoded certificate (0 means do not export) */ -static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t cert, int side, int export_full_cert) { +static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t cert, int side, int export_cert_size) { unsigned char sbuf[64]; /* buffer to hold serials */ char buf[AP_IOBUFSIZE]; @@ -1053,16 +1066,29 @@ static void mgs_add_common_pgpcert_vars(request_rec * r, gnutls_openpgp_crt_t ce _gnutls_log(debug_log_fp, "%s: %d\n", __func__, __LINE__); apr_table_t *env = r->subprocess_env; - if (export_full_cert != 0) { - char cert_buf[10 * 1024]; - len = sizeof (cert_buf); - - if (gnutls_openpgp_crt_export(cert, GNUTLS_OPENPGP_FMT_BASE64, cert_buf, &len) >= 0) - apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), - apr_pstrmemdup(r->pool, cert_buf, len)); - else - ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, - "GnuTLS: Failed to export OpenPGP certificate to environment"); + if (export_cert_size > 0) { + len = 0; + ret = gnutls_openpgp_crt_export(cert, GNUTLS_OPENPGP_FMT_BASE64, NULL, &len); + if (ret == GNUTLS_E_SHORT_MEMORY_BUFFER) { + if (len >= export_cert_size) { + apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), + "GNUTLS_CERTIFICATE_SIZE_LIMIT_EXCEEDED"); + ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r, + "GnuTLS: Failed to export too-large OpenPGP certificate to environment"); + } else { + char* cert_buf = apr_palloc(r->pool, len + 1); + if (cert_buf != NULL && gnutls_openpgp_crt_export(cert, GNUTLS_OPENPGP_FMT_BASE64, cert_buf, &len) >= 0) { + cert_buf[len] = 0; + apr_table_setn(env, apr_pstrcat(r->pool, MGS_SIDE, "_CERT", NULL), cert_buf); + } else { + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, + "GnuTLS: failed to export OpenPGP certificate"); + } + } + } else { + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, + "GnuTLS: dazed and confused about OpenPGP certificate size"); + } } len = sizeof (buf); @@ -1327,9 +1353,9 @@ static int mgs_cert_verify(request_rec * r, mgs_handle_t * ctxt) { } if (gnutls_certificate_type_get(ctxt->session) == GNUTLS_CRT_X509) - mgs_add_common_cert_vars(r, cert.x509[0], 1, ctxt->sc->export_certificates_enabled); + mgs_add_common_cert_vars(r, cert.x509[0], 1, ctxt->sc->export_certificates_size); else if (gnutls_certificate_type_get(ctxt->session) == GNUTLS_CRT_OPENPGP) - mgs_add_common_pgpcert_vars(r, cert.pgp, 1, ctxt->sc->export_certificates_enabled); + mgs_add_common_pgpcert_vars(r, cert.pgp, 1, ctxt->sc->export_certificates_size); { /* days remaining */ diff --git a/src/mod_gnutls.c b/src/mod_gnutls.c index e576fb8..14e8320 100644 --- a/src/mod_gnutls.c +++ b/src/mod_gnutls.c @@ -180,10 +180,10 @@ static const command_rec mgs_config_cmds[] = { RSRC_CONF, "Whether this server has GnuTLS Enabled. Default: Off"), AP_INIT_TAKE1("GnuTLSExportCertificates", - mgs_set_export_certificates_enabled, + mgs_set_export_certificates_size, NULL, RSRC_CONF, - "Whether to export PEM encoded certificates to CGIs. Default: Off"), + "Max size to export PEM encoded certificates to CGIs (or off to disable). Default: off"), { NULL }, }; -- 1.8.5.3 From bas at Dikkenberg.net Sun Feb 23 20:37:19 2014 From: bas at Dikkenberg.net (Bas van den Dikkenberg) Date: Sun, 23 Feb 2014 19:37:19 +0000 Subject: [mod_gnutls-devel] Sugestions for configure.ac and add for autogen.sh Message-ID: <578e75858b2440a984f12c9af8a1f1d3@srv04.dikkenberg.local> Hi all, I am new here but stil i offerd dkg some help. I have some suggestion for configure.ac to more like standards. The biggeste issue I could find that lt_init was missing witch can cause m3 eerror during the automake process. The rest you can read below : By adding te suggestion I made, i think it improves the portability of mod_gnutls. As far as I can see it solves some problems during the build on kfreebsd at least Description: Updated configure.ac * AM_INIT_AUTOMAKE doesn't need any options any more * DNL not needed so removed * LT_INIT was missing needed tot initilize libtool witch can cause m4 erors during the automake proces * Added missing AC_CHECK_FUNCS AC_FUNC_CHOWN * Added an autoconf.sh file . Author: Bastiaan Franciscus van den Dikkenberg --- Last-Update: <2014-02-23> --- mod-gnutls-0.6.orig/configure.ac +++ mod-gnutls-0.6/configure.ac @@ -1,4 +1,3 @@ -dnl AC_INIT(mod_gnutls, 0.6) OOO_CONFIG_NICE(config.nice) MOD_GNUTLS_VERSION=AC_PACKAGE_VERSION @@ -9,7 +8,8 @@ AC_CONFIG_AUX_DIR(config) OOO_MAINTAIN_MODE AM_MAINTAINER_MODE AC_CANONICAL_TARGET -AM_INIT_AUTOMAKE(AC_PACKAGE_NAME, AC_PACKAGE_VERSION) +AM_INIT_AUTOMAKE +LT_INIT AM_CONFIG_HEADER(include/mod_gnutls_config.h:config.in) AC_SUBST(MOD_GNUTLS_VERSION) @@ -40,7 +40,16 @@ SRP_CFLAGS="" if test "$use_srp" != "no"; then SRP_CFLAGS="-DENABLE_SRP=1" fi - +AC_CHECK_FUNCS([memchr]) +AC_CHECK_FUNCS([memmove]) +AC_CHECK_FUNCS([strcasecmp]) +AC_FUNC_CHOWN +AC_FUNC_MALLOC +AC_FUNC_REALLOC +AC_TYPE_SIZE_T +AC_TYPE_SSIZE_T +AC_PROG_LN_S +AC_PROG_MAKE_SET AC_MSG_CHECKING([whether to enable SRP functionality]) AC_MSG_RESULT($use_srp) @@ -61,6 +70,10 @@ fi AC_MSG_CHECKING([whether to enable MSVA functionality]) AC_MSG_RESULT($use_msva) + + + + have_apr_memcache=0 CHECK_APR_MEMCACHE([have_apr_memcache=1], [have_apr_memcache=0]) AC_SUBST(have_apr_memcache) --- /dev/null +++ mod-gnutls-0.6/autogen.sh @@ -0,0 +1,8 @@ +#!/bin/sh +# autogen.sh - generates configure using the autotools +libtoolize --force --copy +aclocal -I m4 +autoheader +automake --add-missing --copy --foreign +autoconf +rm -rf autom4te.cache From bas at Dikkenberg.net Sun Feb 23 20:42:14 2014 From: bas at Dikkenberg.net (Bas van den Dikkenberg) Date: Sun, 23 Feb 2014 19:42:14 +0000 Subject: [mod_gnutls-devel] DOCS Message-ID: <866c81e3a1e14a5fbef0639e051d1399@srv04.dikkenberg.local> Hi, I suggests that we stop generating the pdf and html during the build process, and just include them in the source. All the mayor distro's you can specify in build file(s) what doc files are so I think should be more than enough don't you think so. The only thanks needs adjusting for that is remove of the Makefile in doc dir . This also solves issues on systems like sparc 390x With kind regards, Bas van den Dikkenberg From dkg at fifthhorseman.net Mon Feb 24 06:49:28 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 24 Feb 2014 00:49:28 -0500 Subject: [mod_gnutls-devel] DOCS In-Reply-To: <866c81e3a1e14a5fbef0639e051d1399@srv04.dikkenberg.local> References: <866c81e3a1e14a5fbef0639e051d1399@srv04.dikkenberg.local> Message-ID: <530ADD68.7050301@fifthhorseman.net> Hi Bas-- On 02/23/2014 02:42 PM, Bas van den Dikkenberg wrote: > I suggests that we stop generating the pdf and html during the build process, and just include them in the source. > All the mayor distro's you can specify in build file(s) what doc files are so I think should be more than enough don't you think so. I think i'm going to push back on this one a bit, for a couple reasons: (a) i want people to be able to rebuild the package -- this means i want them to be able to rebuild the documentation as well, since that's an important part of the package. (b) in general, in debian at least, there's an expectation that anything which can be generated from source should be done during the build process. This helps us catch when some things can't be built on some architectures (like the missing pandoc on s390x, as you point out) (c) I don't like the idea of putting generated files under revision control, and i also don't like the idea of shipping a tarball that differs from what's in revision control if we can help it. That said, i don't think we need to generate a pdf from the manual, and pandoc is pretty heavyweight for what we're doing here, though it does make a nice table of contents and cross-referenced hyperlinks, which other markdown interpreters don't do. So i see a few possible ways forward: 0) switch to markdown entirely from pandoc and just drop generation of the pdf. (note that /usr/bin/markdown from the markdown package doesn't actually generate a full HTML file, so something would need to be done about the headers and footers) 1) drop generation of the pdf; during documentation build, detect if pandoc exists or not, and if not, invoke markdown instead (this would mean build-depending on pandoc | markdown, and it would have the weird effect of having the documentation on s390x look different from the documentation on other platforms) 2) ship a separate architecture-independent libapache2-mod-gnutls-doc package, so that the documentation only has to be built on one platform to be shippable on all of them. this seems a little weird given that there is not a lot of content to put in this package other than the html file and the pdf. 3) go through the source code and insert as much of the contents of the manual directly as comments, and generate things using doxygen, which i think is sufficiently cross-platform. do any of those sound plausible to you? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From BenBE at geshi.org Tue Feb 25 08:51:00 2014 From: BenBE at geshi.org (Benny Baumann) Date: Tue, 25 Feb 2014 08:51:00 +0100 Subject: [mod_gnutls-devel] [PATCH 2/2] implement GnuTLSExportCertificates control over max exported cert size In-Reply-To: <530B5917.6090209@fifthhorseman.net> References: <5307A482.6030504@fifthhorseman.net> <1393179323-10830-1-git-send-email-dkg@fifthhorseman.net> <1393179323-10830-2-git-send-email-dkg@fifthhorseman.net> <530B069B.5050504@geshi.org> <530B5917.6090209@fifthhorseman.net> Message-ID: <530C4B64.3030702@geshi.org> Hi Daniel, Am 24.02.2014 15:37, schrieb Daniel Kahn Gillmor: > Hi Benny-- > > On 02/24/2014 03:45 AM, Benny Baumann wrote: > >> Some small notes I'll interleave with the shortened diff for simplicity. > thanks for the review! is there a reason that it's off-list? I'd love > to have this sort of thing on-list. was accidentially off-list. I'd have marked it in the subject or otherwise noted to be off-list if intended. So no problem with republishing it. > For now, my reply is private because i generally don't like forwarding > people's private comments to public lists without permission. > > but if you're OK with this exchange being public, i'm happy to republish > it. let me know! > >>> + while (apr_isspace(*endptr)) endptr++; >>> + if (*endptr == '\0' || *endptr == 'b' || *endptr == 'B') { >>> + ; >>> + } else if (*endptr == 'k' || *endptr == 'K') { >>> + sc->export_certificates_size *= 1024; >>> + } else { >>> + return "GnuTLSExportCertificates must be set to a size (in bytes) or 'On' or 'Off'"; >>> + } >> Works for the common case but allows 64KBoom and other values which >> should throw a warning. > I think you're saying that it doesn't check that byte *after* the B is a > null byte. (do we also want to allow a series of whitespace followed by > a null byte?). That's a good catch. Looking at upstream apache code, i > think there are probably other directives that can be tricked like this. At least we should define it properly. I thing the following should be acceptable: 16384 16K 16KB 16KiB 16kB 16M (and variants). Trailing whitespace might be ignored, non-whitespace should trigger a warning. As should any other invalid value causing the default to be used. >>> + } else { >>> + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, >>> + "GnuTLS: dazed and confused about X.509 certificate size"); >> When can this warning happen? > That's a great question! The answer is "i don't know" -- i expect it to > never trigger, since i don't see how gnutls_x509_crt_export() can return > anything but GNUTLS_E_SHORT_MEMORY_BUFFER when passed an output buffer > of size 0. > > That said, the code needs to verify that its assumption is correct, and > so it will log this failed assumption. > > Do you have any suggestions for other ways we should handle this? No. Just be a bit more clear in the message so people who didn't read the patch know what's going on. >>> + } else { >>> + ap_log_rerror(APLOG_MARK, APLOG_WARNING, 0, r, >>> + "GnuTLS: dazed and confused about OpenPGP certificate size"); >> Same question here: How to trigger this one? > Same answer as above, but for gnutls_openpgp_crt_export() instead. Guessed so ;-) >>> - "Whether to export PEM encoded certificates to CGIs. Default: Off"), >>> + "Max size to export PEM encoded certificates to CGIs (or off to disable). Default: off"), >> Inconsistency with other descriptions. Off with capital O for all the >> other texts. > Ah, so it is. but doc/mod_gnutls_manual.mdwn uses all lowercase. We > should probably standardize across them both. Thanks for catching this > inconsistency. AFAIR Apache uses first letter uppercase in its documentation and I think we should in the module do the same. But I'm indifferent about either way ;-) Yet a slight tendency to keep to the Apache way exists ... > > --dkg Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From ramkumar.chinchani at gmail.com Tue Feb 25 22:48:15 2014 From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani) Date: Tue, 25 Feb 2014 13:48:15 -0800 Subject: [mod_gnutls-devel] `GnuTLSClientVerify` behavior incorrect? Message-ID: As per current config model, it is possible that `GnuTLSClientVerify` is defined in server or vhost but not under directory, in which case this is probably what is desired? Kindly review. diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c index d068ebb..335ae3f 100644 --- a/src/gnutls_hooks.c +++ b/src/gnutls_hooks.c @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) { ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "GnuTLS: Directory set to Ignore Client Certificate!"); } else { - if (ctxt->sc->client_verify_mode < dc->client_verify_mode) { + if (dc->client_verify_mode >= 0 && + ctxt->sc->client_verify_mode < dc->client_verify_mode) { ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "GnuTLS: Attempting to rehandshake with peer. %d %d", ctxt->sc->client_verify_mode, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramkumar.chinchani at gmail.com Thu Feb 27 08:35:02 2014 From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani) Date: Thu, 27 Feb 2014 07:35:02 +0000 Subject: [mod_gnutls-devel] GnuTLSPGPKeyringFile? Message-ID: Is there a way to export the entire keyring? in base64 format? If not, then I am likely pointing GnuTLSPGPKeyringFile to ${HOME}/.gnupg/pubring.gpg which should be in RAW format? diff --git a/src/gnutls_config.c b/src/gnutls_config.c index 3300854..6b672f5 100644 --- a/src/gnutls_config.c +++ b/src/gnutls_config.c @@ -509,7 +509,7 @@ const char *mgs_set_keyring_file(cmd_parms * parms, void *dummy, } rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data, - GNUTLS_OPENPGP_FMT_BASE64); + GNUTLS_OPENPGP_FMT_RAW); if (rv < 0) { return apr_psprintf(parms->pool, "GnuTLS: Failed to load " "Keyring File '%s': (%d) %s", file, rv, -------------- next part -------------- An HTML attachment was scrubbed... URL: From BenBE at geshi.org Thu Feb 27 09:11:04 2014 From: BenBE at geshi.org (Benny Baumann) Date: Thu, 27 Feb 2014 09:11:04 +0100 Subject: [mod_gnutls-devel] GnuTLSPGPKeyringFile? In-Reply-To: References: Message-ID: <530EF318.2080001@geshi.org> Hi, Am 27.02.2014 08:35, schrieb Ramkumar Chinchani: > Is there a way to export the entire keyring? in base64 format? gnupg exports all matching keys when given the --export option. Haven't checked though yet how to export the full keyring at once. > > If not, then I am likely pointing GnuTLSPGPKeyringFile to > ${HOME}/.gnupg/pubring.gpg which should be in RAW format? > > > diff --git a/src/gnutls_config.c b/src/gnutls_config.c > index 3300854..6b672f5 100644 > --- a/src/gnutls_config.c > +++ b/src/gnutls_config.c > @@ -509,7 +509,7 @@ const char *mgs_set_keyring_file(cmd_parms * > parms, void *dummy, > } > > rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data, > - GNUTLS_OPENPGP_FMT_BASE64); > + GNUTLS_OPENPGP_FMT_RAW); > if (rv < 0) { > return apr_psprintf(parms->pool, "GnuTLS: Failed to load " > "Keyring File '%s': (%d) %s", file, rv, > > I'd prefer if the old behaviour stays and it additionally allows for binary keyrings to be loaded. That way you won't offend existing users of this feature. Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: