1.HTTP状态码

2.HTTPS

首先明确一点，https的出现就是为了解决http明文传输数据不安全性的问题。如果要真正做到在网络通信中数据安全传输，首先要解决的三大问题：数据的机密性、数据的有效性、数据的完整性和一致性
对于数据机密性：https(ssl/tls)通过非对称密钥交换密钥，对称加密传输数据保证
对于数据有效性：https(ssl/tls)通过签名和认证保证
对于数据完整性和一致性：https(ssl/tls)通过消息摘要算法（单向散列算法）保证

2.1 HTTPS简介

https并不是一种全新的协议，它实际上是http协议和ssl（TLS）协议的组合，即建立在ssl（Secure Socket Layer）上的安全协议，即安全性通过SSL协议实现。

2.2 SSL简介

SSL是一种位于应用层和传输层之间，可以为任何基于TCP等可靠连接的应用层协议提供安全性保证的协议 SSL利用身份验证，数据加密和消息完整性验证机制，为网络上数据的传输提供安全性保证。SSL目前有三个版本，SSL1.0、SSL2.0、SSL3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。SSL支持各种应用层协议。

SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

TLS（Transport Layer Security）是SSL的继任者，是SSL 3.0的后续版本，该协议也由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。

下图可以看出SSL/TLS与传输层和应用层之间的关系，即位于OSI七层网络模型中的会话层：

2.3 SSL安全机制

• 身份验证机制
  基于证书利用数字签名方法对服务器和客户端进行身份验证，其中客户端的身份验证是可选的。
• 数据传输的机密性
  利用对称密钥算法对传输的数据进行加密。
• 消息完整性验证
  消息传输过程中使用MAC算法来检验消息的完整性。

2.4 SSL握手阶段

SSL通过握手过程交换数据传输过程中加密用的密钥，建立起安全的链接。注意以下几点

• 由于非对称加密的速度比较慢，所以它一般用于密钥交换，双方通过公钥算法协商出一份密钥，然后通过对称加密来通信，当然，为了保证数据的完整性，在加密前要先经过HMAC的处理。
• 握手阶段是发生在TCP建连之后开始进行的，握手其实就是在协商，协商加解密协议所需要的一些参数信息等内容。
• 握手过程有单向验证和双向验证之分，简单解释一下，单向验证就是server端将证书发送给客户端，客户端验证server端证书的合法性等，例如百度、新浪、google等普通的https网站，双向验证则是不仅客户端会验证server端的合法性，同时server端也会验证客户端的合法性，例如银行网银登陆，支付宝登陆交易等。

SSL缺省只进行server端的认证，客户端的认证是可选的。以下是其流程图：

解释一下上图发生的主要四次通信过程：

1. 客户端发出请求

    - 支持的协议版本号（SSL Version），比如TLS 1.0版。
    - 一个客户端生成的随机数（Client Random1），稍后用于生成"对话密钥"。
    - 客户端支持的加密套件（Support Ciphers）比如：RSA公钥加密算法、DH加密算法。

2. 服务器回应（Sever Hello、Certificate、Server Key Exchange、Server Hello Done）
   上图中，从Server Hello到Server Done，有些服务端的实现是每条单独发送，有服务端实现是合并到一起发送。Sever Hello和Server Done都是只有头没有内容的数据。主要发送以下内容：

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

   ps1：此为单向验证，若是双向验证，需要在Sever Hello Done之前发送Certificate Request，表示需要客户端提供证书，内容为：客户端应当提供的证书类型和服务端可以接受的证书列表

此时上面这两步都还是明文传输！！！

3. 客户端回应（Client Key Exchange、 Change Chiper Spec、Encrypted Handshake Message）
   ps1:如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。

    - 一个随机数（Pre Master Secret）。客户端将通过约定算法生成一个48字节的premaster secret，即预主密钥，这个密钥中包含了客户端tls的版本号信息和一个随机数，如果有中间人共计，有意降低TLS版本的话，则会马上终止发送数据。即协议版本设计来抵御rollback attacks（反转攻击）。该随机数用服务器公钥加密，防止被窃听。
    - 编码改变通知（Change Chiper Spec），表示随后的信息都将用双方商定的加密方法和密钥发送。
    - 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

至于为什么一定要用三个随机数，来生成”会话密钥”，dog250解释得很好：
“不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于TLS协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。”

4. 服务器最后回应（New Session Ticket, Change Chiper Spec, Encrypted Handshake Message）

new session ticket
该数据包主要是server端向客户端发送新的session ticket，因为最开始并没有这个信息，并通知客户端开始使用加密方式传输数据。该session ticket就相当于普通网站中的session，当浏览器在次发送请求或者中间网络原因连接被断开之后，client hello阶段携带该session id，则认为是同一个人访问，不在进行证书交互阶段，该session id的复用也是优化的一点。发送的内容如下

- 服务端传输改变通知（Change Chiper Spec）
- 服务端第一个加密报文（Encrypted Handshake Message）用以做出对之前握手过程的简单验证！

简单总结以上过程：
客户端和服务端建立 SSL 握手：客户端通过 CA 证书来确认服务端的身份；互相传递三个随机数，之后通过这随机数来生成一个密钥；互相确认密钥，然后握手结束；数据通讯开始，都使用同一个对话密钥来加解密；
我们可以发现，在 HTTPS 加密原理的过程中把对称加密和非对称加密都利用了起来。即利用了非对称加密安全性高的特点，又利用了对称加密速度快，效率高的好处。

2.5 延申：什么是ＣＡ？以及在整个握手过程中的作用

  认证机构CA（Certificate Authority）在https中是一个很重要的角色，CA是PKI的核心执行机构，是PKI（Public key Infrastructure  公钥基础设施）的主要组成部分，通常称之为认证中心，从广义上讲，认证中心还应该包括证书申请注册机构RA（Registration Authority），它是数字证书的申请注册、证书签发的管理机构。客户端是怎么验证该证书的颁发机构即CA中心是合法有效的呢，其实在系统浏览器中有预埋CA中心的根证书，在其中的根证书为可信任机构.

证书生成过程

1. 认证机构会生成一对秘钥, 公钥和私钥
2. 然后生成服务器（请求者）的数字签名：

• 服务器公钥 经过数字摘要算法 生成数字指纹
• 把生成的数字指纹 在用认证机构的私钥加密 生成数字签名

3. 最后用私钥整体加密生成公钥证书，主要包含两部分内容：数字签名和服务器公钥

客户端校验 CA 证书的步骤

服务器将公钥证书发送给客户端， 客户端验证公钥证书从而确保公钥的合法性。

1、客户端取出提前内置在手机内部的认证机构的公钥
2、用认证机构的公钥去解密公钥证书里的数字签名 从而得到数字指纹
3、客户端对公钥证书的服务器公钥进行数字摘要算法 从而生成数字指纹
4、对比客户端自己生成的数字指纹(第3步)和解密得到的数字指纹(第2步)是否一致 如果一致则公钥证书验证通过，服务端是可以被信任的；如果不相等，那么就说明该证书是错误的，可能被篡改了，浏览器会给出相关提示，无法建立起 HTTPS 连接。除此之外，还会校验 CA 证书的有效时间和域名匹配等。

2.6 加密套件和协议版本

在强化基于SSL/TLS的服务时，两个配置参数至关重要：允许的SSL/TLS版本和允许的密码套件。应根据最佳实践设置这些参数，但这些参数并不总是很清楚; 此外，在不断发展的安全世界中，昨天解决一个安全问题的最佳建议可能成为当今易受攻击的配置。

协议版本
库代码中广泛支持五种版本的SSL/TLS：SSL 2.0，SSL 3.0，TLS 1.0，TLS 1.1和TLS 1.2。

加密套件

• 密钥交换算法
• 数据加密算法
• 消息验证算法（MAC:Message Authentication Code）。

密钥交换算法用于握手过程中建立信道，一般采用非对称加密算法。

数据加密算法用于信道建立之后的加密传输数据，一般采用对称加密算法。

消息验证算法是一种哈希，用于验证消息的完整性，包括整个握手流程的完整性（例如TLS握手的最后一步就是一个对已有的握手消息的全盘哈希计算的过程）。

如何选择各个算法呢？
优先选择ECC证书和ECDHE握手的方式，如果客户端不支持或者只有RSA证书，就会选择RSA证书和ECDHE密钥交换算法，而一直没有选择RSA的密钥交换算法。只有在ECDHE密钥交换算法完全不支持之后才会去可能使用RSA来进行密钥交换
(RSA密钥交换、DH以及DHE密钥交换算法在实际的应用相对在减少。ECDHE逐渐成为主流。)
关于选择ECDHE加密算法主要基于前向安全性 —— 即对历史通讯的安全！

本作品采用《CC 协议》，转载必须注明作者和本文链接