Http与Https区别

1、区别：

1.1 概念

Https是一种通过计算机网络进行安全通信的传输协议。Https经由Http进行通信，利用SSL/TLS进行加密数据包。旨在提供对网络服务器的身份认证，同时，保护交换数据的的隐私与完整性。坦白讲，以安全为目标的Http通道，即Http的安全版。以一个简单的公式来表达：Http + 加密 + 身份认证 + 完整性保护 = Https

Http是一种详细规定了浏览器和万维网服务器之间相互通信的规则，通过因特网传输万维网文档的数据传送协议。

Http有以下几点问题：

重要信息明文传输;
通信双方可能被伪冒;

数据泄密和被篡改;

针对支付交易部分，https显得尤为重要。

1.2 区别

	Http	Https
身份认证	无，易伪冒	需要申请CA证书
端口	80	443
SSL/TLS	无，明文传输，不安全	加密传输，安全完整

从OSI7层模型来看，尤为明显。在Http应用层和TCP传输层增加了一层SSL/TLS安全层.

Https与Http比较

2、SSL/TLS是如何加密的：

2.1 加密方法

共享密钥方式加密 = 对称加密 = 处理速度快

公开密钥方式加密 = 非对称加密 = 处理速度较慢

共享密钥方式加密只要密钥足够安全，服务器将密钥交给客户端，然后通信过程中和客户端使用同一把密钥进行加解密。毕竟通信过程肯定是速度尽量快才最好，达到用户请求，快速响应返回并交互的目的。

那么问题来了，服务器如何将密钥安全的传递给客户端呢？

此时，就需要公开密钥加密方式登场了。公开密钥加密方式就是使用公钥加密，私钥解密的方式对加密信息解密，从而恢复信息。发送方(服务器)使用接收端(客户端)的公钥对数据进行加密，然后接收方使用私钥对接收到的数据进行解密。从而上述问题就解决了，通信双方持有对方的公钥，发送共享密钥使用公钥加密，就不怕共享密钥被获取了。

那么，新的问题又来了，公钥是发放出去的，如何证明发给客户端的过程中，公钥没有被替换掉呢？假如公钥被替换掉，伪冒者可以代替服务器接收客户端发送的数据，从而代替服务端和客户端通信。

这时候就要用到数字证书认证机构。Https中，服务端将公钥给数字认证机构进行安全认证并对公钥进行数字签名，公钥和签名组成数字证书。在和客户端通信时，服务端将数字证书发送给客户端，客户端通过第三方认证机构发布的公钥(一般会在浏览器开发时，内置在浏览器中)对数字证书上的签名进行验证，如果验证通过，则证明一下事实：

认证该服务器的公钥机构是真实有效的数字证书认证机构
该服务器发过来的公钥是值得信赖的

因为通信双方都需要证明自己发出的公钥真实可靠，所以也就存在两种目的性不同的数字证书：可证明组织真实性的EV SSL证书，来确认客户端证书。

2.2 工作流程

因此，SSL/TLS协议基本过程是这样的：

客户端向服务端索要并验证公钥;
双方协商生成“对话密钥”;
双方采用"对话密钥"进行加密通信;

上述过程前两步又称为"握手阶段"

握手的详细过程：

握手阶段

2.2.1 客户端发出请求(Client Hello)

首先，客户端(通常是浏览器)先向服务器发出加密通信的请求，称作ClientHello请求。

客户端主要向服务器提供以下信息:

支持的协议版本如TLS 1.0；
一个客户端生成的随机数，稍后用于生成“对话密钥”;
支持的加密方法，如RSA公钥加密;
支持的压缩方法;

需要注意的是，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

2.2.2 服务器回应(Server Hello)

服务器收到客户端请求后，向客户端发出回应，称作ServerHello。服务器向客户端回应一下内容:

确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
一个服务器生成的随机数，稍后用于生成"对话密钥"。
确认使用的加密方法，比如RSA公钥加密。
服务器证书。

除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供"客户端证书"。

2.2.3 客户端回应

客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。

如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

一个随机数。该随机数用服务器公钥加密，防止被窃听。
编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称“pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把“会话密钥”。

至于为什么一定要用三个随机数，来生成“会话密钥”？

不管客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器导出一个对称密钥。

pre master 的存在在于SSL协议不信任每一个主机都能产生完全随机的随机数。如果随机数不那么随机，那么pre master secret就有可能被猜出来，那么仅使用pre master secret 作为密钥就不适合了，因此必须引入新的随机因素，那么客户端和服务器加上 pre master secret 三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，但三个伪随机就十分接近随机了，每增增加一个自由度，随机性就大增。

此外，如果上一步服务器要求客户端证书，客户端会在这一步发送证书及相关信息。

2.2.4 服务器的最后响应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。

编码通知改变，表示随后的信息都将使用双方商定的加密方法和密钥发送。
服务器握手结束通知，表示服务器握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用的普通的Http协议，只不过使用"会话密钥"加密内容。

3.参考链接

1.SSL/TLS协议运行机制的概述

2.Https与Http --TLS/SSL