说明
单向认证最多的是认证服务器是不是可以信赖的,大部分https都是基于单向认证,不过银行系统应该是双向的.
如果链接的服务器是别人伪造的服务器,那么自己的各种信息将会被不法分子滥用!
首先要明确一点,所有的通信都是走的TCP,然后在TCP传输的数据上做了些文章
为何需要加密呢?
客户端 ---- 服务器
如果只是走http那么所有的数据将会暴露出来
(实际上就是用TCP发送的数据,数据没有任何的加密措施)
比如说:访问我的 http://mnif.cn/
我假设是一个小小小的黑客,然后就监控到了下面的数据了
大家会感觉这有什么
但是大家想一下,如果上面是传输的咱银行卡信息呢?????
大家又会想,什么时候可能会传输银行卡信息呢???
你在浏览器/手机APP上输没输过银行卡号??输没输过密码???
要是这些信息不加密传输,窃听到这些信息是很容易的.
大家如果不是搞支付软件的,可能感觉不出来,但是银行也好,支付宝也好,微信也好
他们可是为了支付数据安全下了大工夫,咱平时只是用他们的软件,可能没多大感受.
先了解点数据加密知识
假设我要传输的数据是 aabbcc
一,简单的加密
客户端和服务器有个约定每隔一个数据插入数据1
然后客户端发送的就是 a1a1b1b1c1c
发给服务器以后服务器便知道需要去掉插入的数据1,然后提取aabbcc
服务器发给客户端也同理
二,对称加密
客户端:
数据加密算法(aabbcc,秘钥(自定义的字符串或者数字))
通过某种加密算法,把要发送的数据和秘钥计算以后再发给服务器 XXXXXXXXXX
服务器:
数据解密算法(客户端发来的加密以后的数据,秘钥(该秘钥和客户端的相同))
通过解密算法,然后填入和客户端一样的秘钥,解析出来真实的数据 aabbcc
加密和解密使用的密钥相同的。然后调用相应的加密算法/解密算法
最常用的对称加密算法: AES
三,非对称加密
---------------------------客户端→服务器-----------------
客户端:
数据加密算法(aabbcc,公钥)
通过某种加密算法,把要发送的数据和公钥计算以后再发给服务器 XXXXXXXXXX
服务器:
数据解密算法(客户端发来的用公钥加密以后的数据,私钥)
通过解密算法和私钥解析出来真实的数据 aabbcc
---------------------------服务器←客户端-----------------
服务器:
数据加密算法(aabbcc,私钥) XXXXXXXXXX
客户端:
数据解密算法(服务器通过私钥加密的数据,公钥) aabbcc
首先要明确公钥和私钥是一对的.
用公钥加密的信息可以用私钥进行解密
用私钥加密的信息可以用公钥进行解密
常用的加密算法: RSA
四,补充 哈希Hash加密算法
常见的有 MD5 , SHA
这些加密算法是不可逆的
就是说一旦数据加密,便不可解密
有人会问,这有什么用处???? 可以做数据验证!
我有个数据aabbcc 经过MD5计算出来的是 61a60170273e74a5be90355ffe8e86ad
用法1: 传输数据后面加上MD5的值 aabbcc61a60170273e74a5be90355ffe8e86ad
如果有人篡改了数据,那么客户端计算的数据的MD5值就和后面的不一样了
可以检验数据是否被篡改
有些爱思考的小朋友可能会想如果全部更改了呢!
就是说我把数据和对应的MD5值全部改了,
嘿嘿,接着看哈,后面会有说明的
用法2:
咱们往数据库里面存储密码的时候,一般不直接存密码,而是存MD5的值
咱在登录的时候先用APP计算用户密码的MD5值,然后和数据库里面的做对比
一致就说明密码正确
注意:MD5加密的可以跑字典跑出来!!!!但是跑的时间很长很长很长很长......
现在咱看看如何一步一步利用上,上面的加密实现https
假设咱用非对称加密,自己手头有公钥和私钥 (注意就是字符串)
有些人会问,咋生成的呀???这个先别管哈,反正可以生成
后面咱也会自己去制作的
现在就认为有了公钥和私钥了哈
私钥是在服务器上的(这个保密,打死不给别人)
TCP连接Web服务器三次握手结束了
首先要明确,咱这节是为了验证服务器是不是合法的!!!!!
然后假设这样通信
1.客户端发给服务器: 自己支持的所有的加密算法等
2.服务器发给客户端: 服务器选择一种加密方式,并告诉客户端(假设数据正常通信时用的对称加密为 AES)
3.服务器发送非对称加密的公钥给客户端
4.服务器发送给客户端随机数数据: 随机数+随机数进行私钥加密后的数据
5.客户端接收到以后,首先用公钥解密下 随机数进行私钥加密后的数据
解析以后和前面的随机数对比下,判断是不是一致
如果一致就说明服务器是OK的
6.客户端把AES对称加密算法的秘钥通过非对称加密的公钥加密以后发给服务器
7.服务器利用非对称加密的私钥就获取了对称加密算法的秘钥
8.然后后期通信都用AES对称加密数据,然后进行数据传输
上面的弊端
假设有个黑客伪造了服务器
有人会问,我连接的IP地址是固定的,还能连接到别人的服务器去???
大家可以看这个例子 : https://www.cnblogs.com/yangfengwu/p/11999995.html
想必大家都听说过伪基站吧!和上面的原理差不多
因为最终还是IP地址进行通信,我只要把自己的服务器设置成你想连接的IP
然后你只要连接上我发出的无线或者基站,那么你就连接上我了!!!!!
道理很简单吧!有些东西就是一层窗户纸!
假设有个假服务器(注意,假服务器有自己的非对称加密的公钥和私钥)
然后还是和上面一样通信
1.客户端发给服务器: 自己支持的所有的加密算法等
2.服务器发给客户端: 服务器选择一种加密方式,并告诉客户端(假设数据正常通信时用的对称加密为 AES)
3.服务器发送非对称加密的公钥给客户端
4.服务器发送给客户端随机数数据: 随机数+随机数进行私钥加密后的数据
5.客户端接收到以后,首先用公钥解密下 随机数进行私钥加密后的数据
解析以后和前面的随机数对比下,判断是不是一致
如果一致就说明服务器是OK的
6.客户端把AES对称加密算法的秘钥通过非对称加密的公钥加密以后发给服务器
7.服务器利用非对称加密的私钥就获取了对称加密算法的秘钥
8.然后后期通信都用AES对称加密数据,然后进行数据传输
现在客户端根本不知道自己连接的服务器其实是假服务器.....
要是给你来个请重新输入银行卡账号和密码....
再来个请输入支付宝账号和密码,再监控个验证码......
怎么办???
然后 CA(Certificate Authority)机构就诞生了
CA是颁发证书的机构,大家伙都信任这家公司(全球好多家这种公司,价位不一样)
在CA购买证书以后,他会给你
XXXXXX.key :非对称私钥
XXXXXX.prm/.crt :证书 ,里面包含证书的颁发机构,到期时间等等,还有非对称加密的公钥
不过这个证书也是加密的,使用的颁发机构的非对称加密私钥进行的加密
然后传输就变为
1.浏览器发给服务器: 自己支持的所有的加密算法等
2.服务器发给浏览器: 服务器选择一种加密方式,并告诉浏览器(假设数据正常通信时用的对称加密为 AES)
3.服务器发送在CA申请的证书给浏览器
有些人会疑问,到底是怎么发送的呀,咱在下一节配置Web服务器实现
https的时候就知道了哈
4.因为证书是CA通过他自己的私钥加密以后的
所以咱需要先用他家的公钥解密,然后再进行证书的其它判断
有人会问? 他家用私钥加密的,他家的公钥怎么获取到的呢????
其实咱电脑系统内置了
命令行输入: certmgr.msc
随便打开一个
5.咱购买证书的时候其实也就从上面那些公司里面购买
然后浏览器验证下服务器的证书是不是安全可靠的
然后提取里面的非对称加密的公钥
6.客户端把AES对称加密算法的秘钥通过非对称加密的公钥加密以后发给服务器
7.服务器利用非对称加密的私钥就获取了对称加密算法的秘钥
8.然后后期通信都用AES对称加密数据,然后进行数据传输
客户端发送自己支持加密套件给服务器
服务器选择的加密套件
TLS_RSA_WITH_AES_256_CBC_SHA
TLS:基于TLS
RSA : 客户端和服务器之间认证过程中用RSA对称加密
AES_256:数据传输采用AES对称加密,秘钥初始长度256
报文认证算法:SHA (检测报文有么有被修改 )
结语
说的可能不全对,但是道理应该是这个道理
其实通信验证的时候主要是验证的那个证书合不合法
验证那个证书首先需要用哪家的根证书里面提取出来公钥先解密
然后再验证
大家百度的时候经常看到 根证书
双向认证的时候服务器和客户端都需要根证书
其实解密颁发的证书需要用根证书里面的公钥