计算机网络——深入理解HTTP以及HTTPs

1.HTTP状态码

名称 分类 举例
1XX 消息状态 100 continue
2XX 请求成功 200 请求成功
202 请求成功,但未返回任何资源实体
3XX 重定向 301 永久性重定向
302 临时性重定向
4XX 客户端错误 400 请求存在语法错误
403 请求被服务端拒绝
404 服务端找不到请求资源
5XX 服务端错误 500 服务器存在错误
502 从上游服务器接受无效响应
503 服务器处于维护或者超载状态

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七层网络模型中的会话层:

计算机网络——深入理解HTTP以及HTTPs

2.3 SSL安全机制

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

2.4 SSL握手阶段

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

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

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

计算机网络——深入理解HTTP以及HTTPs

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

  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,表示需要客户端提供证书,内容为:客户端应当提供的证书类型和服务端可以接受的证书列表

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

  1. 客户端回应(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三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。”

  1. 服务器最后回应(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?以及在整个握手过程中的作用

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

证书生成过程

  1. 认证机构会生成一对秘钥, 公钥和私钥
  2. 然后生成服务器(请求者)的数字签名:
  • 服务器公钥 经过数字摘要算法 生成数字指纹
  • 把生成的数字指纹 在用认证机构的私钥加密 生成数字签名
  1. 最后用私钥整体加密生成公钥证书,主要包含两部分内容:数字签名和服务器公钥

客户端校验 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。

版本号 分析 结论
SSL 2.0 1995年发布。它包含许多密码分析设计缺陷,如果不破坏协议就无法解决这些缺陷,并可能导致机密数据的暴露或修改。 禁用这种协议
SSL 3.0 1996年发布,作为完整的重新设计。谷歌的POODLE攻击利用浏览器脚本功能和SSL 3.0中破坏的填充实现来发起中间人攻击,这可能导致机密数据的暴露或修改。 禁用这种协议
TLS 1.0 1999年发布,作为SSL 3.0的修订版。TLS 1.0易受BEAST攻击 禁用TLS 1.0; 如果出现向后兼容性问题,请重新启用。
TLS 1.1 2006年发布,作为TLS 1.0的修订版。该协议的修改包括新的IV生成方案; 因此,TLS 1.1不易受BEAST影响。 启用TLS 1.1。
TLS 1.2 2008年作为TLS 1.1的修订版发布。TLS 1.2引入了有用的功能,例如更高性能的GCM密码套件和基于SHA-256的伪随机函数。 启用TLS 1.2。

加密套件

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

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

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

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

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

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!