説明
一方向へのアップ認証は、認証サーバが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机构就诞生了