文章转载出自：https://blog.51cto.com/11883699/2160032

安全的获取公钥

细心的人可能已经注意到了如果使用非对称加密算法，我们的客户端A，B需要一开始就持有公钥，要不没法开展加密行为啊。

这下，我们又遇到新问题了，如何让A、B客户端安全地得到公钥？

client获取公钥最最直接的方法是服务器端server将公钥发送给每一个client用户，但这个时候就出现了公钥被劫持的问题，如上图，client请求公钥，在请求返回的过程中被×××劫持，那么我们将采用劫持后的假秘钥进行通信，则后续的通讯过程都是采用假秘钥进行，数据库的风险仍然存在。在获取公钥的过程中，我们又引出了一个新的话题：如何安全的获取公钥，并确保公钥的获取是安全的， 那就需要用到终极武器了：SSL 证书（需要购买）和CA机构

如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性

 

以浏览器为例说明如下整个的校验过程：

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出  颁发者CA  的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥，用于后续加密了

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，

但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，

然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，

所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。

这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。

从而解决了客户端与服务器端之间的通信安全问题。

阿里云现提供4家主流的国际认证机构，其实通过阿里云进行证书的申请，可以理解为由阿里云代理，帮你申请证书。对于证书有单一域名和通配符域名证书，顾名思义，单一域名的证书，获取的证书只能验证指定的一个域名的安全性，但通配符域名（如*.aa.com）所有的以*.aa.com开始的域名都可以识别，当然这里面涉及到DV SSL 、 OV SSL 、EV SSL的概念，因为在买之前一定要知道这个概念的意义，否则钱花的会不知所然。

DV SSL

DV SSL证书是只验证网站域名所有权的简易型（Class 1级）SSL证书，可10分钟快速颁发，能起到加密传输的作用，但无法向用户证明网站的真实身份。

目前市面上的免费证书都是这个类型的，只是提供了对数据的加密，但是对提供证书的个人和机构的身份不做验证。

OV SSL

OV SSL,提供加密功能,对申请者做严格的身份审核验证,提供可信×××明。

和DV SSL的区别在于，OV SSL 提供了对个人或者机构的审核，能确认对方的身份，安全性更高。

所以这部分的证书申请是收费的~

EV SSL

超安=EV=最安全、最严格 超安EV SSL证书遵循全球统一的严格身份验证标准，是目前业界安全级别最高的* (Class 4级)SSL证书。

金融证券、银行、第三方支付、网上商城等，重点强调网站安全、企业可信形象的网站，涉及交易支付、客户隐私信息和账号密码的传输。

这部分的验证要求最高，申请费用也是最贵的。

根据保护域名的数量需求，SSL证书又分为：

单域名版：只保护一个域名，例如 www.abc.com 或者 login.abc.com 之类的单个域名

多域名版：一张证书可以保护多个域名，例如同时保护 www.abc.com , www.bcd.com, pay.efg.com 等

通配符版：一张证书保护同一个主域名下同一级的所有子域名，不限个数，形如 *.abc.com 。注意，通配符版只有 DVSSL 和 OVSSL 具有， EVSSL 不具有通配符版本。

转载来自：https://mp.weixin.qq.com/s/he2TtquMS7qW3kJEvszyug

今天和大家聊一聊HTTPS的东西。因为HTTP协议本身存在着明文传输、不能很好的验证通信方的身份和无法验证报文的完整性等一些安全方面的缺点，所以才有了HTTPS。HTTPS确切的说不是一种协议，而是HTTP + SSL (TSL)的结合体。HTTP报文经过SSL层加密后交付给TCP层进行传输。SSL(安全套节层)主要采取的是RSA（非对称加密）与AES（对称加密）结合的加密方式。先通过RSA交互AES的密钥，然后通过AES进行报文加密和解密。本篇博客主要聊的就是HTTPS具体的工作过程。

RSA与AES简述

在本篇博客的第一部分呢，先聊一下RSA与AES这两个加密策略，如果你在公司做过支付相关的东西，对数据传输的安全性要求比较高，这时候就得采取一些加密措施将传输的报文进行加密，必要时再进行MD5验签。当然本部分聊的RAS与AES是比较简洁的，关于这两者具体的内容，请自行Google吧。因为HTTPS在传输的过程中使用到了RSA与AES加密算法，所以在聊HTTP+SSL之前呢，我们先简单的聊一下AES与RSA。

Advanced Encryption Standard （AES: 高级加密标准）

AES，全称：Advanced Encryption Standard----高级加密标准。该加密算法有一个密钥，该密钥可以用来加密，也可以用来解密，所以AES是对称加密算法。下方这个就是AES加密和解密的过程。Client端与Server端有一个共同的Key, 这个Key是用来加密和解密的。如果报文在传输的过程中被窃取了，没有这个key, 对加密的内容进行破解是非常困难的，当然窃取者如果有key的话，也是可以轻而易举的解密的。所以在AES中，key是关键。这也就相当于你们家的门钥匙，谁拿到钥匙后都可以打开你们家的门。即使门锁再结实，再安全，在钥匙面前也是不行呢。

所以对于AES加密策略来说这个Key的保密措施要做足一些，如果之后有时间的话可以分享一些具体的AES加密策略。比如每次加密的Key都是从一个密码本中动态生成的，而这个密码本服务端和客户端都有同一本，每次传输的是一些参数。这些参数在经过一些算法的映射，从密码本中取出相应的key用来解密。这样一来，就相当于给AES加了一层防盗门，加大了破解的难度。这样做的好处是每次加密的key都是不同的，而且需要密码本以及映射算法的支持。

RSA 公钥加密算法

RSA这个名字，就是该算法三位发明者的名字的首字母的组合。RAS是非对称加密，其在加密和解密的过程中，需要两个Key，一个公钥（public key），一个是私钥（private key）。公钥负责加密，而私钥负责解密。从名字就可以看出，公钥是可以开放出去的，任何人都可以持有公钥进行加密。而私钥必须得进行保护，因为是用来解密的。

这样一来，加密和解密就可以用不同的钥匙来处理。对于加密方来说，即使你可以对报文进行加密，如果没有私钥的话也是不可以对你加密的内容进行解密的。这就相当于一个盒子，盒子上有把锁。你可以把东西放进去，然后再锁上盒子。但是如果你没有钥匙的话，也是打不开这把锁的。

下方这个简图就是服务端单向验证的RSA非对称加密算法，Client内置了一个公钥，该公钥与Server端的私钥是配对的，所以Client端可以使用这个内置的Public key加密，而服务端就可以使用这个private key进行解密。目前最常用的是服务端单向认证机制。

CA证书

如果你自己通过RSA算法生成了一个私钥和公钥，在公钥发送给客户端的过程中有可能被篡改成其他的公钥，而客户端在没有其他措施的保护下是不知道该公钥是否就是服务器那边的私钥对应的公钥的。这种自己做的RAS的公钥和私钥有可能在公钥分发的过程中被篡改。下方就是Client从Server端获取公钥时被中间者篡改了，将public换成了自己的伪public key, 同样这个中间者持有这个伪public key所对应的伪private key。如果客户端使用的伪public key进行加密传输的话，那么中间者是可以使用自己的private key进行解密的。

举个例子来类比一下这个问题。

假设你在古代，你出门在外，妻子在家养子。你们家有个箱子，箱子上有把锁，这就是你和你妻子互通的工具。你媳妇儿负责往箱子里放东西，然后上锁。你有把独特的钥匙，你负责开锁，取东西。可是你再将箱子给镖局托运的的过程中，被镖局的“小黑”掉包了，箱子的外表一致，锁看起来也一样，可是已经不是你的箱子了。因为路途遥远，古代又没有什么iPhone啥的，你媳妇没办法来辨别该箱子是否是原装的。然后就将一些东西放在了箱子里边，然后上锁交给了镖局的“小黑”。

因为“小黑”掉包的箱子，所以小黑有箱子的钥匙呢，然后就可以打开这个箱子，取东西了。原来的箱子又在小黑那，小黑就可以往原来的箱子里边随便往箱子放点没有价值的东西给你就行了。当你发现箱子里的东西不是你想要的时候，完了，小黑从镖局辞职了，找不到人了。找镖局的人讨说法，可是镖局的人说“小黑”是镖局的临时工，这个责任镖局说了，我们不能担。鉴于你无权无势，这事儿也就此罢了。（故事纯属虚构，如有雷同纯属巧合）

关于更多骗子的故事请移步网络剧《毛骗》一二三季。

为了防止“小黑”再次作案，所以颁布一个公正机构来证明你媳妇收到的箱子就是你发出的箱子。在RAS加密中也有一个第三方机构来充当这个角色，负责证明客户端收到的证书就是你发送的证书，中间没有被篡改。这个中间认证机构，就是数组证书认证机构, 其颁发的证书也就是我们常说的CA证书（CA , Certificate Authority）。

下面我们就来详细的叙述一下证书签名，证书分发以及证书验证的整个过程。

• 1、服务端人员使用RSA算法生成两个密钥，一个用来加密一个用来解密。将负责加密的那个密钥公布出去，所以我们称之为公钥（Public Key），而用来解密的那个密钥，不能对外公布，只有服务端持有，所以我们称之为私钥（Private Key）。服务端在将Public Key进行分发证书之前需要向CA机构申请给将要分发的公钥进行数字签名。（服务器公钥负责加密，服务器私钥负责解密）

• 2、生成数字签名公钥证书：对于CA机构来说，其也有两个密钥，我们暂且称之为CA私钥和CA公钥。CA机构将服务端的Public Key作为输入参数将其转换为一个特有的Hash值。然后使用CA私钥将这个Hash值进行加密处理，并与服务端的Public Key绑定在一起，生成数字签名证书。其实数字签名证书的本质就是服务端的公钥+CA私钥加密的Hash值。（CA私钥负责签名，CA公钥负责验证）

• 3、服务器获取到这个已经含有数字签名并带有公钥的证书，将该证书发送给客户端。当客户端收到该公钥数字证书后，会验证其有效性。大部分客户端都会预装CA机构的公钥，也就是CA公钥。客户端使用CA公钥对数字证书上的签名进行验证，这个验证的过程就是使用CA公钥对CA私钥加密的内容进行解密，将解密后的内容与服务端的Public Key所生成的Hash值进行匹配，如果匹配成功，则说明该证书就是相应的服务端发过来的。否则就是非法证书。

• 4、验证完服务端公钥的合法性后，就可以使用该公钥进行加密通信了。

下方这个截图就是苹果的根证书的一些信息，从下方可以看出，CA证书内容中包括加密算法，公共密钥以及数字签名。

下方就是公钥以及数字签名的具体内容，当对下方公共密钥进行验证时，需要使用内置的CA公钥将数字签名进行解密。然后将解密后的内容，与公钥生成的Hash值进行比较，如果匹配成功，那么该证书就是CA机构颁布的合法证书。

HTTPS安全通信机制的建立

上面我们聊完AES与RSA加密策略，然后又聊了带有数字签名的公共密钥。上面这两部分内容都是为HTTPS做铺垫的，接下来就看一看HTTP+SSL是如何进行数据传输的。

HTTPS简介

在开头的部分也说了，HTTPS不是一个新的通信协议，而是HTTP与SSL（或TSL）的组合。SSL--安全套节层(Secure Socket Layer), TSL（Transport Layer Security 安全传输层）是以SSL为原型开发的协议，IETF以SSL3.0为基准后又制定了TLS1.0、TLS1.1和TLS1.2，当前主流版本为SSL3.0与TLS1.0。

HTTPS就是在HTTP与TCP层中间添加了一个SSL层。因为HTTPS被HTTP多了这层加密的流程，所以HTTPS的速度要比HTTP慢的多。

HTTPS的通信过程

SSL的加密过程是RSA与AES混合进行的。简单概括一下，就是通过RSA加密方式来交换AES加解密的密钥，然后使用AES加密的方式来传输报文。下方是SSL建立连接以及传输数据的图解。在下图中大体可以分为四步：

• 第一步：有客户端发起的第一次握手，此次握手过程的主要目的是从服务端获取数字签名证书，服务端在发送数字签名证书之前要先确认客户端的SSL版本、加密算法等信息。

• 第二步：完成第一次握手后，接着进行第二次握手。第二次握手是在客户端收到证书后发起的，主要目的是将AES加解密使用的Key （Pre-master secret）发送给服务端。当然这个AESKEY是使用第一次握手获取的公钥进行加密的。客户端收到这个使用公钥加密后的AESKEY，使用服务端的私钥进行解密。这样客户端和服务端经过二次握手后都持有了AES加解密的KEY。

• 第三步：当Client与Server端都持有AES_KEY后，就可以对HTTP报文进行加解密了。

• END: 最后就是断开连接了。具体如下图所示：