安全通讯

安全通讯

应用层协议大多数本身都没有实现加解密功能，好比http等。http就是直接把数据加载进来而后作简单编码（也就是流式化）而后响应客户端，而后数据在浏览器展现，这个数据在传输过程是明文的，你截获就能够直接查看。这显然不安全，要想作到安全那么就只能在发送端加密而后接收端还能把信息还原成原来的内容，这就是加密解密。其实这个事情很好理解，加密解密在古代就有也不是现代的概念。在安全通讯里面我常常听到的2个东西就是SSL和TLS，这2个有什么区别呢？以及HTTPS是怎么通讯的？

SSL和TLS

SSL

SSL是网景公司研发的一种功能模块这种模块或者叫库就在应用层和传输层之间又加了一层，并且不是一整层只是半层，这要作的好处是你调用这个库就可使用这个功能若是不调用则仍是按照以前的方式来使用，这个半层的库就是SSL，叫作安全套接字层。不过SSL只是一种规范和协议并非具体实现。OpenSSL则是对SSL的实现并且众多实现中的一种。什么叫作一种实现呢？好比httpd和Nginx这两个应用都是http协议的实现或者说x86是一种标准那么DELL和HP均可以基于这种标准来设计本身的电脑。

若是你本身自己不具有开发这种加密解密的功能，那么你就可使用SSL完成这个工做，不过不管你本身开发仍是使用SSL，这些加密解密协议都须要具有2个基本功能：

1. 加密和解密

2. 秘钥分发

在Web应用方面，http调用了ssl就变成了https，虽然就是调用了ssl，可是http和https这两个在机制上有巨大的区别。

TLS

叫作传输层安全，为何有了SSL还会有一个和SSL相似的TLS呢？由于SSL协议是发明者是网景公司，它拥有版权，并且互联网公司不少都须要使用安全通讯，因此国际标准化机构就参照SSL弄了一个TLS协议。二者兼容。TLS由IETF在1999年发布。那么因为SSL的3个版本有漏洞全部不少不用了。如今主流都使用TLS。总之你能够把TLS当作SSL使用其原理都是同样的。

早期使用SSL较多后来大部分使用TLS，虽然咱们平时会说ssl它可能指的是SSL也能够是TLS，因此你不用纠结它指的是什么你只要理解为一种安全通讯机制就能够。因此咱们后面会不加区分的统称SSL。

为何如今都是全站启用SSL呢

以前不少网站都不是https，也只有某些特殊阶段才使用，好比支付阶段、登陆验证阶段。那么后来为何你们包括百度搜索首页这种都变成https了呢？

若是使用SSL加密那么服务端就须要解密，加解密其实很是消耗CPU资源，早期处于性能考虑不会大面积使用SSL，好比只是普通的浏览网页不必进行安全通讯。可是后来服务器性能愈来愈强并且大规模使用x86服务器以及有些网卡也支持SSL卸载，因此全站使用SSL也成为可能。

不过因为http是明文传输的，用户访问什么网页其实能够经过流量拦截，数据能够被修改，有些不法行为就能够利用这一点来实现广告投放，可是使用https通讯则不会出现这种状况。

安全通讯到底怎么安全呢？

基本概念

为了解决安全问题实现安全目标好比保密性、完整性、可用性等其解决方案有两类，就是技术和服务，技术指的是加密和解密；服务指的是认证机制和访问控制机制。
针对加密和解密以及实现服务功能的所用到的加密算法和协议就有以下几种：对称加密、非对称加密、单向加密和认证协议。

在Linux上实现上述算法和协议的工具备OpenSSL（ssl协议的实现）和GPG（pgp协议的实现）。

数字加密算法

先说一下算法，虽然加密用秘钥可是如何用这个秘钥来对数据加密或者解密这个是算法来决定的，可是一般算法是公开的好比RSA（个别安全公司有本身的独有的算法除外）因此是否安全不取决于算法而是秘钥。

什么叫密码，什么叫秘钥？我上面那段话确定会有人迷糊，密码是编码和解码的规则你能够理解为加密和解密规则而秘钥则是改变密码行为的外在参数，也就是说相同的规则当你使用不一样的秘钥加密相同内容时加密后的结果也是不一样的。好比字母移位这就是密码，而移动N位的这个N则是秘钥。假设移动3位，那么ABC则变成DEF。因此这就是为何上面那段话的结论是不取决于算法（密码）而是秘钥。

对称秘钥加密：对称加密算法有不少，可是不管什么算法加密解密都使用相同的秘钥，好处是简单计算量小也就是不会对CPU产生太大压力，缺点以及密码过多（你要和不少人通讯就须要不少人的密码）、密码分发困难。由于你要让对方能够解密你就须要把密码先给对方，这个给密码的过程要不要加密呢？这就变成了先有鸡仍是先有蛋的事情永远扯不清。经常使用算法DES（目前已经弃用）、AES等。

非对称秘钥加密：有公钥和私钥，使用公钥加密私钥解密。若是A和B通讯每一个人都有一对儿公钥和私钥，彼此还都有对方的公钥。A发信息给B则使用B的公钥加密，而后B收到后使用本身的私钥解密，而后B回复信息给A则使用A的公钥加密，A收到后使用本身的私钥解密。这个过程看似完美，但是因为公钥你们都能获取，B怎么知道信息是来自A而不是来自其余冒名A的人呢？这就是数字签名，这个后面再说。非对称加密主要用于数字签名和秘钥交换。加密数据虽然它也能作可是一般不这么用，你看后面的HTTPS通讯过程就知道了。非对称加密主要用来作对称秘钥的交换，完成交换后你们其实就是使用对称密码来作数据加密和解密。经常使用算法RSA（加解密和签名）、DSA（仅能签名）等。

单向加密**：不可逆的，只能加密不能解密，好比MD五、SHA1等。其实主要用来提取数据摘要或者说指纹，因此并不能算做咱们常规意义上的加密。它的特色是数据微小变化都会致使指纹的不一样，因此主要用来作数据完整性验证。

特别注意：并非说只能用公钥加密私钥解密，非对称加密方式的目的就是使用一种秘钥加密的数据必须能使用另一种秘钥解密，因此不管是公钥仍是私钥均可以加密，咱们之因此说用公钥加密用私钥解密是首先是由于公钥是从私钥中提取出来的，其次公钥是公开的若是你用私钥加密那么任何拥有该私钥对应公钥的人均可以解密 。因此才有公钥发给其余人私钥本身留存且用公钥加密私钥解密，由于只有这样才能发挥这种非对称加密或者说公钥加密的主要做用也就是密码交换和数字签名。不过使用私钥加密数据能够证实一件事情就是若是用该私钥的公钥能够解密那就证实这个数据必定是私钥持有人发来的。

秘钥交换（IKE，互联网秘钥交换）：IKE实现的方式有公钥加密和DH算法。这种标准主要用来作秘钥交换。不过对于秘钥交换来讲更加安全的实际上是DH算法，虽然经常使用的是公钥加密方式。

公钥加密最大的问题是密码是要从一方传送到一方，虽然使用对方的公钥加密了。可是DH的好处是双方不用发密码并且双方还能够获得密码。

数字签名

数字签名的主要做用是为了检查数据是否被篡改以及数据是谁发的（就是向对方证实此时他收到的消息是来自消息宣称的人本人而不是冒名顶替的第三人，固然真正验证对方身份的还不能仅仅靠数字签名这个后面再说）。

按照上面的例子A发消息给B，A使用B的公钥加密，B经过本身的私钥解密，但是公钥你们均可以得到那么B怎么知道这个消息是来自A呢？难道仅仅凭借消息内容说我是A就判定消息来自A么？另外B怎么肯定信息在传递过程当中没有被篡改呢？

为了解决这个问题A对消息作哈希摘要（MD5算法或者SHA1算法等）而后用A本身的私钥对摘要进行加密（数字签名），而后把加密后的摘要和消息自己一块儿使用B的公钥加密发送给B，这样B收到消息后用本身的私钥能够解密，而后用A的公钥能够解密签名（上面提到的摘要）若是成功就说明消息来自A。这就是签名和验证签名过程。消息来源确认了，此时就会担忧消息传递过程当中若是被篡改怎么办？这就是那段被加密的摘要的做用，若是B使用相同的算法来计算信息的摘要，若是B计算获得的值和解密签名后的获得的值一致说明信息没有被篡改。

上面的过程的确看起来很好可是有一个漏洞就是全部的公钥都要本身保存和管理万一被别人替换了呢，或者说A和B从未通讯过如今要作第一次通讯如何把公钥给对方呢？难道就不怕有人冒充A把本身的公钥给了B那么反过来也是同样，另外A对信息作哈希摘要的时候用的什么算法，万一B没有这个算法怎么办呢，因此这就引出了CA和证书的概念。

为何须要CA、证书以及CA根证书

公钥加密私钥解密，私钥确定是本身保存其实也就保存一份，若是我须要给不少人通讯难道我要保存不少人的公钥么？若是这个数量达到一个量级在管理上也很困难另外就是如何防止公钥被篡改呢也就是如何验证这个公钥是否是我要通讯的那我的的公钥而不是别人发来冒充他的。若是要是有一个第三方机构来统一管理就行了，这就是CA证书管理机构。CA的做用就是对申请人的公钥进行认证和加密，加密后的公钥就是数字证书，又称CA证书，证书中包含了不少重要信息好比申请人、用途、申请人支持的加密算法、申请人使用hash算法，证书有效期等其中最重要的就是证书申请人的公钥。固然前提是通讯双方都要信任同一个CA机构。

那有了CA以后该怎么作呢？申请者须要本身生成本身的公钥和私钥，而后把公钥和其余申请信息发给证书颁发机构，证书颁发机构本身也有公钥和私钥，而后证书颁发机构提取申请者的公钥和其余信息的特征码，而后CA使用本身的私钥加密这个特征码也就是签名， 这样造成一个由CA签名的证书而后发送给申请者 。此时仍是A和B通讯且为第一次通讯而且双方都信任同一CA颁发机构 。

1. A把本身支持的对称加密算法、单向加密算法、公钥加密算法以及本身的证书发给B
2. B拿到信息后须要对A的证书解密（这样才能获取A的公钥），但证书是CA用私钥加密的须要用CA的公钥解密这怎么办？这就是CA根证书（包含CA的公钥）的做用，B须要下载CA根证书而且安装到本身的电脑里一般只须要安装一次（一般如今操做系统 MacOX、Windows都已经内置了国际著名CA的根证书，由于全球著名CA都是有限的，Linux没有内置）。有了这个根证书也就有了CA的公钥，这样就能够解密A的证书来获取A的公钥。能解密成功说明A的证书是CA颁发的。而后使用证书中的单向加密算法来计算证书的特征码若是和解密签名获得的特征码一致则代表内容没有被篡改，因此这一步完成了对A的身份验证和证书信息的完整性验证。
3. 验证完以后还要看该证书的有效期以及证书主体名称和该证书是否被吊销
4. 验证都经过以后B选择本身支持的对称加密算法、单向加密算法、公钥加密算法以及本身的证书发送给A
5. A采用相同的步骤来验证B，若是验证经过，这时候你们就肯定了使用哪一种对称加密算法、单向加密算法、公钥加密算法而且完成了双方的公钥交换以及身份验证
6. A使用对称加密算法生成一个密码，而后对密码计算摘要，而后用本身的私钥对摘要进行签名，以后用B的公钥进行加密发送给B
7. B收到信息后使用本身的私钥解密，而后使用A的公钥解密签名获得摘要，若是解密成功则说明是A发来的，而后对密码提取摘要并和解密签名获得的摘要对比，若是一直则说明信息完整，这时候就完成了密码交换，今后双发就可使用对称加密方式来通讯。

上述这个过程就是你们经过CA来间接获取通讯双方公钥的过程。若是B使用CA的根证书没法解密A发来的证书说明就说明A的证书不是该CA签发的，因为世界上公认的CA也就那么几个因此若是B用这些CA的根证书都解密不了A的证书，那么就会提示风险，颇有可能A这个证书就是一个自签名的证书。

这里咱们只是阐明概念，在实际应用中上述过程还有些不一样，好比上面A发给B的包括签名和证书以及信息，难道信息不加密么？若是加密用什么加密等。这些东西都会在具体应用场景中再说明。

既然明白了CA那么咱们就说一下PKI。

PKI

公钥基础设施，以CA为中心所生成的一套体系就是PKI。它有四个重要组件：

• 签证机构，就是CA，这个是负责生成证书的

• 注册机构，就是RA，这个是负责接收证书申请的

• 证书吊销列表，就是CRL，这个是标记哪些证书已经不可用或者不可信了，至关于证书黑名单，这里的证书都不能被信任了。

• 证书存取库，就是CB，这里存放的是CA发的证书能够供其余人下载和使用

证书经常使用字段和格式

首先要说一下X.509，它就是证书标准，也叫作证书格式。全部证书都要符合这个标准，它定义了证书中包含那些内容。好比版本号、序列号（CA发的第几个证书）、签名算法ID（这个证书用什么算法作的签名）、CA颁发机构名称、证书有效期、申请者名称、申请者公钥、CA颁发机构的惟一标识、申请者的惟一标识、CA对该证书的签名（用CA本身的私钥对全部信息的摘要作签名）等扩展信息。下面就看看证书中常见的字段：

字段	含义
Common Name	简称CN，对于SSL证书来讲通常为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端证书来讲则是申请者名称也能够当作用户帐号名称
Organization Name	简称O，对于SSL证书来讲通常为网站域名；而对于代码签名证书则为申请单位名称；而对于客户端证书来讲则是申请者名称也可当作用户帐号所属的组
Locality	简称L，表示城市
State/Provice	简称ST，表示省份
Country	简称C，表示国家，好比中国为CN，美国为US

浏览器使用HTTPS访问时它是怎么检查证书和地址栏中的名称呢？有下面三种方式

1. 主机名（地址栏中的域名）与证书Subject中的CN字段彻底匹配
2. 主机名称与通配符通用名称相匹配，好比www.abc.com匹配通用名称*.abc.co
3. 主机名在主题备用名称（Subject Alternative Name检查sans）字段中列出

咱们知道了X.509是证书格式，但是不少时候看到的.pem、.key都什么呢？，这里就要作一些区分，证书编码格式和证书扩展名。

证书编码格式

全部的证书都是经过X.509标准生成的证书，可是有2中编码格式：

• PEM（Privacy Enhanced Mail），它是基于X.509标准生成的，文件可读能够直接打开查看，它是以"-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----"开头和结尾且用Base64编码的证书，这种编码格式的证书一般是.pem扩展名。

  使用命令 openssl x509 -in XXX.pem -text -noout 来查看证书内容。

• DER（Distinguished Encoding Rules），二进制格式的，没法直接读取。

  使用命令 openssl x509 -in XXX.der -inform der -noout 来查看证书内容。

证书扩展名

虽然证书编码格式有2种，可是扩展名有不少：

扩展名	说明
.der	用于DER编码的证书
.pem	它是基于X.509标准生成的，它是以"-----BEGIN CERTIFICATE-----" 和 "-----END CERTIFICATE-----"开头和结尾且用Base64编码的证书
.crt	这种扩展名的证书能够是DER编码也能够是PEM编码，在Unix系统中常见。
.cer	微软系统常见，在微软系统中能够将.crt转换为.cer。一样能够是DER编码也能够是PEM编码。
.key	用于存储公钥和私钥，一样可使用DER或者PEM编码。
.csr	这个不是证书文件，而是证书签名请求文件，向CA申请得到签名证书时须要提供的申请文件。

HTTPS通讯过程

双向认证

上图为SSL的双向验证过程

1. 浏览器发起https请求，生成随机数（用于稍后生成会话秘钥），并发送client_hello信息里面将本身支持的加密协议版本、加密算法、压缩算法和生成的随机数发送给服务端。
2. 服务端收到信息之后，也生成随机数（用于稍后生成会话秘钥），并发送server_hello信确认本身客户端发送来的协议版本、算法等。若是不支持那么就没法通讯了。
3. 服务端发送服务器证书给客户端，而且要求客户端也发送证书过来
4. 客户端检查服务端证书合法性和有效性，经过之后，发送客户端证书给服务端
5. 服务器检查客户端的证书合法
6. 客户端把全部以前收到的信息作HASH，而后使用本身私钥作签名，发送给服务器端
7. 服务端检查哈希值和签名
8. 客户端使用对称加密算法生成一个加密密码，而后使用客户端公钥进行加密发送给服务端
9. 服务端收到之后就可使用对称加密密码和客户端通讯
10. 断开链接

单向认证

HTTPS访问一般使用单向认证，好比你访问百度、淘宝、京东等虽然是https通讯可是它们不会去验证客户端证书，客户端只会去验证服务端证书。为何呢？由于证书花钱啊，哪一个网站要是须要作客户端证书认证那么估计就没有人去访问了，再有对于服务端来讲它不在意你是谁来的人越多越好。固然也有通讯双方要求作双向认证的好比登陆网银的U盾就是客户端证书。

1. 浏览器发起https请求，生成随机数将本身支持的一套加密规则、协议版本发送给服务端。
2. 服务端从中选出一组加密算法与HASH算法，服务端也生成一个随机数并将本身的身份信息以证书的形式发回给浏览器。证书里面包含了服务端地址，加密公钥，以及证书的颁发机构等信息。
3. 客户端得到服务端证书以后浏览器要作如下工做：（验证我访问的www.abc.com是否是真正的那个www.abc.com，这个验证过程就经过服务端证书和本身的CA根证书来完成）

   • 验证证书的合法性和有效性（使用客户端保存的CA根证书的公钥解密服务端发来的证书的签名，解密成功说明服务端证书能够信任，而后使用HASH算法计算证书摘要而后对比解密签名后获得的摘要，若是一致则说明内容没有篡改，而后 检查证书中的其余信息，能够检查证书中的域名和我访问的域名是否一致 （这里防止钓鱼网站）、检查是否过时、检查是否被吊销等，若是检查都经过则证书受信任，则浏览器栏里面会显示一个小锁头，不然会给出证书不受信的提示。

   • 若是证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数，而后把随机数、编码变动通知（表示随后的通讯都使用双方商定的协议版本以及加密算法）和客户端握手结束通知发送给服务器

4. 服务端接收浏览器发来的数据以后要作如下的操做：

   • 这时候服务端会有3个随机数，2个是客户端发来的，一个是服务端本身产生的，用着三个随机数并结合对称加密算法生成“会话密码”

   • 生成编码变动通知、服务端握手结束通知

   • 使用商定好的HASH算法对会话密码、编码变动通知、握手结束通知计算摘要，而后使用本身的私钥进行对摘要进行签名，最后使用客户端公钥加密信息并发送给客户端

5. 浏览器解密，而后获得消息的HASH，若是与服务端发来的HASH一致，此时握手过程结束，以后全部的通讯数据都使用获得的“会话密码” 加密。

这里为何在认证经过后的数据传输使用认证过程产生的随机密码呢？这是由于使用对称加密解密性能要比非对称的高，尤为是对服务端的CPU压力比较小，可是若是使用一个长期固定的对称密码就很不安全而随机生成的就会有一个如何告诉通讯双方且传递过程当中不被窃取的问题因此就使用非对称加密方式这样不但保证了随机密码的安全同时也能够验证服务端身份的真实性。

为何会产生这么多随机数呢？为了不计算机上产生的随机数不是真的随机数，因此双方都产生随机数而后使用你们的随机数来生成密码。