Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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?


share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

1.) is recommended because of this, so #1 is a good idea anyway.

share|improve this answer
    
Yes, I've seen that, but I thought that a fixed openssl was coming soon. After reading openssl.org/news/secadv_20091111.txt & openssl.org/news/state.html again I'm not so sure. –  pra Jan 12 '10 at 5:50
    
The "fix" that is currently available is to disable renegotiation completely. There is a draft RFC that proposes a fix to SSL itself; I understand that recent snapshots of openssl implement this draft RFC. But both the client and server need to implement this fix, and you only control the server side, so I agree it will be awhile before it's out there. option #1 seems to solve all your problems. –  GregS Jan 13 '10 at 2:35
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.