SSL相关知识科普

小明开发了一个多人博客网站，所有人都可以在上面发表文章，下载资源

例子2

小黑开发了一个多人博客网站，只允许登录的用户在上面发表文章，下载资源

之前我一直以为，用户认证的过程就是安全通信的过程。: (

以下是英文版维基百科的定义，中文版的维基百科和百度百科没有找到相关的定义。

Secure communication is when two entities are communicating and do not want a third party to listen in.

中文：安全通信是指两个实体正在通信并且不希望第三方监听。
复制代码

为了达到上述的目标，就需要** 以不易被窃听或拦截 **的方式进行通信。

维基百科中还有一段话，附上

Other than spoken face-to-face communication with no possible eavesdropper, it is probably safe to say that no communication is guaranteed secure in this sense, although practical obstacles such as legislation, resources, technical issues (interception and encryption), and the sheer volume of communication serve to limit surveillance.

中文大致意思：除了没法监听面对面交流，理论上其他的手段只能限制监听。
复制代码

Tips：有兴趣可以阅读以下维基百科原文 en.wikipedia.org/wiki/Secure… 有一些关于安全的讨论。

OK！看完百科的定义，我们可以get一些关键词： 监听 和 拦截 ，安全通信，就是围绕这两个概念展开的。

窃听

关于窃听，有两个问题。

1. 窃听的定义
2. 怎么做到窃听

先来看 问题1 ，计算机中窃听，通常指的是网络窃听，接下来，有请万能的维基百科。

在电脑网络中，窃听攻击是在网络层，利用软件，收集其他电脑送出的封包（Packet），分析其内容，以取得其中的资讯。
复制代码

get到关键词， 网络层 和 Packet ，对于这两个概念不熟悉的同学，请出门右转(点击这里)

网络层提供路由与寻址功能，如果在这一层动手脚，那么源IP+端口/目标IP+端口/Packet我们在这一层中都可以获取到，解析Packet，就可以获取到我们所发送的内容。

再来看 问题2 ，理论上，大部分的公共wifi都可以被窃听，运营商的基站，甚至是一些代理。原理也比较简单，附上一个教程 github

拦截

不赘述，附上百科

理论上，我们是无法避免窃听的，因为我们开发的应用是在应用层，远在网络层的攻击，我们是无法避免的。我们能做的，就是即使数据被监听了，他无法解析出来他想要的数据。

Http与Https

Http与Https的区别就是，Https将Http明文传输的协议进行加密，即使信息被截取，也无法破解。

Https使用的加密方式是对称加密

配置过Https的都知道，配置流程中，只需要申请pem和key文件( CA证书 )，在nginx中配置规则，开启443端口即可。

那么问题来了：

(注意:客户端是没有任何配置的)

我们去看Https的维基百科( 长文预警 )。

HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的防护。

HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如Symantec、Comodo、GoDaddy和GlobalSign等）（意即“我信任证书颁发机构告诉我应该信任的”）。因此，一个到某网站的HTTPS连接可被信任，当且仅当：
- 用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构；
- 用户相信证书颁发机构仅信任合法的网站；
- 被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
- 该证书正确地验证了被访问的网站（如，访问https://example.com时收到了给example.com而不是其它组织的证书）；
- 互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃听者破坏。
复制代码

关键词提取： 预先安装在浏览器中的证书颁发机构

也就是说中，预先安装了一个叫 证书颁发机构 的东西，想知道这个东西有什么用，我们就需要了解客户端的证书颁发机构和服务器端( CA证书 )的工作原理( SSL握手过程 )，以下内容来自百度百科：

1. 客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。
2. 服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。
3. 客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步
4. 用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。
5. 如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
6. 如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。
7. 服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通讯的加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。
8. 客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。
9. 服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
10. SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

感叹一声，大写的NB！！！

不理解上述步骤的，看一下我的简化版( C客户端，S服务器 )：

1. C端与S端验证对方证书的合法性
2. C端产生一个 随机数1 ，用S端公匙加密，产生 随机密码1
3. S端用自己的私匙解析 随机密码1 ，获取 随机数1 ，此时，C端与S端使用相同的方式对 随机数1 进行运算得到一个 通讯密码
4. C端与S端使用相同的通讯密码对数据进行对称加密

什么是SSL

哈哈哈，上面不小心已经解释过SSL建立连接的过程了。这里只简单说几点：

1. SSL是一种安全协议
2. SSL针对HTTP进行了特别设计，是的HTTP协议能够在SSL运行
3. HTTPS是HTTP+SSL
4. HTTPS运行在443端口，HTTP运行在80端口
5. HTTPS需要申请证书 CA
6. 在我写的SSL简化握手步骤中的123步，为什么需要这种方式来生成对称加密的密码，有以下几点原因：
   • 如果C与S使用默认的密匙，那么这个密匙一旦被别人获取到，那么加密数据就会被解析出来
   • 如果使用非堆成加密的方式，如果服务端通过私匙加密的数据被截取到的话，也是会被加戏出来的，因为公匙是公开的，而且非对称加密消耗的时间长，并且公匙一旦泄露，也有风险

TSL 与 SSL的区别

SSL是协议层安全性协议 TSL是传输层安全性协议

认证方式不同

TSL使用X.509认证( 看到这里，终于知道composer安装文件中为什么大量出现openssl_x509_parse，妈耶 ) SSL认证方式前面已经提到

工作地点不同

TLS工作在传输层，应用层协议能透明地运行在TLS协议之上