|
HTTP和HTTPS的区别？
HTTP协议全称Hyper Text Transfer Protocol，翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层。HTTP协议通过请求/响应的方式，在客户端和服务端之间进行通信。
HTTPS = HTTP+ 加密 + 认证 + 完整性保护，HTTPS 采用混合加密机制：在交换密钥环节使用非对称加密方式，之后的建立通信交换报文阶段则使用对称加密方式。
它们之间的区别：
(1) 端? ：HTTP的URL由“http://”起始且默认使?端?80，?HTTPS的URL由“https://”起始且默认使?端?443。
(2) 安全性和资源消耗： HTTP协议运?在TCP之上，所有传输的内容都是明?，客户端和服务器端都?法验证对?的身份。HTTPS是运?在SSL/TLS之上的HTTP协议，SSL/TLS 运?在TCP之上。所有传输的内容都经过加密，加密采?对称加密，但对称加密的密钥?服务器?的证书进?了?对称加密。所以说，HTTP 安全性没有 HTTPS?，但是 HTTPS ?HTTP耗费更多服务器资源。
对称加密：密钥只有?个，加密解密为同?个密码，且加解密速度快，典型的对称加密算法有DES、AES等；缺点是发送秘钥有被窃听的风险，但不发送对方又不能解密。
?对称加密：密钥成对出现（且根据公钥?法推知私钥，根据私钥也?法推知公钥），加密解密使?不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的?对称加密算法有RSA、DSA等。
接下来详细说明HTTP为什么不够安全？
HTTP协议的信息传输完全以明文方式，不做任何加密，但是由于传输信息是明文，这个信息有可能被某个中间人恶意截获甚至篡改。这种行为叫做中间人攻击。为了防止中间人攻击，我们可以对明文信息进行加密。
-
如何进行加密？
可以事先约定一种对称加密方式，并且约定一个随机生成的密钥。后续的通信中，信息发送方都使用密钥对信息加密，而信息接收方通过同样的密钥对信息解密。 -
这样做是不是就绝对安全了呢？并不是。
虽然我们在后续的通信中对明文进行了加密，但是第一次约定加密方式和密钥的通信仍然是明文，如果第一次通信就已经被拦截了，那么密钥就会泄露给中间人，中间人仍然可以解密后续所有的通信内容。 -
因此我们可以使用非对称加密，为密钥的传输做一层额外的保护。
非对称加密的一组秘钥对中，包含一个公钥和一个私钥。明文既可以用公钥加密，用私钥解密；也可以用私钥加密，用公钥解密。 -
但是中间人会 偷天换日？
虽然不知道对方的私钥是什么，但是在截获了对方的公钥Key1之后，自己另外生成一对公钥私钥，把自己的公钥Key3发送给另一方。而另一方并不知道公钥被偷偷换过，于是按照先前的流程，用Key3加密了自己生成的对称加密密钥Key2，发送给对方。这一次通信再次被中间人截获，中间人先用自己的私钥解开了Key3的加密，获得Key2，然后再用当初对方发来的Key1重新加密，再发给对方。这样一来，中间人就可以轻松的解密。 -
因此引入第三方，一个权威的证书颁发机构（CA）来解决这个问题。流程如下：
1.首先服务端把自己的公钥发给证书颁发机构，向证书颁发机构申请证书。
2.证书颁发机构自己也有一对公钥私钥。机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样经过机构的私钥加密。证书制作完成后，机构把证书发送回服务端。
3.当客户端向服务端请求通信的时候，服务端不再直接返回自己的公钥，而是把自己申请的证书返回给客户端。
4.客户端收到证书以后，要做的第一件事情是验证证书的真伪。需要说明的是，各大浏览器和操作系统已经维护了所有权威证书机构的名称和公钥。所以客户端只需要知道是哪个机构颁布的证书，就可以从本地找到对应的机构公钥，解密出证书签名。接下来，客户端按照同样的签名规则，自己也生成一个证书签名，如果两个签名一致，说明证书是有效的。验证成功后，客户端就可以放心地再次利用机构公钥，解密出服务端的公钥Key1。 -
这就是HTTPS的主要思想，HTTPS在HTTP协议的基础上增加了SSL安全层，认证的流程就是在SSL层中完成的，最新推出的TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的。
|