- 综合排序
- 最热优先
- 最新优先
- 来自专栏架构之巅
【appScan】并非所有密码套件均支持完全前向保密解决方案
检测到弱密码：并非所有密码套件均支持完全前向保密（弱密码套件 - ROBOT 攻击：服务器支持易受攻击的密码套件）图片背景介绍HTTP 协议自身没有加密机制，但可以通过和 TLS (Transport 图片漏洞分析漏洞前提：此问题在HTTPS环境下出现弱密码套件 - ROBOT 攻击：服务器支持易受攻击的密码套件原因：使用了过期的TLS/SSL协议，部分TLS/SSL协议由于过于老旧，已经被各类操作系统及浏览器弃用 （SSL所有版本、TLSv1.0、TLSv1.1）图片并非所有密码套件均支持完全前向保密原因：使用了不支持前向加密的密码套件'ssl_ciphers',目前支持前向加密的密码套件第二部分必须为DHE、ECDHE 位，分组模式是 GCM； 摘要算法使用 SHA384；图片 所谓前向加密是指：每一次通信过程的私钥都是临时的，即使某一次通信过程的私钥被破解或者泄露、 其他通信过程的私钥仍然是安全的，因为每个通信过程的私钥都是没有任何关系的 ，都是独立的，这样 就保证了「前向安全」。
8.3K144编辑于 2022-09-29 - 来自专栏雨落秋垣
目前最安全的 HTTPS 的配置方案
在配置TLSv1.2和TLSv1.3时，选择最安全的加密套件需综合考虑现代加密标准、国密算法（如SM2/SM3/SM4）以及前向保密（PFS）特性，同时兼容HTTP/2和HTTP/3（QUIC）。 以下是推荐的配置方案及关键要点：一、加密套件配置原则优先支持TLS1.3TLS1.3默认移除不安全的算法（如RSA密钥交换、CBC模式），强制使用前向保密，且握手效率更高。 国密TLS握手优化在Nginx中启用国密套件：ssl_ciphers'ECDHE-SM2-SM4-GCM-SM3:ECDHE-ECDSA-AES256-GCM-SHA384';三、PQC（后量子密码）算法支持目前 四、HTTP/2与HTTP/3（QUIC）配置HTTP/2需启用TLS1.2+，并确保加密套件支持前向保密：listen443sslhttp2;HTTP/3（QUIC）依赖TLS1.3和QUIC协议，需编译 ;add_headerStrict-Transport-Security"max-age=63072000;includeSubDomains";}注意事项国密兼容性：需确保客户端和服务端均支持国密算法
59100编辑于 2025-11-24 - 来自专栏ZC.TigerRoot
HTTPS 安全最佳实践（一）之SSL/TLS部署
您应该主要依靠提供强身份验证和密钥交换，前向保密和至少 128 位加密的 AEAD 套件。还有一些其他较弱的套房可能仍然得到支持，只要它们只能与不支持任何更好的老客户进行协商。 2.5 使用 FS 前向保密（有时也称为完全前向保密）是一种协议功能，可实现不依赖服务器私钥的安全对话。 对于不提前向保密的密码套件，可以恢复服务器的私钥的人就可以解密所有较早记录的加密对话（也就是可以先大量记录密文，再解密，比如您的证书到期后没有正确销毁，它的私钥就能用来解密非PFS的密文）。 您需要支持并喜欢 ECDHE 套件，以便通过现代网络浏览器实现前向保密。为了支持更广泛的客户，您还应该使用 DHE 套件作为 ECDHE 后备。避免 RSA 密钥交换，除非绝对必要。 我在2.3节中提出的默认配置只包含提供前向保密的套件。
2K21发布于 2020-04-30 - 来自专栏绿盟科技研究通讯
一文读懂https中密钥交换协议的原理及流程
第二次握手 1 Say Hello 当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random RSA密钥交互的缺陷 使用 RSA 密钥协商算法的最大问题是不支持前向保密。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。 图3.2.1 ECDHE流程图 DH 密钥交换过程中，即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密。 四、RSA协议和ECDHE协议对比分析 4.1RSA 和 ECDHE 握手过程的区别 RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密； 使用了 RSA 密钥协商算法，TLS 因此也称此为不具有前向安全性，只要服务端不换证书，那么所有证书范围内的会话都可以进行解密。对于旁路监听流量，拥有全量数据包的情况下，是可以全部解密的 4.3为什么ECDHE模式不可以解密流量包？
11.5K20编辑于 2022-06-06 - 来自专栏全栈程序员必看
HTTP与HTTPS的区别，详细介绍[通俗易懂]
（3） 【支持的密码套件】支持的加密方法，比如RSA公钥加密。 （4） 支持的压缩方法。 SSL/TLS 密码套件 浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。 5、完全前向加密PFS，保护用户数据，预防私钥泄漏 非对称加密算法 RSA，包含了公钥、私钥，其中私钥是保密不对外公开的，由于此算法既可以用于加密也可以用于签名，所以用途甚广，但是还是会遇到一些问题 那就需要PFS（perfect forward secrecy）完全前向保密功能，此功能用于客户端与服务器交换对称密钥，起到前向保密的作用，也即就算私钥被泄漏，黑客也无法破解先前已加密的数据。 ID，下次连接客户端发ID过来就可以直接用之前的私钥交流了 4、OSCP Stapling：服务器将带有 CA 机构签名的 OCSP 响应在握手时发给客户端，省的客户端再去CA查询 5、完全前向加密PFS
5.7K20编辑于 2022-07-01 - 来自专栏啄木鸟软件测试
软件安全性测试（连载21）
l 使用支持域名的证书。 l 在证书中使用完全限定名称，注意不要用localhost或类似192.168.1.1私有地址的证书 l 不要使用通配符证书：比如“*”。 临时密码交换是基于Diffie-Hellman(DH)的算法，在初始化SSL/TLS握手期间完成，保证了前项保密性(PFS) l 仅支持密码学强加密。关于密码学强加密如下。 Ø 使用最新安全建议。 Ø 服务器端激活并设置密码算法顺序，比如SSLHonorCipherOrderOn。 Ø 前项保密密码的密码为最高优先级，如DHE、ECDHE。 Ø 禁用不提供加密的密码套件。 Ø 禁用不提供认证的密码套件，包括匿名密码套件。 Ø 禁用DES。 Ø 禁用密钥长度小于128的密钥。 Ø 禁用MD5、SHA-1散列算法。 l 通过手机重置密码，是否每次向手机发送验证码或激活连接前都验证手机是否为当前用户注册信息？ l 通过电子邮件重置密码，是否每次向电子邮件发送验证码或激活连接前都验证电子邮件是否为当前用户注册信息？
1.8K10发布于 2020-02-19 - 来自专栏AI SPPECH
033_密码学实战：Diffie-Hellman密钥交换技术深度解析——从密钥协商到中间人攻击的完整指南
启用完美前向保密(PFS)") print("4. # 传统DH密码套件 "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384", # 临时DH（完美前向保密） "TLS_DHE_RSA_WITH_AES 椭圆曲线DH密码套件 "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384", # 临时ECDHE（完美前向保密） "TLS_ECDHE_RSA_WITH_AES 优先使用ECDHE密码套件，它们提供更好的性能和安全性") print("2. 确保启用完美前向保密(PFS)") print("3. (): """演示完美前向保密(PFS)""" print("\n完美前向保密(PFS)演示") # 解释PFS概念 print("完美前向保密定义：即使长期私钥泄露
51710编辑于 2025-11-18 - 来自专栏全栈程序员必看
SSL协议简介
SSL是Netscape于1994年开发的，后来成为了世界上最著名的web安全机制，所有主要的浏览器都支持SSL协议 目前有三个版本：2、3、3.1，最常用的是第3版，是1995年发布的。 （4）一个客户端可以支持的密码套件列表。 密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。 （客户端一个、服务端一个） （3）会话ID （4）从客户端的密码套件列表中选择的一个密码套件 （5）从客户端的压缩方法的列表中选择的压缩方法 这个阶段之后，客户端服务端知道了下列内容： （1）SSL版本 可以参考Behrouz A.Forouzan著的《密码学与网络安全》。 1.3 客户机鉴别与密钥交换： 客户机启动SSL握手第3阶段，是本阶段所有消息的唯一发送方，服务器是所有消息的唯一接收方。 生成过程如下： 2、记录协议 记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务： （1）保密性
1.5K20编辑于 2022-09-05 - 来自专栏zaking's
真正“搞”懂HTTPS协议15之安全的定义
比如，就拿前两篇文章讲的代理服务。 如果通信时另外一方是一个假冒网站，那么数据再保密再完整也没用，黑客完全可以使用冒充的身份套出各种信息，加密不加密，完整不完整，没啥意义，因为你最终的接收人就是不可靠的。 浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（cipher suite，也叫加密套件）。 其实 TLS 的密码套件命名非常规范，格式很固定。 四、还要说一下OpenSSL 聊完了TLS，我们就不得不谈一下OpenSSL，它是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现
73530编辑于 2023-02-16 - 来自专栏小林coding
这 HTTPS，真滴牛逼！
其中，RSA 是比较传统的密钥交换算法，它不具备前向安全的性质，因此现在很少服务器使用的。而 ECDHE 算法具有前向安全，所以被广泛使用。 TLS 第一次握手 客户端首先会发一个「Client Hello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）。 ? 第二次握手 服务端收到客户端的「打招呼」，同样也要回礼，会返回「Server Hello」消息，消息面有服务器确认的 TLS 版本号，也给出了一个随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件 image.png 不过，这次选择的密码套件就和 RSA 不一样了，我们来分析一下这次的密码套件的意思。 ---- 总结 RSA 和 ECDHE 握手过程的区别： RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密； 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输
2.2K11发布于 2021-01-26 - 来自专栏全栈程序员必看
密码学专题 SSL协议
（4）一个客户端可以支持的密码套件列表。 （5）一个客户端可以支持的压缩算法列表。 补充 密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。 （客户端一个、服务端一个） （3）会话ID （4）从客户端的密码套件列表中选择的一个密码套件 （5）从客户端的压缩方法的列表中选择的压缩方法 这个阶段之后，客户端服务端知道了下列内容： （1）SSL版本 该阶段分为4步，前2个消息来自客户机，后2个消息来自服务器。 密钥生成的过程 这样握手协议完成，下面看下什么是预备主密钥，主密钥是怎么生成的。 生成过程如下： 记录协议 记录协议在客户机和服务器握手成功后使用，即客户机和服务器鉴别对方和确定安全信息交换使用的算法后，进入SSL记录协议，记录协议向SSL连接提供两个服务： （1）保密性 session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。
1K20编辑于 2022-08-27 - 来自专栏全栈工程师修炼之路
HTTPS安全优化配置最佳实践指南简述
与之相对，在一些DH密钥交换方式中，某些参数是静态的，并被嵌入到服务器和客户端的证书中，这样的话密钥交换的结果是一直不变的共享密钥，就无法具备前向保密的能力。 临时椭圆曲线Diffie-Hellman密钥交换，和DHE类似，使用临时的参数，具有前向保密的能力。 RC4 : 是一种流加密算法，对称加密，密钥长度可变。 这种攻击会影响支持 DHE_EXPORT 密码的所有服务器。 2.5) 建议使用FS前向保密, FS有时也称为完全前向保密是一种协议功能，可实现不依赖服务器私钥的安全对话, 对于不提前向保密的密码套件，如果有可以恢复服务器的私钥的人就可以解密所有较早记录的加密对话 2.6) 建议使用强的密钥交换算法，前面我们说不建议选择经典的短暂的 Diffie-Hellman密钥交换（DHE）以及RSA 密钥交换（不提供FS前向保密），通常推荐其椭圆曲线变体 ECDHE 密钥交换
3.6K11编辑于 2022-09-29 - 来自专栏Yangsh888的专栏
HTTPS网络安全与SSL证书相关术语合集
与之相对，在一些DH密钥交换方式中，某些参数是静态的，并被嵌入到服务器和客户端的证书中，这样的话密钥交换的结果是一直不变的共享密钥，就无法具备前向保密的能力。 临时椭圆曲线Diffie-Hellman密钥交换，和DHE类似，使用临时的参数，具有前向保密的能力。 PFS PFS(perfect forward secrecy)正向保密 ，在密码学中也可以被称为FS(forward secrecy)，是安全通信协议的特性，要求一个密钥只能访问由它所保护的数据，用来产生密钥的元素一次一换 这种攻击会影响支持 DHE_EXPORT 密码的所有服务器。 SRP TLS-SRP（ Secure Remote Password）密码套件有两类：第一类密码套件仅使用SRP认证。第二类使用SRP认证和公共密钥证书来增加安全性。
1.9K50编辑于 2022-03-24 - 来自专栏绿盟科技研究通讯
TLS指纹分析研究（下）
其次，该工具必须支持加密套件、扩展和流行实现中存在的特性，例如，如果一个工具模仿Chrome发送但实际上不支持CHACHA20密码套件，服务器可能会为连接选择该密码套件，导致该工具终止连接，这不仅会导致兼容性问题 其次，如果服务器由工具维护者控制，这个问题可以得到部分缓解，因为服务端可以只选择工具所支持的密码套件和扩展，但是无法控制两个端点的工具中并非如此，例如域前置、折射网络和生成到其他服务器流量的工具。 一方面，由于Server Hello消息的内容较少，它只指定了一个密码套件和压缩方法，而不是服务器支持的完整列表。 然而，分析服务端选择的唯一密码套件，发现只选择了70个密码套件，前10个占所有连接的93%以上，有趣的是，在所有Client Hello中最流行的密码套件(TLS_ECDHE_RSA_WITH_AES_ 支持非标准特性的共性表明，检测人员可能很难完全了解或使用白名单覆盖所有常用的指纹。
2.5K20编辑于 2022-11-14 - 来自专栏公共互联网反网络钓鱼（APCN）
基于Mamba 2FA套件的AiTM攻击机理与防御架构研究
该套件通过实时代理技术，能够在受害者完成MFA验证的瞬间劫持会话Cookie，从而完全绕过双因素认证机制。 2 Mamba 2FA套件架构与攻击链路解析Mamba 2FA并非单一脚本，而是一个包含前端诱饵、后端代理、控制面板及基础设施管理模块的完整生态系统。 这种“实时镜像”技术确保了钓鱼页面与真实页面在视觉和功能上完全一致，包括所有的安全标识、多语言支持甚至动态加载的验证码。 当用户在页面上进行操作时，所有请求均先发送至攻击者的代理服务器，再由代理服务器转发至Microsoft官方服务器。响应数据则沿原路返回。 同时，建立快速响应机制，确保用户在怀疑受损时能迅速获得支持，缩短攻击者的驻留时间。6 结论Mamba 2FA钓鱼套件的出现，标志着网络攻击已进入高度自动化与服务化的新阶段。
13610编辑于 2026-02-27 - 来自专栏小林coding
几幅图，拿下 HTTPS
消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。 TLS 第二次握手 当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random）。 接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。 ? ---- RSA 算法的缺陷 使用 RSA 密钥协商算法的最大问题是不支持前向保密。 DH 密钥交换过程中，即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密。
98522发布于 2021-01-12 - 来自专栏公共互联网反网络钓鱼（APCN）
新兴钓鱼套件对多因素认证体系的威胁与防御路径
本文聚焦于新兴钓鱼套件的技术架构、攻击逻辑及其对现有身份验证体系的穿透能力，系统分析其绕过 MFA 的核心机制，并结合实证数据与代码示例，提出以 FIDO2 无密码认证为核心的纵深防御策略。 （二）GhostFrame：轻量化部署与高隐蔽性GhostFrame 采用单 HTML 文件设计，所有逻辑（包括表单渲染、数据回传、地理定位）均内嵌于 <script> 标签中，无需后端服务器支持。 即使攻击者获取用户名和密码，也无法在其他设备上完成认证。三、基于流量与行为的钓鱼活动检测模型为应对上述威胁，组织需在认证前、中、后三个阶段部署检测能力。 五、对低资源组织的务实建议并非所有机构都能立即部署 FIDO2。 本文论证，唯有通过技术范式转型——从知识型 MFA 向基于硬件绑定的无密码认证迁移，并辅以网络层检测、条件访问与情报共享，方能构建具备抗钓鱼韧性的身份基础设施。
26810编辑于 2025-12-24 - 来自专栏响应式编程
与加密相关的一些名词
序列密码(Stream Cipher)、分组密码(Block Cipher) RC4 属于序列密码，AES 算是最流行的分组密码，无线安全技术 WPA2 就是使用 AES。 分组密码：ECB、CBC。 RSA 不支持前向保密 下图是 Diffie-Hellman 密钥交换示意图： 证书 证书是包含公钥、订阅人信息、证书颁发者数字签名的数字文件，是存储、传递、使用公钥的容器。 客户端需要提供自己 TLS 版本、随机数、加密套件、压缩方法、扩展信息给服务端，让服务端进行选择。 因为客户端发送的密码套件、服务器最终选择的密码套件未必需要身份认证，同时不是所有身份认证都需要证书，所以，这个消息是可选的。 这个消息中很重要的一个字段是 verify_data, 其值是用协商得到的主密钥结合协商确定的 MAC 算法对所有按序排列的握手消息进行计算得到的散列值。
80230编辑于 2022-05-30 - 来自专栏Android源码框架分析
用WireShark简单看看SSL/TLS协议
每个HTTPS网站都需要TLS证书，在数据传输开始前，服务端先将证书下发到用户端，由用户根据证书判断是否是目标网站。这其中的原理是什么，证书又是如何标识网站的有效性呢？ ，因为协商对称秘钥的算法不止一种，所以握手的具体操作也并非一成不变，比如RSA就比ECDHE要简单的多，目前主流使用的都是ECDHE，具体流程拆分如下： Client Hello 【TLS/SSL握手发起 】 Client Hello是TLS/SSL握手发起的第一个动作，类似TCP的SYN，Client Hello 阶段客户端会指定版本，随机数、支持的密码套件供服务端选择，具体的包数据如下 image.png 启动TLS握手过程，提供自己所能支持各种算法，同时提供一个将来所能用到的随机数。 之后就是支持的供服务端选择的密码套件，接下来等服务端返回。
3.9K30编辑于 2022-05-26 - 来自专栏FreeBuf
等保2.0系列安全计算环境之数据完整性、保密性测评
其实在商用密码中，密码算法分为加密算法和哈希算法两大类，其中哈希算法常见是MD5和SHA系列，哈希算法也属于密码算法，所以通过密码技术完全可以实现完整性校验， 2传输过程中的完整性，传输过程中的完整性主要通过协议来实现 其实在开发过程中，技术方面进行哈希校验并不难，因为常见开发语言均内置哈希函数，比如php的hash()、java的hashcode()等，但是问题重点在主流开发语言目前少于内置SM3等国密哈希算法，随着商密应用的测评 四、数据的保密性测评 a)应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等； 传输过程中的保密性测评中，这个比较简单，主要核查是否采用TLS、SSH等加密协议 不对从服务器向客户端发送的数据进行加密。 兼容 这是默认设置，此级别以客户端支持的最大密钥强度对在客户端与服务器之间发送的数据进行加密。 符合FIPS标准 此级别使用联邦信息处理标准 (FIPS) 140-1 经过验证的加密方法，对从客户端向服务器发送的数据以及从服务器向客户端发送的数据进行加密和解密。
6.4K22编辑于 2023-04-26
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号