[Feature Request] Customize the tls.Config used in HTTPProxyConf

[clarkmcc]

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
• [X] Security
• [ ] User Experience
• [ ] Test and Release
• [ ] Developer Infrastructure
• [X] Client Plugin
• [ ] Server Plugin
• [ ] Extensions
• [ ] Others

[fatedier]

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.

[clarkmcc]

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.

[fatedier]

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.

[clarkmcc]

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