https为什么安全,对称加密非对称加密以及数字证书的详详解

2019-11-22 11:59:10

其实https的安全只能是传输过程中的安全,普通的抓包也是能够破解获取信息的,只是对防篡改安全了写。

参考地址  漫话:什么是 https ?这应该是全网把 https 讲的最好的一篇文章了

今天这篇文章,讲通过对话的形式,让你由浅入深着知道,为什么 Https 是安全的。








一、对称加密



一禅:在每次发送真实数据之前,服务器先生成一把密钥,然后先把密钥传输给客户端。之后服务器给客户端发送真实数据的时候,会用这把密钥对数据进行加密,客户端收到加密数据之后,用刚才收到的密钥进行解密。如图:




当然,如果客户端要给服务器发送数据,也是采用这把密钥来加密,这里为了方便,我采用单方向传输的形式










小白:那万一密钥在传输的过程中被别人截取了怎么吧?


例如:


假如服务器用明文的方式传输密钥给客户端,然后密钥被中间人给捕获了,那么在之后服务器和客户端的加密传输过程中,中间人也可以用他捕获的密钥进行解密。这样的话,加密的数据在中间人看来和明文没啥两样












二、非对称加密



一禅:这种方法就是,让客户端和服务器都拥有两把钥匙,一把钥匙是公开的(全世界知道都没关系),我们称之为公钥;另一把钥匙则是保密的(只有自己本人才知道),我们称之为私钥。这且,用公钥加密的数据,只有对应的私钥才能解密;用私钥加密的数据,只有对应的公钥才能解密。


这样,服务器在给客户端传输数据的过程中,可以用客户端明文给他的公钥进行加密,然后客户端收到后,再用自己的私钥进行解密。客户端给服务器发送数据的时候也一样采取这样的方式。这样就能保持数据的安全传输了。画个图理解一下:
















一禅:处理方式就是结合 对称加密+非对称加密这两种方式,我们可以用非对称加密的方式来传输对称加密过程中的密钥,之后我们就可以采取对称加密的方式来传输数据了。具体是这样子的:


服务器用明文的方式给客户端发送自己的公钥,客户端收到公钥之后,会生成一把密钥(对称加密用的),然后用服务器的公钥对这把密钥进行加密,之后再把密钥传输给服务器,服务器收到之后进行解密,最后服务器就可以安全着得到这把密钥了,而客户端也有同样一把密钥,他们就可以进行对称加密了。








小白:例如:


服务器以明文的方式给客户端传输公钥的时候,中间人截取了这把属于服务器的公钥,并且把中间人自己的公钥冒充服务器的公钥传输给了客户端。


之后客户端就会用中间人的公钥来加密自己生成的密钥。然后把被加密的密钥传输给服务器,这个时候中间人又把密钥给截取了,中间人用自己的私钥对这把被加密的密钥进行解密,解密后中间人就可以获得这把密钥了。


最后中间人再对这把密钥用刚才服务器的公钥进行加密,再发给服务器。如图:




毫无疑问,在这个过程中,中间人获取了对称加密中的密钥,在之后服务器和客户端的对称加密传输中,这些加密的数据对中间人来说,和明文没啥区别。














数字证书登场

在刚才的讲解中,我们知道,之所以非对称加密会不安全,是因为客户端不知道这把公钥是否是服务器的,因此,我们需要找到一种策略来证明这把公钥就是服务器的,而不是别人冒充的。


解决这个问题的方式就是使用数字证书,具体是这样的:


我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。


服务器在给客户端传输公钥的过程中,会把公钥以及服务器的个人信息通过Hash算法生成信息摘要。如图




为了防止信息摘要被人调换,服务器还会用CA提供的私钥对信息摘要进行加密来形成数字签名。如图:




并且,最后还会把原来没Hash算法之前的个人信息以及公钥 和 数字签名合并在一起,形成数字证书。如图




当客户端拿到这份数字证书之后,就会用CA提供的公钥来对数字证书里面的数字签名进行解密来得到信息摘要,然后对数字证书里服务器的公钥以及个人信息进行Hash得到另外一份信息摘要。最后把两份信息摘要进行对比,如果一样,则证明这个人是服务器,否则就不是。如图:




这样,就可以保证服务器的公钥安全着交给客户端了。






其实,(有些)服务器一开始就向认证中心申请了这些证书了(有没有看过没有证书的网站在地址栏会被标出警告?),而客户端是,也会内置这些证书。如图:




当客户端收到服务器传输过来的数据数字证书时,就会在内置的证书列表里,查看是否有解开该数字证书的公钥,如果有则…,如果没有则…



  • 2020-12-14 15:06:50

    youtube-dl视频下载神器

    youtube-dl 是一款命令行下的视频下载工具,看着名称像是 YouTube 下载工具,其实这款工具不仅支持 YouTube ,还支持非常多的视频网站,比如优酷、爱奇艺、 bilibili 等,在写这篇日志的时候,暂时不支持腾讯视频。

  • 2020-12-15 20:06:43

    更多WebTorrent例子

    WebTorrent是第一个运行在浏览器的Torrent客户端。是的,没错。就是浏览器! 它完全是用JavaScript编写的,并使用WebRTC实现了真正的点对点传输。不需要浏览器插件、扩展或安装。 使用开放的Web标准,WebTorrent将网站用户连接在一起,形成一个分布式的、分散的Browser-to-browser网络,以实现高效的文件传输。

  • 2020-12-16 06:43:06

    WebRTC 实现Android点到点互连(含Demo)

    WebRTC被誉为是web长期开源开发的一个新启元,是近年来web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或者点对点数据传输,不需要复杂的代码或者昂贵的配置。目前支持Chrome、Firefox和Opera,后续会支持更多的浏览器,它有能力达到数十亿的设备。

  • 2020-12-16 22:04:03

    基于本地代理的边下边播技术分析

    我们熟知的边下边播技术,是迅雷提供的,还有之前的快播、快车等工具,它们使用的技术基本上都是P2P下载技术。 P2P下载技术,本质上它并不是C-S的架构,P2P----> Peer to Peer,实际上它将各个客户端的资源调度起来,给上传资源种子,方便后续的下载者可以快速有效的下载资源,这种方式需要服务器整合各个Client,在有用户需要下载的情况下,服务器能及时调度资源,开始给下载者提供资源信息,保证下载者下载资源越快越好。P2P的下载方式后面我们专门介绍一下。这儿不继续展开了。

  • 2020-12-16 22:07:44

    Android视频点播-边播边缓存

    一些知名的视频app客户端(优酷,爱奇艺)播放视频的时候都有一些缓存进度(二级进度缓存),qq,微信有关的小视频,还有一些短视频app,都有边播边缓的处理。还有就是当文件缓存完毕了再次播放的话就不再请求网络了直接播放本地文件了。既节省了流程又提高了加载速度。 今天我们就是来研究讨论实现这个边播边缓存的框架,因为它不和任何的业务逻辑耦合。

  • 2020-12-16 22:46:44

    基于coturn项目的stun/turn服务器搭建

    webrtc是google推出的基于浏览器的实时语音-视频通讯架构。其典型的应用场景为:浏览器之间端到端(p2p)实时视频对话,但由于网络环境的复杂性(比如:路由器/交换机/防火墙等),浏览器与浏览器很多时候无法建立p2p连接,只能通过公网上的中继服务器(也就是所谓的turn服务器)中转。示例图如下: