os-OPNWAF with Client Certificate Authentication should send certificate information to remote destinations

[0x646f6d]

• [ x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md
• [ x] I have searched the existing issues, open and closed, and I'm convinced that mine is new.
• [ x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe. The remote destination needs information about the client certificate (SSL_CLIENT_S_DN, SSL_CLIENT_I_DN) used for the mTLS communication for autorisation. This should be provided if client certificate authentication is activated.

Describe the solution you'd like If client certificate authentication is activated, the following lines should be appended in apaches configuration:

<VirtualHost ...>
   ...

   # initialize the special headers to a blank value to avoid http header forgeries
   RequestHeader set SSL_CLIENT_S_DN    ""
   RequestHeader set SSL_CLIENT_I_DN    ""
   RequestHeader set SSL_SERVER_S_DN_OU ""
   RequestHeader set SSL_CLIENT_VERIFY  ""

   <Location />
     # add all the SSL_* you need in the internal web application
     RequestHeader set SSL_CLIENT_S_DN "%{SSL_CLIENT_S_DN}s"
     RequestHeader set SSL_CLIENT_I_DN "%{SSL_CLIENT_I_DN}s"
     RequestHeader set SSL_SERVER_S_DN_OU "%{SSL_SERVER_S_DN_OU}s"
     RequestHeader set SSL_CLIENT_VERIFY "%{SSL_CLIENT_VERIFY}s"

     ...
   </Location>
</VirtualHost>

Describe alternatives you've considered None. This is also the behaviour of nginx-plugin an can be used as a default option.

Additional context Resources:

• https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
• http://www.zeitoun.net/articles/client-certificate-x509-authentication-behind-reverse-proxy/start

[AdSchellevis]

adding some standard headers for the application behind the proxy is practical indeed, just leaving some notes here for further processing on our end.

Removing the header should probably use (https://httpd.apache.org/docs/2.4/mod/mod_headers.html):

RequestHeader unset XXXX

It's probably a good idea as well to check RFC's for naming, e.g. sending the client ip is standardized in rfc7239 (https://datatracker.ietf.org/doc/html/rfc7239), I wouldn't be surprised if the same is the case for sending TLS attributes to the server (at least they should all start with X- to make their origin explicit)

[AdSchellevis]

@0x646f6d I have an update available offering a PassTLSHeaders option in locations, don't want to change any defaults, but this should offer what you need. If you want to test this before release, just drop an email to support at opnsense dot com referring this ticket.

[0x646f6d]

Your update seems to work fine, thanks a lot! but I stumbled over a problem: underscores are obviosly not standard or common for http headers, nginx just drops them. I couldn't find good resources, but the problem arised already:

• https://dev.to/thesameeric/dont-use-underscores-in-your-http-headers-gfp
• https://stackoverflow.com/questions/22856136/why-do-http-servers-forbid-underscores-in-http-header-names
• https://serverfault.com/questions/586970/nginx-is-not-forwarding-a-header-value-when-using-proxy-pass

Yes, there are workarounds, but I think it should be done right in the first place. I adjusted the apache conf by hand and replaced the _ with -: it works fluently!

Just for your information (I know I am late for that, but I am pretty busy...): I previously used the nginx plugin of opnsense. This plugin attaches the headers by default and named them:

• X-Tls-Cipher
• X-Tls-Protocol
• X-Tls-Sni-Host
• X-Client-Dn
• X-Client-Verify

...but I don't know if they are standardized or not.

[AdSchellevis]

@0x646f6d I couldn't find formalized headers, but I also don't mind replacing the underscores and change the help text. To keep these more or less consistent with upstream documentation I do prefer to leave the names as they are to avoid confusion (X-Tls-Cipher isn't a standard as far as I could find)

[AdSchellevis]

@0x646f6d I've updated the software on our end, if you would like an updated version, just let me know and I'll send you a new link.