Linux知识点 -- HTTPS协议

Linux知识点 – HTTPS协议

文章目录

  • Linux知识点 -- HTTPS协议
  • 一、概念
    • 1.HTTPS协议
    • 2.加密
    • 3.运营商劫持
    • 4.常见的加密方式
    • 4.数据摘要&&数字指纹
    • 5.数字签名
  • 二、HTTPS的工作过程探究
    • 1.方案一:只用对称加密
    • 2.方案二:只使用非对称加密
    • 3.方案三:双方都使用非对称加密
    • 4.方案四:非对称加密 + 对称加密
    • 5.中间人攻击
    • 6.CA认证
    • 7.方案五:非对称加密 + 对称加密 + 证书认证
    • 8.问题
    • 9.HTTPS协议的完整流程


一、概念

1.HTTPS协议

HTTPS也是一个应用层协议,是在HTTP协议的基础上引入了一个加密层;
HTTP协议内容都是按照文本的方式明文传输的,这就导致在传输过程中出现一些被篡改的情况;

2.加密

加密就是把明文(要传输的信息)进行一系列变换, 生成密文;
解密就是把密文再进行一系列变换,还原成明文;
在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥(正确发音yue四声,不过大家平时都读作yao四声);
Linux知识点 -- HTTPS协议_第1张图片

3.运营商劫持

由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等),那么运营商的网络设备就可以解析出你传输的数据内容,并进行篡改;
点击"下载按钮",其实就是在给服务器发送了一个HTTP请求,获取到的HTTP响应其实就包含了该
APP的下载链接;运营商劫持之后,就发现这个请求是要下载天天动听,那么就自动的把交给用户的响应给篡改成"QQ浏览器"的下载地址了;
Linux知识点 -- HTTPS协议_第2张图片
Linux知识点 -- HTTPS协议_第3张图片

4.常见的加密方式

  • 对称加密:
    采用单钥密码系统的加密方法,同一个密钥可以同时用作信息的加密和解密,这种加密方法称加密,也称为单密钥加密,特征:加密和解密所用的密钥是相同的;
    常见对称加密算法(了解): DES、 3DES、AES、 TDEA、Blowfish、 RC2等;
    特点:算法公开、计算量小、加密速度快、加密效率高;

  • 非对称加密:
    需要两个密钥来进行加密和解密,这两个密钥是公开密钥(public key,简称公钥)和私有密钥
    (private key,简称私钥);
    常见非对称加密算法(了解): RSA, DSA,ECDSA;
    特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快;
    非对称加密要用到两个密钥,一个叫做"公钥", 一个叫做"私钥";
    公钥和私钥是配对的,最大的缺点就是运算速度非常慢,比对称加密要慢很多;
    通过公钥对明文加密, 变成密文;
    通过私钥对密文解密, 变成明文;
    也可以反着用;
    通过私钥对明文加密,变成密文;
    通过公钥对密文解密, 变成明文;

4.数据摘要&&数字指纹

数字指纹(数据摘要)其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被窜改;

每一段文本,都只能形成唯一的摘要;

摘要常见算法:有MD5、SHA1、 SHA256、SHA512等, 算法把无限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率非常低);
摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对比;

5.数字签名

摘要经过加密,就得到数字签名;

二、HTTPS的工作过程探究

1.方案一:只用对称加密

如果通信双方都各自持有同一个密钥X,且没有别人知道,这两方的通信安全当然是可以被保证的非密钥被破解);
Linux知识点 -- HTTPS协议_第4张图片
引入对称加密之后,即使数据被截获,由于黑客不知道密钥是啥,因此就无法进行解密,也就不知道请求的真实内容是啥了;
但事情没这么简单,服务器同一时刻其实是给很多客户端提供服务的,这么多客户端,每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,黑客就也能拿到了),因此服务器就需要维护每个客户端和每个密钥之间的关联关系,这也是个很麻烦的事情;
因此密钥的传输也必须加密传输!
但是要想对密钥进行对称加密,就仍然需要先协商确定一个"密钥的密钥",这就成了"先有鸡还是先有蛋"的问题了,此时密钥的传输再用对称加密就行不通了;

2.方案二:只使用非对称加密

鉴于非对称加密的机制,如果服务器先把公钥以明文方式传输给浏览器,之后浏览器向服务器传数据
前都先用这个公钥加密好再传,从客户端到服务器信道似乎是安全的(有安全问题),因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全?
如果服务器用它的私钥加密数据传给浏览器,那么浏览器用公钥可以解密它,而这个公钥是一开始通
过明文传输给浏览器的,若这个公钥被中间人劫持到了,那他也能用该公钥解密服务器传来的信息
了。

3.方案三:双方都使用非对称加密

服务端拥有公钥S与对应的私钥S’,客户端拥有公钥C与对应的私钥C’;
客户和服务端交换公钥;
客户端给服务端发信息:先用S对数据加密,再发送,只能由服务器解密,因为只有服务器有私钥;
服务端给客户端发信息:先用C对数据加密,再发送,只能由客户端解密,因为只有客户端有私钥
C’;

这种方案似乎可行,但是

  • 效率太低;
  • 依旧有安全问题;

4.方案四:非对称加密 + 对称加密

Linux知识点 -- HTTPS协议_第5张图片
服务端具有非对称公钥S和私钥S’;
客户端发起hftps请求,获取服务端公钥S;
客户端在本地生成对称密钥C,通过公钥S加密,发送给服务器;
由于中间的网络设备没有私钥,即使截获了数据,也无法还原出内部的原文,也就无法获取到对称密
钥;
服务器通过私钥S’解密,还原出客户端发送的对称密钥C,并且使用这个对称密钥加密给客户端返回
的响应数据;

但是,方案二、三、四都存在同一个问题,如果最开始,中间人就开始攻击了呢?这样依旧可以拿到双方的公钥

5.中间人攻击

Man-in-the-MiddleAttack, 简称“MITM攻击”;
确实,在方案2/3/4中,客户端获取到公钥S之后,对客户端形成的对称秘钥X用服务端给客户端的公钥S进行加密,中间人即使窃取到了数据,此时中间人确实无法解出客户端形成的密钥X,因为只有服务器有私钥S’;
但是中间人的攻击,如果在最开始握手协商的时候就进行了,那就不一定了,假设hacker已经成功成
为中间人:
1.服务器具有非对称加密算法的公钥S,私钥S’;
2.中间人具有非对称加密算法的公钥M,私钥M’;
3.客户端向服务器发起请求,服务器明文传送公钥S给客户端;
4.中间人劫持数据报文,提取公钥S并保存好,然后将被劫持报文中的公钥S替换成为自己的公钥M,并将伪造报文发给客户端;
5.客户端收到报文,提取公钥M(自己当然不知道公钥被更换过了),自己形成对称秘钥X,用公钥M加
密X,形成报文发送给服务器;
6.中间人劫持后,直接用自己的私钥M’进行解密,得到通信秘钥X,再用曾经保存的服务端公钥S加
密后,将报文推送给服务器;
7.服务器拿到报文,用自己的私钥S’解密,得到通信秘钥X;
8.双方开始采用X进行对称加密,进行通信。但是一切都在中间人的掌握中,劫持数据,进行窃听甚
至修改,都是可以的;

6.CA认证

服务端在使用HTTPS前,需要向CA机构申领一份数字证书,数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书里获取公钥就行了,证书就如身份证,证明服务端公钥的权威性;
Linux知识点 -- HTTPS协议_第6张图片
当服务端申请CA证书的时候,CA机构会对该服务端进行审核,并专门为该网站形成数字签名,过程如下:

  1. CA机构拥有非对称加密的私钥A和公钥A’;
  2. CA机构对服务端申请的证书明文数据进行hash,形成数据摘要;
  3. 然后对数据摘要用CA私钥A’加密,得到数字签名S;
  4. 数字签名与明文信息一起生成CA证书;
  • 数字签名的生成与验证:
    Linux知识点 -- HTTPS协议_第7张图片

给到客户端的是服务器的证书,从证书中提取密钥;
一旦中间人篡改了证书的明文,由于他没有CA机构的私钥,所以无法hash之后用私钥加密形成签名,那么也就没法办法对篡改后的证书形成匹配的签名;
如果强行篡改,客户端收到该证书后会发现明文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人;

7.方案五:非对称加密 + 对称加密 + 证书认证

在客户端和服务器刚一建立连接的时候,服务器给客户端返回一个证书,证书包含了之前服务端的公
钥,也包含了网站的身份信息;
Linux知识点 -- HTTPS协议_第8张图片

  • 客户端进行认证
    当客户端获取到这个证书之后,会对证书进行校验(防止证书是伪造的);
    ●判定证书的有效期是否过期;
    ●判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构);
    ●验证证书是否被篡改:从系统中拿到该证书发布机构的公钥,对签名解密,得到一个hash值(称为数据摘要),设为hash1;然后计算整个证书的hash值,设为hash2;对比hash1和hash2是否相等;如果相等,则说明证书是没有被篡改过的;

8.问题

  • 为什么摘要内容在网络传输的时候一定要加密形成签名?
    常见的摘要算法有:MD5和SHA系列;
    以MD5为例,我们不需要研究具体的计算签名的过程,只需要了解MD5的特点:
    ●定长: 无论多长的字符串,计算出来的MD5值都是固定长度(16字节版本或者32字节版本);
    ●分散:源字符串只要改变一点点,最终得到的MD5值都会差别很大;
    ●不可逆:通过源字符串生成MD5很容易,但是通过MD5还原成原串理论上是不可能的;
    正因为MD5有这样的特性,我们可以认为如果两个字符串的MD5值相同,则认为这两个字符串相同;
    理解判定证书篡改的过程:(这个过程就好比判定这个身份证是不是伪造的身份证)
    假设我们的证书只是一个简单的字符串hello,对这个字符串计算hash值(比如md5),结果为
    BC4B2A76B9719D91;
    如果hello中有任意的字符被篡改了,比如变成了hella,那么计算的md5值就会变化很大,BDBD6F9CF51F2FD8
    然后我们可以把这个字符串hello和哈希值BC4B2A76B9719D91从服务器返回给客户端,此时客户端就只要计算hello的哈希值,看看是不是BC4B2A76B9719D91即可;

  • 为什么签名不直接加密,而是要先hash形成摘要?
    缩小签名密文的长度,加快数字签名的验证签名的运算速度;

9.HTTPS协议的完整流程

Linux知识点 -- HTTPS协议_第9张图片

HTTPS工作过程中涉及到的密钥有三组:

  • 第一组(非对称加密):用于校验证书是否被篡改;服务器持有私钥(私钥在形成CSR文件与申请证书时获得),客户端持有公钥(操作系统包含了可信任的CA认证机构有哪些,同时持有对应的公钥);服务器在客户端请求是,返回携带签名的证书;客户端通过这个公钥进行证书验证,保证证书的合法性,进一步保证证书中携带的服务端公钥权威性;
  • 第二组(非对称加密):用于协商生成对称加密的密钥;客户端用收到的CA证书中的公钥(是可被信任的)给随机生成的对称加密的密钥加密,传输给服务器,服务器通过私钥解密获取到对称加密密钥;
  • 第三组(对称加密):客户端和服务器后续传输的数据都通过这个对称密钥加密解密;

你可能感兴趣的:(Linux,linux,https,运维,网络)