HTTPS详解

置顶李爱乐

已于 2022-08-20 14:24:45 修改

阅读量9.5k

点赞数 5

分类专栏：网络安全文章标签： https ssl 安全网络

于 2021-03-31 19:12:18 首次发布

本文链接：https://blog.csdn.net/qq_38244676/article/details/115336379

版权

网络安全专栏收录该内容

1 篇文章 1 订阅

订阅专栏

HTTPS通过结合HTTP和SSL/TLS协议提供安全的网络通信。它涉及非对称加密、对称加密、数字证书和握手过程，确保数据的加密、认证和完整性。在加密过程中，服务器的公钥通过数字证书传递给客户端，客户端生成随机数并使用服务器公钥加密，然后双方使用共享的对称密钥进行数据传输。中间人攻击可以通过验证证书和域名来防范。HTTPS相比HTTP更安全，但也带来额外的计算开销和成本。

摘要由CSDN通过智能技术生成

1.HTTPS概述

通常，HTTP 直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再由 SSL 和TCP 通信了。简言之，所谓 HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。

SSL 是独立于 HTTP 的协议，所以不光是 HTTP 协议，其他运行在应用层的 SMTP 和Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界上应用最为广泛的网络安全技术。

HTTPS相当于基于SSL的HTTP,更详细来说HTTPS=HTTP+加密+认证+完整性保护。

2.HTTPS详述

2.1前驱知识点:

非对称加密算法（公钥加密）

秘钥成对出现，一个用来加密一个用来解密。如：有RSA、DSA/DSS、Elgamal、Rabin、D-H、ECC等。

对称加密算法（私钥加密）

加密解密使用相同的秘钥，如：有AES、DES、3DES、TDEA、Blowfish、RC4、RC5、IDEA等。

2.2加密过程

一共三种加密：证书加密（本质是HASH加密和非对称加密），公私钥非对称加密，对称加密。

简单过程：

1.服务器端产生一对公钥和私钥，并使用数据证书的方式传输自己的公钥。

2.用户端接到数据后，通过证书解密出公钥，自己通过产生一个对称加密的秘钥假设为key，通过刚才拿到的公钥加密此秘钥，进行传输。

3.服务器接到数据后，通自己的私钥解密出秘钥Key，传输数据，双方后续都通过这个key进行加密传输。

注：数字证书的加密手段也是公私钥的非对称加密，只不过为了防止篡改多了一层hash加密。

2.3 数字证书深入

问题：数字证书怎么保证被截获后无法篡改：

如果不愿意深究可以理解为（网上大多数博客也是这么写的）：对数字证书的加密是通过机构的私钥进行的，而解密用的公钥已经被游览器或者操作系统内置进系统中的。所以，黑客拿到也无法解密。

而实际比这个复杂得多，系统内置的只是几个大的证书公钥，有个授权链，可以一步一步验证。但是CA除了用来加密客户端和服务器交互时的公钥外，还有个不可篡改的保证。证书加密中有有个会附带服务端的网站等信息，篡改会改变。加密用到了Hash算法。

HASH算法：

单向加密。就是只能从明文得到密文，却无法从密文得到明文。如：MD5，SHA1，SHA256。可以用来确认信息没有被篡改。主要用来生成签名，签名是加在信息后面的，可以证明信息没有被修改过。

证书加密的过程：

先对证书所需的信息M进行hash加密，得到一个hash值，然后生成一个机构的非对称公私秘钥对，然后用私钥加密这个hash值得到S。最后把这个S和M合在一起发送。

接收方收到以后通过相同的hash算法对M进行计算，得到的hash值，和使用机构公钥解密S后得到的hash值进行对比，若发现不一致，则证明有人篡改过。

第一个问题：为什么要在hash的基础上再加一层公私钥加密？

若不加，则存在一种情况，黑客修改了M并把hash值也改了，这时无法判断证书被篡改。

第二个问题：套娃来了，那此时这个机构产生的非对称公私秘钥对中的公钥怎么传输？不是又回到原点了？

但是此时黑客拿到这个机构的公钥也无用了，他换成自己的公私钥，但是在游览器和操作系统中内置了各大AC机构的网址，你冒充一个自己的签名是无法通过验证的。

最后一个问题：当HTTPS通讯的初始阶段完成后，使用对称加密的手段进行通讯时。黑客虽然无法识别信息，但是篡改加密后的内容使得无法解密或者重复发送截获的信息如何解决：

给发送的内容加版本号或随机值，如果接收到版本号或随机值不相同的信息，双方立刻停止通信。

除此之外，这个对称秘钥的合成也相当复杂：

在HTTPS四次握手中，一共有三段随机数进行共享，这三段随机数合在一起才是最终要使用的对称秘钥。

2.4 HTTPS加密过程

1）客户端发起一个HTTPS请求，请求服务器公钥，连接服务器443端口，还包含此时客户端生成的随机数（Client Random）。

2）服务端接到请求后生成一个公私钥和一个随机数（Server Random），把公钥以数字证书的形式加上刚才生成的随机数（Server Random）返回给客户端。证书中有一个公钥（此公钥是机构的公钥）来加密信息，私钥由服务器持有（数字证书除了服务器的公钥外，还有网站地址，证书颁发机构，失效日期等）。

3）客户端收到服务器的数字证书后，先验证证书的合法性（是否被篡改，是否过期）。

4）如果验证通过，客户端则生成一个随机数 (pre-master)，并用刚拿到的服务器公钥加密，发给服务器。

5）服务器收到这个随机数后，使用私钥进行解密，此时双方就都拥有3个随机数，分别是Client Random、Server Random、pre-master，通过这三个随机数生成会话秘钥（对称秘钥）。以后双方就使用这个对称秘钥进行传输数据，提高效率。

6）最后，客户端和服务端相互发送一个摘要信息，包含之前发送的所有数据的摘要，叫做「Encrypted Handshake Message（Finishd）」，用会话加密加密后发送，以验证之前交互的消息是否被篡改过。服务器做个验证，验证加密通信是否可⽤和之前握⼿信息是否有被中途篡改过。

2.5 对称加密算法的生成深入

上面2.4的交换方式被称为RSA秘钥交换算法，是传统方法，也是最简单的方法，存在的问题是不支持向前保密，即一旦服务器私钥泄露，之前的所有消息都有被破解的可能。

解决方法是基于离散对数的DHE算法，客户端和服务端各⾃会⽣成随机数，并以此作为私钥，然后根据DH 算法计算公示算出各⾃的公钥，然后通过交换双方公钥。此时双方都有自己的私钥和对方的公钥，通过这个这个公私钥算出一个随机数，此随机数就是最后用的对称加密密钥。

离散对数很简单，如下

g的x次方取模于p得到y，其中g和p是公开的，当知道x时，很容易得到有，但是只知道y很难得到x。

放入上述所说过程，其中y就相当于公钥，x相当于私钥。而离散对数的幂运算有交换律，所以很容易通过自己的私钥和对方的公钥得到相同的结果，即最后用的对称秘钥。

而在实际应用中双方每次在交换秘钥时，自己的私钥都是随机生成的（即每次都变）。这样才能保证向前安全性。

但是DHE算法虽然安全性高，但是对性能的要求实在太高，故当前主流的是通过ECC（椭圆加密算法）特性的ECHE算法。

过程如下：

1.双方事先确定好使用的椭圆曲线和曲上的基点G；

2.双方各自生成一个随机数d（私钥），与基点 G相乘得到公钥D；

3.双方交换各自的d和D，由于椭圆曲线也满足乘法交换和结合律，故双方可以得到相似的数，此数也就是最后用的会话秘钥（对称的）。
此过程的利用了椭圆曲线的特性，相较于传统离散对数运算量较小。（其实还是挺大的，只是相对于离散对数）。

然后实际生产的会话秘钥（对称的）也是通过客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥）三个材料⽣成的。

而选择椭圆曲线和椭圆曲线基点G，则是在服务器第一次收到客户端的请求时选择好并发给客户端的。

而ECDHE算法相当于 RSA 密钥算法的一大优化，也在于此时，双方已经具备相互发送消息的条件了，此时服务器便可以向客户端发送数据了。客户端可以不用等服务端的最后⼀次 TLS 握⼿，就可以提前发出加密的 HTTP 数据，节省了⼀个消息的往返时间；

最后，虽然会话秘钥是通过非对称加密算法生成的，但是会话秘钥本身是对称的。

3.中间人攻击

中间人攻击是指在建立游览器和服务器建立连接的一开始，就被一个中间人给劫持了，换成自己的域名、端口和证书，HTTPS能否解决？

这个得看客户端或游览器端是如何实现的？是否开启了域名效验或者证书效验是否完整。

所以预防方式也分为一下几种：

1）如果是安全性要求特别高那种，建议直接把服务器的证书锁死。即这个证书就内置进入，不变了，过期的时候强制下载更新证书。

2）开启校验域名，证书有效性、证书关键信息及证书链。

4.HTTP 和 HTTPS 的区别

（1）端口： HTTP默认使⽤端口80，⽽HTTPS的默认使⽤端口443。

（2）安全性。

（3）效率：

HTTPS协议多次握手，导致页面的加载时间是HTTP的2-100倍；
HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗；
SSL涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大（可以使用SSL加速器进行加速）。

（4）成本：申请SSL证书需要钱，功能越强大的证书费用越高。

4.如何发展到HTTPS这种级别的加密协议的：

最初

共享密钥加密：加密和解密同用一个密钥的方式称为共享密钥加密（Common key crypto system），也就是上文说的对称密钥加密。

单纯用此方法会出现第一个俄罗斯套娃问题：秘钥怎么安全发送？

万物的本质都是俄罗斯套娃。

公开密钥加密：

使用一对非对称的密钥，这一对秘钥中一把用来加密，一把用来解密。一把叫做私有密钥（private key），另一把叫做公开密钥（public key），两者没有本质区别，使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。（多说一句，既可以用公钥就进行加密，也可用私钥用来加密。）

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。

HTTP将这两者混合起来，并取长补短。在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

第二个套娃来了，怎么证明公开秘钥是正确的？就是A传给B的公钥key1，万一被C改了变为key2，通讯还是不安全的。

使用由数字证书认证机构（CA，Certificate Authority）和其相关机关颁发的公开密钥证书。

首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。服务器会将这份由数字证书认证机构颁发的公钥证书发送给客户端，以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二，服务器的公开密钥是值得信赖的。

此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。