HTTPS

  • 时间:2018-06-20 22:30 作者:北京尚脑软件测试 来源:北京尚脑软件测试 阅读:161
  • 扫一扫,手机访问
摘要:不管手机还是电脑上网,都离不开数据互联网传输数据,普遍用的是超文本传输协议,即 HTTP (HyperText Transfer Protocol)HTTP 协议定义规范,完成数据传输,让用户端或者浏览器能和服务器正常通信但是,HTTP 用明文传输,比方你输入账号/密码提交登录:很有可可以被中间人窃

HTTPS

不管手机还是电脑上网,都离不开数据

互联网传输数据,普遍用的是超文本传输协议,即 HTTP (HyperText Transfer Protocol)

HTTP 协议定义规范,完成数据传输,让用户端或者浏览器能和服务器正常通信

但是,HTTP 用明文传输,比方你输入账号/密码提交登录:

很有可可以被中间人窃听,从而造成数据泄露,所以说 HTTP 是不安全的

为理解决安全传输的问题,人们发明了 HTTPS,即 HTTP + Secure

为什么 HTTPS 是安全的?

只需把传输的数据加密,那么通信就是安全的,前提是除通信双方外,任何第三方无法解密

通信的数据经过加密,即便被中间人窃听到了,它也无法知道数据内容

HTTPS 是怎样实现安全通信的?

加密传输的确安全,但是用户端把数据加密后,服务器怎样解密呢?又怎么保证中间人窃听到密文后无法解密呢?

答案是:用对称加密技术

什么是对称加密?

简单而言,通信双方各有一把相同的钥匙(所谓对称),用户端把数据加密锁起来后,传送给服务器,服务器再使用钥匙解密。同理,服务器加密后传输给用户端的数据,用户端也能使用钥匙解密

那么,新的问题又出现了:怎么在通信之前,给双方分配两把一样的钥匙呢?

假如真的只有两个人要通信的话,能简单的私下见个面分配好,以后要通信的时候使用就行。但是,实际通信往往是一个服务器和成千上万的用户端之间,总不可以让每个人都和服务器先私下见个面

另外,即便用了对称加密技术,假如一方保管不善的话,也有可可以钥匙被人偷了去复制一个,这样就存在很大的安全隐患,最好是每个用户端每次和服务器通信都使用不同的密钥

一个简单的处理方案是:用户端在每次请求通信之前,先和服务器协商,通过某种办法,产生只有双方知道的对称密钥

这个过程就是所谓:密钥交换(Key Exchange)

密钥交换算法有很多种实现,常见的有:

Deffie-Hellman 密钥交换算法

RSA 密钥交换算法

本文以较简单的 RSA 密钥交换为例

简单而言,RSA 密钥交换算法需要用户端向服务器提供一个 Pre-Master-Key,而后通信双方再生成 Master-Key,最后根据 Master-Key 产生后续一系列所需要的密钥,包括传输数据的时候用的对称密钥

那么,用户端怎样把 Pre-Master-Key 告诉服务器呢?直接明文传输么?

我们之前说过,没加密的通信都会被窃听,是不安全的

似乎进入死循环了:为了加密通信,需要先把 Pre-Master-Key 传送给服务器,但是这个传送又必需要加密

我们引入一种新的加密技术:非对称加密

什么是非对称加密?

简单而言,服务器能生成一对不同的密钥(所谓非对称),一把私自保存,称为私钥;一把向所有人公开,称为公钥

这对密钥有这样的性质:公钥加密后的数据只有私钥可以解密,私钥加密后的数据只有公钥可以解密

非对称加密的一种经典实现叫 RSA 算法,这种加密算法最早 1977 年由罗纳德·李维斯特(Ron Rivest)、阿迪·萨莫尔(Adi Shamir)和伦纳德·阿德曼(Leonard Adleman)一起提出的,RSA 就是他们三人姓氏开头字母拼在一起组成的

有了非对称加密的技术后,事情就好办了:

用户端把 Pre-Master-Key 使用服务器的公钥加密后,传送给服务器

由于只有服务器才有私钥,所以只有服务器才可以解密数据,获取用户端发送来的 Pre-Master-Key

具体的交互过程:

用户端向服务器索取公钥 PublicKey;

服务器将公钥发给用户端(这里没有保密需求,由于公钥是向所有人公开的);

用户端用服务器的公钥 PublicKey 把 Pre-Master-Key 加密成密文,传送给服务器;

服务器使用私钥 PrivateKey 解密密文,获取到用户端发送的 Pre-Master-Key;

看起来很完美,但是第 2 步骤又引发了一个新问题:

因为互联网是公开的,服务器发送给用户端的公钥可可以在传送过程中被中间人截获并篡改(所谓中间人攻击 Man-in-the-middle attack,缩写:MITM)

中间人攻击

由于中间人也能生成一对非对称密钥,它会截获服务器发送的公钥,而后把它自己的公钥 MiddleMan-PublicKey 发送给用户端,进行欺骗

可怜我们的用户端,竟然信以为真!而后傻乎乎的把自己的 Pre-Master-Key 使用 MiddleMan-PublicKey 加密后,发给中间人

怎样处理这个问题?

问题等价于:用户端怎样确定收到的公钥,真的就是服务器的公钥?

想一想你乘高铁、坐飞机的时候,怎样向工作人员证实你是你

答案很简单,到公安局(权威机构 英文名:Authority)出个身份证实(Certificate)

身份证上记载了你的号码、姓名、年龄、照片、住址,还有签发机关、有效期等

所以,服务器也想办法到权威机构 (Authority) 办一张证书 Certificate,上面记载了服务器的域名、公钥、所属单位,还有签发机关、有效期等

当用户端收到服务器发过来的证书后,只需证书不是伪造的,那么上面记载的公钥一定也就是真的!

证书长啥样?

点击 IE 浏览器上的小锁即可以查看服务器的证书

查看证书

不过,这里又有个新问题:怎样证实证书不是伪造的?

我们详情一种防伪手段:签名(Signature)

什么是签名?

我们在生活、工作过程中,经常遇到需要签名的情况:刷信誉卡、签合同等,使用来证实这是本人的行为。签名之所以可信,是由于理论上每个人的签名都有生理学基础,别人是无法伪造的,就像你的指纹一样

所以,只需服务器发送的证书上有权威机构 Authority 的签名,即可以确信证书是颁发给服务器的,而不是谁伪造的

这就相当于,只需你的请假条上有领导的签名,那么 HR 就会确信领导已经审批同意你请假了

假如说人类签名用纸笔,那么计算机的数字化签名怎样实现呢?

答案是用非对称加密技术:

数字证书认证机构(Certificate Authority,简称 CA)生成一对公/私钥;

服务器将自己的域名、公钥等信息提交给 CA 审查;

CA 审查无误,用私钥把服务器信息的摘要加密,生成的密文就是所谓签名(Signature);

CA 把服务器的信息、签名、有效期等信息集合到一张证书上,颁发给服务器;

用户端收到服务器发送的证书后,用 CA 的公钥解密签名,取得服务器信息的摘要,假如和证书上记录的服务器信息的摘要一致,说明服务器信息是经过 CA 认可的

什么是信息摘要?

简单来说,就是一段任意长的数据,经过信息摘要解决后,能得到一段固定长度的数据,比方 32 字节,只需原始数据有任意变动,生成的信息摘要都不一样

但是,在第5步骤又有一个新问题:用户端怎样知道 CA 的公钥?

答案:与生俱来

世界上的根 CA 就那么几家,浏览器或者者操作系统在出厂的时候,已经内置了这些机构的自签名证书,上面记录他们的公钥信息,你也能在需要的时候手动安装 CA 证书

以 Windows 系统为例:

系统信任的根证书

至此,HTTPS 通信过程已经很明朗了:

操作系统/浏览器 自带了 CA 根证书;

用户端因而能验证服务器发送的证书真实性,从而获取到服务器的公钥;

有了服务器的公钥,用户端即可以把 Pre-Master-Key 传送给服务器;

服务器获取到 Pre-Master-Key 后,通过后续产生的对称密钥,即可以和用户端加密通信了。

总结

本文简述了 HTTPS 通讯过程的基本原理,涉及到了对称加密、非对称加密、信息摘要、签名、密钥交换等技术基础,以及发行机构、数字证书等概念具体的 HTTPS 实现细节还要复杂得多,这里并没有开展讲,但是并不影响对 HTTPS 不熟习的读者对原理有基本的认知。

  • 全部评论(0)
最新发布的资讯信息
【网页前端|】从BAT大数据工程师那里总结的大数据学习方法(2019-05-23 11:46)
【系统环境|Linux】值得了解的十大数据发展趋势(2019-05-22 11:33)
【系统环境|软件环境】如何成为一名大数据工程师?(2019-05-20 12:11)
【系统环境|Linux】大数据四大常识,不会你敢说自己在做大数据?(2019-05-19 11:39)
【系统环境|】需要同时掌握AVA和Linux,才可以继续大数据课程的学习(2019-05-18 10:28)
【系统环境|软件环境】学习大数据,一定要了解大数据的这些用途(2019-05-16 10:49)
【系统环境|Linux】bt宝塔控制面板mysql频繁自动停止详细解决办法(2019-05-16 08:52)
【系统环境|】大数据零基础学习路线,新人记得保存收藏哦(2019-05-15 10:54)
【系统环境|】全网最全最新的大数据系统学习路径(2019-05-14 15:38)
【系统环境|Linux】毕业设计:音乐分享系统(2019-05-14 07:48)
手机二维码手机访问领取大礼包
返回顶部