一、HTTP 与 HTTPS 有哪些区别？
1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险。HTTPS ，是在 TCP 和网络层之间加入了 SSL/TLS 安全协议，也就是安全套接字层，使得报文能够加密传输。
2. HTTP 连接建立相对简单， TCP 三次握手建立之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP三次握手之后，还需进行 SSL/TLS 的四次握手过程，才可进入加密报文传输。
3. HTTP 的端口号是 80，HTTPS 的端口号是 443。
4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。淘宝是真的淘宝，不是假冒的钓鱼网站等。
二、HTTPS 解决了 HTTP 的具体哪些问题呢？
- 窃听风险，“有心人”窃听到具体的通信内容，信息被不该知道的人，知道了，比如盗取QQ账号。
- 篡改风险，“有心人”篡改了通信内容。不该知道的人，虽然没有知道信息的内容，但是他在信息序列上加上、删除、或者编辑了原来的的内容。比如强制植入垃圾广告
- 冒充风险，“有心人”冒充银行、淘宝等网站，诱导用户输入一些敏感信息，从而盗取用户账户中的钱财等，俗称钓鱼网站。
所以https解决了三个问题，防窃听、防篡改、防冒充。
四、基础的加密算法和基于这些加密算法的加密机制
1、对称加密算法
加密密钥和解密密钥是一样的，加密过程和解密过程是对称的，所以叫做对称加密算法。
优点：加密速度快
缺点：需要双方都有密钥，怎么样传输密钥是最大的问题。
2、非对称加密算法（公开密钥加密算法）
几点说明：
- 加密密钥和解密密钥是不一样的，所以是非对称加密。
- 加密密钥和解密密钥是成对的，可以互相加解密，也就是用其中一个加密，用另一个可以解密。
- 一个公钥，一个私钥，公钥公开，私钥只能自己持有，是自己的一个特征，就好像身份证上的照片，而且不能通过其中一个推算出另一一个。
3、混合加密--数字信封技术
通过公开密钥加密算法传输对称加密算法的密钥，这样就解决了对称加密算法的密钥分发问题。
在实际的通信过程中，HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：
在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
采用「混合加密」的方式的原因：
对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。
4、摘要算法（哈希算法）
几点说明：
- 哈希算法也是一种加密算法。
- 同样的明文输入，输出的密文相同；无论多长的明文，密文的长度都是相同的。不同的明文，哪怕只是很长明文中改动一个字符，输出的密文也会不同。
- 哈希算法不可逆，就是不可能通过密文解密出明文。但是可以通过加密同样的明文，来比对在传输过程中密文是否被改动过。
5、数字证书
客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
这就存在些问题，如何保证客户端得到的服务器的公钥没有被篡改过、且不是钓鱼网站的公钥呢？
所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥在数字证书认证机构中注册，注册后的公钥就可以证明服务器的真实身份。
1、服务器把自己的公钥在数字证书认证机构（CA）注册，数字证书认证机构用自己的私钥加密服务器的公钥，得到服务器的数字证书，并发给服务器。
2、在客户端和服务器通信时，服务器把自己的CA证书发送给客户端。
3、客户端用数字证书认证机构的公钥解密服务器的数字证书，得到服务器的公钥。并用服务器的公钥加密通信信息，传给服务器。
4、服务器用自己的私钥解密客户端传来的密文，得到明文。
综上：一共讲述了三种加密算法和三种基于这些加密算法的加密机制，加密算法：对称加密算法、非对称加密算法（公开密钥加密算法）和哈希算法（摘要算法）；加密机制：数字信封技术、混合加密机制、数字证书。
四、HTTPS是如何建立连接的？其间交互了什么？
在传输层，通过TCP协议的三次握手通信双方建立连接之后，SSL/TLS 协议的握手阶段涉及四次通信。
这四次的通信过程其一为了产生一个双方都知道的会话密钥，来加密通信的内容；其二是验证服务器的真实身份。具体可见下图：：
SSL/TLS 协议建立的详细流程：
step1. 客户端发起加密通信请求
客户端主要向服务器发送以下信息：2个支持+1个随机数
（1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
（2）客户端支持的密码套件列表，如公开密钥加密算法RSA 加密算法。
（3）第一个随机数，即客户端生产的随机数（ Client Random ），后面用于生产“会话秘钥”。
step2. 服务端回应step1中的请求
服务器收到客户端请求后，向客户端发出响应 。服务器回应的内容有如下内容：2个确认+一个随机数+CA证书
针对客户端发来的支持的TLS协议版本和加密算法列表，给出2个确认。
（1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
（2）确认使用密码套件列表，如RSA 加密算法。
（3）第二个随机数，即服务器生产的随机数（ Server Random ），后面用于生产“会话秘钥”。
（4）服务器的CA证书，用来验证服务器的真实身份。
step3. 客户端回应服务器
客户端收到服务器的回应之后，首先通过事先内置于浏览器或者操作系统中的 CA 公钥，解密服务器的CA证书，如果可以解密成功，说明服务器身份真实，不是钓鱼网站。解密出来的明文就是服务器的公钥。然后向服务器发送如下信息：2个通知+2个数据。
2个通知：
1、加密通信算法改变通知，随后客户端发出的信息都将用“会话秘钥”加密通信。
2、客户端握手结束通知，表示客户端的握手阶段已经结束。
2个数据：
1、第三个随机数，即用服务器公钥加密过的随机数（ pre-master key ），也就是随机数pre-master key的密文。
2、用摘要算法把之前通信的所有数据做个摘要，发送给服务端，用来供服务器校验。
以上这样服务器和客户端就同时有三个随机数，即客户端随机数、服务器随机数和pre-master key，接着就用双方协商定的加密算法，各自生成本次通信的“会话秘钥”。在产生会话密钥之前，服务器需要用私钥解密得到第三个随机数pre-master key。
step4. 服务器的最后回应
向客户端发生最后的信息：2个通知+一个摘要
（1）加密通信算法改变通知，表示随后的信息都将用会话秘钥加密通信。
（2）服务器握手结束通知，表示服务器的握手阶段已经结束。
（3）服务器同时把之前所有通信数据做个摘要，用来供客户端校验。
至此，整个 SSL/TLS 的握手阶段全部结束。
接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用会话秘钥加密内容。
综合四次握手过程，
在第一次和第二次握手中，双方互换了各自随机数给对方，协定了TLS版本和加密算法。
在第二次握手中，服务器发送自己的CA证书给客户端。客户端解密出服务器的公钥。验证了服务器的真实身份，防冒充
在第三次握手中，客户端用服务器的公钥加密第三个随机数，使得通信双方都有了产生会话密钥的全部的、原始的信息：三个随机数和加密算法，这样产生了对称加密的密钥，并且分发给了通信双方。防窃听
在第三次握手中，客户端除了向服务器传输了第三个随机数的密文，还有所有通信数据的摘要，供服务器比对校验，防篡改
在第四次握手中，服务器向服务器向客户端传输了所有通信数据的摘要，供客户端比对校验，防篡改。
