本文原作者“JackJiang2011”，收录时有改动，感谢原作者。
简介
image.png
- HTTPS（全称： Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。
- HTTP+加密+认证+完整性保护=HTTPS
- HTTP加上加密处理和认证以及完整性保护后即是HTTPS
-
使用HTTPS通信时，不再使用http://，而是改用https://。当浏览器方位HTTPS通信有效的Web网站时，浏览器的地址栏内会出现一个带锁的标记。对HTTPS的显示方式会因浏览器的不同而有所改变；
https.png
http.png
为什么要用HTTPS
因为HTTP存在弊端,因为不安全,所以要替换,弊端如下:
- 无法保证消息的保密性
- 无法保证消息的准确性和完整性
- 无法保证消息来源的可靠性
比如客户端向服务端发送保密信息的时候,被抓包以后,信息被篡改,然后伪装成客户端发送给服务端,这样是不是很可怕,举个例子:
- 1.转账功能来说,A人从手机银行发起转账给B人的业务,坏蛋C进行了抓包,将B的信息改成C的信息,然后C发送给服务器;服务器接受到以后,给C转了一笔钱,这就是典型的不知道消息来源的是否可
- 2.A从手机银行向客户端发起了提现10000的业务给服务器,然后A自己想从银行那里搞一个亿,然后自己抓包,篡改数据将10000变成了10000000,然后自己吃了牢饭
HTTPS概念组成 (加密技术,数字签名和数字证书)
为了保证消息的保密性，就需要用到加密和解密。加解密算法分对称加密和非对称加密。
对称加密
采用单钥密码系统的加密方法，同一个密钥可以同时用作信息的加密和解密，这种加密方法称为对称加密，也称为单[密钥加密]
举例
甲和乙是一对生意搭档，他们住在不同的城市。由于生意上的需要，他们经常会相互之间邮寄重要的货物。为了保证货物的安全，他们商定制作一个保险盒，将物品放入其中。他们打造了两把相同的钥匙分别保管，以便在收到包裹时用这个钥匙打开保险盒，以及在邮寄货物前用这把钥匙锁上保险盒。上面是一个将重要资源安全传递到目的地的传统方式，只要甲乙小心保管好钥匙，那么就算有人得到保险盒，也无法打开。
常用算法
在对称加密算法中常用的算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK等。
一般常用DES,3DES,AES
特征
1、DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合；
2、3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高；
3、AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高，支持128、192、256、512位密钥的加密；
特点
传输图.png
对称加密的优点：对称加密解决了http中消息保密性的问题
image.png
对称加密的缺点：对称加密虽然保证了消息保密性，但是因为客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露。对称加密的缺点：对称加密虽然保证了消息保密性，但是因为客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露。
非对称加密
对称加密算法在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密。因为加密和解密使用的是两个不同的密钥，所以这种算法叫作非对称加密算法。采用交换的机制.
举例
甲和乙是一对生意搭档，他们住在不同的城市。由于生意上的需要，他们经常会相互之间邮寄重要的货物。为了保证货物的安全，他们商定制作一个保险盒，将物品放入其中。甲有两把钥匙,把一把(公钥)给乙了,然后乙也将自己的公钥给了甲;接着甲给这个盒子上面上了一把锁,用乙的钥匙(公钥)去锁 一下.乙收到盒子以后,用自己的钥匙(私钥)打开了盒子;如果乙给甲邮寄,原理也是一样的;都是需要将公钥给对方保存自己的私钥,这样就是别人收到盒子以后,也无法打开;
常用算法
RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）。
使用最广泛的是RSA算法，Elgamal是另一种常用的非对称加密算法。
特征
RSA对极大整数做因数分解的难度决定了RSA算法的可靠性。换言之，对一极大整数做因数分解愈困难，RSA算法愈可靠。假如有人找到一种快速因数分解的算法的话，那么用RSA加密的信息的可靠性就肯定会极度下降。但找到这样的算法的可能性是非常小的。今天只有短的RSA钥匙才可能被强力方式解破。到目前为止，世界上还没有任何可靠的攻击RSA算法的方式。只要其钥匙的长度足够长，用RSA加密的信息实际上是不能被解破的。
特点
image.png
缺点
1）非对称加密时需要使用到接收方的公匙对消息进行加密，但是公匙不是保密的，任何人都可以拿到，中间人也可以。那么中间人可以做两件事，第一件是中间人可以在客户端与服务器交换公匙的时候，将客户端的公匙替换成自己的。这样服务器拿到的公匙将不是客户端的，而是服务器的。服务器也无法判断公匙来源的正确性。第二件是中间人可以不替换公匙，但是他可以截获客户端发来的消息，然后篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息；
image.png
2）非对称加密的性能相对对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正是因为如此，https将两种加密结合了起来。
非对称加密最大的问题就是原来数据被篡改,接收方接受到错误数据,造成这个的原因就是公钥公开的问题,那么数字签名就是解决这一问题的最好办法
数字证书与数字签名
数字证书就是互联网通讯中标志通讯各方身份信息的一串数字，提供了一种在Internet上验证通信实体身份的方式，数字证书不是数字身份证，而是身份认证机构盖在数字身份证上的一个章或印（或者说加在数字身份证上的一个签名）。它是由权威机构——CA机构，又称为证书授权（Certificate Authority）中心发行的，人们可以在网上用它来识别对方的身份。
为了解决非对称加密中公匙来源的不安全性。我们可以使用数字签名与数字证书来解决。
申请的过程大致是：
1）自己本地先生成一对密匙，然后拿着自己的公匙以及其他信息（比如说企业名称啊什么的）去CA申请数字证书。
2）CA在拿到这些信息后，会选择一种单向Hash算法（比如说常见的MD5）对这些信息进行加密，加密之后的东西我们称之为摘要：
单向Hash算法有一种特点就是单向不可逆的，只要原始内容有一点变化，加密后的数据都将会是千差万别（当然也有很小的可能性会重复，有兴趣的小伙伴鸽巢原理了解一下），这样就防止了信息被篡改。
3）生成摘要后还不算完，CA还会用自己的私匙对摘要进行加密，摘要加密后的数据我们称之为数字签名。
4）最后，CA将会把我们的申请信息（包含服务器的公匙）和数字签名整合在一起，由此而生成数字证书。
5）然后CA将数字证书传递给我们。
数字证书怎么起作用：
服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端就需要用CA的公匙解密数字证书并验证数字证书的合法性。那我们如何能拿到CA的公匙呢？我们的电脑和浏览器中已经内置了一部分权威机构的根证书，这些根证书中包含了CA的公匙。
image
之所以是根证书，是因为现实生活中，认证中心是分层级的，也就是说有顶级认证中心，也有下面的各个子级的认证中心，是一个树状结构，计算机中内置的是最顶级机构的根证书，不过不用担心，根证书的公匙在子级也是适用的。
客户端用CA的公匙解密数字证书，如果解密成功则说明证书来源于合法的认证机构。解密成功后，客户端就拿到了摘要。
此时，客户端会按照和CA一样的Hash算法将申请信息生成一份摘要，并和解密出来的那份做对比，如果相同则说明内容完整，没有被篡改。最后，客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方式。
下图用图解的方式说明一般的证书申请及其使用过程：
image
https的工作原理
通过上面的学习，我们了解对称加密与非对称加密的特点和优缺点，以及数字证书的作用。https没有采用单一的技术去实现，而是根据他们的特点，充分的将这些技术整合进去，以达到性能与安全最大化。这套整合的技术我们称之为SSL（Secure Scoket Layer 安全套接层）。
所以https并非是一项新的协议，它只是在http上披了一层加密的外壳。
image
先看一下https连接的建立流程图：
image
如上图所，这里把https连接建立到断开分为6个阶段，12过程。
下面将对12个过程一 一做解释：
1）客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密匙长度等）；
2）服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容时从接收到的客户端加密组件内筛选出来的；
3）服务器发送证书报文。报文中包含公开密匙证书；
4）最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束；
5）SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密匙进行加密；
6）接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密匙加密；
7）客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准；
8）服务器同样发送Change Cipher Spec报文；
9）服务器同样发送Finished报文；
10）服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会收到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求；
11）应用层协议通信，即发送HTTP相应；
12）最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
另外，在以上流程图中，应用层发送数据时会附加一种叫做MAC（Message Authentication Code）的报文摘要。MAC能够查知报文是否遭到篡改，从而保证报文的完整性。
下面再用图解来形象的说明一下，此图比上面数字证书的图更加的详细一些（图片来源于《图解HTTP》）：
image
经过上面的介绍，我们可以看出https先是利用数字证书保证服务器端的公匙可以安全无误的到达客户端。然后再用非对称加密安全的传递共享密匙，最后用共享密匙安全的交换数据。
一定要用https吗？
https那么的安全，是不是我们在什么场景下都要去使用https进行通信呢？答案是否定的。
1）https虽然提供了消息安全传输的通道，但是每次消息的加解密十分耗时，消息系统资源。所以，除非在一些对安全性比较高的场景下，比如银行系统，购物系统中我们必须要使用https进行通信，其他一些对安全性要求不高的场景，我们其实没必要使用https。
2）使用https需要使用到数字证书，但是一般权威机构颁发的数字证书都是收费的，而且价格也是不菲的，所以对于一些个人网站特别是学生来讲，如果对安全性要求不高，也没必要使用https。
阿里的收费标准,还是不低的
image.png
未来
Google表示，为保证用户数据和设备的安全，针对下一代 Android 系统(Android P) 的应用程序，将要求默认使用加密连接，这意味着 Android P 将禁止 App 使用所有未加密的连接，因此运行 Android P 系统的安卓设备无论是接收或者发送流量，未来都不能明码传输，需要使用下一代(Transport Layer Security)传输层安全协议，而 Android Nougat 和 Oreo 则不受影响。
iOS 9 以后未来安全也是需要证书的;
网友评论