Actions
Bug #4324
closedHAproxy and SSL client certificate validation
Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
01/27/2015
Due date:
% Done:
0%
Estimated time:
1.00 h
Plus Target Version:
Affected Version:
2.1.5
Affected Plus Version:
Affected Architecture:
All
Description
I just stumbled upon something with HAproxy that is probably not the expected/intended behavior when building an ACL :
- "SSL client certificate valid." → Even though it generates a static string "ssl_fc_has_crt ssl_c_verify 0", it still requires a value
- Minor annoyance, that should probably be changed.
- "SSL client certificate valid." → When using the generated condition "ssl_fc_has_crt ssl_c_verify 0", I noticed a huge problem with most browsers :
- Browsers don't send the client certificate all the time, which leads this condition to fail.
- This does not take in account the cached client certificate in the session.
Following the documentation :
ssl_c_used : boolean Returns true if current SSL session uses a client certificate even if current connection uses SSL session resumption. See also "ssl_fc_has_crt". ssl_fc_has_crt : boolean Returns true if a client certificate is present in an incoming connection over SSL/TLS transport layer. Useful if 'verify' statement is set to 'optional'. Note: on SSL session resumption with Session ID or TLS ticket, client certificate is not present in the current connection but may be retrieved from the cache or the ticket. So prefer "ssl_c_used" if you want to check if current SSL session uses a client certificate.
I worked around the problem on my side by creating a custom ACL that checks not only the front connection, but the whole session :
ssl_c_used ssl_c_verify 0
For the (hopefully) few people who still have a need for SSLv3 (i.e no TLS tickets) in this day, this should cover every case :
ssl_c_used ssl_c_verify 0 or ssl_fc_has_crt ssl_c_verify 0
Actions