HTTP
基于TCP协议
缺点
- 明文传输
- 无法验证内容完整性，信息有可能被篡改
- 无法验证对方身份
为了解决这些问题，可以使用HTTPS
HTTPS基于TSL/SSL协议
对于缺点1，可以在传输过程中对信息加密，如双方约定一个加密密码‘abc’，
对发送的信息用‘abc’加密。
但有个问题，如果约定这个加密密码，如果还是通过http协议去发送这个密码，就还是存在被截获的风险。
为此，可以采用两个密钥进行加密和解密，私钥用来解密，公钥用来加密。
比如a,b两人，a的两个密钥为a-s(私钥)，a-p（公钥）。b的为b-s和b-p。
a在发送信息的时候用b-p加密，b收到a发的信息后用b-s解密。
b在发送信息的时候用a-p加密，a收到b发的信息后用a-s解密 。
a-s和b-s都放在各自本地，不需要传输。
那么问题来了，需要把各自的公钥发送给对方，这时就存在公钥被截获的风险。
如果黑客把公钥换成自己的公钥，获取信息后用自己的私钥解密，解密后对信息进行篡改，然后用自己公钥加密后再发送，就会造成隐患。
为了解决公钥的安全性问题，可以使用数字证书。
所谓数字证书，是指从CA处获取的一种证书。
现在假设有A，B要通信，A为客户端，B为服务端，通信初始阶段，A向B发起连接请求，B会把公钥放在证书里发送给A。
这个证书就是CA颁发的证书，通常包含以下内容。
1. 证书包含了颁发证书的机构的名字 -- CA
2. 证书内容本身的数字签名（用CA私钥加密）
3. 证书持有者的公钥
4. 证书签名用到的hash算法
这个给A的数字证书，是经过数字签名的（用的CA的私钥），目的是为了防止证书被篡改。
数字签名由来
对证书内容本身进行hash，得到证书的摘要，然后用CA私钥对摘要进行加密，得到的就是俗称的“数字签名”。
A在收到证书后，用CA的公钥去解密，得到证书的摘要a，因为证书本身包含生成摘要使用的hash算法，此时A再用同样的hash算法对证书生成摘要b，如果a和b相同，则证明证书未被篡改。
证书的真实性验证后，则能从证书中获取B的公钥，此时A生成一个随机的密钥，用B的公钥加密后发送给B，B拿到后用自己的私钥解密，得到这个密钥，注意，这个密钥就是之后A和B通信时加密信息用到的密钥，也就是说，https可以在交换传输密钥时候用非对称加密，在获取密钥后，使用对称加密传输信息，保证速度和安全。
网友评论