bypassing client authentication

Hi Skuba,

 

 

I'm working on an iRule which does this and a bit more. Maybe when I finish testing it I can post it to the Codeshare.

 

 

In the meantime, if you want to selectively request or require a client cert, you'll need to set the SSL profile client cert option to none and then use an iRule to check the requested URI and renegotiate the SSL handshake using SSL::renegotiate for specific URIs. The SSL::renegotiate wiki page has a very simplified example (Click here).

 

 

Aaron

hi

 

 

thanks for your reply. i've just been looking at the example, and i think we need something similar but even more simplistic. such as...

 

 

when HTTP_REQUEST {

 

if {[HTTP::uri] starts_with "/abc/" } {

 

***something to route traffic straight to pool members bypassing client authentication***

 

}

 

else {}

 

***client is forced to authenticate***

 

}

 

 

any tips/advice would be appreciated

 

 

thanks

That's pretty much what the wiki page example does. Just reverse the logic for the check of the URI.

 

 

Aaron

would something like this do the trick? the clients would eventually go on to the same back end pool, don't know if i could just reference it once at the bottom?

 

 

cheers

 

 

when CLIENTSSL_HANDSHAKE {

 

if { [SSL::cert count] > 0 } {

 

HTTP::release

 

}

 

pool serverpool

 

}

 

 

when HTTP_REQUEST {

 

if {[SSL::cert count] == 0} {

 

HTTP::collect

 

SSL::authenticate always

 

SSL::authenticate depth 9

 

SSL::cert mode require

 

SSL::renegotiate

 

}

 

pool serverpool

 

}

I think you could start with something like this:

 
 when CLIENTSSL_HANDSHAKE { 
   if { [SSL::cert count] > 0 } { 
     HTTP::release 
   } 
 } 
  
 when HTTP_REQUEST { 
   if {not ([HTTP::uri] starts_with "/abc/") } { 
     if {[SSL::cert count] == 0} { 
       HTTP::collect 
       SSL::authenticate always 
       SSL::authenticate depth 9 
       SSL::cert mode require 
       SSL::renegotiate 
     } 
   } 
 } 
 

Aaron

hi aaron

 

 

why do you have to specify the SSL:: options? won't these be picked up in the actual client ssl profile that already exists? if not, why don't you need to specify the actual CA and CRL in the irule?

 

 

thanks for all your help

The clientssl profile you add to the virtual server should have client cert set to ignore and then the iRule dynamically requests (or requires) a client cert for specific URIs using the SSL:: commands.

 

 

If you set the cert mode to require, a client who doesn't send a cert when it's prompted will receive a TCP reset. If you want to handle this more gracefully, you could set the profile to request and then have the app send a response if no cert is present.

 

 

You'll probably want to insert the client cert in the session table and include some details about the cert in the HTTP headers in requests to the pool. This way the pool member can validate the cert before allowing the request. This could also be done in the iRule using the clientssl profile's Trusted CA cert field and the SSL::verify command.

 

 

Aaron

it was the irule vs. client profile that was confusing me, but that makes sense now

 

 

thanks a lot aaron!

aaron

 

 

one last question...

 

 

can you explain what this part actually does?...

 

 

when CLIENTSSL_HANDSHAKE {

 

if { [SSL::cert count] > 0 } {

 

HTTP::release

 

}

 

}

 

 

i guess it's saying, if the client offers a certificate then release the data. but according to the wiki, the CLIENTSSL_HANDSHAKE is triggered when a client-side SSL handshake has actually been completed

 

 

in addition, i don't know why this is required and what effect it has on the second part of the irule?

 

 

thank you

CLIENTSSL_HANDSHAKE is triggered when the clientside SSL handshake is completed. SSL::cert count returns the number of client certs in the request. If there is one or more certs, then the HTTP held from when HTTP::collect was called is released and the request continues.

 

 

Aaron