前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >TLS协议学习笔记

TLS协议学习笔记

原创
作者头像
roper
修改2018-07-02 19:54:11
2.2K1
修改2018-07-02 19:54:11
举报
文章被收录于专栏:后台开发后台开发后台开发

一,概述

说起TLS(Transport Layer Security 传输层安全协议),可能有点陌生,但是说起HTTPS,大家应该都知道,我们现在浏览网页基本上都是HTTPS的。HTTPS就是加密的HTTP,HTTP基于明文传播,直接使用HTTP的话内容很容易被窃取。HTTPS则对内容进行了一层加密,避免了内容被窃取和篡改的可能性,如下图所示。

现在知道了TLS是用来保护数据安全的,那么TLS是怎么做到的呢?先来看一下数据安全的三个目标:

  • 数据是加密的
  • 防止被篡改
  • 防止冒充

实现了这三个目标,可以认为数据通信就是安全的。 TLS为了实现上面的目标,分别使用了如下机制:

  • 非对称加密
  • 数字签名
  • 数字证书

如果没有去了解过这几个名词的含义,那么会感到有点懵逼,就像我之前一样,下面仔细解释下这些名词的含义。

二,概念解释

1,非对称加密

非对称加密是计算机通信安全的基石。相对于非对称加密的另外一种加密方式是对称加密。对称加密的意思是通信双方使用的密钥是一样的,双方使用相同的密钥进行加解密。这种加密方式的一个最大问题就是密钥如何传递,传递密钥的过程中很容易被窃听截取。古希腊就有用木棍作为密钥的,把纸条缠绕在木棍上对齐来实现解密,通信双方只要使用的木棍大小一样,就能解密出纸条中的文字。如下图所示。只要有人截获或者偷走了你的木棍,那么通信过程相当于就是明文的了。

理解了对称密钥和它的缺点,非对称加密也就好理解了。非对称加密的通信双方使用的密钥是不一样的,其中通信一方使用的密钥叫私钥(private key),另一方使用的叫公钥(public key)。私钥顾名思义就是私有的密钥,不公开的,这个密钥千万不能告诉别人。公钥是可以公开给所有人看到的。为什么公钥可以公开给所有人看到,这样还怎么保证通信的安全性?答案在于非对称加密的两个重要特性:

  • 公钥加密的内容只有私钥可以解开。刚才说过,私钥是由通信的一方秘密持有的,这就保证了任何公钥加密的内容只有私钥持有者能解开。
  • 非对称加密只能保证单向安全。使用公钥的一方向私钥的一方发消息是安全的,但是使用私钥向公钥的一方通信是不安全的,因为使用私钥加密的内容任何持有公钥的人都能解开。而TLS协议是不依赖双向安全的,只要有单向安全就能保证TLS是安全的,后面会再介绍TLS协议的实现。

下面是维基百科上一个非对称加密的例子。鲍伯持有着私钥,并把公钥公开给了爱丽丝。爱丽丝使用鲍伯的公钥加密了一段

2,数字签名

我们日常生活中会经常在纸上签名,来证明纸上内容的真实性和可靠性。比如租房合同,你在上面签了名,就代表你确认合同上内容的真实有效性,其他任何拿到这份合同的人,只要看到了你的签名,就会认同这份签名的真实有效性。

同样的,在计算机通信中也存在数字签名,数字签名的意义和真实生活中的意义几乎是一样的,通过数字签名可以确认一份数字内容是真实有效的,没有被人篡改过的。那么数字证书是怎么生成的呢。分为两步。

Step1. 发送方使用hash函数对要发送的内容计算出一个hash值,叫做摘要(Digest)。常见的hash函数就是MD5(另外还有高端一点的带密钥的hash算法,即MAC算法)

Step2. 使用私钥对刚才生成的摘要进行加密,生成签名(Signature)

接收方收到内容和签名后,怎么确认内容是真实有效,没有被篡改过的呢?验证的过程也是分为两步:

Step1. 使用发送方的公钥去解开签名(Signature),得到发送方计算出来的hash值。如果能解开,说明内容确实是真实的发送方发出的。其他人伪造的签名,用真实的公钥是解不开的。(这里是假设发送方的私钥没有泄露,伪造方签名使用的私钥是假的)

Step2. 对发送的内容用同样的hash算法计算出hash值,如果和发送方在签名中带的hash值一致,说明内容没有损坏或者被篡改过。

3,数字证书

有了非对称加密和数字签名,好像数据通信的过程已经很安全了,那么数字证书是个什么东西,为什么还要这玩意呢?这就要涉及到通信安全中三个目标中的最后一个---防止冒充。

假设这么一个场景,A代表银行,B代表客户,A持有私钥,B持有公钥,C是一个黑客,他想盗取B与A通信过程中输入的银行密码,那么C该怎么做呢?盗取A银行的私钥再伪装成A与B通信是一个办法,但是难度太大,盗银行的私钥基本上是不可能的。但是对B客户的电脑做做手脚还是比较简单的,说不定就是个小白用户。C于是成功黑进了B的电脑,把B手上的银行公钥换成了自己的公钥。这样B就无法与A正常通信了,反而可以与C通信。C于是就伪造成A堂而皇之地与B通信,成功地盗取了B的银行密码。而B对此一无所知,他以为和他通信的是A银行。

数字证书就是为了解决公钥被替换冒充问题而产生的,那么数字证书到底是什么呢?我觉得有一个比较形象的比喻,数字证书就像是一张国家颁发给每个公民的身份证,数字证书就是一些权威的证书中心(CA,certificate authority)颁发给每个通信端的一张身份证。身份证的属性就是独一无二的,无法伪造和替代的。同样的,CA颁发给每个通信端的数字证书也是唯一的,无法被伪造的。数字证书里有通信端的一些信息(名字,地址,邮箱等),证书的信息(过期时间等),以及最重要的通信端的公钥。CA把这些信息汇总之后,使用CA私钥加密生成证书。

再回到刚才的例子,此时B客户的电脑上持有的不是A银行的公钥,而是一张CA颁发给银行的证书以及CA的公钥。B与A银行通信时,使用CA公钥从证书中解析出A银行的公钥,再用银行的公钥去和A通信。这个时候C黑客还有没有机会去伪造呢?C黑客尝试去伪造证书,发现CA根本不可能去给C黑客颁发一张署名为A银行的证书,就好像美国不会给你颁发一张特朗普的身份证。其它署名的证书可以被B客户发现,无法达到伪造的目的。那么C黑客能否再替换B电脑上CA证书,直接伪造CA呢?这条路也走不通,因为一般顶级的CA证书都是直接预装在操作系统里的。要是能黑掉操作系统那简直猥琐欲为了。摘抄一段来自知乎的关于CA证书安全性的回答,有点带感。。。

三,TLS协议的过程

TLS协议做了如下几件关键事情:

  • 客户端请求服务端证书。如果是双向验证,服务端也会向客户端请求证书。比如银行系统安全级别比较高,就会验证客户端证书(还记得以前银行发的像U盘一样的token吗)。
  • 服务端和客户端协商出一个“对话密钥”
  • 双方使用”对话密钥“进行加密通信

这里为什么要生成一个”对话密钥“来对后续的通信加密呢,为什么不直接用证书的公私钥加密?我的理解是有两点原因:

1,非对称加密性能很低,之前看过一篇文章提到过对称加密的性能是非对称加密的500倍。因此双方协商出一个对话密钥,使用对称加密通信可以有效提高通信效率。

2,非对称加密是单向安全的。在介绍非对称加密概念的时候也提到过,只能保证公钥发给私钥的数据是安全的。如果要双向安全,需要通信双方都有一套公私钥,这显然是很难保证的。

下图就是TLS协议握手的过程。详细的介绍可以看一下阮一峰的博客,讲的很详细很好,链接在文章末尾。为了完整性,这里大概介绍一下这四个步骤:

Step1. Client客户端发起TLS通信请求,请求里有Client支持的TLS协议版本,支持的加密方法(比如RSA加密),第一个随机数,并请求Server的证书

Step2. Server服务端给Client回复支持的TLS协议和加密方法,Server端的证书,以及第二个随机数。如果Sever需要验证Client的身份,还会请求Client的证书。

Step3. Client回复第三个随机数(使用服务端的公钥加密,保证不被窃取)。如果Server端请求了客户端证书,也会带上Client证书。此时Client已经拥有三个随机数,利用这三个随机数生成”对话密钥“。

Step4. Server端解析出第三个随机数,也生成同样的”对话密钥”。从而TLS握手过程结束,Server给Client回复握手结束通知。

四,TLS-PSK

上一章节提到的TLS协议过程其实只是TLS加密套件中的一种 -- 使用证书认证的过程,即非对称加密方式的认证过程。其实TLS也是可以支持使用对称加密方式来进行认证过程的,这种方式就是TLS-PSK(Pre-Shared Key Ciphersuites for Transport Layer Security)。TLS-PSK是为了给性能受限的场景提供支持,因为不是所有的场景都有足够的计算能力去实现非对称加密的,比如说我们现在做的物联云设备接入,设备的性能很有可能就没有这个计算能力。这个时候提供一个对计算能力比较低的对称加密验证方式就很有必要了。

下面是TLS-PSK协议的握手过程,和之前介绍TLS证书过程很类似。

握手过程中主要完成如下两件关键事情:

  • 协商加密的方法套件,比如TLS_PSK_WITH_RC4_128_SHA,这是对性能要求最低的一种加密方法。
  • 协商出对称加密的密钥。通信的双方一般在握手之前就都已经拥有了对称加密的密钥,这里为什么还要协商呢?这是因为通信双方手上可能有多个密钥,因此需要协商出使用哪个密钥。特别是服务端,可能保存了多个客户端的密钥,需要根据客户端的id去选择相应的密钥。Client端在ClientKeyExchange请求中携带了一个”PSK Identify“,以此来选择出对应的密钥。

参考文献:

《SSL/TLS协议运行机制的概述》http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

《数字签名是什么》http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html

《图解SSL/TLS协议》http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

《WebSocket教程》http://www.ruanyifeng.com/blog/2017/05/websocket.html

《TLS-PSK RFC》 https://tools.ietf.org/html/rfc4279

《Go和HTTPS》https://tonybai.com/2015/04/30/go-and-https/

《怎么保证「CA 的公钥」是真实的》https://www.zhihu.com/question/47232448

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一,概述
  • 二,概念解释
    • 1,非对称加密
      • 2,数字签名
        • 3,数字证书
          • 三,TLS协议的过程
          • 四,TLS-PSK
          • 参考文献:
          领券
          问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档