Opened 14 years ago

Closed 13 years ago

#56 closed defect (fixed)

Disable global SSLUserName kludge

Reported by: andersk Owned by:
Priority: normal Milestone:
Component: web Keywords:
Cc:

Description

SSLUserName is an evil kludge in our global configuration that interferes with mod_auth_optional, complicates debugging of authentication problems, and cannot be disabled on a per-user basis once enabled globally. We need to get rid of it.

To quote from the scripts-commits@ thread on this issue:

andersk (r409 commit):

Remove SSLUserName, because mod_auth_sslcert is better and having the wrong REMOTE_USER set is confusing.

presbrey:

Its fine if you want to change that behavior from now on but you should certainly leave the old setting for everyone else who quite possibly depend on the old format of the value in the code of their scripts. This is a common issue with global configs.

andersk:

I had done a quick survey of the way REMOTE_USER was used on our vhosts, and didn't notice any obvious problems. We have always been telling users to use SSL_CLIENT_S_DN_Email, anyway, and the fact that REMOTE_USER happened to contain the same value was undocumented. Obviously I can't check every use and there could be new problems, but they will be reported and quickly solved, just like when various PHP extensions were disabled.

(This highlights the need for a good way to inform our users of configuration changes. Is scripts-announce still a useful list to send them to?)

Now that we have more powerful Apache modules for SSL authentication, the SSLUserName hack only gets in the way. For example, with mod_auth_sslcert's AuthSSLCertStripSuffix enabled along with AuthOptional?, I believe that a user with a valid certificate that doesn't match the suffix will still get the REMOTE_USER left over from SSLUserName even though they shouldn't. It's also a pain for debugging that the only side effects of authentication not being properly set up are a @MIT.EDU appended to REMOTE_USER, and mysterious failures when you try to use Apache-level authorization.

I see that you went and reverted my change on the two servers, without making an svn commit. It's fine to let changes lie around uncommited for a little while, but please send email when you do so. Unless you can point to something specific that broke, I'm going to redisable SSLUserName some time tomorrow.

presbrey:

Removing the SSLUserName directive results in a blank REMOTE_USER variable for anyone who hasn't set "AuthType? SSLCert" even when "SSLVerifyClient require" is set.

Surveying the vhosts doesn't quit do it. This change affects everyone on the scripts and scripts-cert hosts as well.

quentin:

I know I'm using REMOTE_USER on one of my sites; rather, I'm using Trac's default handling of REMOTE_USER.

andersk:

But that's part of my point--the scripts server shouldn't be authenticating visitors to scripts that didn't explicitly ask for it. If Trac honors REMOTE_USER by default, then it should be up to the owner to say what a user is, not our global configuration.

Note that, although you can specify SSLUserName in .htaccess if you know you want it, there is no way to _unset_ it if you don't!

quentin:

I don't think it's a good idea to make a non-backwards-compatible change to the way we handle it.

andersk:

I was not aware that people were depending on this broken behavior, so I agree that the change should probably be handled a bit more carefully. Do you think it would be sufficient for this to be part of a mail to scripts-announce, or do you have other suggestions for alerting users?

Regardless of how users are notified, temporarily breaking some scripts that were written with bad assumptions is inevitable. But I think the impact here will be minimal and I'm willing to deal with a few extra support requests.

quentin:

Can I still achieve the same results by configuring mod_auth_sslcert? I don't want authz, just authn.

andersk:

There are plenty of options:

  • You can always set SSLUserName SSL_CLIENT_S_DN_Email in .htaccess.
  • Or, with the normal
    AuthType SSLCert
    Require valid-user
    
    you'll get REMOTE_USER=quentin.
    • If you don't want to forbid visitors without certificates, add
      AuthSSLCertAuthoritative off
      AuthOptional on
      
    • If you need the REMOTE_USER=quentin@… format, add
      AuthSSLCertStripSuffix ''
      
  • Alternatively, you can use SSL_CLIENT_S_DN_Email directly instead of assuming that REMOTE_USER will be the same thing.

Change History (3)

comment:1 Changed 14 years ago by andersk

As a particular example of the mod_auth_optional conflict, I have configured https://andersk.scripts.mit.edu:444/sslusername/ as follows:

AuthType SSLCert
AuthSSLCertStripSuffix k@MIT.EDU
Require user anders
AuthSSLCertAuthoritative off
AuthOptional on

This causes me to get REMOTE_USER=anders, but broder to get REMOTE_USER=broder@… instead of unset.

comment:2 Changed 14 years ago by quentin

I agree that we should make this change, but I think we should look more closely to identify users whose sites might be broken by this change and mail them about it first.

--Quentin

comment:3 Changed 13 years ago by andersk

  • Resolution set to fixed
  • Status changed from new to closed

We decided a week ago to announce a date for disabling this on the blog. That date has now passed.

If anyone is interested in publicizing this more widely (linking to the blog), feel free.

Note: See TracTickets for help on using tickets.