Http与Https介绍

1. 相关概念

1.1 http和https

HTTP（Hyper Text Transfer Protocol），超文本传输协议。应用层协议，由请求和响应两个部分构成，是一个标准的客户端服务器类型。HTTP本身是一个无状态协议。HTTP协议通常承载于TCP（传输层协议）/IP（网络层协议）协议之上。缺省端口80。

HTTPS（Hyper Text Transfer Protocol Secure），以安全为目标的HTTP通道。HTTPS中的secure是由TLS（SSL）提供。缺省端口443。

HTTPS与HTTP的区别主要如下：

• HTTP是超文本传输方式，信息都是明文传输；HTTPS通过SSL加密传输，比较安全。
• HTTPS协议需要到CA申请证书。
• HTTP连接比较简单，无状态的。HTTPS协议是由SSL+HTTP协议构建的可进行传输、身份认证的网络协议。

1.2 对称加密和非对称加密

• 公钥和私钥成对出现
• 公开的密钥叫公钥，只有自己知道的叫私钥
• 用公钥加密的数据只有对应的私钥可以解密
• 用私钥加密的数据只有对应的公钥可以解密

如果加密和解密使用的是同一个密钥，那么这就是“对称密钥加解密”（最常见的对称加密算法是DES）；如果加密和解密使用的是两个不同的密钥，那么这就是“非对称密钥加解密”（最常用的非对称加密算法是RSA）。

1.3 数字摘要和数字签名

数字摘要就是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。

常见的Hash算法有md5，sha1，sha224，sha256，sha384，sha512

结合“非对称密钥加解密”和“数字摘要”技术，就可以进行数字签名。例如下边这个例子：

在这里插入代码片发送方想把一份报文发送给接收方，在发送报文前，发送方用一个哈希函数从报文文本中生成报文摘要,然后用自己
的私人密钥对这个摘要进行加密，这个加密后的摘要将作为报文的”签名“和报文一起发送给接收方，接收方首先用与发送方一样的哈希
函数从接收到的原始报文中计算出报文摘要，接着再用发送方的公用密钥来对报文附加的数字签名进行解密，如果这两个摘要相同、
那么接收方就能确认报文是从发送方发送且没有被遗漏和修改过！(注意，数字签名只能验证数据的完整性，数据本身是否加密不属于
数字签名的控制范围) 

在上述的过程中，对传送数据生成摘要并使用私钥进行加密地过程就是生成”数字签名“的过程，经过加密的数字摘要，就是人们所说的“数字签名”！

数字签名有两种功效：

• 能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
• 数字签名能确定消息的完整性。

1.4 数字证书

只从“准确认证发送方身份”和“确保数据完整性”两个安全方面来看，数字签名似乎已经完全做到了，还有漏洞存在的可能么？有，漏洞不在数字签名技术本身，而在它所依赖的密钥，只有密钥是真实可靠的前提下，使用数字签名才是安全有效的。

考虑这种可能的情况：在上述发送方向接收方传送报文的例子中，如果发送方所持有的公钥来路有问题或是被替换了，那么，持有对应私钥的冒充接受方就有可能接收到发送方发送的报文。这里的问题就是：对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。这种机构被称为证书权威机构（Certificate Authority, CA），它们所发放的包含主机机构名称、公钥在内的文件就是人们所说的“数字证书”。

数字证书的颁发过程一般为：用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布。数字证书各不相同，每种证书可提供不同级别的可信度。可以从证书发行机构获得您自己的数字证书。

OpenSSL 是一个免费开源的库，它提供了构建数字证书的命令行工具，其中一些可以用来自建 Root CA。
通常情况下，root CA 不会直接为服务器或者客户端签证，它们会先为自己生成几个中间 CA（intermediate CAs），这几个中间 CA 作为 root CA 的代表为服务器和客户端签证。

2. SSL

2.1 介绍

SSL（Secure Socket Layer）安全套接层，位于TCP/IP协议与应用层协议之间，为数据通讯提供安全支持。SSL协议可以分为两层：SSL记录协议、SSL握手协议

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

SSL建立通信的过程分为两个阶段：握手阶段和传输阶段。SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！这并不奇怪，因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！

2.2 特性

• 保密：在握手协议中定义了会话密钥后，所有的消息都被加密。
• 鉴别：可选的客户端认证，和强制的服务器端认证。
• 完整性：传送的消息包括消息完整性检查（使用MAC）。

2.3 用途

• 认证用户和服务器，确保数据发送到正确的客户端和服务器
• 加密数据，防止数据中途被窃取
• 维护数据的完整性，确保数据在传输过程中不被改变。

3. TSL

3.1 介绍

TLS（Transport Layer Security Protocol）安全传输层协议。位于两个通信应用程序之间，保证数据安全和完整性。如下图所示：

TLS协议可以分为两层：TLS记录协议、TLS握手协议。

• TLS记录协议（TLS Record Protocol）
  支持信息传输，将数据分段到可处理块、压缩数据、应用MAC、加密以及传输结果等；对接收到的数据进行解密、校验、解压缩、重组等，然后发送到高层客户机。

• TLS握手协议（TLS Handshake Protocol）握手协议提供的连接安全具有基本的三个属性:

  可以使用非对称或公共密钥的密码来认证对方身份。认证方式可选。

  共享加密密钥的协商过程是安全的。

  协商是可靠的，没有经过通信双方的检测，任何其他攻击者都不能修改通信协商。

4. https握手过程

1. 客户端发起HTTPS请求

2. 服务端的配置

3. 传送证书

   这个证书其实就是服务器的公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等，该公钥的目的是为了和服务器端之间协商对称秘钥对使用，也就是服务器用于自己的私钥加密数据，客户端要用该公钥进行解密；

4. 客户端解析证书

   这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随机值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5. 传送加密信息

   这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。服务器与客户端之间的数据传输过程是采用对称加密方式加密的；

5. 单向认证

客户端验证服务端证书

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。

2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3. 客户端使用服务端返回的信息验证服务器的合法性，包括：

• 证书是否过期

• 发型服务器证书的CA是否可靠

• 返回的公钥是否能正确解开返回证书中的数字签名

• 服务器证书上的域名是否和服务器的实际域名相匹配

  验证通过后，将继续进行通信，否则，终止通信

4. 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

5. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。

6. 服务器将选择好的加密方案通过明文方式返回给客户端

7. 客户端接收到服务端返回的加密方式后，使用该加密方式生成产生随机码，用作通信过程中对称加密的密钥，使用服务端返回的公钥进行加密，将加密后的随机码发送至服务器

8. 服务器收到客户端返回的加密信息后，使用自己的私钥进行解密，获取对称加密密钥。

9. 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。

6. 双向认证

客户端验证服务端证书，服务端也要验证客户端证书

1. 客户端向服务端发送SSL协议版本号、加密算法种类、随机数等信息。

2. 服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息，同时也返回服务器端的证书，即公钥证书

3. 客户端使用服务端返回的信息验证服务器的合法性，包括：

• 证书是否过期

• 发型服务器证书的CA是否可靠

• 返回的公钥是否能正确解开返回证书中的数字签名

• 服务器证书上的域名是否和服务器的实际域名相匹配

  验证通过后，将继续进行通信，否则，终止通信

4. 服务端要求客户端发送客户端的证书，客户端会将自己的证书发送至服务端

5. 验证客户端的证书，通过验证后，会获得客户端的公钥

6. 客户端向服务端发送自己所能支持的对称加密方案，供服务器端进行选择

7. 服务器端在客户端提供的加密方案中选择加密程度最高的加密方式

8. 将加密方案通过使用之前获取到的公钥进行加密，返回给客户端

9. 客户端收到服务端返回的加密方案密文后，使用自己的私钥进行解密，获取具体加密方式，而后，产生该加密方式的随机码，用作加密过程中的密钥，使用之前从服务端证书中获取到的公钥进行加密后，发送给服务端

10. 服务端收到客户端发送的消息后，使用自己的私钥进行解密，获取对称加密的密钥

11. 在接下来的会话中，服务器和客户端将会使用该密码进行对称加密，保证通信过程中信息的安全。