Bug #4324: HAproxy and SSL client certificate validation - pfSense Packages - pfSense bugtracker

Actions

Copy link

Bug #4324

closed

HAproxy and SSL client certificate validation

Added by Stéphane Lapie about 10 years ago. Updated about 10 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Category:

Target version:

Start date:

01/27/2015

Due date:

% Done:

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

Copy link

Updated by Pi Ba about 10 years ago

Thanks for reporting this, my suspicion is that 'ssl_c_used ssl_c_verify 0' would be enough for all cases.

Have you confirmed that the second combination 'ssl_c_used ssl_c_verify 0 or ssl_fc_has_crt ssl_c_verify 0' is actually required in some cases? That would complicate the 'Client certificate verify error result' acl..

Actions

Copy link

Updated by Stéphane Lapie about 10 years ago

No, I haven't. In my production settings, I am only using "ssl_c_used" since I can guarantee for sure we are in a TLS environment.

I just wrote the or expression "to make 100% sure nothing is forgotten", but I honestly think this is overkill.
My personal understanding is that "ssl_c_used" encompasses also any case also handled by "ssl_fc_has_crt", but I didn't probe the source code to confirm whether this is the case or not (because then, this would then put in question why "ssl_fc_has_crt" still exists... unless it's only 100% for compatibility reasons)

Actions

Copy link

Updated by Stéphane Lapie about 10 years ago

Just reporting another little very minor thing, I am testing the latest version for which you added ACL negation and a lot of stuff I talked to you about on IRC the other day, I fumbled a bit before figuring out you now have to actually register a "None" entry on top of the desired client certificate CA. :) Also, any other CA that was declared before will now force "verify required", it seems, which was a bit surprising.
I had to look at the code in haproxy.inc to figure out for sure that this was what happened :)

Actions

Copy link

Updated by Pi Ba about 10 years ago

Could you checkout 0.17 package?(or perhaps 0.18) I've changed the 'none' CA to a separate checkbox which probably makes more sense (with config convert code in place for that.).. Also the ssl_c_used and required value for checking a valid certificate have been changed. No more duplicate acl's should be written as well..

I'm kinda hoping its now 'mostly' feature complete and features present work properly to copy it to a 'stable' version.

Thanks for the feedback.

Actions

Copy link

Updated by Stéphane Lapie about 10 years ago

Quick question, what is the proper way to install a development package?
The interface only allows me to install up to 1.5.9 v0.16.
I'll gladly test the latest version on my test environment.

As for features, I have created a ticket (#4394) for one little thing that I thought might make HAproxy further complete.
I'd like to hear your opinion if it's no trouble.

Thanks again for your time and the awesome work !

Actions

Copy link

Updated by Pi Ba about 10 years ago

There is no public 'development' repository to install developing packages from, however the official package repository should have had 0.17 available yesterday, by now it is updated to 0.18. So simply re-installing haproxy-devel package should give you the updated version.. (with no easy way back either..).

Actions

Copy link