前言:前几天问人家要友链却被告知博客的域名与ssl证书对不上,exo me?一个友链而已为什么还要求全站的https加呢,后来发现他们的友链应该是后台自动生成的,已经全站https的网站去访问没有加密资源的可能会报错,现在自己的博客也有了coding提供的免费SSL,然后如愿加上了,原谅他们都是参加过hack.init( )的高中生大佬,所以现在自己的博客在加密访问的时候同样会报请求的cdn静态资源未被https加密的错了,然后上课无聊又看了几篇文章,可以简单整理一下


HTTPS流程
客户端

hi!我要发起一个HTTPS请求,我需要你的公钥加密我主动生成的秘钥(1),我好把请求(内容)和加密的秘钥发给你

服务端

为了避免公钥(2)在路上被掉包,不能直接给你,我把我在权威机构注册的SSL证书(3)给你,里面有我加密过的公钥

客户端

ok,我的系统或浏览器认可了你的证书并拿到你的公钥了,这是用你的公钥加密过的秘钥和用秘钥加密过的内容

服务端

ok,我用我的公钥把你的秘钥解开了,并用秘钥解开了你的内容,同意请求,马上给你下发用我私钥加密过得内容

}

(1)秘钥是有客户端主动生成并加密并给服务端,加密和解密使用相同的秘钥,这一点属于对称秘钥

(2)对于需要加密客户端主动生成的秘钥,用公钥加密,在服务端用私钥解,这一部分非对称秘钥,整个流程属于对称秘钥非对称秘钥的结合使用

(3)SSL证书:确保客户端收到的公钥是该服务器的公钥,凭什么确保?

哈希算法的特点,它可以压缩数据,如果从函数角度来看,不管多复杂的数据(定义域可以非常大)经过哈希算法都会得到一个值,而且这个值处在某个特定(远小于定义域的范围)值域内。相同数据的哈希结果一定相同,不相同数据的哈希结果一般不同,不过也有小概率会重复,这叫哈希冲突。为了确保原始证书没有被篡改,我们可以在传递证书的同时传递证书的哈希值。由于第三者无法解析数据,只能 XJB 改,那么修改后的数据在解密后,虽然公钥已知,每个人都可以解密,解密完也可以篡改,但是因为没有私钥,所以无法正确的加密。所以它再返回给客户端的数据是无效数据,用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析,也无法通过哈希校验。

那权威机构的公钥又怎么传输

存在电脑里!表示终于找到头啦!这个公钥不用传输,会直接内置在各大操作系统(或者浏览器)的出厂设置里。之所以不把每个服务器的公钥内置在电脑里,一方面是因为服务器太多,存不过来。另一方面操作系统也不信任你,凭什么你说你这个就是百度/淘宝的证书呢?

HTTPS 握手对性能的影响

TCP 有三次握手,再加上 HTTPS 的四次握手,影响肯定有,但是可以接受首先,HTTPS 肯定会更慢一点,时间主要花费在两组 SSL之间的耗时和证书的读取验证上,对称算法的加解密时间几乎可以忽略不计,而且如果不是首次握手,后续的请求并不需要完整的握手过程。客户端可以把上次的加密情况直接发送给服务器从而快速恢复。除此以外,SSL握手的时间并不是只能用来传递加密信息,还可以承担起客户端和服务器沟通HTTP2兼容情况的任务。因此从HTTPS切换到HTTP2.0不会有任何性能上的开销,反倒是得益于HTTP2.0的多路复用等技术,后续可以节约大量时间。如果把 HTTPS2.0 当做目标,那么HTTPS的性能损耗就更小了,远远比不上它带来的安全性提升。

Last updated:
转载注明出处,原文地址:http://blog.liufulin.online/2017/12/09/https/