HTTPS也是一个应用层协议,是在HTTP协议的基础上引入了一个加密层;
HTTP协议内容都是按照文本的方式明文传输的,这就导致在传输过程中出现一些被篡改的情况;
加密就是把明文(要传输的信息)进行一系列变换, 生成密文;
解密就是把密文再进行一系列变换,还原成明文;
在这个加密和解密的过程中,往往需要一个或者多个中间的数据,辅助进行这个过程,这样的数据称为密钥(正确发音yue四声,不过大家平时都读作yao四声);
由于我们通过网络传输的任何的数据包都会经过运营商的网络设备(路由器,交换机等),那么运营商的网络设备就可以解析出你传输的数据内容,并进行篡改;
点击"下载按钮",其实就是在给服务器发送了一个HTTP请求,获取到的HTTP响应其实就包含了该
APP的下载链接;运营商劫持之后,就发现这个请求是要下载天天动听,那么就自动的把交给用户的响应给篡改成"QQ浏览器"的下载地址了;
对称加密:
采用单钥密码系统的加密方法,同一个密钥可以同时用作信息的加密和解密,这种加密方法称加密,也称为单密钥加密,特征:加密和解密所用的密钥是相同的;
常见对称加密算法(了解): DES、 3DES、AES、 TDEA、Blowfish、 RC2等;
特点:算法公开、计算量小、加密速度快、加密效率高;
非对称加密:
需要两个密钥来进行加密和解密,这两个密钥是公开密钥(public key,简称公钥)和私有密钥
(private key,简称私钥);
常见非对称加密算法(了解): RSA, DSA,ECDSA;
特点:算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂,而使得加密解密速度没有对称加密解密的速度快;
非对称加密要用到两个密钥,一个叫做"公钥", 一个叫做"私钥";
公钥和私钥是配对的,最大的缺点就是运算速度非常慢,比对称加密要慢很多;
通过公钥对明文加密, 变成密文;
通过私钥对密文解密, 变成明文;
也可以反着用;
通过私钥对明文加密,变成密文;
通过公钥对密文解密, 变成明文;
数字指纹(数据摘要),其基本原理是利用单向散列函数(Hash函数)对信息进行运算,生成一串固定长度的数字摘要。数字指纹并不是一种加密机制,但可以用来判断数据有没有被窜改;
每一段文本,都只能形成唯一的摘要;
摘要常见算法:有MD5、SHA1、 SHA256、SHA512等, 算法把无限的映射成有限,因此可能会有碰撞(两个不同的信息,算出的摘要相同,但是概率非常低);
摘要特征:和加密算法的区别是,摘要严格意义不是加密,因为没有解密,只不过从摘要很难反推原信息,通常用来进行数据对比;
摘要经过加密,就得到数字签名;
如果通信双方都各自持有同一个密钥X,且没有别人知道,这两方的通信安全当然是可以被保证的非密钥被破解);
引入对称加密之后,即使数据被截获,由于黑客不知道密钥是啥,因此就无法进行解密,也就不知道请求的真实内容是啥了;
但事情没这么简单,服务器同一时刻其实是给很多客户端提供服务的,这么多客户端,每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,黑客就也能拿到了),因此服务器就需要维护每个客户端和每个密钥之间的关联关系,这也是个很麻烦的事情;
因此密钥的传输也必须加密传输!
但是要想对密钥进行对称加密,就仍然需要先协商确定一个"密钥的密钥",这就成了"先有鸡还是先有蛋"的问题了,此时密钥的传输再用对称加密就行不通了;
鉴于非对称加密的机制,如果服务器先把公钥以明文方式传输给浏览器,之后浏览器向服务器传数据
前都先用这个公钥加密好再传,从客户端到服务器信道似乎是安全的(有安全问题),因为只有服务器有相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全?
如果服务器用它的私钥加密数据传给浏览器,那么浏览器用公钥可以解密它,而这个公钥是一开始通
过明文传输给浏览器的,若这个公钥被中间人劫持到了,那他也能用该公钥解密服务器传来的信息
了。
服务端拥有公钥S与对应的私钥S’,客户端拥有公钥C与对应的私钥C’;
客户和服务端交换公钥;
客户端给服务端发信息:先用S对数据加密,再发送,只能由服务器解密,因为只有服务器有私钥;
服务端给客户端发信息:先用C对数据加密,再发送,只能由客户端解密,因为只有客户端有私钥
C’;
这种方案似乎可行,但是
服务端具有非对称公钥S和私钥S’;
客户端发起hftps请求,获取服务端公钥S;
客户端在本地生成对称密钥C,通过公钥S加密,发送给服务器;
由于中间的网络设备没有私钥,即使截获了数据,也无法还原出内部的原文,也就无法获取到对称密
钥;
服务器通过私钥S’解密,还原出客户端发送的对称密钥C,并且使用这个对称密钥加密给客户端返回
的响应数据;
但是,方案二、三、四都存在同一个问题,如果最开始,中间人就开始攻击了呢?这样依旧可以拿到双方的公钥;
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进行对称加密,进行通信。但是一切都在中间人的掌握中,劫持数据,进行窃听甚
至修改,都是可以的;
服务端在使用HTTPS前,需要向CA机构申领一份数字证书,数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器,浏览器从证书里获取公钥就行了,证书就如身份证,证明服务端公钥的权威性;
当服务端申请CA证书的时候,CA机构会对该服务端进行审核,并专门为该网站形成数字签名,过程如下:
给到客户端的是服务器的证书,从证书中提取密钥;
一旦中间人篡改了证书的明文,由于他没有CA机构的私钥,所以无法hash之后用私钥加密形成签名,那么也就没法办法对篡改后的证书形成匹配的签名;
如果强行篡改,客户端收到该证书后会发现明文和签名解密后的值不一致,则说明证书已被篡改,证书不可信,从而终止向服务器传输信息,防止信息泄露给中间人;
在客户端和服务器刚一建立连接的时候,服务器给客户端返回一个证书,证书包含了之前服务端的公
钥,也包含了网站的身份信息;
为什么摘要内容在网络传输的时候一定要加密形成签名?
常见的摘要算法有: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形成摘要?
缩小签名密文的长度,加快数字签名的验证签名的运算速度;
HTTPS工作过程中涉及到的密钥有三组: