之前咱们说到,马老板让手下阴差阳错买下了肯德基,这次又想买点东西,但是难以启齿,所以悄悄给手下耳语一番,手下连连称是,并狂拍胸脯口出豪言:马总,放心,这事包在我身上,一定会出色完成任务!
手下打开浏览器输入:http://某宝.com.敲回车键,接下来发生一连串的连锁反应.
第一步:浏览器与某宝建立tcp链接
第二步:服务器会弹出一个页面提醒安装数字证书,如果不安装,接下来一切都不会顺利进行
第三步:浏览器需要认证某宝是真实的服务器(不是山寨的),服务器发来了自己的数字证书.
插一句:某宝的数字证书从哪里来?
某宝自己的认证中心简称CA(Certificate Authority),CA给某宝颁发了一个证书,这个证书有:
签发者
证书用途
某宝的公钥
某宝的加密算法
某宝用的HASH算法
证书的到期时间等
如果证书就这样给某宝了,那传输过程中如果有人篡改这个证书,那这个证书还有什么权威性?简单的很,把以上内容做一次HASH,得到一个固定长度(比如128位的HASH,然后再用CA的私钥加密,就得到了数字签名,附在以上证书的末尾,一起传输给某宝).
设想一下,如果不加密那个HASH,任何人都可以先篡改证书,然后再计算HASH,附在证书的后面,传给某宝时,某宝无法发现是否有人篡改过,而用CA私钥加密后,就生成了类似人体指纹的签名,任何篡改证书的尝试,都会被数字签名发现.
第四步:浏览器接到某宝的数字证书,从第二步得到的CA公钥值,可以解密数字证书末尾的数字签名(CA私钥加密,可以用CA公钥解密,此为非对称加密),得到原始的HASHs
然后自己也按照证书的HASH算法,自己也计算一个HASHc,如果HASHc==HASHs,则认证通过,否则认证失败.假设认证成功,否则故事无法继续下去咯,哈哈哈哈......
第五步:双发会运行Diffie Hellman算法,简称DH算法,通俗地说:双方会协商一个master-key,这个master-key不会在网络传输.交换.他们独立计算出来的,其值是相同的,只有他们自己双方知道,任何第三方不会知道,俗称的天不知,地不知,只有你知,我知.
然后以master-key推导出session-key,用于双方SSL数据流得到加密/解密.采用对称加密,保证数据不被偷窃,加密算法一般用AES.
以master-key推导出hash-key,用于数据完整性检查(Integrity Check Verification)的加密密钥,HASH算法一般有:MD5,SHA,通俗滴说,保证数据不被篡改.
第六步:然后就可以正常发送订单了,用HASH key生成一个MAC(Message Authentication Code),附在HTTP报文的后面,然后用session key加密所有数据(HTTP+MAC),然后发送出去
第七步:服务器先用session key解密数据,得到HTTP+MAC,然后自己用相同的算法计算自己的MAC,如果两个MAC相等,则数据没有被篡改.
第八步:所有购物安全无误的完成,手下给马老板买了一件神秘礼物.一件jk制服,马老板脸僵了五秒钟,随即绽开了笑容,说了一句:换个人
