Forum Discussion
Maudigan
Altocumulus
AltocumulusRevocation Status in HTTP Request Header
I'm setting up a web app that will use the EDIPI to validate my user's accounts. I think I have a working udnerstanding of how that'll work--I'm going to be setting up a iRule to forward the users ED...
CAC sites tend to be locked down. Often they'd prefer that if the user has a revoked CAC that the site simply refuse to issue ANY HTTP response to them at all, which is definitely the most secure position. Typically the less information you send to an unauthorized user, the better. However, if you set it up this way (clientssl set to require client cert), then the site appears broken to users with a bad CAC.
A slightly less secure one would be to have BIG-IP respond with a "CAC auth failed" kind of message and not forward the request to the server. This way the site doesn't seem completely broken to invalid users, which makes user support easier. But it gives attackers more information. It's a trade-off.
BIG-IP can easily facilitate either of these positions by configuring the clientssl profile to request (validate the cert, allow the associated HTTP request), or it can be set to require (validate the cert, shutdown the connection if the cert is not valid). I'd recommend reading this article to get an understanding of how to set that up to meet your requirements.
To answer your question directly though, the fired events would look like this depending on the request/require setting:
Cert Bad Cert Good clientssl client cert = Request CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x clientssl client cert = Require CLIENTSSL_HANDSHAKE CLIENTSSL_HANDSHAKE,HTTP_REQUEST_x
Lucas_Thompson
Employee
EmployeeCAC sites tend to be locked down. Often they'd prefer that if the user has a revoked CAC that the site simply refuse to issue ANY HTTP response to them at all, which is definitely the most secure position. Typically the less information you send to an unauthorized user, the better. However, if you set it up this way (clientssl set to require client cert), then the site appears broken to users with a bad CAC.
A slightly less secure one would be to have BIG-IP respond with a "CAC auth failed" kind of message and not forward the request to the server. This way the site doesn't seem completely broken to invalid users, which makes user support easier. But it gives attackers more information. It's a trade-off.
BIG-IP can easily facilitate either of these positions by configuring the clientssl profile to request (validate the cert, allow the associated HTTP request), or it can be set to require (validate the cert, shutdown the connection if the cert is not valid). I'd recommend reading this article to get an understanding of how to set that up to meet your requirements.
To answer your question directly though, the fired events would look like this depending on the request/require setting:
| Cert Bad | Cert Good | |
| clientssl client cert = Request | CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x | CLIENTSSL_HANDSHAKE, HTTP_REQUEST_x |
| clientssl client cert = Require | CLIENTSSL_HANDSHAKE | CLIENTSSL_HANDSHAKE,HTTP_REQUEST_x |
MaudiganAwesome, Thanks again!