nacos icon indicating copy to clipboard operation
nacos copied to clipboard

cipher-aes 配置文件再次编辑时conetent会变成明文

Open lch-ye opened this issue 1 year ago • 9 comments

When fixing the cipher-aes storage configuration file, only the encrypted content will be stored in the database when the file is first created. Modifying the configuration file again will cause the encrypted content in the database to become plaintex.

  1. go to nacos config craete yaml file.
  2. client on new yaml file , use cipher-aes.
  3. update cipher-aes yaml file, nacos db content changed from ciphertext to plaintext.

修复cipher-aes存储配置文件时,只有首次创建文件才会在数据库中存储加密内容,再次修改配置文件,数据库中的加密内容会变成明文的缺陷问题。

lch-ye avatar Sep 15 '23 09:09 lch-ye

@i will solve it@

E1se2t avatar Sep 20 '23 03:09 E1se2t

https://github.com/alibaba/nacos/blob/84b3afcfcaeefbc66e1d20d2e1911d96efdeec0f/config/src/main/java/com/alibaba/nacos/config/server/controller/ConfigController.java#L147-L173 Why is it necessary to pass the encryptedDataKey when encrypting and publishing configurations? When publishing a configuration in the cipher-aes format, this encryptedDataKey should ideally be generated each time and used to encrypt the content.

I've identified a flaw in the current implementation. During the initial configuration publication, because the encryptedDataKey was not provided, the EncryptionHandler.encryptHandler(dataId, content) function performed encryption on the data. However, in subsequent modification operations, the frontend provided the encryptedDataKey, which resulted in the modified content not being encrypted.

In theory, within EncryptionHandler.encryptHandler(dataId, content) , there is a checkCipher method that validates based on dataId, taking into account scenarios where configurations are published without encryption. Therefore, I believe the conditional check on line 165 may be somewhat redundant

Additionally, it appears that the encryptedDataKey parameter is not needed here. In the case of publishing configurations without encryption, encryptedDataKey should be empty. In the case of encrypting and publishing configurations, generate a new encryptedDataKey

Is there any other context or scenario where this condition is needed? I haven't found any additional information yet. @KomachiSion

E1se2t avatar Sep 20 '23 04:09 E1se2t

it's need to pass encryptedDataKey when encrypting and publishing configurations, otherwise nacos plugin don't know how to encrypt the content.

KomachiSion avatar Sep 25 '23 08:09 KomachiSion

it's need to pass encryptedDataKey when encrypting and publishing configurations, otherwise nacos plugin don't know how to encrypt the content.

image 加密内容是通过插件生成的secretKey和content生成的,跟encryptedDataKey看起来是无关的

E1se2t avatar Sep 25 '23 08:09 E1se2t

image 我认为可以去掉这个判断,每次加密创建&发布配置都会根据secretKey和content生成加密内容

E1se2t avatar Sep 25 '23 09:09 E1se2t

插件有一种情况是在客户端加密后传入服务端。 这种情况传输过程中也是密文。

控制台是因为不支持插件扩展, 所以只能在服务端进行加密,你看起来才是都是在服务端生成的。

KomachiSion avatar Oct 09 '23 03:10 KomachiSion

那就是有两种情况:

  1. 客户端直接加密配置后传入服务端,这个情况传输过程中content也是密文,所以无需再次加密
  2. 控制台发布配置,这个时候需要通过服务端加密

可不可以在ConfigController#searchConfig方法的响应对象ConfigInfo里面加一个字段,用于区分是否是控制台进行的配置发布,这样在控制台发布配置的时候,就能通过这个字段去判断是否需要对content进行加密了,现在的问题就是控制台发布配置的时候encryptedDataKey不为空,导致服务端以为不需要对content进行加密了,是否能加一个字段区分这种控制台发布配置的情况

或者说大佬你还有什么好的方法吗?

E1se2t avatar Oct 10 '23 15:10 E1se2t

主要还是要梳理一下加密插件的工作流,这块之前是 @li-xiao-shuang 做的, 等后面有空了我再和 @shiyiyue1102 等配置中心的大佬一起梳理下吧。

KomachiSion avatar Oct 11 '23 02:10 KomachiSion

想问一下这个问题有进展了吗?二次编辑密文就变明文了

Saoforest avatar Jun 18 '24 02:06 Saoforest

@i will solve it@

在 2.3.2 中还没解决,这都快一年了。

javastacks avatar Jul 05 '24 10:07 javastacks

this bug is fixed in PR https://github.com/alibaba/nacos/pull/12061 and already release in version 2.4.0-beta

shiyiyue1102 avatar Jul 09 '24 08:07 shiyiyue1102