[PR #4722] [CLOSED] Added support for HTTPS client certificate authentication #5037

New issue

Closed

opened 2026-05-05 14:53:29 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 14:53:29 -06:00

Owner

📋 Pull Request Information

Original PR: https://github.com/fatedier/frp/pull/4722
Author: @leogcurvelo
Created: 3/23/2025
Status: ❌ Closed

Base: dev ← Head: dev

📝 Commits (3)

acb53ac Added optional HTTPS client certificate authentication to https2http and https2https
a1532e9 Updated README.md: HTTPS client authentication
b365891 Updated README.md: HTTPS client authentication

📊 Changes

6 files changed (+319 additions, -77 deletions)

View changed files

📝 README.md (+41 -2)
📝 pkg/config/v1/plugin.go (+16 -14)
📝 pkg/plugin/client/https2http.go (+28 -0)
📝 pkg/plugin/client/https2https.go (+28 -0)
📝 pkg/transport/tls.go (+26 -0)
📝 test/e2e/v1/plugin/client.go (+180 -61)

📄 Description

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:
https://github.com/fatedier/frp/issues/3242#issuecomment-1374694878
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:

[[proxies]]
name = "web"
type = "https"
customDomains = ["test.example.com"]

[proxies.plugin]
type = "https2http"
localAddr = "127.0.0.1:80"
crtPath = "server.crt"
keyPath = "key.pem"
clientCertificates = ["authorizedClient1.cert"]

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.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/fatedier/frp/pull/4722 **Author:** [@leogcurvelo](https://github.com/leogcurvelo) **Created:** 3/23/2025 **Status:** ❌ Closed **Base:** `dev` ← **Head:** `dev` --- ### 📝 Commits (3) - [`acb53ac`](https://github.com/fatedier/frp/commit/acb53acb2e729ced5282a263c8940a575bd2d763) Added optional HTTPS client certificate authentication to https2http and https2https - [`a1532e9`](https://github.com/fatedier/frp/commit/a1532e90759d0bb191e0dcdb5b367be09292166b) Updated README.md: HTTPS client authentication - [`b365891`](https://github.com/fatedier/frp/commit/b365891b433a3ace5c58dfe8c59199a30b89f363) Updated README.md: HTTPS client authentication ### 📊 Changes **6 files changed** (+319 additions, -77 deletions) <details> <summary>View changed files</summary> 📝 `README.md` (+41 -2) 📝 `pkg/config/v1/plugin.go` (+16 -14) 📝 `pkg/plugin/client/https2http.go` (+28 -0) 📝 `pkg/plugin/client/https2https.go` (+28 -0) 📝 `pkg/transport/tls.go` (+26 -0) 📝 `test/e2e/v1/plugin/client.go` (+180 -61) </details> ### 📄 Description ### 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: https://github.com/fatedier/frp/issues/3242#issuecomment-1374694878 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: ```toml [[proxies]] name = "web" type = "https" customDomains = ["test.example.com"] [proxies.plugin] type = "https2http" localAddr = "127.0.0.1:80" crtPath = "server.crt" keyPath = "key.pem" clientCertificates = ["authorizedClient1.cert"] ``` 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](https://github.com/user-attachments/assets/ec436752-5665-403c-81b0-8246762cbf55) 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. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>