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.)