客户端获取配置的加密算法存在弱加密算法，存在安全风险

[maweibin]

你好，请问客户端获取配置的接口的签名算法，当前是HmacSHA1，属于弱加密算法。接口本身属于微服务配置拉取，可能存在敏感配置，弱加密算法可能会存在安全风险。
同时也考虑兼容性的问题，不知道是否可以支持允许同时校验HmacSHA1或者HmacSHA256，优先使用HmacSHA1，解密失败就再次使用HmacSHA256校验，来提升客户端的弱加密算法。
同时是否可以记录存在HmacSHA1的校验的一些记录，方便推动弱加密算法的客户端进行升级。

[github-actions]

🤖 感谢反馈这个安全加固建议。

关于客户端配置接口签名算法从 HmacSHA1 升级到 HmacSHA256 的提议，已标记为安全相关的功能增强请求。您提到的渐进式迁移方案（同时支持两种算法并记录弱算法使用情况）是个不错的兼容性思路。

维护者会评估具体实现方案，包括：

• 客户端与服务端的协议升级路径
• 兼容性策略（fallback 机制）
• 是否需要配置开关控制
• 监控与日志记录

如果您有更多技术细节（如具体的接口路径、当前使用的 Apollo 版本等），欢迎补充，这将有助于加快评估。

AI generated by Apollo Issue Triage

[nobodyiam]

这个方向具有长期价值，但结合当前风险与实现成本，我们暂不将其视为高优先级安全修复。SHA-1 的碰撞问题不能直接等同于 HMAC-SHA1 已可被伪造，同时 AccessKey 签名只负责请求鉴权和完整性，敏感配置的传输保密仍应由 HTTPS/TLS 保证。

从算法演进和合规角度，Apollo 后续应支持 HmacSHA256。考虑到这会涉及 apollo-java、apollo-configservice、协议兼容和多语言客户端，建议先完成轻量协议设计：为签名增加明确的算法/版本标识，保留未标识请求作为 legacy HmacSHA1，并定义服务端先升级、客户端后启用的顺序。实现可以结合下一次客户端协议升级推进，不建议现阶段直接引入无标识的双算法 fallback 和复杂迁移平台。

如果存在明确的合规要求、安全基线阻塞或当前 HmacSHA1 的实际攻击证据，欢迎补充，我们可以据此重新评估优先级。

[maweibin]

@nobodyiam 你好，再咨询一下。客户端获取配置的时候，都是先通过configservice的接口获取configservice服务的应用节点，而configservice在注册的时候会默认注册8080端口。请问这个可以怎么改为注册nginx代理的ip，让客户端拉取配置的接口都可以走nginx代理。

[nobodyiam]

可以，不需要修改源码。你当前描述的是 Eureka 服务发现模式：客户端请求 Meta Service 的 /services/config 后，拿到的是 ConfigService 实例注册到 Eureka 的 homePageUrl。

如果希望所有客户端都通过 Nginx，而且不想逐个修改客户端配置，可以在每个 apollo-configservice 的启动参数中把注册 URL 设置为 Nginx 地址：

-Deureka.instance.homePageUrl=https://apollo-config.example.com/
-Deureka.instance.preferIpAddress=false

或使用环境变量：

EUREKA_INSTANCE_HOME_PAGE_URL=https://apollo-config.example.com/
EUREKA_INSTANCE_PREFER_IP_ADDRESS=false

这样 ConfigService 实例仍然以各自节点注册到 Eureka，但 /services/config 返回给客户端的访问地址会是 Nginx，后续配置拉取和长轮询都会经过 Nginx。官方部署文档也提供了相同的注册 URL 配置方式。

如果允许修改客户端，也可以直接指定：

-Dapollo.config-service=https://apollo-config.example.com/

或：

APOLLO_CONFIG_SERVICE=https://apollo-config.example.com/

这种方式会跳过 Meta Service 服务发现，由 Nginx 负责 ConfigService 的负载均衡和高可用。该配置适用于 apollo-client 0.11.0+；apollo-client 1.9.0+ 使用 apollo.config-service，更早版本使用 apollo.configService。参见客户端文档。

结合你的目标，优先推荐第一种注册 URL 方案，客户端不需要逐一改造。

Nginx 配置还需要注意：

1. 必须代理 /configs/、/configfiles/ 和 /notifications/v2。
2. 不要修改原始 path 和 query。AccessKey 签名包含 path 和 query，增加或删除路径前缀可能导致 401 Unauthorized。
3. 不要过滤 Authorization 和 Timestamp 请求头。
4. 长轮询服务端等待约 60 秒，建议将 proxy_read_timeout 配置为 120s。
5. 建议使用独立域名的根路径进行代理，同时启用 HTTPS 和访问控制。

如果使用的是 Apollo 3.0 默认的 database-discovery，则应改用：

apollo.service.registry.uri=https://apollo-config.example.com/

而不是 Eureka 的 homePageUrl。

[maweibin]

@nobodyiam 非常详细，非常感谢，谢谢！