HTTPS原理解析

tsteam

一、HTTPS风险

1.1 风险一: 网络嗅探与监听

用wireshark抓包时发现,途径终端ip的所有http报文都可以以明文方式被直接捕获,包括但不限于用户名、密码、报表数据等。

  • 本地src = 10.252.18.21,天枢服务器desc = 172.28.63.46。浏览器通过post方式向服务器发起请求:
    image.png
  • 服务器返回数据:
    image.png
  • 思考:不使用https的情况下,应该如何处理客户端输入的口令/提交的表单以保证数据机密性?
    前端:
    将明文数据用md5哈希;
    将哈希过的密文拼上一段随机生成的, 固定长度的盐;
    将上一步的结果使用后端的公钥加密并传递给后端.

    后端:
    将前端传递过来的密文用私钥解密;
    去盐。因为盐是固定长度的, 所以直接裁剪即可;
    再次随机生成一段盐;
    将第2步去盐后的密码拼上第3步生成的盐, 并作 md5 哈希;
    将第4步的结果和第3步生成的盐存入数据库;

    验证密码的时候, 后端只需将第2步去盐后的密码拼上从数据库中取得的盐, 作 md5 哈希后与数据库中的密码相比较即可。

1.2 风险二:身份认证缺乏校验,存在中间人攻击。

image.png

1.3 风险应对措施

  • 信息加密
    HTTP 交互信息是被加密的,第三方就无法被窃取。
  • 校验机制
    校验信息传输过程中是否有被第三方篡改过,如果被篡改过,则会有警告提示。
  • 身份证书
    证明通信双方身份的真实性。

二、HTTPS协议

2.1 HTTPS

HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议,主要通过数字证书、对称加密、非对称加密等技术完成互联网数据传输加密,实现互联网传输安全保护。

设计目标主要有三个。
(1)机密性(通过对称加密实现):保证传输数据内容不会被第三方知晓。就像快递员传递包裹一样,都进行了封装,别人无法获知里面装了什么。

(2)完整性(通过数字签名/哈希实现):保证传输数据内容没有被第三方篡改。就像快递员虽然不知道包裹里装了什么东西,但他有可能中途掉包,数据完整性就是指如果被掉包,我们能轻松发现并拒收。

(3)可靠性(通过非对称加密实现):保证传输数据内容只会被指定有权限的通信方收到。就像我们邮寄包裹时,虽然是一个封装好的未掉包的包裹,但必须确定这个包裹不会送错地方,通过身份校验来确保送对了地方。
image.png

2.2 SSL

Secure Socket Layer,安全套接字协议,用以保障在Internet上数据传输的安全,利用数据加密技术,保证传输数据的机密性、完整性、可靠性。

SSL是一个不依赖于平台和运用程序的协议,位于TCP/IP协议与各种应用层协议之间,为数据通信提高安全支持。
image.png

SSL协议主要分为两层:

(1)SSL握手协议层:包括SSL握手协议(SSL HandShake Protocol)、SSL密码参数修改协议(SSL Change Cipher Spec Protocol)和SSL告警协议(SSL Alert Protocol)。握手层的这些协议用于SSL管理信息的交换,允许应用协议传送数据之间相互验证,协商加密算法和生成密钥等。

(2)SSL记录协议层:为高层协议提供基本的安全服务。SSL纪录协议针对HTTP协议进行了特别的设计,使得超文本的传输协议HTTP能够在SSL运行。纪录封装各种高层协议,具体实施压缩解压缩、加密解密、计算和校验MAC等与安全有关的操作。

2.3 TLS

TLS(Transport Layer Security,传输层安全协议)建立在SSL 3.0协议规范之上,是SSL 3.0的后续版本。与SSL主要的区别在于支持的加密算法不同。
TLS对于安全性的改进:

1)对于消息认证使用密钥散列法:TLS 使用“消息认证代码的密钥散列法”(HMAC),当记录在开放的网络(如因特网)上传送时,该代码确保记录不会被变更。SSLv3.0还提供键控消息认证,但HMAC比SSLv3.0使用的(消息认证代码)MAC 功能更安全。

2)增强的伪随机功能(PRF):PRF生成密钥数据。在TLS中,HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了,只要第二种算法未暴露,则数据仍然是安全的。

3)改进的已完成消息验证:TLS和SSLv3.0都对两个端点提供已完成的消息,该消息认证交换的消息没有被变更。然而,TLS将此已完成消息基于PRF和HMAC值之上,这也比SSLv3.0更安全。

4)一致证书处理:与SSLv3.0不同,TLS试图指定必须在TLS之间实现交换的证书类型。

5)特定警报消息:TLS提供更多的特定和附加警报,以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

三、加解密算法

image.png

3.1 非对称加密

3.1.1 特点

加密密钥≠解密密钥,公钥和私钥之间存在数学上的配对关系。

公钥:公开的,用于加密或者验签。使用公钥加密的数据,只能使用对应私钥解密
私钥:秘密的,用户解密或者签名。使用私钥签名的数据,可以使用对应的公钥验签。

3.1.2 加密机制

公钥密码:公钥加密得到密文,私钥解密得到明文消息。
image.png
数字签名
):私钥加密生成签名,公钥解密验证签名
image.png
TLS常用非对称加密、密钥协商算法:
image.png
TLS常用签名算法:
image.png
ECDSA详细:https://zhuanlan.zhihu.com/p/66794410

ECC(ECDSA)与RSA 相比,有以下的优点:
a. 相同密钥长度下,安全性能更高,如160位ECC已经与1024位RSA、DSA有相同的安全强度。
b. 计算量小,处理速度快,在私钥的处理速度上(解密和签名),ECC远 比RSA、DSA快得多。
c. 存储空间占用小 ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多, 所以占用的存储空间小得多。
d. 带宽要求低使得ECC具有广泛得应用前景。

注意:不要选择1024bit及以下的RSA算法做HTTPS的加密,建议使用2048bit以上的RSA。ECDHE+AESGCM最先选,目前没有已知漏洞。

3.2 对称加密

3.2.1 特点

加密密钥=解密密钥。
TLS常用对称加密算法:AES,主要有四种操作处理,分别是密钥加法层(也叫轮密钥加,英文Add Round Key)、字节代换层(SubByte)、行位移层(Shift Rows)、列混淆层(Mix Column)。
image.png

四、HTTPS通信流程

4.1 概览

image.png

4.2 具体步骤

  1. 客户端发起请求,与服务器建立TCP连接(三次握手)
    image.png
  2. TLS第一次握手
    (1)客户端->服务器 Client Hello
    消息里面有客户端使用的 TLS 版本号、支持的密码套件列表,支持的压缩算法,以及生成的随机数(Client Random),这个随机数会被服务端保留,它是生成对称加密密钥的材料之一。
    image.png
    注:TLS支持的所有加密算法: Transport Layer Security (TLS) Parameters (iana.org)
    (2)服务器→客户端 ACK
  3. TLS第二次握手
    (1)服务器->客户端 Server Hello

当服务端会确认 TLS 版本号是否支持,和从密码套件列表中选择一个密码套件,以及生成随机数(Server Random)。

接着,返回「Server Hello」消息,消息里面有服务器确认的 TLS 版本号,也给出了随机数(Server Random),然后从客户端的密码套件列表选择了一个合适的密码套件。
image.png

可以看到,服务端选择的密码套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个密码套件看起来真让人头晕,好一大串,但是其实它是有固定格式和规范的。基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」, 一般 WITH 单词前面有两个单词,第一个单词是约定密钥交换的算法,第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是:

由于 WITH 单词只有一个 RSA,则说明握手时密钥交换算法和签名算法都是使用 RSA;
握手后的通信使用 AES 对称算法,密钥长度 128 位,分组模式是 GCM;
摘要算法 SHA256 用于消息认证和产生随机数;

就前面这两个客户端和服务端相互「打招呼」的过程,客户端和服务端就已确认了 TLS 版本和使用的密码套件,而且你可能发现客户端和服务端都会各自生成一个随机数,并且还会把随机数传递给对方。

那这个随机数有啥用呢?其实这两个随机数是后续作为生成「会话密钥」的条件,所谓的会话密钥就是数据传输时,所使用的对称加密密钥。

注:配置https时,加密套件的安全性:

ECDHE+AESGCM最先选,目前没有已知漏洞。
PFS ciphersuite优先,其中ECDHE优先于DHE
SHA256优先于SHA1。完全禁用MD5。
AES 128优先于AES 256。这个问题有一些讨论。
在向后兼容模式中,AES优先于3DES。
完全禁止RC4。3DES只用于兼容老版本。

(2)服务器->客户端 Server Certificate
服务端为了证明自己的身份,会发送「Server Certificate」给客户端,这个消息里含有数字证书。
image.png
(3)服务器→客户端 Server Hello Done
目的是告诉客户端,我已经把该给你的东西都给你了,本次打招呼完毕。
image.png

  1. 客户端验证证书,验证原理如本文3.1-加密机制-数字签名。
    image.png
    image.png
    image.png
  2. TLS第三次握手

客户端验证完证书后,认为可信则继续往下走。接着,客户端就会生成一个新的随机数 (pre-master),用服务器的 RSA 公钥加密该随机数,通过「Change Cipher Key Exchange」消息传给服务端。

服务端收到后,用 RSA 私钥解密,得到客户端发来的随机数 (pre-master)。

至此,客户端和服务端双方都共享了三个随机数,分别是 Client Random、Server Random、pre-master。

于是,双方根据已经得到的三个随机数,生成会话密钥(Master Secret),它是对称密钥,用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后,然后客户端发一个「Change Cipher Spec」,告诉服务端开始使用加密方式发送消息。
image.png
然后,客户端再发一个「Encrypted Handshake Message(Finishd)」消息,把之前所有发送的数据做个摘要,再用会话密钥(master secret)加密一下,让服务器做个验证,验证加密通信是否可用和之前握手信息是否有被中途篡改过。
image.png
可以发现,「Change Cipher Spec」之前传输的 TLS 握手数据都是明文,之后都是对称密钥加密的密文。

  1. TLS第四次握手

服务器也是同样的操作,发「Change Cipher Spec」和「Encrypted Handshake Message」消息,如果双方都验证加密和解密没问题,那么握手正式完成。

  1. 用会话密钥加解密请求与响应

4.3 其他

1.为什么公钥存储在客户端,私钥存储在服务器?

(1)请求是由客户端向特定服务器发起的,客户端只希望特定的服务器能解密,因此https设计成只有持有特定私钥的服务器才能解密的机制。

(2)私钥存储在用户物理机器上,每次请求用户都要输私钥(响应不过来);私钥存储在浏览器cookie上,容易泄露、被iframe读取;还有一种口令密钥协商的情况(不适合C-S http请求的应用场景)

(3)密码学角度上来说,私钥加密的数据,一定能被公钥解密。无法满足信息的机密性。

2.为什么要用随机数进行对称加密?

保证会话的前向安全性。即使本次会话的会话密钥泄露,也不会影响之前会话的秘密泄露。

阅读 700
1 声望
1 粉丝
0 条评论
1 声望
1 粉丝
文章目录
宣传栏