最浅显易懂的SSL

安全套接层.

在tcp协议和http协议之间.主要作用是加密传输.其中client和server大概有如下握手协商.

翻译:

注意下面红色字体是代表握手,黑色是自处理.

 

客户端说:

你好,我准备连你,我现在有非对称加密算法RSA,ECC,对称加密算法DES,RC5,摘要算法SHA256,MD5

 服务器说:

你好,那我挑选了,嗯,就用RSA-DES-MD5

服务器说:

这是我的CA证书,里面有公钥,你看看,没问题的话你就使用它.

服务器说:

我说完了.

客户端:(注意,这里没用说,没用传输数据,只是内部处理)

我检查下证书,咦?本机并没有信任该证书,那我追溯下源头,看谁发给他的证书,找到了,原来该证书的签发者我是信任的,那没问题,这个证书我也认可.

客户端:

生成一个主秘钥premaster secret,该主秘钥实际上可以再次生成对称加密秘钥和散列秘钥

客户端说:

这是我利用非对称加密RSA配合CA的公钥把premaster secret加密后的结果,给你

客户端说:

以后我就按里面包含的那个DES对称算法秘钥加密数据了.

客户端说:

我已经通过摘要算法MD5计算了我们上述所有的话的hash值发给你,你检查下.如果正确就回复我一下.

服务器:

通过RSA私钥解密出premaster secret,生成DES和MD5的秘钥.通过MD5算法检查hash值,和客户端传来比较一致.

服务器说:

以后我也就按里面包含的那个DES对称算法秘钥加密数据了.

服务器说:

我已经通过摘要算法MD5计算了我们上述所有的话的hash值发给你,你检查下.

 

解读:

注意客户端和服务器最后阶段都互相确认了HASH值,这并不浪费,因为服务端最后多说了两句.计算的不一样

客户端检查证书的本事并没有多少,只是通过信任根证书继而信任其子证书.所以怎么说呢?ssl在确认好对象后传输很安全,但是它确认对象的过程却很傻,被冒名顶替了也完全不知道.只要对面的证书它信任.那么https抓包也是基于此原理,我们加入A要访问B,希望抓包,那么可以让A访问c,c访问B.c要有证书,骗过傻傻的A,把访问B的结果给a