微网站需要域名吗,电子商务冷门吗,互联网营销培训,wordpress 后台 重定向循环在说HTTP前#xff0c;一定要先介绍一下HTTP#xff0c;这家伙应该不用过多说明了#xff0c;大家每天都在用#xff0c;每一次HTTP请求#xff0c;都是一次TCP连接。遗憾的是#xff0c;请求的内容在TCP报文中是明文传输的#xff0c;任何人截取到请求都可以读取其中的…在说HTTP前一定要先介绍一下HTTP这家伙应该不用过多说明了大家每天都在用每一次HTTP请求都是一次TCP连接。遗憾的是请求的内容在TCP报文中是明文传输的任何人截取到请求都可以读取其中的内容很尴尬。
数据加密
为了防止请求内容被人窃取在网络传输的路上我们做不了手脚那就只能对传输的数据报文上做手脚了。对报文内容进行加密就是其中的一种方法。
有一种加密算法叫做对称加密算法即加密和解密使用同一个秘钥使用这种算法对请求数据进行加密中间人因为没有秘钥无法读取其中的内容。但是使用这种算法进行加密肯定要同意秘钥那秘钥在网络中传输同样存在被窃取的风险啊。
这时出现了新的加密算法非对称加密算法它有两把钥匙一把叫私钥是只有自己知道的另一个叫公钥可以发到互联网山随便谁都可以看到也就是说传输过程中即使被别人看到也无所谓。这时A向B发消息时可以先用B的公钥对数据进行加密B收到消息后再使用自己的私钥进行解密中间即使被窃取了因为没有对应的秘钥也无法对了数据进行解密。
但是非对称加密算法要比对称加密算法慢上许多。一个折中的办法先使用非对称加密算法来传输对称加密的秘钥以确保秘钥安全送达之后就可以使用对称加密算法来加密数据报文了。
中间人劫持
你以为现在可以高枕无忧了吗你以为你可以放心安全的进行通信了吗天真。
假设你现在正在和A通信来自灵魂的拷问你怎么能确定和你通信的人是A呢
我们假设通信正常进行。在通信开始传输公钥的时候请求被中间人C劫持了。C讲A的公钥换成自己的公钥发给了你在你发送请求后再讲你的信息解密使用A的公钥进行加密发送给A。这样在你和A看来好像是在和彼此通信其实所有的信息都经过了C所有的信息都被C一览无余。
那么如何保证收到的公钥是A的呢完犊子了又回到开始的问题了如何保证秘钥在网络中安全的传输。但这次加密似乎救不了我们了我们必须要确保收到的秘钥确实是A发来的也就是说报文没有别中途篡改过。
数字证书
其实无法保证报文内容的关键在于我们对于收到的公钥无法确定有没有被人修改过那如果有一个我们信任的中间人S来传输这个公钥就可以了。问题来了D的公钥传输中同样存在被修改的问题拿到再找其他人来传输S的公钥么这要下去简直没完没了完全就是三次握手的翻版。
问题的根源是什么我们没有一个可以信任的公钥那么解决办法也很粗暴我们在本地保存一个绝对信任的公钥它不是通过互联网来获取的而是预装在系统中的也就是系统/浏览器预置的顶层CA证书。 这些预装信任的内容就是CA证书。通过CA获取A的公钥时获得的数字证书大概长这样 当收到证书后我们对信息通过童谣的hash算法计算出信息摘要在用CA的公钥对数字签名进行解密若解密后的信息摘要与我们计算的摘要相同则可以认为信息没有被人修改过。验证流程如下 难道这样就不拍别人篡改了么不怕。因为我们已经拿到CA的公钥了这是没有问题的。中间人因为没有CA的私钥及时截取到信息也无法对修改后的内容进行加密并生成对应的数字签名。
这样一来信息的传输问题算是暂时告一段落了。不知道什么时候就冒出了新的安全问题毕竟道高一尺魔高一丈
HTTPS
到这里HTTPS介绍完毕以上大概就是HTTPS的全部内容了。HTTPS的一次请求大概流程如下 浏览器发出HTTPS请求 服务器讲自己的数字证书返回 浏览器用预置的CA来验证证书若没有问题顺利拿到公钥 浏览器生成对称加密算法的秘钥通过服务器的公钥进行加密将报文发送给服务器 服务器用自己的私钥进行解密得到对称加密的秘钥 可以开始用获得的对称加密秘钥进行通信了
