Home / user-7343

pra's questions

Martin Hope
pra
Asked: 2011-01-20 09:03:17 +0800 CST
  • 1

Is it possible to recreate the functionality of pam_userdb.so to make an application authenticate virtual users (valid for one specific service only) on Solaris?

Situation is: higher-ups have dictated that we use a file distribution tool that only supports password-based authentication, and transfers passwords in the clear. Because of the amount of data that will be transferred, using SSL tunnels is impractical.

The application is pam-aware so we can configure a special authentication stack for it. On our linux servers, we configure pam_userdb to use a separate passwd database so no one can use the password to login direcctly:

someapp auth sufficient pam_userdb.so db=/etc/someapp-passwd try_first_pass

There seems to be no equivalent on Solaris.

solaris security user-management
Martin Hope
pra
Asked: 2010-01-12 16:33:26 +0800 CST
  • 0

One of our partners is using Microsoft Web Services 2.0 to connect to our webservices through Apache HTTPD 2.0 reverse-proxies. The resource they're POSTing to requires client (mutual) ssl authentication:

<Location /SecuredArea>
    SSLVerifyClient require
    SSLDepth 10
    SSLCACertificatePath /path/to/clientcas
    SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
                 and %{SSL_CLIENT_S_DN_CN} in { "List", "of", "accepted" "names" } \
    }
</Location>

Soon we noticed that requests arriving less than about 1 minute apart would fail. The web client returned Could not create SSL/TLS secure channel.

The apache error logs showed:

[debug] ssl_engine_kernel.c(1893): OpenSSL: Write: SSLv3 read client hello B
[debug] ssl_engine_kernel.c(1912): OpenSSL: Exit: error in SSLv3 read client hello B
[error] [client 12.34.56.78] Re-negotiation handshake failed: Not accepted by client!?

The access log showed:

12.34.56.78 - - [11/Jan/2010:13:58:39 -0500] "POST /SecuredArea HTTP/1.1" 403 - "-" "Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.3603)"

Since the partner was connecting to several other sites without issues, they were not interested in troubleshooting their end. I don't know how their other peers are configured or even what they're running.

I tried all the workarounds for this apache bug, including upgrading a test server to Apache 2.2.

I was also seeing bad PUTs in the Inter-Process Session Cache caused by large session sizes. Changing SSLSessionCache from dbm to shmcb cleared those up, but did not resolve the actual issue.

Finally, I found two fixes:

  1. Get rid of the SSL re-negotiation by moving SSLVerifyClient up to VirtualHost context. Since the rest of the resources under the VirtualHost aren't intended to be under client authentication, this means setting up a separate host for one resource.

  2. Comment out BrowserMatch ".\*MSIE.\*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 I'm concerned that removing this will have unintended consequences down the road.

The question is, which of these solutions is better? Or is there yet another one? If this site will never have living & breathing users, how risky is removing the BrowserMatch settings?

apache-2.2 web-server ssl