数据加密
问题
- 数字签名的作用是什么？
- 为什么 HTTPS 是安全的
- CA存在的动机是什么
- 客户端的公钥的都是一致的吗？
我们先思考一下数据的传输过程中,我们得考虑几个方面 :
- 数据的完整性 : 中途不能给篡改了
- 验证身份 : 我和发信息的到底是不是那个他
- 数据的保密性 : 数据丢了别人也看不懂
场景分析
场景一
假如服务端和客户端使用的是对称加密我们来看一下会出现什么情况？
这样子有个问题黑客E利用假装是正常用户与服务端通信，获取到密钥，然后在中途截取到其他客户端和服务端的通信（例如 A 和 B 之间的通信）那么就可能获取到他们之间的信息。 所以这种模式是不安全的。要是有一种方式可以让客户端和服务端之间的通信密钥是他们自身独有就好了，这样即使黑客拿到消息后也无法解析出来。
场景二
假如服务端没有经过CA, 而是发送给客户端过程中公钥G给人篡改了呢？黑客E拿到公钥G后，生成一个私钥PRH和公钥PUG，发了个假的公钥给客户端，然后客户端利用这个假公钥发送消息给黑客E(又被截取了)，此时黑客E可以利用手头的PRH 就可以解开又 PUG 加密的消息，然后在利用G加密消息发送给服务端。这样黑客E就充当两者之间的窃听者，可以窃取和修改两者之间的消息。所以公钥能否安全地送到客户端手上成了关键，于是就引入了第三方认证
就像我们平时，要证明一个人的身份，派出所成了最好的证明场所，前提是那个人要提前在派出所有记录，HTTPS 也是同样的道理，于是有了CA机构。
场景三
道格 --> 苏珊 , 道格 和 苏珊 通讯, 道格 ,苏珊拥有的秘钥分别为私钥和公钥, 可以认为道格是服务器 , 苏珊 是客户端, 此时 波比 为了窃取他们的通讯内容, C波比 把 苏珊 的公钥换做成了自己的公钥, 然后呢 , 波比 再用自己的私钥给 苏珊发送消息 , 苏珊用假的公钥解开了消息, 而此时的苏珊不知道自己的公钥已经被换了所以一直会认为自己是和 道格在通讯 ,而波比这样就达到了窃取信息的目的.
直到有一天 苏珊发现了不对劲, 她要道格去 CA 做个数字证书 ,重新发给她
黑客的目的就是替换CA发给客户的公钥为自己的公钥 !! 好拦截请求后
CA 机构使用机构的私钥对道格的公钥进行加密(毫无疑问 , 机构用私钥加密的数据肯定只有机构的公钥才能解得开), 上面会有拥有者, 颁发者,有效期等等信息,，客户端如果是使用浏览器,浏览器本身会配置信任的CA机构，浏览器首先会去CA机构拿到CA的公钥，然后利用CA的公钥解开经过CA加密的道格的公钥，当然这个地方还有验证一下信息，包括证书是否过期等等。当确定该证书确实来自于服务端，且没被修改过后。
由于CA 承担着认证的责任 ,所以一旦被黑客攻克 , 就失去了安全性 .
那么有没有一种情况, CA 发给服务器证书的时候给黑客截取了 , 那么黑客可能进行两种情况的行为 :
(1) 修改掉证书的内容, 例如把里面的公钥给修改成自己提前伪造好的
(2) 黑客也去CA 那里申请一张数字证书, 然后把CA发给用户的数字证书换成黑客自己的数字证书
针对情况一, 我们可以通过数字签名(一堆hash)来确认是否给人修改过了 ; 情况二 , 也是行不通的, 因为黑客自己的证书上的地址url和客户要返回的地址会对不上的
那么这里会引出一个问题 ,就是会不会 CA 会给一个网站颁发错误的公钥呢(比如这个公钥是黑客的公钥)?? 那么这个时候就危险了! 所以 CA 机构一点要千真万确确认该公钥就是该域名负责人提供的公钥 , 而不是黑客 , 所以一般来说 CA 会采取一些方式来确定用户就是正是的用户 , 例如 : 发送邮件进行确认 ; 线下调查进行确认 ;
事件
CA 事件
2015年谷歌和著名的CA机构赛门铁克就发生了一件互喷的事件 ,起因就是谷歌发现赛门偷偷地自己的域名颁发了一份错误的证书(也就是说别人访问自己的域名时, 由于是错误的证书 ,那么就意味着有中间人攻击的可能性) , 赛门则宣称该证书并没有传播出去造成实质性的危害 , 2017 年谷歌团队对赛门的证书进行调查并宣称其曾错误地版发过至少 3万个假证书 .
根据谷歌官方安全博客报道和Mozilla官方博客报道，谷歌发现CNNIC颁发了多个针对谷歌域名的伪造CA假证书。这个名为MCS集团的中级证书颁发机构发行了多个谷歌域名的假证书，而MCS集团的中级证书则来自中国的CNNIC。
该证书冒充成受信任的谷歌的域名，被用于部署到网络防火墙中，用于劫持所有处于该防火墙后的HTTPS网络通信，而绕过浏览器警告。谷歌联系了CNNIC，CNNIC在3月22日回应称，CNNIC向MCS发行了一个无约束的中级证书，MCS本应该只向它拥有的域名发行证书，但MCS将其安装在一个防火墙设备上充当中间人代理，伪装成目标域名，用于执行加密连接拦截（SSL MITM）。企业如出于法律或安全理由需要监控员工的加密连接，必须限制在企业内网中，然而防火墙设备却在用户访问外部服务时发行了不受其控制的域名的证书，这种做法严重违反了证书信任系统的规则。尽管这种解释看起来符合事实，然而，CNNIC还是签发了不适合MCS持有的证书。
CNNIC作为根CA被几乎所有操作系统和浏览器信任，谷歌已经将这些情况通知了所有的主流浏览器，谷歌所有版本的Chrome浏览器（包括Windows、OS X、Linux版）、Firefox浏览器都会拦截这些证书，Firefox从37版开始引入OneCRL机制，建立证书黑名单，拦截被滥用及不安全的证书。
后续：MCS回应称，该证书用于测试环境，并且是人为操作错误引起的。CNNIC回应称，1、CNNIC未发布用于中间人攻击的证书。2、CNNIC 服务器证书业务合作方MCS公司确认其不当签发的测试证书仅用于其实验室内部测试。3、CNNIC已于3月22日撤销对MCS公司的业务授权。
概念
数字摘要
hash对于学java的应该比较熟悉，这东西可以用来作用唯一标识。一旦内容改变了一点hash值就会不同。对内容进行 hash 函数后得到的东西称之为 "数据摘要"
数字签名
然后对数据摘要经过私钥加密生成数字签名，然后附在内容底下发给客户端。
当客户端收到消息 , 用拿到的公钥进行解密后再对消息进行hash，对比发来的消息的hash值是否一致，不一致说明消息被人修改了。
数字证书
证书中包含什么信息
- 证书信息：过期时间和序列号
- 所有者信息：姓名等
- 所有者公钥
CA 是什么
动机 : 保证客户端收到的公钥一定是服务端的公钥,而不是伪造的
为了使公钥可以安全地发送到客户端的手上，HTTPS引入了第三方验证机构，在最初的时候服务端首先会把自己的公钥发给CA , CA用自己的私钥对服务端的公钥还有其他信息进行加密，然后生成数字证书，发送给客户端。比如说客户端是浏览器 , 浏览器自身就会自带一些CA机构的公钥.
根证书
https://proprivacy.com/guides/root-certificates-explained 重要参考
Certificate Authorities issue certificates based on a chain of trust, issuing multiple certificates in the form of a tree structure to less authoritative CAs. A root Certificate Authority is therefore the trust anchor upon which trust in all less authoritative CAs are based. A root certificate is used to authenticate a root Certificate Authority.
证书颁发机构基于信任链颁发证书，以树形结构的形式向权威性较低的 CA 颁发多个证书。 因此，根证书颁发机构是所有权威性较低的 CA 的信任所基于的信任锚。 根证书用于验证根证书颁发机构。
Generally speaking, root certificates are distributed by OS developers such as Microsoft and Apple. Most third party apps and browsers (such as Chrome) use the system’s root certificates, but some developers use their own, most notably Mozilla (Firefox), Adobe, Opera, and Oracle, which are used by their products.
一般来说，根证书是由微软和苹果等操作系统开发商分发的。 大多数第三方应用程序和浏览器（例如 Chrome）使用系统的根证书，但一些开发人员使用他们自己的，最著名的是 Mozilla (Firefox)、Adobe、Opera 和 Oracle，它们的产品使用这些证书。
去中心化
我们为了安全于对消息进行了加密 , 然后对加密的认证我们引入了 CA , 但是后面我们又发现 CA 始终是人为工作, 且掌握的权利很大 , 只要他从中作梗 , 便也无人知晓 . 那么有没有一种方式可以避免这种情况呢 ? 有的 !
"去中心化"就是一种方案 , 从下图我们可以看到为了解决 CA 的问题 ,我们又引入了另外一个东西 , CT (Certificate Transparency 证书透明) , 它的核心就是它的日志服务 .
它的工作过程如下 : CA 再颁发一个证书的时候要先向日志服务提交证书详情 , 日志服务则向CA 返回一个 SCT 数据 , CA将SCT加入证书的扩展中 , 把这个携带SCT信息的证书颁发给站点服务器 , 在TLS 握手的时候 , 浏览器拿到服务器给他的这份附加了SCT信息的证书,除了像前面说的那样验证证书本身还要向日志服务验证SCT , 日志服务也有自己的公私钥对 , 而SCT 中则包含被其私钥签名的数据 , 所以浏览器使用日志服务的公钥对SCT信息中的签名进行验签来确定真实性 , PS : 你可能在想这不是套娃了 , 这样 CA 又依赖 CT , 那 CT 也有可能是不安全的呀 .
日志服务是去中心化的 , 它运用类似于区域链类似的技术使得信息只要发生一些变化就会影响其他信息的变化 .
当然"去中心化"也有缺点, 以下是目前"去中心化"未解决的问题
HTTPS
来自百度
HTTPS 协议是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称密钥等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个 :
（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么 [4] 。
（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收 [4] 。
（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方
那么一个不准确的描述 :
HTTPS = HTTP + TLS
简介
SSL 和 TLS 是什么, 有什么联系
TLS 是 1999年以后的叫法 , 其实它们表示的是同一个东西 , 可以从下面的时间轴看到这两个东西的演化过程 .
TLS的前身是SSL，TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。本文着重描述TLS协议的1.2版本
TLS 协议
下文主要来自这篇文章 ,非原创 ,小部分是自己的学习注释
下图描述了在TCP/IP协议栈中TLS(各子协议）和HTTP的关系
来源 : https://cattail.me/tech/2015/11/30/how-https-works.html
也就是简单来说 , TLS 协议部分组成有两部分
- SSL握手协议
- TLS Record Layer Protocol
SSL 握手协议又包含三部分 :
-
TLS 握手协议(Handshake protocol)
-
TLS 改变密码标准协议(Change Cipher Spec Protocol)
-
TLS 告警协议(Alert protocol)
其中，数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。
TLS 简要过程
下面分这两部分介绍协议相关的内容
第一部分 : TLS Record Layer 协议
在TLS协议中，有四种子协议运行于Record protocol之上
- Handshake protocol
- Alert protocol
- Change cipher spec protocol
- Application data protocol
Record protocol起到了这样的作用
- 在发送端：将数据（Record）分段，压缩，增加MAC(Message Authentication Code)和加密
- 在接收端：将数据（Record）解密，验证MAC，解压并重组
值得一提的是，Record protocol提供了数据完整性和隐私性保证，但Record类型（type）和长度（length）是公开传输的
Record Protocol有三个连接状态(Connection State)，连接状态定义了压缩，加密和MAC算法。所有的Record都是被当前状态（Current State）确定的算法处理的。
TLS Handshake Protocol和Change Ciper Spec Protocol会导致Record Protocol状态切换。
这个地方不好理解 , 你得往下看 第二部分:SSL握手协议 之 TLS 改变密码标准协议 再回来看这个图就好理解多了 .
初始当前状态（Current State）没有指定加密，压缩和MAC算法，因而在完成TLS Handshaking Protocols一系列动作之前，客户端和服务端的数据都是明文传输的；
当TLS完成握手过程后，客户端和服务端确定了加密，压缩和MAC算法及其参数，数据（Record）会通过指定算法处理。
其中，Record首先被加密，然后添加MAC（message authentication code）以保证数据完整性。
可不可以这样理解 , Record Layer 协议就是主线 ,主分支 , 而在其上的子协议就是对应分支实现细节的实现.
第二部分 : SSL握手协议 之 TLS-握手协议
过程如下 :
- [明文] 客户端发送随机数
client_random和支持的加密方式列表 - [明文] 服务器返回随机数
server_random，选择的加密方式和服务器证书链(注意哦 , 这个时候公钥就发了过去了) - [RSA] 客户端验证服务器证书(前面我们讲的 CA 机构验证证书就是在这里 )，使用证书中的公钥加密
premaster secret发送给服务端 - 服务端使用私钥解密
premaster secret - 两端分别通过
client_random，server_random和premaster secret生成master secret(这东西就是对称加密的密钥)，用于对称加密后续通信内容
这里 第三步 ,第四步就用到我们前面讲到的 非对称加密 和 CA 机构验证证书 , 然后非对称加密的最终目的是为了协商出一个 对称加密的密钥 .
我们前面讲了非对称加密比较安全 ,为什么到了最后还是用回了 对称加密呢?这是因为非对称加密过程比较消耗性能, 而对称加密由于是使用同一密钥 , 较为方便 ,且前序步骤是由非对称加密生成的密钥 , 那么这个过程是比较安全的 .
第二部分:SSL握手协议 之 TLS 改变密码标准协议
参考这篇文章
SSL修改密文协议的设计目的是为了保障SSL传输过程的安全性，因为SSL协议要求客户端或服务器端每隔一段时间必须改变其加解密参数。当某一方要改变其加解密参数时，就发送一个简单的消息通知对方下一个要传送的数据将采用新的加解密参数，也就是要求对方改变原来的安全参数。
SSL修改密文协议是使用SSL记录协议服务的SSL高层协议的3个特定协议之一，也是其中最简单的一个。协议由单个消息组成，该消息只包含一个值为1的单个字节。该消息的唯一作用就是使未决状态复制为当前状态，更新用于当前连接的密码组。为了保障SSL传输过程的安全性，双方应该每隔一段时间改变加密规范。
通俗点说就是通信过程我还会随时变化加密的一些参数 ,使得通过过程更加不会给黑客渗透 .
看下面这张图比较好懂一些
其他
除了使用RSA算法在公共信道交换密钥，还可以通过Diffie–Hellman算法。这里就不多介绍了, 感兴趣看这里 HTTPS工作原理(推荐阅读)
总结
这篇文章我们开始从几个场景开始去理解HTTPS 的一些动机, 为什么要这么做, 是因为有这些场景的存在, 然后我们介绍了https 协议中出现的概念和名词 , 最后我们深入协议内部 ,了解工作原理 .
参考资料
HTTPS
