From jared.jennings.ctr at eglin.af.mil Wed May 4 22:20:02 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Wed, 4 May 2011 17:20:02 -0500 Subject: [Mod_nss-list] hello, and problem 1 Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Hello, mod_nss-list! I'm having interesting adventures in authenticating clients using certificates, but I don't understand everything I'm seeing. I've got httpd 2.2.15 and mod_nss 1.0.8, as on RHEL6. I have a website where I want to authorize people for some areas by groups I define, so I'm using FakeBasicAuth. Well and good, but when I reload my page several times in Firefox, it's fairly easy to get to a username and password prompt, which I should never get: who the user is is strictly a function of the certificate he presents. After adding a few debug logging statements, I see that when the browser shows the username and password box, the FakeBasicAuth has declined to fake, because sslconn->client_cert is false in nss_hook_UserCheck (nss_engine_kernel.c, line 641 +/- 40, "We decline operation in various situations"). My question is this: As you'll see below, I set NSSVerifyClient require at the top level. How is it possible that there is no client certificate associated with a connection? All NSS-related configuration follows; about 60 lines. LoadModule nss_module modules/libmodnss.so Listen 192.168.122.187:443 AddType application/x-x509-ca-cert .crt AddType application/x-pkcs7-crl .crl NSSPassPhraseDialog file:/etc/pki/mod_nss/pwfile NSSPassPhraseHelper /usr/sbin/nss_pcache NSSSessionCacheSize 10000 NSSSessionCacheTimeout 100 NSSSession3CacheTimeout 86400 NSSRandomSeed startup builtin #NSSRandomSeed startup file:/dev/random 512 #NSSRandomSeed startup file:/dev/urandom 512 NSSRenegotiation off NSSRequireSafeNegotiation off NSSVerifyClient require #NSSUserName SSL_CLIENT_S_DN_CN NSSUserName SSL_CLIENT_S_DN DocumentRoot "/var/www/html" ServerName mumble.mumble ServerAdmin mumble at mumble ErrorLog logs/ssl_error_log CustomLog logs/ssl_access_log common LogLevel debug NSSEngine on NSSProtocol TLSv1 NSSCipherSuite +rsa_3des_sha,+fips_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha NSSFIPS on NSSCertificateDatabase /etc/pki/mod_nss NSSNickname mumble NSSOCSP off NSSOptions +FakeBasicAuth AuthName "mumble website" AuthType Basic AuthUserFile "userfile" AuthGroupFile "groupfile" AuthName "mumble Website root" Require group admins ScriptAlias /cgi-bin/ /var/www/cgi-bin/ NSSOptions +StdEnvVars Require group admins From jared.jennings.ctr at eglin.af.mil Wed May 4 23:07:42 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Wed, 4 May 2011 18:07:42 -0500 Subject: [Mod_nss-list] Problem 2 Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA30@VFEGMLEG03.Enterprise.afmc.ds.af.mil> When FakeBasicAuth does not fill in a username and password from a certificate, there's a mechanism which is supposed to prevent the user from maliciously gaining access by typing a certificate-related username, and the password 'password'. I don't think it works right in mod_nss. Around line 602 of nss_engine_kernel.c ("Make sure the user is not able to fake"), nss_hook_UserCheck checks to see if the first character of the username is '/'. Under mod_ssl with FakeBasicAuth, this is a sufficient check, because certificate-based usernames always start with '/'. (I believe mod_ssl ignores SSLUserName when FakingBasicAuth.) But under mod_nss (nss_engine_kernel.c:486, 650, nss_engine_io.c:1371), the username checked here is only the CN, and the CN doesn't start with '/' - neither when it's legitimate nor when someone is trying to "fake the client certificate based authentication." So the if at line 602 never fires. Consequently, when I hit Reload a few times and I get that username/password box (this is "problem 1" that I posted a bit ago), if I know the common name of anyone else's certificate, under mod_nss I can type it in, and use the password 'password', and become them. The simplest way I can see to secure this would be: instead of making sure there are no maliciously faked Authorization headers in the request, make sure there are no Authorization headers at all. If we're FakingBasicAuth, all the authentication should be coming from the certificate. But this may not work unless all access is via certificate - or if I don't understand the ways of Apache properly, may not work at all. Next simpler, instead of setting client_dn to NULL (nss_engine_kernel.c:486, nss_engine_io.c:1371), come up with the same slash-delimited, country-first distinguished name that mod_ssl does, and set it instead of the common name. Perhaps don't set the common name as a default anymore, because the client_dn will always be set. Then the check at nss_engine_kernel.c:602 would work. The final user name may not even have to be the client_dn: it appears that NSSUserName does its work during fixup, so I'm authenticated with one name, but then REMOTE_USER can be set to another. I'm new to mod_nss, so I can't be sure that either is a good idea. Any wisdom? From rcritten at redhat.com Fri May 6 13:31:18 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 May 2011 09:31:18 -0400 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <4DC3F826.1000307@redhat.com> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: > Hello, mod_nss-list! I'm having interesting adventures in authenticating > clients using certificates, but I don't understand everything I'm > seeing. > > I've got httpd 2.2.15 and mod_nss 1.0.8, as on RHEL6. I have a website > where I want to authorize people for some areas by groups I define, so > I'm using FakeBasicAuth. Well and good, but when I reload my page > several times in Firefox, it's fairly easy to get to a username and > password prompt, which I should never get: who the user is is strictly a > function of the certificate he presents. > > After adding a few debug logging statements, I see that when the browser > shows the username and password box, the FakeBasicAuth has declined to > fake, because sslconn->client_cert is false in nss_hook_UserCheck > (nss_engine_kernel.c, line 641 +/- 40, "We decline operation in various > situations"). > > My question is this: As you'll see below, I set NSSVerifyClient require > at the top level. How is it possible that there is no client certificate > associated with a connection? Right, I'll have to take a look to see whether we aren't configuring the SSL socket to require a client cert or we are somehow not storing a copy of it in the request. I believe NSS should reject the connection if a client cert is required and one is not presented. In this case did you provide a valid client cert? thanks rob > > All NSS-related configuration follows; about 60 lines. > > LoadModule nss_module modules/libmodnss.so > Listen 192.168.122.187:443 > AddType application/x-x509-ca-cert .crt > AddType application/x-pkcs7-crl .crl > NSSPassPhraseDialog file:/etc/pki/mod_nss/pwfile > NSSPassPhraseHelper /usr/sbin/nss_pcache > NSSSessionCacheSize 10000 > NSSSessionCacheTimeout 100 > NSSSession3CacheTimeout 86400 > > NSSRandomSeed startup builtin > #NSSRandomSeed startup file:/dev/random 512 > #NSSRandomSeed startup file:/dev/urandom 512 > > NSSRenegotiation off > NSSRequireSafeNegotiation off > > NSSVerifyClient require > #NSSUserName SSL_CLIENT_S_DN_CN > NSSUserName SSL_CLIENT_S_DN > > DocumentRoot "/var/www/html" > ServerName mumble.mumble > ServerAdmin mumble at mumble > ErrorLog logs/ssl_error_log > CustomLog logs/ssl_access_log common > LogLevel debug > > NSSEngine on > NSSProtocol TLSv1 > NSSCipherSuite > +rsa_3des_sha,+fips_3des_sha,+rsa_aes_128_sha,+rsa_aes_256_sha > NSSFIPS on > NSSCertificateDatabase /etc/pki/mod_nss > NSSNickname mumble > NSSOCSP off > > > NSSOptions +FakeBasicAuth > AuthName "mumble website" > AuthType Basic > AuthUserFile "userfile" > AuthGroupFile "groupfile" > > > > AuthName "mumble Website root" > Require group admins > > > ScriptAlias /cgi-bin/ /var/www/cgi-bin/ > > NSSOptions +StdEnvVars > Require group admins > > > > > _______________________________________________ > Mod_nss-list mailing list > Mod_nss-list at redhat.com > https://www.redhat.com/mailman/listinfo/mod_nss-list From rcritten at redhat.com Fri May 6 13:33:35 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 06 May 2011 09:33:35 -0400 Subject: [Mod_nss-list] Problem 2 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA30@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA30@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <4DC3F8AF.6020800@redhat.com> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: > When FakeBasicAuth does not fill in a username and password from a > certificate, there's a mechanism which is supposed to prevent the user > from maliciously gaining access by typing a certificate-related > username, and the password 'password'. I don't think it works right in > mod_nss. > > Around line 602 of nss_engine_kernel.c ("Make sure the user is not able > to fake"), nss_hook_UserCheck checks to see if the first character of > the username is '/'. Under mod_ssl with FakeBasicAuth, this is a > sufficient check, because certificate-based usernames always start with > '/'. (I believe mod_ssl ignores SSLUserName when FakingBasicAuth.) But > under mod_nss (nss_engine_kernel.c:486, 650, nss_engine_io.c:1371), the > username checked here is only the CN, and the CN doesn't start with '/' > - neither when it's legitimate nor when someone is trying to "fake the > client certificate based authentication." So the if at line 602 never > fires. > > Consequently, when I hit Reload a few times and I get that > username/password box (this is "problem 1" that I posted a bit ago), if > I know the common name of anyone else's certificate, under mod_nss I can > type it in, and use the password 'password', and become them. > > The simplest way I can see to secure this would be: instead of making > sure there are no maliciously faked Authorization headers in the > request, make sure there are no Authorization headers at all. If we're > FakingBasicAuth, all the authentication should be coming from the > certificate. But this may not work unless all access is via certificate > - or if I don't understand the ways of Apache properly, may not work at > all. > > Next simpler, instead of setting client_dn to NULL > (nss_engine_kernel.c:486, nss_engine_io.c:1371), come up with the same > slash-delimited, country-first distinguished name that mod_ssl does, and > set it instead of the common name. Perhaps don't set the common name as > a default anymore, because the client_dn will always be set. Then the > check at nss_engine_kernel.c:602 would work. The final user name may not > even have to be the client_dn: it appears that NSSUserName does its work > during fixup, so I'm authenticated with one name, but then REMOTE_USER > can be set to another. > > I'm new to mod_nss, so I can't be sure that either is a good idea. Any > wisdom? I agree that the code looking for / is a bug. mod_nss is a derivation from the mod_ssl code, this must be a piece I missed when implementing this originally. I'll take a look. rob From jared.jennings.ctr at eglin.af.mil Mon May 9 14:56:55 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Mon, 9 May 2011 09:56:55 -0500 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <4DC3F826.1000307@redhat.com> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <4DC3F826.1000307@redhat.com> Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> > > My question is this: As you'll see below, I set NSSVerifyClient > > require at the top level. How is it possible that there is no client > > certificate associated with a connection? > > Right, I'll have to take a look to see whether we aren't configuring > the SSL socket to require a client cert or we are somehow not storing a > copy of it in the request. I believe NSS should reject the connection if a > client cert is required and one is not presented. > > In this case did you provide a valid client cert? I provided a valid client cert for the original connection, then hit Refresh in the browser. This is Firefox 3.6.17; its normal behavior is that once you choose a certificate for a site, it won't ask you again in the same browsing session, and it will silently keep presenting the same certificate you chose for that server in ensuing connections. So I have no a priori evidence that a client cert was presented in the second connection, but I think there was a client cert. I'll see if I can make that more sure. From jared.jennings.ctr at eglin.af.mil Mon May 9 19:39:08 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Mon, 9 May 2011 14:39:08 -0500 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil><4DC3F826.1000307@redhat.com> <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> > So I have no a priori evidence that a client cert was presented in the > second connection, but I think there was a client cert. I'll see if I > can make that more sure. I've added a bunch of debug logging statements. In nss_hook_pre_connection (mod_nss.c:361 or so), right after the local variable ssl is set up, the options SSL_REQUEST_CERTIFICATE and SSL_REQUIRE_CERTIFICATE are successfully passed from mctx->model to ssl. Both are true in all new sockets with my configuration. A bit farther down, we SSL_ResetHandshake. Apparently the handshake happens in between the creation of the socket and the time when we can receive a request over it, and all the necessary inputs from mod_nss during the handshake process are handled with hook functions. One among these is nss_AuthCertificate (nss_engine_io.c:1373 or so), which is set as the SSL_AuthCertificateHook. During the first connection, this hook happens: I put a log call in it and the message shows up. During ensuing connections, the hook does not happen. By the time of nss_hook_ReadReq (nss_engine_kernel.c:81 or so, "Log information about incoming HTTPS requests") there is no sslconn->client_cert. Subsequent requests over the first connection (via keepalives) work fine; only after the connection is closed, and another connection is made, is there no client certificate. I tested this using httpd -X to eliminate multiple-process issues from consideration. Also tried turning off keepalives; that makes the problem appear immediately. When I use the NSS tstclnt, it works right every time I've tried it. With Firefox, when I take out my smartcard and put it back in, it works right. When I leave the card in, that's when it fails. Enough with Firefox. I decided to try it with IE. Trying to visit one page takes seven connections; the nss_AuthCertificate happens in two of those seven. What a mess. In fine, I'm not any surer whether a certificate is presented or not than before writing this email: the actual request for the certificate and the actual provision of the certificate are happening at a lower level than I'm observing, inside NSS. From rcritten at redhat.com Mon May 9 21:12:04 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 09 May 2011 17:12:04 -0400 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA2F@VFEGMLEG03.Enterprise.afmc.ds.af.mil><4DC3F826.1000307@redhat.com> <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <4DC858A4.3010409@redhat.com> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: >> So I have no a priori evidence that a client cert was presented in the >> second connection, but I think there was a client cert. I'll see if I >> can make that more sure. > > I've added a bunch of debug logging statements. > > In nss_hook_pre_connection (mod_nss.c:361 or so), right after the local > variable ssl is set up, the options SSL_REQUEST_CERTIFICATE and > SSL_REQUIRE_CERTIFICATE are successfully passed from mctx->model to ssl. > Both are true in all new sockets with my configuration. > > A bit farther down, we SSL_ResetHandshake. Apparently the handshake > happens in between the creation of the socket and the time when we can > receive a request over it, and all the necessary inputs from mod_nss > during the handshake process are handled with hook functions. One among > these is nss_AuthCertificate (nss_engine_io.c:1373 or so), which is set > as the SSL_AuthCertificateHook. During the first connection, this hook > happens: I put a log call in it and the message shows up. During ensuing > connections, the hook does not happen. By the time of nss_hook_ReadReq > (nss_engine_kernel.c:81 or so, "Log information about incoming HTTPS > requests") there is no sslconn->client_cert. > > Subsequent requests over the first connection (via keepalives) work > fine; only after the connection is closed, and another connection is > made, is there no client certificate. I tested this using httpd -X to > eliminate multiple-process issues from consideration. Also tried turning > off keepalives; that makes the problem appear immediately. > > When I use the NSS tstclnt, it works right every time I've tried it. > With Firefox, when I take out my smartcard and put it back in, it works > right. When I leave the card in, that's when it fails. > > Enough with Firefox. I decided to try it with IE. Trying to visit one > page takes seven connections; the nss_AuthCertificate happens in two of > those seven. What a mess. > > In fine, I'm not any surer whether a certificate is presented or not > than before writing this email: the actual request for the certificate > and the actual provision of the certificate are happening at a lower > level than I'm observing, inside NSS. Ok, thanks for doing this legwork. I'm just getting back to the office after a week and have a lot of catching up to do. I"ll get on this as soon as I can. regards rob From jared.jennings.ctr at eglin.af.mil Mon May 9 21:54:28 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Mon, 9 May 2011 16:54:28 -0500 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA39@VFEGMLEG03.Enterprise.afmc.ds.af.mil> > I'm not any surer whether a certificate is presented or not > than before writing this email After some funny stares at the code, I've realized that the sslconn->client_cert is set only in one place: the nss_AuthCertificate callback, used when a client certificate needs to be authenticated. It's set to the SSL_PeerCertificate of the socket. I previously added a log message in nss_hook_ReadReq, warning when sslconn->client_cert is null. When I checked there for whether SSL_PeerCertificate(ssl) exists, I found that it does, as far as I've tested. When I set sslconn->client_cert to that value, now I have an sslconn->client_cert, and the FakeBasicAuth proceeds properly. Is there some legitimate means by which a recently seen client certificate is not re-authenticated? If there is no such means, something screwy is going on, because the AuthCertificate callback is not being called in subsequent connections with the same certificate. If there is such a means, it would appear that all that's needed is for somewhere else in the code besides the AuthCertificate callback to set the client_cert. From jared.jennings.ctr at eglin.af.mil Mon May 9 22:09:58 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Mon, 9 May 2011 17:09:58 -0500 Subject: [Mod_nss-list] Problem 2 In-Reply-To: <4DC3F8AF.6020800@redhat.com> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA30@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <4DC3F8AF.6020800@redhat.com> Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA3A@VFEGMLEG03.Enterprise.afmc.ds.af.mil> > I agree that the code looking for / is a bug. mod_nss is a derivation > from the mod_ssl code, this must be a piece I missed when implementing > this originally. I'll take a look. If you're going to detect spoof attempts solely by the username (and that's all you have in this function), there needs to be some way of separating a username that looks FakeBasicAuthed from a username that doesn't look that way, quickly, easily, and without messing with it too much (any smart processing you do may have a flaw, which adversarial users could try to exploit). So it's true that the / is an unintended holdover from mod_ssl -- but it's also true that / is generally a weird character to start a manually-typeable user name with, and that checking the first character of the username is one of the simplest, dumbest things you can do. All told, I've come around to thinking it's a good idea to make mod_nss FakeBasicAuth usernames start with /, and to check for that when spoof-checking - you just need to have the whole DN after the slash, not only the CN, because otherwise two certs from different issuers but having the same CN would lead to the same username, leading to unintended consequences in the authorization stage. From rcritten at redhat.com Tue May 10 19:15:39 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 May 2011 15:15:39 -0400 Subject: [Mod_nss-list] Problem 2 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA3A@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA30@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <4DC3F8AF.6020800@redhat.com> <09B8D4A01E10D14CA028A4D0CD5779D90294FA3A@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <4DC98EDB.8060100@redhat.com> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: >> I agree that the code looking for / is a bug. mod_nss is a derivation >> from the mod_ssl code, this must be a piece I missed when implementing >> this originally. I'll take a look. > > If you're going to detect spoof attempts solely by the username (and > that's all you have in this function), there needs to be some way of > separating a username that looks FakeBasicAuthed from a username that > doesn't look that way, quickly, easily, and without messing with it too > much (any smart processing you do may have a flaw, which adversarial > users could try to exploit). > > So it's true that the / is an unintended holdover from mod_ssl -- but > it's also true that / is generally a weird character to start a > manually-typeable user name with, and that checking the first character > of the username is one of the simplest, dumbest things you can do. > > All told, I've come around to thinking it's a good idea to make mod_nss > FakeBasicAuth usernames start with /, and to check for that when > spoof-checking - you just need to have the whole DN after the slash, not > only the CN, because otherwise two certs from different issuers but > having the same CN would lead to the same username, leading to > unintended consequences in the authorization stage. I've come to the same conclusion. sslconn->client_dn seems to only be used for this purpose so I can do what I wish with it. Sticking in an extra character won't hurt anything. regards rob From rcritten at redhat.com Tue May 10 20:51:43 2011 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 May 2011 16:51:43 -0400 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <09B8D4A01E10D14CA028A4D0CD5779D90294FA39@VFEGMLEG03.Enterprise.afmc.ds.af.mil> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA35@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <09B8D4A01E10D14CA028A4D0CD5779D90294FA36@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <09B8D4A01E10D14CA028A4D0CD5779D90294FA39@VFEGMLEG03.Enterprise.afmc.ds.af.mil> Message-ID: <4DC9A55F.308@redhat.com> Jennings, Jared L CTR USAF AFMC 46 SK/CCI wrote: >> I'm not any surer whether a certificate is presented or not >> than before writing this email > > After some funny stares at the code, I've realized that the > sslconn->client_cert is set only in one place: the nss_AuthCertificate > callback, used when a client certificate needs to be authenticated. It's > set to the SSL_PeerCertificate of the socket. > > I previously added a log message in nss_hook_ReadReq, warning when > sslconn->client_cert is null. When I checked there for whether > SSL_PeerCertificate(ssl) exists, I found that it does, as far as I've > tested. When I set sslconn->client_cert to that value, now I have an > sslconn->client_cert, and the FakeBasicAuth proceeds properly. > > Is there some legitimate means by which a recently seen client > certificate is not re-authenticated? If there is no such means, > something screwy is going on, because the AuthCertificate callback is > not being called in subsequent connections with the same certificate. If > there is such a means, it would appear that all that's needed is for > somewhere else in the code besides the AuthCertificate callback to set > the client_cert. I'll need to look at this a bit more. It may be that the SSL session is still active so the NSS callback doesn't need to be executed so the Apache session isn't getting updated. The good news is I think I've reproduced the problem. Still working out the why. rob From jared.jennings.ctr at eglin.af.mil Thu May 12 15:30:26 2011 From: jared.jennings.ctr at eglin.af.mil (Jennings, Jared L CTR USAF AFMC 46 SK/CCI) Date: Thu, 12 May 2011 10:30:26 -0500 Subject: [Mod_nss-list] hello, and problem 1 In-Reply-To: <4DC9A55F.308@redhat.com> References: <09B8D4A01E10D14CA028A4D0CD5779D90294FA39@VFEGMLEG03.Enterprise.afmc.ds.af.mil> <4DC9A55F.308@redhat.com> Message-ID: <09B8D4A01E10D14CA028A4D0CD5779D90294FA42@VFEGMLEG03.Enterprise.afmc.ds.af.mil> > I'll need to look at this a bit more. It may be that the SSL session is > still active so the NSS callback doesn't need to be executed so the > Apache session isn't getting updated. Thanks for looking at it. This is the part I'm not expert in, and I didn't want to make some security blunder. (For those following along via mailing list archives, the patch attached to RHBZ702437 is the product of rcritten's deliberations.)