更安全的https && https的问题

视频推荐：https的性能优化

推荐文章：腾讯https性能优化实践

更安全的https（内容加密、身份认证、数据完整性）

　　https实际上就是在http和tcp之间添加了ssl层或者是TLs层，这两层一般是指相同的层，主要做的工作就是内容加密、身份认证、数据完整性校验。

TLS 的前身是 SSL（Secure Sockets Layer，安全套接字层），由网景公司开发，后来被 IETF 标准化并改名。通常没有特别说明时，SSL 和 TLS 指的是同一个协议，不做严格区分。　　

故事助记

1、两人聊天，在中国的张大胖，在美国的bill，他们无话不谈。。

2、 突然有一天，他们突然意识到有一种被偷窥的感觉 --- 他们的聊天是否被人一直在观察，关键是他们还谈了很多的秘密啊！ 以后如果想要说点其他重要的事情，这可不行！

　　于是bill建议能否在大胖发送信息的时候先用一种加密算法加密发送的内容，然后bill在接受到信息之后再使用同样的算法来解密，这样，信息在网络中就是以加密的形式传输，不就不会被偷窥了吗！ 如下：

　　

注意:这种加密和解密使用同一种算法的方式为对称加密。

但是，在秘钥被传输的过程中也被人给偷窥了呢？ 这样，你即使加密了，偷窥的人也可以通过偷偷得到的秘钥进行解密啊，这不是功亏一篑了吗？

3、 大胖很不甘心，他觉得不能就这么放弃，于是在网上找到了一种叫做RSA非对称加密算法（RSA是三个人发明的，即三个人的首字母组成RSA），这种算法要求两个钥匙，一个公钥，一个私钥。

私钥只有一把，非常重要；公钥可以有很多，谁都可以使用。但是私钥加密的内容只有公钥可以解密，公钥加密的内容也只有私钥可以解密。

这样，问题就很好解决了，即bill将公钥通过网络发送给大胖，然后大胖拿到这个对文件进行加密发给bill，而只有bill具有私钥，所以就可以使信息保密啦！

同样的，如果bill给大胖发送信息，通过大胖的公钥进行加密，然后大胖收到信息之后，通过自己的私钥来解密就可以了。

这种加密和解密方式不同的加密方法为非对称加密。

4、经过几次尝试之后，果然可以。但是大胖发现，这种非对称加密要比对称加密慢了百倍，这是他所不能容忍的，于是他又相出了这么个对称加密和非对称加密（RSA）结合的方法：

　即首先大胖把通过RSA加密方法把对称加密的钥匙发送给bill，这样，bill和大胖在之后的聊天过程中不就可以使用速度更快的对称加密了吗！  好方法！

5、 中间人攻击。

　　后来啊，他们发现这种方法还是存在漏洞的，如当bill给大胖发送公钥的时候，这个公钥被中间人给截住了，然后把中间人的公钥发送给了大胖，那么大胖就会通过这个中间人公钥把对称密钥发送给bill，中间人截取到这个密钥之后就会，使用自己的私钥就会看到里面的信息，接着通过之前截取的公钥再把这个对称密钥发送给bill，后面他们就会通过这个对称密钥聊天，而中间人就可以完全看到他们的信息了，如下：

所以这里的问题是，如何确保大胖接收到的公钥是bill的，而不是中间人的！

6、但是大胖很快就又想到了办法，就是找一个第三方来给网络上的人办法一个证书，证明存在这个人，并且这个证书上还要有这个人的公钥，这样，大胖收到第三方的这个证书之后，就可以确认公钥就是bill的了！ 但是如果证书也是被修改了呢？  天无绝人之路，很快，大胖就意识到了使用数字签名！  Bill可以把他的公钥和个人信息用一个Hash算法生成一个消息摘要， 这个Hash算法有个极好的特性，只要输入数据有一点点变化，那生成的消息摘要就会有巨变，这样就可以防止别人修改原始内容。

可是作为攻击者的中间人笑了： “虽然我没办法改公钥，但是我可以把整个原始信息都替换了， 生成一个新的消息摘要， 你不还是辨别不出来？

张大胖说你别得意的太早 ， 我们会让有公信力的认证中心（简称CA）用它的私钥对消息摘要加密，形成签名：

这还不算， 还把原始信息和数据签名合并， 形成一个全新的东西，叫做“数字证书”

张大胖接着说：当Bill把他的证书发给我的时候， 我就用同样的Hash 算法， 再次生成消息摘要，然后用CA的公钥对数字签名解密， 得到CA创建的消息摘要， 两者一比，就知道有没有人篡改了！

如果没人篡改， 我就可以安全的拿到Bill的公钥喽，有了公钥， 后序的加密工作就可以开始了。

虽然很费劲， 但是为了防范你们这些偷窥者，实在是没办法啊。

但是中间人还要伪造CA呢？ 大胖认为，必须要信任CA，否则就没法玩下去了。

（注：这些ＣＡ本身也有证书来证明自己的身份，并且ＣＡ的信用是像树一样分级的，高层的ＣＡ给底层的ＣＡ做信用背书，而操作系统／浏览器中会内置一些顶层的ＣＡ的证书，相当于你自动信任了他们。　这些顶层的ＣＡ证书一定得安全地放入操作系统／浏览器当中，否则世界大乱。）

---

较为专业的发展历程：

• 对称加密时代：最开始A向B发送密钥，然后之后的通信都是使用密钥加密，使用相同的密钥解密。
• 非对称加密时代： 若最开始的时候，密钥被窃取，那么后面的过程都是会被窃取的。
• 对称加密和非对称加密混合：非对称加密的速度很慢，所以需要一定的时间。 所以，可以先用非对称加密（安全的）发送过去用于对称加密的私钥，然后拿着私钥就可以进行对称加密而言的工作了。
• 对称加密和非对称加密混合并使用hash值：非对称加密也是存在问题的，即开始发送公钥的时候，中间人就有可能拿到这个公钥，然后发送自己的公钥。所以，可以将想要发送的公钥以及个人信息通过MD5或者是SHA1生成hash值（hash值的特点是不可逆性以及唯一性），即使有很小的改变，那么hash值就会发生巨大的改变。
• 对称加密和非对称加密混合并使用hash值并使用数字签名生成数字证书： 之前使用的hash值也是会存在问题的，因为虽然，如果中间人把公钥换成了自己的，这时hash值发生了变化，另一端不再信任；但是，中间人不仅可以替换公钥，还可以生成一个全新的hash然后发送啊，所以，这时单纯的hash也是没有用的了。可以可以使用CA证书，即给每一个站点颁发一个信任证书，然后发送的时候把hash值通过CA私钥进行加密（只有受信任的站点才有CA，只有收信人的站点才有这个CA的私钥），然后把加密后的hash值称之为数字签名，接着把数字签名和之前的公钥以及个人信息组成数字证书一起发送（注意：这个过程只是开始进行通信的时候才会发生的，不可能每次链接都这么麻烦），然后接收端收到之后，会比对本地的CA证书，判断这个证书是否是受信任的，如果不是，就警告，如果是，就拿到这个证书中的公钥将自己的对称密钥发送过去，当对方通过私钥对之进行解密之后就拿到了这个对称密钥，就可以使用对称密钥进行通信了。 如下所示：

7、

终于可以介绍https了，前面已经介绍了https的原理， 你把张大胖替换成浏览器， 把Bill 替换成某个网站就行了。

一个简化的（例如下图没有包含Pre-Master Secret）https流程图是这样的， 如果你理解了前面的原理，这张图就变得非常简单：

那么这里就很好理解了，客户端发送一个请求希望和服务器建立安全地链接，然后为了建立链接服务器发送了一个数字证书，证明身份并发送过了一个公钥，浏览器端认真身份之后就使用这个公钥加密对称密钥发送，然后服务器就会通过自己的私钥得到对称密钥，这样，双方都知道了对称密钥，就可以用它来进行加密通信了！强！

8、那么如何在浏览器端查看证书呢？

　　一般，https协议都是使用的这种证书的方式。比如百度，https://www.baidu.com，我们可以看到如下：

　　即这里的Secure就是通信是加密了的，然后如果我们希望查看服务器的证书，可以打开开发者工具的security选项，如下：

　　然后，我们可以通过 View Certificate 来查看百度的证书，如左边所示。

　　即证书的目的如下：

• 确保远程服务器的身份。
• 向远程服务器证明你的身份。
• 。。。。

　　即这个证书是由 GlobalSign Organization Validation CA  - SHA256 来办法的，之前的介绍中，我们说通过hash，这里就是通过SHA256的算法。证书的有效期是 2017年的6月29日到2018年的4月25日，即十个月的时间。 但是证书的时间不是固定的，我们可以看到360搜索的证书时间长达3年。 所以这个是得多交钱吧。。。

https详解

http缺点(三个)：

　　1.通信使用明文(不加密),内容可能被窃听.(抓包工具可以获取请求和响应内容)

　　2.不验证通讯方的身份,可能遭遇伪装.(任何人都能发送请求,不管对方是谁都会返回响应).

　　3.无法证明报文的完整性,可能会遭篡改.(没有办法确认发出的请求/响应和接收到的请求/响应前后一致)

　　HTTP+加密+认证+完整性保护 = HTTPS. （可以认为https比http多了三个功能）

　　

　　HTTPS的英文全称是： HyperText Transfer Protocol over Secure Socket Layer， 即基于安全套阶层（SSL）的超文本传输协议。 

　　近年，google、baidu、facebook等大厂都开始大力推行https，国内外的很多互联网公司全站启动了https，这也是未来互联网的发展趋势。 

　　为了鼓励全球网站的https实现，一些互联网公司都提出了自己的要求：

• Google调整了搜索引擎算法，让使用了https的网站在搜索中排名靠前。
• 从2017年开始，chrome浏览器已经把采用http协议的网站标记为不安全网站，
• 
• （提示网站不安全，不能输入一些密码、银行卡等敏感信息）
• 苹果要求2017年的app store中的所有应用必须使用https加密链接，而微信小程序也要求必须使用https协议。
• 新一代的http/2协议的支持需要以https为基础。

　　

       https协议可以理解为 http + SSL/TLS， 即http下加入ssl层，https的安全基础就是ssl，因此加密的详细内容就需要上来了，如下：

    

　　所以，ssl层是在tcp层以上，在http层以下的，这样就构成了https。

 SSL（Secure Socket Layer，安全套接字层）：1994年为 Netscape 所研发，SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。

 

 TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0和TLS1.0由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是TLS 1.1、TLS 1.2。

1、对称加密

有流式、分组两种，加密和解密都是使用的同一个密钥。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非对称加密

加密使用的密钥和解密使用的密钥是不相同的，分别称为：公钥、私钥，公钥和算法都是公开的，私钥是保密的。非对称加密算法性能较低，但是安全性超强，由于其加密特性，非对称加密算法能加密的数据长度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希算法

将任意长度的信息转换为较短的固定长度的值，通常其长度要比信息小得多，且算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、数字签名

签名就是在信息的后面再加上一段内容（信息经过hash后的值），可以证明信息没有被修改过。hash值一般都会加密后（也就是签名）再和信息一起发送，以保证这个hash值不被修改。

https的问题

https最大的特点就是很慢，一般都是要慢几百毫秒以上，在移动端大概会慢500ms以上。但是通过优化，实际上可以做到

第二点就是贵。

第三点就是https是需要消耗服务器成本，因为加密的过程是需要计算的。

缺点一：延时

　　https确实是更加安全了，但是https也是存在问题的，一个很大的问题就是https非常慢！ 为什么呢？ 因为正常的http建立链接的时候，通过三次握手就可以建立链接了，而https除了三次握手的部分，还需要SLL握手，也就是：

http耗时 = TCP握手

https耗时 = TCP握手 + SSL握手

　　所以，https肯定是比http耗时的，这个耗时就是SSL延迟。

　　

　　下面，我们通过curl命令来进行测试：

　　这里，我们通过curl命令就可以输出了，-w参数为了定义输出格式，使用%{}即为变量形式，time_connect为TCP握手，time_appconnect为SSL握手， 通过测试，发现， SSL握手的时间约为TCP握手时间的3倍。  在尝试连接 https://www.baidu.com 以及 https://www.zhihu.com 的时候，最终得到的大概是TCP握手时间的两倍左右，当然具体数字取决于当前的状态等。

　　所以，如果是对安全性要求不高的场合，为了提高网页性能，建议不要采用保密强度很高的数字证书。一般场合下，1024位的证书已经足够了，2048位和4096位的证书将进一步延长SSL握手的耗时。

　　

缺点二：贵

　　因为使用https，你就需要买SSL证书，买证书是需要花钱的啊！

　　另外，在服务器端要进行大量的加密和解密的工作，所以成本增加是必然的。

https的主要的计算环节

　　  https主要的计算环节包括四个部分：

1. 红色环节是非对称密钥交换，通过客户端和服务端不一致的信息协商出对称的密钥；

2. 蓝色环节是证书校验，对证书的签名进行校验，确认网站的身份；

3. 深绿色环节是对称加解密，通过非对称密钥交换协商出对称密钥来进行加解密；

4. 浅绿色环节是完整性校验，不仅要加密还要防止内容被篡改，所以要进行自身的完整性校验。

　　知道这些主要的计算环节之后，每一个计算环节对计算性能的影响分别是多少以及如何分析？这里和大家分享我们计算性能的分析维度，主要分为三部分：算法、协议和系统。

1. 算法，所谓的算法其实是HTTPS所用到密码学里最基本的算法，包括对称加密、非对称密钥交换、签名算法、一致性校验算法等，对应的分析手段也很简单：openssl speed；

2. 协议，因为不同的协议版本和消息所对应使用的算法是不一样的，虽然算法的性能很确定，但是和协议关联起来它就不确定了。由于性能和协议相关，我们重点分析的是协议里完全握手的阶段，我们会对完全握手的每个消息和每个函数进行时间的分析；

3. 系统，比如我们使用Nginx和OpenSSL，我们会对它进行压力测试，然后在高并发压力环境下对热点事件进行分析和优化。