下面是一个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消息本身就需要认证,而认证的公私钥信息可以在证书中。
协议本身来看,任何的算法都能组合成一个cipher-suit,以RFC2246的一个建议为例,使用RSA作为密钥交换算法的不能发送ServerKeyExchange消息,我们来看一下如何违反它从而实现一个新的不在RFC中的cipher-suit,这个cipher-suit使用rsa作为密钥交换算法,但是使用ecdsa作为认证算法,暂且不考虑对称加密算法和摘要算法。仍以上述握手过程为例,第2步时server端选择了RSA-ECDSA-XX-YY这个cipher-suit,紧接着第3步,server将自己的使用ecdsa签名的证书发送给了client,client用ca的ecc公钥验证server证书中ecc签名,然后server违反rfc建议,在密钥交换算法是rsa的情况下发送ServerKeyExchange消息,由于使用rsa进行密钥交换,而证书中的公钥是ecc算法签名的,那么这个ServerKeyExchange消息中必须包含一个临时的rsa公钥,server自己保留临时rsa私钥,然后server用自己的ecc私钥将这个ServerKeyExchange消息进行签名后发给client,client收到后会使用server证书中的ecc公钥来验证这个签名,通过后保存该消息中提取的server的临时rsa公钥,接着处理完hellodone消息后生成一个pre-master,然后用刚才保存的server临时rsa公钥加密这个pre-master作为ClientKeyExchange消息发送给server,随后两端使用密钥导出算法导出一个对称密钥,认证完成,密钥交换完成,握手完成。
上述的整个过程理解起来很简单,就把ecc算法签名的证书当成密钥太长并有出口限制的rsa证书即可。总之,不考虑匿名dh以及一切类似情况下,任何需要验证的地方,公钥一般都取证书里面的,私钥都取本地加载的,涉及密钥交换的地方,严格按照cipher-suit中的算法进行。以上的论述在OpenSSL中不被支持,要想让OpenSSL支持这个RSA-ECDSA-XX-YY的话就必须修改OpenSSL的源代码,这个修改很简单,仅仅修改s3_srvr.c,s3_clnt.c等不多的几个文件即可,加上对诸如(l & SSL_kRSA) && (l & SSL_aECDSA)等组合的判断,本文不述。总之,就协议而言,任意的算法都能组合成一个cipher-suit。
再分享一下我老师大神的人工智能教程吧。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到我们人工智能的队伍中来!https://blog.csdn.net/jiangjunshow
原文地址:https://www.cnblogs.com/ksiwnhiwhs/p/10390422.html