简单讲解HTTPS如何保证安全性和可靠性

我们知道https比http多了SSL/TLS协议,使得原先的明文传输得到加密,那么来分析一下原理。

首先要了解一些基础的概念:

对称加密和非对称加密:

对称加密就是双方使用相同的加密和解密方式去处理数据。会比明文传输要安全一些,当然密钥一旦泄露,就不再安全了。

非对称加密双方都会使用两个密钥:公钥和私钥。简单来说,公钥就是可以公开的密钥,私钥就是个人私有的密钥。

举个例子,A和B要使用非对称加密,A把自己的公钥给B,于是B用A的公钥加密数据之后发送回A,A需要用自己的私钥解密。

而TLS握手协议使用的是混合加密:

TLS握手

步骤如下

  1. 客户端发起握手,向服务端发送一个随机数1
  2. 服务器收到后,向客户端发送一个随机数2
  3. 服务器向客户端发送一个数字证书和公钥(数字证书容后解释)
  4. 客户端用收到的公钥加密后发送预主密钥,服务端用自己的私钥解密。(非对称加密)
  5. 现在双方手里都有随机数1、随机数2、预主密钥,三者联合都能算出会话密钥
  6. 此后的沟通都采用会话密钥进行加密沟通,及对称加密。

通过这种方式,先通过非对称加密在保证只有会话双方知道会话密钥的情况下,在进行对称加密可以保证安全

我们注意到有一个东西叫做数字证书出现了,它是做什么的呢?

它是服务器用来向客户端保证"我是我"的。

数字证书

因为上述过程会出现一个问题,加入客户端发送请求没能到达正确的服务端,而是被"黑客"拦截,"黑客"完全可以代替服务端完成全套流程,那就谈不上安全可言了。所以我们需要服务端证明它是正确的服务端。

如何证明呢?我们知道,自己是无法证明自己不是神经病的(bushi),只有大夫可以证明。

那么我们在此引入一个第三方CA,由它来派发证书,就可以证明了。同样的,如何这个证书的真实性呢?可以采用非对称加密。

CA使用自己的私钥在证书签名,客户端用CA公钥验证证书真实性。

数字签名

现在我们已经建立了一个安全的会话,但是仍然存在一些问题:我们可以保证会话过程中信息不被窃取,但是如何保证信息不会丢失呢?或者,仍然有可能发生的篡改如何避免?也就是,如何保证信息的完整性?

https的做法是使用摘要算法生成数字签名,即:

发送方用摘要算法对原始数据计算哈希值,该哈希值唯一,且无法逆向推导出内容。将哈希值附加到数据中一起传输。

接收方用相同密钥计算哈希值,比较哈希值,判断内容是否被篡改。

相关推荐
不做菜鸟的网工12 小时前
BGP特性
网络协议
AlfredZhao17 小时前
生产环境里,为什么不建议把普通端口直接暴露到公网?
linux·https·443·80
明月_清风3 天前
开发者网络概念全扫盲:一篇搞定
后端·网络协议
刘马想放假3 天前
Modbus 全栈技术解析:TCP、RTU、ASCII、RTU over TCP
数据结构·网络协议
王二端茶倒水4 天前
一套可落地的无线运营方案,不能只管 AP,还要管用户、计费和运维
网络协议
162723816084 天前
EtherCAT 分布式时钟(DC)原理与配置实战:把多轴真正"对齐到同一时刻"
网络协议
王二端茶倒水4 天前
宽带无线项目,怎么从一次性交付变成长期运营收入?
网络协议
Avan_菜菜5 天前
FRP 内网穿透完整实战:从 HTTP 映射到 HTTPS 自签代理
运维·nginx·https
用户2530171996275 天前
第6篇:从技术到产品 — Ghost Proxifier 的设计哲学
网络协议