[GH-ISSUE #3992] [Feature Request] Customize the tls.Config used in HTTPProxyConf

gitea-mirror commented

2026-05-05 14:02:59 -06:00

Owner

Copy link

Originally created by @clarkmcc on GitHub (Feb 14, 2024).
Original GitHub issue: https://github.com/fatedier/frp/issues/3992

Describe the feature request

After upgrading to Go 1.22 I can no longer initiate proxy connections to some devices using some of the cipher suites deprecated in Go 1.22. I was able to resolve this issue in my application by customizing the cipher suites used in the tls.Config, however, I don't see any ability to do this within FRP.

Is there a solution or workaround? I'm using FRP as an embedded library.

Describe alternatives you've considered

No response

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @clarkmcc on GitHub (Feb 14, 2024). Original GitHub issue: https://github.com/fatedier/frp/issues/3992 ### Describe the feature request After upgrading to Go 1.22 I can no longer initiate proxy connections to some devices using some of the cipher suites [deprecated in Go 1.22](https://tip.golang.org/doc/go1.22). I was able to resolve this issue in my application by customizing the cipher suites used in the `tls.Config`, however, I don't see any ability to do this within FRP. Is there a solution or workaround? I'm using FRP as an embedded library. ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [X] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [X] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror added the

proposal

label 2026-05-05 14:02:59 -06:00

gitea-mirror commented

2026-05-05 14:03:01 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 19, 2024):

By default, cipher suites without ECDHE support are no longer offered by either clients or servers during pre-TLS 1.3 handshakes. This change can be reverted with the tlsrsakex=1 GODEBUG setting.

You can revert to the previous behavior by setting the tlsrsakex=1 GODEBUG environment variable from the release notes of golang?

I do not tend to provide configuration capabilities to use some parameters and capabilities that are deprecated by default in Go.

@fatedier commented on GitHub (Feb 19, 2024): > By default, cipher suites without ECDHE support are no longer offered by either clients or servers during pre-TLS 1.3 handshakes. This change can be reverted with the tlsrsakex=1 GODEBUG setting. You can revert to the previous behavior by setting the tlsrsakex=1 GODEBUG environment variable from the release notes of golang? I do not tend to provide configuration capabilities to use some parameters and capabilities that are deprecated by default in Go.

gitea-mirror commented

2026-05-05 14:03:02 -06:00

Author

Owner

Copy link

@clarkmcc commented on GitHub (Feb 19, 2024):

The go:debug route isn't a good long term option because it will eventually be removed. I need to maintain compatibility with third-party IoT devices that are older and may not be upgraded.

For the record, I'm not asking for deprecated features, I'm asking for the ability to customize the TLS config used by the HTTP proxy. Being able to customize the TLS config is useful for many things not just compatibility with cipher suites required by older devices.

I was able to work around this by writing my own plugin, similar to how the http2https plugin works.

@clarkmcc commented on GitHub (Feb 19, 2024): The go:debug route isn't a good long term option because it will eventually be removed. I need to maintain compatibility with third-party IoT devices that are older and may not be upgraded. For the record, I'm not asking for deprecated features, I'm asking for the ability to customize the TLS config used by the HTTP proxy. Being able to customize the TLS config is useful for many things not just compatibility with cipher suites required by older devices. I was able to work around this by writing my own plugin, similar to how the http2https plugin works.

gitea-mirror commented

2026-05-05 14:03:03 -06:00

Author

Owner

Copy link

@fatedier commented on GitHub (Feb 19, 2024):

frp is currently not a fully functional proxy, so it is not suitable to expose configurations like these. Without the support of a unified architecture, this will only make things more complex and difficult to maintain.

However, in the plan for v2, we hope to introduce more such extension capabilities.

In general, this will not be done in the short term, but it may be supported in the long term.

@fatedier commented on GitHub (Feb 19, 2024): frp is currently not a fully functional proxy, so it is not suitable to expose configurations like these. Without the support of a unified architecture, this will only make things more complex and difficult to maintain. However, in the plan for v2, we hope to introduce more such extension capabilities. In general, this will not be done in the short term, but it may be supported in the long term.

gitea-mirror commented

2026-05-05 14:03:04 -06:00

Author

Owner

Copy link

@clarkmcc commented on GitHub (Feb 19, 2024):

Sounds good! The plugin system does meet my needs in the short term.

@clarkmcc commented on GitHub (Feb 19, 2024): Sounds good! The plugin system does meet my needs in the short term.

No Branch/Tag specified