网络基础(二) HTTPS和网络安全

上一篇文章描述了HTTP协议的基础, 本文主要讲述HTTP的不足和网络安全方面的内容

一 HTTP的不足

HTTPS的诞生和HTTP的不足息息相关; 主要有以下几个缺点:

• 通信使用明文传输, 内容可能会被窃听
• 不对通信方的身份做任何验证, 可能遭遇身份伪装
• 报文的完整性无法验证, 所以内容有可能遭到篡改

1 通信使用明文可能会被窃听

HTTP本身不无法加密, 所以也无法做到对通信整体(使用HTTP协议通信的请求和响应的内容)进行加密. 也就是, HTTP报文传输是明文发送的;因此也会带来安全问题

1.1 TCP/IP 是可能被窃听的网络

网络是互通的, 不仅如此, 在传输的过程中, 可能经历了很多中间步骤, 比如代理等! 由于传输没有任何加密, 因此TCP在建立连接和断开连接, 以及通道建立后的传输, IP数据的传输等任何一个环节都有可能遭到攻击, 劫持.

1.2 Charles抓包原理

相信大家都用过这个抓包工具, 操作步骤不再讲述. 其中有一步, 就是设置中间代理. 当我们进行客户端和服务端交互时, Charles设置的代理相当于是个中间人, 客户端和服务端不再通过直连的方式进行数据交互, 而是通过这个中间人进行转发.

在转发的过程中, 因为HTTP通信机制的不加密性也就是明文传输, 所以Charles工具可以对请求和响应做任意的篡改. 主要是对传输过程中的数据包进行抓取手机, 然后再解析的过程. 这就是中间人攻击

2 不验证通信方的身份就可能遭遇伪装

HTTP 协议在传输过程中, 不论是请求或响应, 通信方都不会确认其身份. 也就是说, 服务器可能并不是你请想请求的服务器主机, 返回的响应也不一定是客户端想要的数据等类似问题.

2.1 任何人都可以发请求

因为不验证通信双方的身份, 所以服务器会接受任何人的请求, 只要你的请求主机名正确, 服务器都会收到并响应.所以会有以下问题

• 请求的服务器可能是经过伪装的
• 发起请求的客户端可能是经过伪装的
• 服务器保持了某些特定的信息, 只开放给特定用户, 但是无法确定对方是否有权限
• 无法判定请求是从哪来、谁发的, 即使是无意义的请求也会照单全收。
• 无法阻止海量请求(暴力攻击)下的 DoS 攻击(Denial of Service拒绝服务攻击)

3 无法证明报文完整性，可能已遭篡改

仍然是由于未加密和权限验证的原因, 你的请求和响应无法保证准确度. 换句话说, 你没法判断自己接受到的信息是否正确, 所以带来了以下问题:

3.1 接收的内容可能有误

同样是因为HTTP无法验证通信报文的完整性, 所以即使报文被篡改了, 也无法获悉具体内容. 换句话说, 服务端和客户端都无法确定收到的请求/发出的响应是否是对方想要的

3.2 即使加密也无法保证被篡改

我们在使用HTTP通信时, 最常用的加密方式就是对请求报文进行MD5或者SHA1等方式的散列式校验的方式加密. 但是用这些方法也依然无法百分百保证确认结果正确. 因为MD5等本身被改写的话, 用户是没有办法意识到的.
比如HTTP报文在传输的过程中可能会遭到代理或是其他通信实体的无意修改, 为了让接收方知道这种情况, 服务器会对body部分作一个md5, 并把值放到Content-MD5这个字段中. 但是, 如果中间的代理即修改了报文主体, 又修改了md5, 仍然很难检测

二 HTTP的升级版HTTPS

HTTPS又称HTTP2.0, 为啥叫二点零. 为啥不叫1.2, 因为这次的升级改动非常🐂🍺. 在第一节中我们讲述的HTTP安全方面的不足, HTTPS都给解决了!

1 HTTPS和HTTP的区别

如果你认为仅仅是从HTTP1.1 到 HTTP2.0的改变, 那真是太年轻了. 其实真正的改变是, HTTP 到 HTTP + S的改变.这个S 是什么呢, S = SSL+TLS

• SSL, 安全套接层协议: 为网络通信提供安全及数据完整性的一种安全协议
• TLS,安全传输层协议:用于在两个通信应用程序之间提供保密性和数据完整性

换句话说
HTTPS = HTTP+ 加密 + 认证 + 完整性保护

2 HTTPS的外壳SSL/TLS

HTTPS并不是新的协议, 只是添加了另外两个安全协议经过加密认证机制后形成的安全的HTTP协议, 即 HTTP Secure!

严格来说, SSL和TLS并非应用层协议, 他们是处于应用层之下, 传输层之上的一种保证数据安全的特殊安全层. 通常, HTTP 直接和 TCP 通信. 当有了这一层后, 则演变为HTTP先和安全层通 信, 再由安全层和TCP 通信.他们的架构方式如下图

这里需要注意的是, SSL/TLS是独立的安全协议, 跟HTTP协议没有任何耦合, 除了HTTP协议他们还对接其他类型的协议, 如邮件协议等

3 相互交换密钥的公开密钥加密技术

SSH采用公开密钥加密技术, 即公钥加密. 这种加密方式, 加密算法是公开的, 但是密钥是保密的. 不论加密和解密都是通过保密的密钥和公开的算法构成. 所以, 如果密钥被攻击获得, 加密也就没了意义.

3.1 共享密钥加密的困境

共享密钥加密: 就是客户端和服务端都用同一个密钥, 也被叫做对称密钥加密, 即对称加密
这种方式的缺点:

• 必须设法安全的保存密钥
• 相对安全的一端在服务端, 所以在传输时, 服务端必须把密钥发给客户端, 所以在发送密钥的过程中, 就有可能被监听攻击进而导致密钥被获取
• 

3.2 使用两把密钥的公开密钥加密

公开密钥加密: 就是客户端和服务端各有一把密钥, 也叫非对称密钥加密, 即非对称加密

• 一把是公开密钥(public key), 公钥是公开的可以传输的
• 另一把是私有密钥 (private key), 私钥为服务端(安全端)持有

私钥不能让其他任何人知道, 而公开密钥则可以随意发布, 任何人都可以获得. 在建立连接的过程中客户端使用公开的公钥加密, 发送密文给服务端;服务端收到密文后用自己持有的私钥进行解密. 这个私钥只有服务端持有, 不需要进行传输. 因此保证了安全

3.3 证明公开密钥正确性的证书

使用非对称加密时, 服务端会把公钥发送给客户端. 这里仍然会存在问题, 同样的也是上面描述的问题, 客户端怎么知道这个公钥就是想要的公钥? 比如, 客户端正准备和某台服务器建立非对称加密通信时, 如何证明收到的公钥就是原本预想的那台服务器发行的公钥. 或许在公开密钥传输途中被攻击劫持, 导致真正的公钥已经被攻击者替换掉. 这种情况是可能存在的. 那怎么解决这个问题呢?

• 使用由数字证书认证机构(CA)和其相关机关颁发的公钥证书

这个数字认证机构解决了什么问题呢?

• 虽然客户端无法确收到的是否为真正公钥, 即不相信服务端, 但是客户端相信这个CA机构, 同时, 服务端也相信这个机构. 那就交由这个机构做’公证人’.

获取证书的步骤

• 服务端向数字证书认证机构申请公开密钥
• CA机构在判明申请者的身份之后, 对申请者提供的公开密钥做数字签名
• 将公开密钥放入公钥证书后和CA机构对其分配的数字签名绑定在一起, 也叫数字证书
• 通信时, 服务端将公钥证书发送给客户端
• 客户端收到公钥证书后, 使用CA机构提供的公钥验证公钥证书中的数字签名

到此, 如果客户端验证通过, 即可证明此公钥证书中的公钥是有效的, 即是自己想要的服务器获取的.

4 HTTPS的加密机制

HTTPS采用混合的加密机制进行加密, 什么叫混合的加密机制, 即

1. 在建立连接时, 使用非对称加密, 保证数据安全
   
2. 建立连接通道后, 使用对称加密, 保证速度(非对称加密更耗时, 对CPU性能损耗更大)
   

三 HTTPS建立建立的过程

注意:这里面有一些专业术语甚至有些是密码学中概念, 有兴趣的同学可以自己google
HTTPS连接的建立流程和HTTP相比, 只多了一个中间环节. 刚上面也有讲, 即HTTP不再直接和TCP通信, 而是通过中间层SSL/TLS层验证通过后, 由中间层和TCP通信. HTTPS握手的过程实质上是TLS握手协议执行的过程, 主要分为两个部分. 下面简单讲述步骤

1 TLS握手协议

采用C / S模型, 即客户端和服务端模型

1.1 协商建立安全通信

1> 客户端向服务端发送建立TLS请求, 请求获取证书, 本次请求报文包含了

• 客户端支持的TLS协议版本号
• 加密套件(包含客户端支持的对称加密算法)
• 一个随机数C(用于后面生成会话秘钥, 也叫主秘钥)

2> 服务端向客户端返回响应, 此响应报文包含了

• TLS版本号一致性和商定的加密算法(客户端提供的算法由服务端选择一种)
• 一个随机数S(用于后面生成会话秘钥, 也叫主秘钥)
• 由服务端向CA机构申请的携带有公钥和数字签名的公钥证书

3> 客户端收到服务端回复并验证正确性, 然后再次发送请求, 此流程其实包含两步
第一步, 验证服务端返回的公钥证书

• 客户端根据CA机构公钥(根证书)匹配验证公钥证书中的数字签名
• 如果证书验证通过, 则通过随机数C、S和客户端产生的预主秘钥组装成会话秘钥(所以, 客户端仅需通过数字证书验证, 就可知道是否为想请求的服务器)

第二步, 发送请求, 此请求报文包含

• 客户端通过服务端公钥证书中的公钥加密预主秘钥之后的密文结果

4> 服务端收到公钥加密后的预主秘钥, 这时服务端会做如下操作

• 使用私钥对收到的密文进行解密, 得到预主秘钥
• 通过随机数C、S和客户端产生的预主秘钥组装成会话秘钥

1.2 安全通信进行测试

• 客户端先生成一个对称加密算法加密后的验证数据(会话密钥)
• 然后客户端通过一定的策略告诉服务端我用什么方式做的加密, 并发送再次加密过的验证数据给服务端
• 服务器接收到加密过的验证数据和加密策略, 解密后收到验证数据
• 然后通服务端过一定的策略告诉服务端我用什么方式做的加密, 并发送再次加密过的验证数据传给客户端
• 客户端解密后对比是否是原来的报文, 是的话就意味着整个加密体系没有问题
• 握手过程结束

1.3 预主秘钥和主密钥(会话秘钥)

• 预主秘钥:
  预主密钥的生成方式与密钥交换协议以及具体的算法有关!
  对预主秘钥加密传输的方式是非对称加密传输.
• 主密钥(会话秘钥)
  客户端和服务端达成了加密套件一致性, 因此双端加密后生成的主密钥是相同的
  主密钥就相当于公钥, 用于后面通信建立后的报文传输
  使用主密钥传输的过程是对称加密

到此, HTTPS连接建立完成, 可以通信

本文完

我是个写代码的小学生, 如有不足, 万望不吝指教

转载请注明作者和链接哦!
参考资料:
图解HTTP
一文弄懂HTTPS
iOS应用安全之HTTP/HTTPS详解

转载：https://blog.csdn.net/weixin_43837354/article/details/104717987