Client Certificate Authentication w/ specific url's?

Hi JC,

 

 

You can do selectively request a client cert based on the URI using the SSL::renegotiate command. Selective client cert requesting by URI is not a simple thing to do in an iRule, but there are a few examples in the forums and the Codeshare.

 

 

Are you planning on upgrading to 10.1 or 10.2 any time soon? If so, the process is a little simpler as LTM caches the cert for you. On 9.x and 10.0.x, you'd need to use the session table to store the cert in order to handle resumed SSL sessions.

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/ssl__renegotiate

 

http://devcentral.f5.com/wiki/default.aspx/iRules/client_cert_request_by_uri_with_ocsp_checking.html

 

http://devcentral.f5.com/wiki/default.aspx/iRules/RequestClientCertificateAndPassToApplication.html

 

 

However, there are some additional security concerns and a potentially easier method for implementing this. First, if you allow renegotiation of the SSL handshake, you open yourself up to a vulnerability in the SSL (or TLS) protocol. This is described in CVE-2009-3555:

 

 

CVE-2009-3555

 

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3555

 

 

Another option for implementing selective client cert requesting would be to use a new subdomain which requests a client cert for all URIs. You could then use an iRule on the main VS which redirects requests for the URIs you want a client cert for to the new subdomain. A separate iRule on the new subdomain VS would request a client cert for all URIs. You could use the same pool for both VSs, so it's possible that you wouldn't need to make any changes to the application. This should allow you to avoid SSL renegotiation and the plaintext injection vulnerability.

 

 

Depending on what approach and LTM version you want to use, we can provide you with more detailed examples. Jason and I were discussing doing a few articles on SSL based iRules. Maybe this could be a use case for one.

 

 

Aaron

Thx Hoolio! We are not planning on upgrading to 10.1/10.2 until next year sometime. After reviewing some of your recommended options, it seems that we would rather avoid any vulnerabilities if possible and go with trying the subdomain approach first. The OCSP article looked interesting but required a 9.4.8 HF3 upgrade which we are not ready to do just yet. We certainly don't mind being a case study, in hopes we can collectively find a good solution in the end. Do you have an example of the subdomain method you mentioned earlier? This sounds like it might work well, the part I'm a little confused is if we create a new subdomain VS for all Client Certificate Authentication do we only redirect the specific URI's from the main VS to this one? In other words, if our client hits https://www.abc123...rvice.asmx on the main VS and gets redirected to https://www.abc321...rvice.asmx on the new subdomain VS using CCA (2-way ssl) and works as expected. However, if the same client hits https://www.abc123.com/ClaimService on the main VS would he get redirected as well? And at that point can he just use normal SSL certificate authentication to connect to this service?

 

 

"Another option for implementing selective client cert requesting would be to use a new subdomain which requests a client cert for all URIs. (So are you saying create a new subdomain VS for all CCA URI's).

 

 

You could then use an iRule on the main VS which redirects requests for the URIs you want a client cert for to the new subdomain. (Place an iRule redirect on the main VS to redirect the specific URI's to the new subdomain VS).

 

 

A separate iRule on the new subdomain VS would request a client cert for all URIs. (Place another iRule on the new subdomain VS to allow CCA on this VS).