HTTPS 如何保证数据传输的安全性

更新日期: 2018-10-17阅读: 3k标签: http

大家都知道,在客户端与服务器数据传输的过程中,HTTP协议的传输是不安全的,也就是一般情况下HTTP是明文传输的。但HTTPS协议的数据传输是安全的,也就是说HTTPS数据的传输是经过加密的。

在客户端与服务器这两个完全没有见过面的陌生人交流中,HTTPS是如何保证数据传输的安全性的呢?下面我将带大家一步步了解HTTPS是如何加密才得以保证数据传输的安全性的。

我们先把客户端称为小客,服务器称为小服。然后一步步探索在小客与小服的交流中(就是一方请求一方响应),HTTPS是如何保证他们的交流不会被中间人窃听的。


1.对称加密

假如现在小客与小服要进行一次私密的对话,他们不希望这次对话内容被其他外人知道。可是,我们平时的数据传输过程中又是明文传输的,万一被某个黑客把他们的对话内容给窃取了,那就难受了。

为了解决这个问题,小服这家伙想到了一个方法来加密数据,让黑客看不到具体的内容。该方法是这样子的:

在每次数据传输之前,小服会先传输给小客一把密钥,然后小服在之后给小客发消息的过程中,会用这把密钥对这些消息进行加密。小客在收到这些消息后,会用之前小服给的那把密钥对这些消息进行解密,这样,小客就能得到密文里面真正的数据了。如果小客要给小服发消息,也同样用这把密钥来对消息进行加密,小服收到后也用这把密钥进行解密。 

这样,就保证了数据传输的安全性。如图所示:


这种方法称之为对称加密,加密和解密都用同一把密钥。

这时,小服想着自己的策咯,还是挺得意的。但这个策略安全的前提是,小客拥有小服的那把密钥。可问题是,小服是以明文的方式把这把密钥传输给小客的,如果黑客截取了这把密钥,小服与小客就算是加密了内容,在截取了密钥的黑客老哥眼里,这和明文没啥区别。


2.非对称加密

小服还是挺聪明的,意识到了密钥会被截取这个问题,他又想到了另外一种方法:用非对称加密的方法来加密数据。方法如下:

小服和小客都拥有两把钥匙,一把钥匙是公开的(全世界都知道也没关系),称之为公钥;而另一把钥匙是保密(也就是只有自己才知道),称之为私钥。并且,用公钥加密的数据,只有对应的私钥才能解密;用私钥加密的数据,只有对应的公钥才能解密。

所以在传输数据的过程中,小服在给小客传输数据的过程中,会用小客给他的公钥进行加密,然后小客收到后,再用自己的私钥进行解密。小客给小服发消息的时候,也一样会用小服给他的公钥进行加密,然后小服再用自己的私钥进行解密。

这样,数据就能安全到达双方。如图:


想着这么复杂的策略都能想出来,小服可是得意的不能再得意了…..还没等小服得意多久,小客就给它泼了一波冷水。

小客严肃着说:其实,你的这种方法也不是那么安全啊,还是存在被黑客截取的危险啊。例如:

你在给我传输公钥的过程中,如果黑客截取了你的公钥,并且拿着自己的公钥来冒充你的公钥来发给我。我收到公钥之后,会用公钥进行加密传输(这时用的公钥实际上是黑客的公钥)。黑客截取了加密的消息之后,可以用他自己的私钥来进行解密来获取消息内容。然后再用你(小服)的公钥来对消息进行加密,之后再发给你(小服)。 这样子,我们的对话内容还是被黑客给截取了(倒过来小客给小服传输公钥的时候也一样)。

......这么精妙的想法居然也不行,小服这波,满脸无神。

这里插讲下,其实在传输数据的过程中,在速度上用对称加密的方法会比非对称加密的方法快很多。所以在传输数据的时候,一般不单单只用非对称加密这种方法(我们先假设非对称密码这种方法很安全),而是会用非对称加密 + 对称加密这两种结合的方法。基于这个,我们可以用非对称加密方法来安全着传输密钥,之后再用对称加密的方法来传输消息内容(当然,我这里假定了非对称加密传输是安全的,下面会讲如何使之安全)。


3.数字证书

我们回头想一下,是什么原因导致非对称加密这种方法的不安全性呢?它和对称加密方法的不安全性不同。非对称加密之所以不安全,是因为小客收到了公钥之后,无法确定这把公钥是否真的属于小服。

也就是说,我们需要找到一种策略来证明这把公钥就是小服的,而不是别人冒充的。

为了解决这个问题,小服和小客绞尽脑汁想出了一种终极策略:数字证书——我们需要找到一个拥有公信力、大家都认可的认证中心(CA)。小服在给小客发公钥的过程中,会把公钥以及小服的个人信息通过Hash算法生成消息摘要。如图:


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


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


当小客拿到这份数字证书之后,就会用CA提供的公钥来对数字证书里面的数字签名进行解密得到消息摘要,然后对数字证书里面小服的公钥和个人信息进行Hash得到另一份消息摘要,然后把两份消息摘要进行对比,如果一样,则证明这些东西确实是小服的,否则就不是。如图:


这时可能有人会有疑问,CA的公钥是怎么拿给小客的呢?小服又怎么有CA的私钥呢?

其实,(有些)服务器在一开始就向认证中心申请了这些证书,而客户端里,也会内置这些证书。如图(此图来元阮一峰的网络日志):


当客户端收到服务器返回来的数据时,就会在内置的证书列表里,查看是否有有解开该数字证书的公钥。


此文参考CSDN作者帅地 --《HTTPS 如何保证数据传输的安全性?》 
来源: https://www.cnblogs.com/yinn/archive/2018/10/16/9796455.html


链接: https://fly63.com/article/detial/1154

HTTPS 常见部署问题及解决方案

到任何有关部署 HTTPS 或 HTTP/2 的问题,都推荐先用 Qualys SSL Labs SSL Server Test 跑个测试,大部分问题都能被诊断出来。

HTTP请求头和响应头部包括的信息有哪些【HTTP请求头各字段解释】

每个HTTP请求和响应都会带有相应的头部信息。默认情况下,在发送XHR请求的同时,还会发送下列头部信息: Accept、Accept-Charset、Accept-Encoding、Connection、Host

服务器响应常用状态码及含义_ajax请求中http返回的状态码大全

HTTP状态码是用以表示网页服务器HTTP响应状态的3位数字代码,其中第一位数字表示响应类别,响应类别从1到5分为五种,分别代表:临时响应、成功、重定向、请求错误、服务器错误。

http协议的发展历史

在最早的时候,第一个定稿的http协议是http/0.9版本,在这个版本里面,http协议,它的内容,非常非常的简单 只有一个命令。http协议的历史,其中当然还有https,https是http的安全版本,它实际使用的内容跟http/1.1没有很大的区别

axios 模块化封装_对axios的二次封装的实现

Axios 是一个基于 promise 的 HTTP 库 ,使用了axios来进行数据的请求,一般都需要我们对它进行封装处理。下面简单介绍下如何对axios的二次封装的实现,以及在vue中的使用。

HttpClient的3种超时

设置ConnectionPoolTimeout:这定义了从ConnectionManager管理的连接池中取出连接的超时时间,此处设置为1秒。设置ConnectionTimeout:这定义了通过网络与服务器建立连接的超时时间。Httpclient包中通过一个异步线程去创建与服务器的socket连接

HTTP 请求头中的 Remote_Addr,X-Forwarded-For,X-Real-IP

X-Forwarded-For一般是每一个非透明代理转发请求时会将上游服务器的IP地址追加到X-Forwarded-For的后面,使用英文逗号分割;X-Real-IP一般是最后一级代理将上游IP地址添加到该头中;X-Forwarded-For是多个IP地址,而X-Real-IP是一个

HTTP协议中的短轮询、长轮询、长连接和短连接

HTTP协议是基于请求/响应模式的,因此只要服务端给了响应,本次HTTP连接就结束了,根本没有长连接这一说。网络上说HTTP分为长连接和短连接,其实本质上是说的TCP连接。TCP连接是一个双向的通道,它是可以保持一段时间不关闭的,因此TCP连接才有真正的长连接和短连接这一说。

常见HTTP请求错误码

一些常见的状态码为:200 - 服务器成功返回网页;404 - 请求的网页不存在;503 - 服务不可用。1xx(临时响应):表示临时响应并需要请求者继续执行操作的状态代码。2xx (成功):表示成功处理了请求的状态代码。

Nginx http资源请求限制

前置条件:nginx 需要有 ngx_http_limit_conn_module 和 ngx_http_limit_req_module 模块,如果没有请重新编译安装这两个模块。使用 limit_conn_zone 指令定义密钥并设置共享内存区域的参数

点击更多...

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!