HTTPS详解(1)，offer拿到手软

最新推荐文章于 2024-04-12 23:02:45 发布

2401_84149685

最新推荐文章于 2024-04-12 23:02:45 发布

阅读量876

点赞数 8

分类专栏：程序员文章标签： https 网络协议 http

本文链接：https://blog.csdn.net/2401_84149685/article/details/137498059

版权

程序员专栏收录该内容

131 篇文章 0 订阅

订阅专栏

文章详细解释了HTTPS的工作原理，涉及SSL协议的握手过程，强调了对称加密与非对称加密的结合以及为何如此设计。同时讨论了抓包原理和如何避免抓包，提供了抓包工具的使用方法和安全策略建议。

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

Https = Http + SSL

这样看来，HTTPS并不是一个单独的应用层协议，而只是Http使用SSL通道进行数据传输的过程。那么对于Https, 只需要了解Http（参考HTTP详解）和SSL协议即可。而所谓的HTTPS报文也就是SSL报文：外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

SSL协议

SSL（Secure Socket Layer）安全套接层，是一种位于应用层与传输层之间，为网络通信提供安全及完整性验证的一种网络协议。

相对于TCP或HTTP协议，SSL协议要复杂很多。由于它也是建立在TCP协议之上的，所以在使用SSL传输数据之前需要先进行三次握手和服务器建立连接，具体的流程如图所示：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

SSL协议的握手过程

客户端先给服务端发送一个消息，消息内容包括：客户端支持的加密方式，支持的压缩方法，SSL的版本号，客户端生成的随机数，文本内容“Hello”等；
服务端接收到消息后，也回发一个Hello，并携带从客户端支持的加密方式中选择的加密方式，服务端生成的随机数，服务端的SSL版本号等信息；
随后服务器给客户端发送一个Certificate报文，报文中包含服务端的公钥证书；
紧接着服务器给客户端发送Server Hello Done, 表示最初的协商握手过程结束；
客户端接收到服务端发送的握手结束的消息后，以Client Key Exchange作为回应，此报文中包含通信加密过程中使用的一种被称为Pre-master secret的随机密码串，并使用第三步接收到的公钥证书进行了加密；
接着客户端发送Change Cipher Spec报文，该报文告知服务端，此步骤之后的所有数据将使用第五步中生成的master secret进行加密（master secret的生成过程看后面的介绍）；
随后客户端发送Finish报文，此报文中包含连接至今所有报文的整体校验值，用于完整性验证；
服务端接收到客户端发送的Change Cliper Spec报文后，同样以Change Cliper Spec报文作为回应；
接着服务端发送Finish报文给客户端，表示服务端已正确解析客户端发送的整体校验值，至此，SSL握手的过程结束。
随后开始使用HTTP协议传输使用master secret加密过的数据。

说明

前两步是协商加密算法以及传输各自生成的随机数（为后续生成master secret做准备）的过程；
第三步服务端将自己的证书发送给客户端，这个证书中包含一个数字签名（CA签名）和服务端CA证书的公钥，客户端对证书中包含的服务端信息进行Hash, 同时使用接收到的公钥对数字证书解密，获取其中的Hash值，与前面计算得到的Hash值进行比较，即可验证证书的有效性（完整性&真实性）；
服务端收到客户端发送的Change Cipher Spec（第五步），会使用自己的私钥进行解密，获取报文中的Pre-master secret，这时通信双方都拥有对方的Random(前两步生成的)，Pre-master secret，以及自身的Random, 将三个数作为种子通过算法生成master secret, 用来加密后续Http请求过程中的数据。其中master secret的生成规则为:

master_secret = MD5(pre_master_secret + SHA(‘A’ + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA(‘BB’ + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA(‘CCC’ + pre_master_secret + ClientHello.random + ServerHello.random));

更详细的有关SSL协议的内容可参考：RFC 6101 SSL

为什么需要这么复杂

两个方面的考量：安全，效率。如果直接使用对称加密的方式进行加密，如果密钥不被泄漏当然也是安全，但问题是：密钥如何传递给另一端呢，在数据传输过程中，如果通信被窃听，则密钥被窃取，那此时加密就没有任何意义了。那可不可以使用非对称加密的方式呢？理论上是可以的，数据传输之前，服务端只需要将自己的公钥传输给客户端，客户端在传输数据时，使用接收的公钥进行加密，服务端接收到数据后使用私钥进行解密即可。但这里有个不容忽视的问题：效率。非对称加密需要大量计算，肯定会占用很多硬件资源，所以效率太低。所以为了解决安全和效率问题，SSL使用了对称加密（加密和解密使用同样的密钥）和非对称加密（公钥加密，私钥解密）组合的方式：使用非对称加密的方式传输对称加密中生成密钥的种子（pre master secret）【对应上面的第五步】，然后使用对称加密的方式对通信数据进行加密【对应上面的第十步】，既保障了密钥的安全性，也提高了加密速度。

Https真的安全么

既然Https那么安全，那为什么用抓包工具还是可以看到里面的数据。这里需要对抓包过程的原理做一个简单的介绍，抓包，其实就是中间人攻击，在网络请求过程中，抓包工具充当着客户端/服务端的角色，当客户端请求数据时，抓包工具将请求进行拦截，然后构造数据（冒充客户端）向服务端发起请求，此时服务端会返回自己的公钥证书，然后抓包工具将服务端的公钥证书替换成自己的公钥证书，随后将数据返回可客户端（此时充当服务端的角色）。客户端拿到公钥证书后，使用公钥证书中的公钥对Pre-master secret进行加密，并发送给服务端，发送过程中又被抓包工具拦截，由于客户端使用的公钥其实就是抓包工具生成的证书公钥，所以抓包工具只需要使用自己的私钥进行解密即可拿到真实的Pre-master secret（因为抓包工具在之前的过程中已经拿到了双方的随机码，所以到这一步抓包工具相当于已经拿到了后续通信使用的密钥），随后抓包工具使用从服务端接收到的公钥证书中的公钥对Pre-master secret进行加密，然后发送给服务端。随后的通信过程虽然进行了加密，但抓包工具已经生成了密钥（master secret），所以可以查看Https的通信内容。一图以蔽之：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

从抓包的原理可以看出，对Https进行抓包，需要PC端和手机端同时安装证书。

既然这么容易被抓包，那Https会不会显得很鸡肋？其实并不会，能抓包，那是因为你信任抓包工具，手机上安装了与之对应的证书，你要不安装证书，你抓一个试试。而且安全这个课题，是在攻防中求发展，没有最安全，只有更安全，所以将攻击的成本提高了，就间接达到了安全的目标。

如何对Https进行抓包

这里以Charles4.0为例，对Https进行抓包：

依次点击菜单Help -> SSL Proxying -> Install Charles Root Certificate安装PC证书；
依次点击菜单Help -> SSL Proxying -> Install Charles Root Certificate on a Mobile Device or Romote Browser, 此时会弹出一个框，提示让你去 chls.pro/ssl 去下载证书，下载完成后进行安装即可；
依次点击菜单Proxy -> SSL Proxying Settings, 选中页面中的Enable SSL Proxying, 然后点击下面的add, 在弹出的框中的Host编辑框中填写*.* （表示可对所有Https请求进行抓包），端口填写443，点击OK；
手机设置代理（你的电脑的IP地址，端口默认为8888）即可进行抓包；

如何避免被抓包

既然使用了Https协议，就是不想让别人看到数据，那如何避免被抓包呢？这里有2种方法可参考：

使用自定义协议；
使用SSL Pinning;

使用TCP协议

使用自定义协议，也就是以TCP/UDP为基础，使用Socket进行通信（具体可参考网络编程之理论篇），这种方式由于不是使用的Http/Https协议，所以可避免Http类型的抓包工具（如Charles, Fiddler）进行抓包, 但不可避免WireShark，毕竟它太强大，可抓取网络模型中各层的数据。