Added support for HTTPS client certificate authentication #4722
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
WHY
While a proxy of "http" type can be protected by "httpUser" and "httpPassword", no such protection is provided for "https" proxies. This leaves them unprotected in case someone guesses the URL, the URL leaks, or someone looks over your shoulder; as a system administrator, you would want to put yet another reverse proxy in front of the service to protect it, or if possible modify the actual service to ask for username and password.
This lack of support for HTTP Basic Authentication on HTTPS proxies has been talked about as a technical limitation:
#3242 (comment)
And due to my novice skills in Go, I took that to heart and didn't even think of intercepting the encrypted connection, so I turned to the next best thing: HTTPS client certificate authentication, which is done at the TLS configuration level.
This PR adds a new "clientCertificates" configuration to "https2http" and "https2https" plugins, as such:
Multiple, self-signed, certificates can be set in this configuration, and at least one of them will be required to access the service. The client certificate can normally be installed at system-level or at application-level, at the discretion of the user.
Below is a demonstration of the feature using the Vivaldi browser, with a self-signed certificate installed at system-level:
frp_demo.webm
While this form of authentication is not common like Basic Authentication, it does provide security benefits, and I think they're worth considering as well:
https://en.wikipedia.org/wiki/Mutual_authentication#Defenses
Finally, I have updated the README to reflect these changes with instructions; and created two new e2e tests, separate from the existing https2http and https2https tests, specifically for client certificate authentication.