ssl握手协议中的CipherSuite

最新推荐文章于 2024-07-27 14:04:19 发布

满舅舅

最新推荐文章于 2024-07-27 14:04:19 发布

阅读量6.6k

点赞数 1

本文链接：https://blog.csdn.net/gdfhhj/article/details/87206305

版权

本文详细解析了SSL握手过程中CipherSuite的选择与应用，探讨了如何创建一个不在RFC建议中的自定义组合，例如RSA作为密钥交换算法，ECDSA作为认证算法。通过模拟握手流程，解释了如何在不违反协议的基础上实现这一组合，并提到了OpenSSL中可能需要的源代码修改。同时，文章强调了公钥、私钥的使用原则以及协议的灵活性。

摘要由CSDN通过智能技术生成

下面是一个ssl握手的过程，没有进行客户端验证：
1.C-S：ClientHello---cipher-suit-list
2.S-C：ServerHello---selected-cipher-suit
3.S-C：ServerKeyExchange
4.S-C：ServerHelloDone
5.C-S：ClientKeyExchange
6.C-S：完成
7.S-C：完成
第3步是否发送要看c和s协商的cipher-suit是什么，cipher-suit包含四个部分(将摘要算法并入认证算法的话也可以看作三个部分)，第一是密钥交换算法，第二是签名算法/验签算法，第三是摘要算法，第四是对称加密算法，RFC2246中建议了很多中组合，一般写法是"密钥交换算法-签名算法-对称加密算法-摘要算法"，如果只有rfc的建议是可用的，那就难免要在各个ssl实现中加以若干硬性的规定，这样密钥交换和认证就不得不耦合起来了，比如使用ECC算法签名的证书不能使用RSA算法进行密钥交换，证书中密钥太长的的涉及出口限制的必须使用临时rsa进行密钥交换，如果使用rsa作为密钥交换算法，那么在ClientKeyExchange中的pre-master必须用证书中的公钥加密等等，之所以有这么多限制就是因为一些人或者机构的管理因素在里面，比如美国的出口限制等等，从协议本身来说，这些限制是不应该的，证书仅仅用于认证，而不和密钥交换挂钩，当然，它们之间也不是没有任何关系，比如KeyExchange消息本身就需要认证࿰