Http与Https的区别

       HTTP协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取Web浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息 

　　安全套接字层超文本传输协议HTTPS，为了数据传输的安全，HTTPS在HTTP的基础上加入了SSL协议，SSL依靠证书来验证服务器的身份，并为浏览器和服务器之间的通信加密

　　HTTPS协议的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。

HTTPS加密、加密、及验证过程，如下图所示：

　　

HTTPS和HTTP的区别主要如下：

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

HTTPS的工作原理

    HTTPS能够加密信息，以免敏感信息被第三方获取，所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。

　　　　

1、客户端发起HTTPS请求

　　用户在浏览器里输入一个https网址，然后连接到server的443端口。

2、服务端的配置

　　采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。

　　这套证书其实就是一对公钥和私钥

3、传送证书

　　这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4、客户端解析证书

　　这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。

　　如果证书没有问题，那么就生成一个随机值，然后用公钥对该随机值进行加密，

5、传送加密信息

　　这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密。

6、服务段解密信息

　　服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥

7、传输加密后的信息

　　这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8、客户端解密信息

　　客户端用之前生成的私钥解密服务段传过来的信息，于是获取解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

TLS握手协议如下图所示

　　

(1) client端发起握手请求，会向服务器发送一个ClientHello消息，该消息包括其所支持的SSL/TLS版本、Cipher Suite加密算法列表（告知服务器自己支持哪些加密算法）、sessionID、随机数等内容

(2) 服务器收到请求后会向client端发送ServerHello消息，其中包括：

　　SSL/TLS版本；

　　session ID，因为是首次连接会新生成一个session id发给client；

　　Cipher Suite，sever端从Client Hello消息中的Cipher Suite加密算法列表中选择使用的加密算法；

　　Radmon 随机数

(3) 经过ServerHello消息确定TLS协议版本和选择加密算法之后，就可以开始发送证书给client端。证书中包含公钥、签名、证书机构等信息。

(4) 服务器向client发送ServerKeyExchange消息，消息中包含了服务器这边的EC Diffie-Hellman算法相关参数。此消息只在选择使用DHE 和DH_anon等加密算法组合时才会由服务器发出。

(5) server端发送ServerHelloDone消息，表明服务器端握手消息已经发送完成了

(6) client端收到server发来的证书，会去验证证书，当认为证书可信之后，会向server发送ClientKeyExchange消息，消息中包含客户端这边的EC Diffie-Hellman算法相关参数，然后服务器和客户端都可根据接收到的对方参数和自身参数运算出Premaster secret，为生成会话密钥做准备。

(7) 此时client端和server端都可以根据之前通信内容计算出Master Secret（加密传输所使用的对称加密秘钥），client端通过发送此消息告changeCiperSpec知server端开始使用加密方式发送消息。

(8) 客户端使用之前握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成会话密钥master secret，然后使用该会话密钥加密之前所有收发握手消息的Hash和MAC值，发送给服务器，以验证加密通信是否可用。服务器将使用相同的方法生成相同的会话密钥以解密此消息，校验其中的Hash和MAC值

(9) 服务器发送ChangeCipherSpec消息，通知客户端此消息以后服务器会以加密方式发送数据。

(10) sever端使用会话密钥加密（生成方式与客户端相同，使用握手过程中获得的服务器随机数、客户端随机数、Premaster secret计算生成）之前所有收发握手消息的Hash和MAC值，发送给客户端去校验。若客户端服务器都校验成功，握手阶段完成，双方将按照SSL记录协议的规范使用协商生成的会话密钥加密发送数据。

             client在向server发送ClientHello消息的时候，会传送Session ID给server端，server端收到session Id后会去session缓存中查找是否有相同值。如果找到相同值，则server直接发送一个具有相同session ID的ServerHello消息给client端（此时不必新建Session ID），然后双方各发一次ChangeCipherSpec消息后直接进入Finished消息互发阶段，具体如下图所示：

      Client                                                Server

      ClientHello                   -------->
                                                       ServerHello
                                                [ChangeCipherSpec]
                                    <--------             Finished
      [ChangeCipherSpec]
      Finished                      -------->
      Application Data              <------->     Application Data

          Figure 2.  Message flow for an abbreviated handshake

            client和server通过缓存Session ID可以快速建立TLS握手，但是这么做也有一些弊端，例如：1）负载均衡中，多机之间往往没有同步 Session 信息，如果客户端两次请求没有落在同一台机器上就无法找到匹配的信息；2）服务端存储 Session ID 对应的信息不好控制失效时间，太短起不到作用，太长又占用服务端大量资源。而 Session Ticket（会话记录单）可以解决这些问题，Session Ticket 是用只有服务端知道的安全密钥加密过的会话信息，最终保存在浏览器端。浏览器如果在 ClientHello 时带上了 Session Ticket，只要服务器能成功解密就可以完成快速握手。

数字证书的验证

证书的组成

证书包含以下内容：

(1) Validity即有效期，有效期包含生效时间和失效时间，是一个时间区间；

(2) 公钥信息Subject Public Key Info，包括公钥的加密算法和公钥内容；

(3) Fingerprints信息，fingerprints用于验证证书的完整性，也就是说确保证书没有被修改过。 其原理就是在发布证书时，发布者根据指纹算法(此处证书使用了SHA-1和SHA-256算法)计算整个证书的hash值(指纹)并和证书放在一起，client在打开证书时，自己也根据指纹算法计算一下证书的hash值(指纹)，如果和刚开始的值相同，则说明证书未被修改过；如果hash值不一致，则表明证书内容被篡改过；

(4) 证书的签名Certificate Signature Value和Certificate Signature Algorithm，对证书签名所使用的Hash算法和Hash值；

(5) 签发该证书的CA机构Issuer；

(6) 该证书是签发给哪个组织/公司信息Subject；

(7) 证书版本Version、证书序列号Serial Number以及Extensions扩展信息等。

　　如上图所示，为签名过程和client端验证过程。中间方框为一个数字证书，在制作数字证书时，会将证书中的部分内容进行一次Hash得到一个Hash值，然后证书认证机构简称CA会使用私钥将该Hash值加密为Certificate Signature。

　　当证书发送给Client端之后，Client端首先会使用同样的Hash算法获得一个证书的hash值H1。通常浏览器和操作系统中集成了CA机构的公钥信息，浏览器收到证书后可以使用这些公钥解密Certificate Signature内容，得到一个hash值H2。

　　比较H1和H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。

　　自己通过openssl生成的自签发证书只是使用自己的私钥去加密上图左侧计算出的Hash Value，这个时候client端得到server端发过来的证书之后，仍然会尝试使用浏览器或系统内置的CA机构的公钥去解密，解密出来的hash值H2当然不可能与H1相同，因此浏览器认为该证书不受信任。但是如果我们选择相信该证书并且继续访问该web，访问并不会出现任何问题，这是因为证书中的公钥并未加密，使用该公钥也确实能和server端的私钥进行TLS握手。

证书信任链

　　在证书认证过程中还存在一个证书信任链的问题，因为我们从CA机构申请到的证书基本不可能是根证书签发。还是以百度的证书为例，如下图所示，百度证书层级为三层，认证过程如下：

(1) 当client端访问baidu.com的时候，baidu的server会将baidu.com证书发送给client端。

(2) client端的操作系统或者浏览器中内置了根证书，但是client端收到baidu.com这个证书后，发现这个证书不是根证书签发，无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。

于是client端根据baidu.com证书中的Issuer找到该证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2，去CA请求baidu.com证书的颁发机构GlobalSign Organization Validation CA - SHA256 - G2的证书。

(3) 请求到证书后发现GlobalSign Organization Validation CA - SHA256 - G2证书是由根证书签发，而本地刚好有根证书，于是可以利用根证书中的公钥去验证（验证方法见上一节）GlobalSign Organization Validation CA - SHA256 - G2证书，发现验证通过，于是信任GlobalSign Organization Validation CA - SHA256 - G2证书。

(4) GlobalSign Organization Validation CA - SHA256 - G2证书被信任后，可以使用GlobalSign Organization Validation CA - SHA256 - G2证书中的公钥去验证baidu.com证书的可信性。验证通过，于是信任baidu.com证书。

在这四个步骤中，最开始client端只信任根证书GlobalSign Root CA证书的，然后GlobalSign Root CA证书信任GlobalSign Organization Validation CA - SHA256 - G2证书，而GlobalSign Organization Validation CA - SHA256 - G2证书又信任baidu.com证书，于是client端也信任baidu.com证书。这样的一个过程就构成了一条信任链路，整个证书信任链验证流程如下图所示。

 

参考

　　https://www.cnblogs.com/wudaoyongchang/p/6253451.html