[GH-ISSUE #4654] [Feature Request] Encrpyt the `Login` msg with pre-defined shared secret

gitea-mirror commented

2026-05-05 14:21:34 -06:00

Owner

Originally created by @bigcat88 on GitHub (Jan 31, 2025).
Original GitHub issue: https://github.com/fatedier/frp/issues/4654

Describe the feature request

Hello, I would like to thank you in advance for your contribution to open source.

We are considering using your product for some of our open source tasks, and a couple of questions about security have arisen.

In func (svr *Service) login() we see the following transmission of the first login message from FRPc to FRPs:

	loginMsg := &msg.Login{
		Arch:      runtime.GOARCH,
		Os:        runtime.GOOS,
		PoolCount: svr.common.Transport.PoolCount,
		User:      svr.common.User,
		Version:   version.Full(),
		Timestamp: time.Now().Unix(),
		RunID:     svr.runID,
		Metas:     svr.common.Metadatas,
	}
	if svr.clientSpec != nil {
		loginMsg.ClientSpec = *svr.clientSpec
	}

	// Add auth
	if err = svr.authSetter.SetLogin(loginMsg); err != nil {
		return
	}

	if err = msg.WriteMsg(conn, loginMsg); err != nil {
		return
	}
}

Perhaps I did not fully understand their sources, but it seems to me that this message is encrypted only at the TCP level with the built-in TCP TLS.

If so, then a fairly simple attack is possible with control over the data transfer channel.

To make the hacking task more difficult, it is possible to encrypt this Login message with a hash from a "token"(which will not be transmitted over the network), but which is known to both the server and the client.

My suggestion is to optionally introduce an additional key/token for this, and use something like AES-GCM for Encrypting the Login message

I hope I haven't missed anything obvious in the source code, correct me if I'm wrong.

Describe alternatives you've considered

If there are any ways other than generating custom TLS certificates for this (and do they work for Login messages?), I'd be glad to hear it.

Affected area

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

Originally created by @bigcat88 on GitHub (Jan 31, 2025). Original GitHub issue: https://github.com/fatedier/frp/issues/4654 ### Describe the feature request Hello, I would like to thank you in advance for your contribution to open source. We are considering using your product for some of our open source tasks, and a couple of questions about security have arisen. In `func (svr *Service) login()` we see the following transmission of the first login message from FRPc to FRPs: ``` loginMsg := &msg.Login{ Arch: runtime.GOARCH, Os: runtime.GOOS, PoolCount: svr.common.Transport.PoolCount, User: svr.common.User, Version: version.Full(), Timestamp: time.Now().Unix(), RunID: svr.runID, Metas: svr.common.Metadatas, } if svr.clientSpec != nil { loginMsg.ClientSpec = *svr.clientSpec } // Add auth if err = svr.authSetter.SetLogin(loginMsg); err != nil { return } if err = msg.WriteMsg(conn, loginMsg); err != nil { return } } ``` Perhaps I did not fully understand their sources, but it seems to me that this message is encrypted only at the `TCP level` with the built-in TCP `TLS`. If so, then a fairly simple attack is possible with control over the data transfer channel. To make the hacking task more difficult, it is possible to encrypt this `Login` message with a hash from a "token"(which will not be transmitted over the network), but which is known to both the server and the client. **My suggestion is to optionally introduce an additional key/token for this, and use something like `AES-GCM` for Encrypting the Login message** *I hope I haven't missed anything obvious in the source code, correct me if I'm wrong.* ### Describe alternatives you've considered If there are any ways other than generating custom `TLS` certificates for this (_and do they work for Login messages?_), I'd be glad to hear it. ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [x] Security - [ ] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 14:21:35 -06:00

gitea-mirror commented

2026-05-05 14:21:36 -06:00

Author

Owner

@bigcat88 commented on GitHub (Feb 4, 2025):

Sorry for bothering, we checked, with self-signed certificates if we specify Trusted CA - the MiTM attack we were thinking about is not possible.

Thank you for your software, we will use it :)

@bigcat88 commented on GitHub (Feb 4, 2025): Sorry for bothering, we checked, with self-signed certificates if we specify Trusted CA - the MiTM attack we were thinking about is not possible. Thank you for your software, we will use it :)