Forum Discussion
NimbostratusDealing with SSL client cert auth and long-running connections
Hi everyone.
We have a SSL VS that requires SSL client certificate authentication. We use an iRule to store the client certificate used for authentication in the SSL session so we can inject it as a HTTP header into server-side requests.
We have an interesting problem that goes along the lines of:
1. Client connections, performs SSL handshake and authenticates
2. We store their client certificate in the SSL session
3. Client sends HTTP request, and then keeps sending TCP keepalives to hold the connection open
4. The socket is then held open for an infinite amount of time and re-used for sending further HTTP requests
5. SSL is never renegotiated
The problem occurs when the client certificate the client used to authenticate with expires in the middle of the long running TCP session. Since SSL is never re-negotiated, we essentially allow the client to continue to send requests despite their certificate having expired.
I'm after thoughts on how we can address this. A few ideas come to mind
1. We could limit the number of HTTP requests over a connection to a certain number using a HTTP profile, but this will adversly affect clients that want to use this functionality with a long-term certificate that hasn't expired
2. We could try and check the expiry on the certificate in each HTTP_REQUEST event, but I cannot see an [SSL] command that allows me to access the expiry in the iRule. Am I missing something ? If we were able to determine it had expired then we could potentially force a SSL renegotiation.
3. We could implement a timer in the iRule and force SSL re-negotiation if it hasn't occured in the past 24 hours, which at least would limit the scope of the problem. I could store a "last time we authenticated this connection" away in the SSL session and check it each HTTP_REQUEST
Anyone come across this same issue before ?
Regards,
Mark.
2 Replies
- Kevin_Stewart
Employee
In short, you cannot know the status of a client certificate without first asking for it, which generally requires an SSL negotiation/re-negotiation. Keep in mind though that TCP, SSL, and HTTP "sessions" are different. You can maintain HTTP sessions over many SSL sessions, and you can maintain SSL sessions over many TCP sessions. Further, if your application is browser-based, it's likely that the SSL re-negotiation and client certificate sending would be transparent to the user.
One other thing to consider, if you still require not renegotiating SSL, is to implement a session table entry per user (perhaps based on the SSL session ID) that holds information about the client's certificate. When the client first negotiates, store the client certificate's validity date via X509::not_valid_after in the table. On ~every HTTP request check this entry and terminate/re-negotiate the session if the user exceeds a predefined session limit or the certificate end date (whichever comes first). 
Mark_Wallis_833Thanks for the reply Kevin.
We already have access to the certificate, and have stored it away in the SSL session so we can pull it back out again in the HTTP_REQUEST event. Our application is B2B based, and doesn't rely on HTTP sessions at all. We do rely on SSL sessions though to ensure that we don't have to rehandshake for every TCP connection.
Thanks for the pointer though to X509::not_valid_after. That is exactly what we need. I'll store it away and check it again on HTTP_REQUEST.
Regards,
M.
