客户端是通用浏览器密钥不安全，解决办法只能用国密浏览器吗？否则密钥就存在高风险？

从新版的FAQ就能看出来了，鼓励用国密算法，非国密算法最高只能给到0.25
这个就要考虑高风险的适用时了，FAQ中应该有类似解答，具体场景不太一样，我们不能直接帮您判定是否存在高风险或者是否能够缓解
国密浏览器真的会对协商的会话密钥进行保护吗，测试过一些也都是跟通用浏览器一样把会话密钥放计算机缓存里。如果是这样的话，为什么国密浏览器的K就给√，通用浏览器就给×呢。如果硬要这么判，只能理解为给出这个结论是从产品合规角度，而不是密钥安全角度。

如果是双向鉴别场景，协商的会话密钥难道就会存到ukey中吗？测试过仍然是放到计算机缓存里。当然这个测试可能只是特例，或者厂商没有按照标准研制产品。
确实有疑问，假设另一个场景，就是非国密浏览器直接和应用服务器直接建立通道，站点证书放中间件中，那这种协商过程判高风险吗，这是很多系统常用部署场景。如这种情况不判高风险，那和部署了合规VPN情况的得分一样咯。
测评过程发现app直接走私有协议，报文全加密，现在不允许对app进行逆向的情况，对于网络和通信安全层面各指标，应该如何去判定？
关键是这种情况风险如何判定？
证书放中间件，因为中间件没有产品认证证书，所以K给不了分，是否高分险，就…[呲牙][呲牙]
这样怎么过密评[捂脸]
一般 安全认证网关 也可以代理 RSA的证书的呀 做双协议兼容
把中间件的证书+私钥提取出来 放到安全认证网关去
厂商实现有时候一言难尽 明明界面配置里边只有国密协议，但底层还会开放 RSA协议依旧可以访问服务 建立链接[脸红]
如果在中间件和在VPN中一样的得分，并且都没高风险情况下，与鼓励使用密码产品相违背了[抠鼻]
尽快出过检的国密中间件，可能可以解决这些问题
国密中间件 这个有呀看见过几个了
有过检测的中间件，只不过是一级的
一级
是的
绝大部分安全认证网关可以双代理。优先国密，不匹配就自动降为非国密