HTTPS通讯说明.docx

HTTPS通讯说明一、常见加解密算法MD5/SHA/BASE64/urlEncodeMD5/view/2313810.htm消息摘要算法-5（Message Digest Algorithm）SHA安全散列算法(Secure Hash Algorithm)Base64Base64编码要求把3个8位字节（3*8=24）转化为4个6位的字节（4*6=24），之后在6位的前面补两个0，形成8位一个字节的形式。 如果剩下的字符不足3个字节，则用0填充，输出字符使用=，因此编码后输出的文本末尾可能会出现1或2个=。例如：“baidu and google” ==》 “YmFpZHUgYW5kIGdvb2dsZQ==”urlEncodeurlEncode用于解决url参数中的特殊字符、中文等问题。以上4中算法严格意义上说，不属于加解密算法的范畴。只是使用比较广泛的格式转换、摘要计算方法而已。BASE64/urlEncode属于格式转换，MD5/SHA属于摘要计算。DES/DES3/AES这三种算法都属于对称加解密算法，DES3是DES的升级版算法，AES是DES3的升级版本算法。目前使用比较广泛的是DES3和AES。这两个算法虽然有新老版本之分，但是还是有性能和适用场景的区别。算法说明：使用密钥K1+算法S1对明文进行加密，生成密文。使用密钥K1+算法S1对密文进行解密(再一次加密)，生成明文。整个过程中，使用的密钥相同，算法相同。RSARSA属于非对称加解密算法，也是最复杂的一种算法。非对称加解密衍生出两种认证场景。一种是签名，一种是加密。加密的流程示意图：算法说明：使用密钥PK+算法S1对明文进行加密，生成密文。使用密钥SK+算法S1对密文进行解密(再一次加密)，生成明文。整个过程中，使用的密钥不相同，算法相同。这种加密的流程中，只能做到数据的加密，不可被获取(获得明文)，但是无法确保不被篡改。签名的流程示意图：假设A要想B发送消息，A会先计算出消息的消息摘要，然后使用自己的私钥加密这段摘要加密，最后将加密后的消息摘要和消息一起发送给B，被加密的消息摘要就是“签名”。B收到消息后，也会使用和A相同的方法提取消息摘要，然后使用A的公钥解密A发送的来签名，并与自己计算出来的消息摘要进行比较。如果相同则说明消息是A发送给B的，同时，A也无法否认自己发送消息给B的事实。数字签名的作用是保证数据完整性，机密性和发送方角色的不可抵赖性。如果甲想给乙发一个安全的保密的数据，那么应该甲乙各自有一对公私钥，甲先用乙的/s?wd=%E5%85%AC%E9%92%A5%E5%8A%A0%E5%AF%86tncprfenlei=mv6quAkxTZn0IZRqIHckPjm4nH00T1d9PWbLnvnsm199rH01nHN-0ZwV5Hcvrjm3rH6sPfKWUMw85HfYnjn4nH6sgvPsT6KdThsqpZwYTjCEQLGCpyw9Uz4Bmy-bIi4WUvYETgN-TLwGUv3EnHnsnWR1nHnYPHRLP1nkrH0krf公钥加密这段数据，再用自己的私钥加密这段加密后的数据，最后再发给乙。这样确保了内容即不会被读取，也不会被篡改。所有算法对比算法名称密钥类型是否可逆MD5/SHA无不可逆BASE64/urlEncode无可逆DES/DES3/AES一个密钥可逆RSA一对密钥可逆加密盐和碰撞因子二、证书及CA介绍公钥、私钥、证书一个公钥对应一个私钥。密钥对中，让大家都知道的是公钥，不告诉大家，只有自己知道的，是私钥。为什么需要用证书来替代公钥？答：在上面的加密签名等过程中，我们都忽略了一点，那就是如何确保我们获取的公钥是正确的。第三者很容易制作一个公钥来冒充我们的交互目标，我们没法凭借这个公钥来确认对方的身份。在这样的情况下，证书就诞生了，证书是一个包装了公钥的实体，他里面包含了公钥，机构名称，证书有效期，ca签名等信息。这样我们获取证书后，就可以通过证书里面对机构的描述来确认对方的身份。证书中的ca是什么意思？答：其实上面对证书的描述并没有完全解决我们提出的问题，第三者完全可能制作一个证书，而证书里的机构信息也是伪造的。那么ca就在这种情形下出现了。ca是证书颁发机构(certification authority)。ca是第三方的，为数不多的，可信赖的机构，我们可以在其官网上获取他的公钥，用他的公钥来解析ca签名，就能够唯一的验证这个证书是由这个ca机构颁发的。ca机构会维护自己的publickey库，比如公司“通联支付”去ca申请证书后，那第三者就无法再以“通联支付”的名字来申请证书了。那么也就能验证这个证书不是由第三者假冒的了。Ca的分级认证模式假设C证书信任A和B；然后A信任A1和A2；B信