科普扫盲帖

HTTPS科普扫盲帖

文/程卡带

为什么需要https

HTTP是明文传输的，也就是说发送方和接收方之间的任何节点都可以知道你在传输什么。这些节点可以是路由器、代理等。

举个最常见的例子，用户登录。输入用户的帐号和密码。如果你使用HTTP，你只需要在代理服务器上做一些事情就可以得到你的密码。

用户登录-->:代理服务器(篡改)->:实际授权服务器

在发送方加密密码？没用的。虽然别人不知道你原来的密码是什么，但是如果你能拿到加密的账号密码，你还是可以登录的。

HTTPS是如何获得

其实httpS的意思是安全http，是HTTP的安全升级版。稍微有点网络基础的同学都知道，HTTP是应用层协议，TCP是HTTP下面的传输协议。TCP负责传输，而HTTP定义了数据的封装方式。

HTTP->；TCP(明文传输)

HTTPS和HTTP的区别是什么？实际上，在HTTP和TCP之间增加了一个额外的加密层TLS/SSL。

什么是TLS/SSL？

总的来说，TLS和SSL是差不多的东西。SSL是一个加密套件，负责加密HTTP数据。是TLS的升级版本。现在谈到HTTPS，加密套件基本上是指TLS。

传输加密过程

原来是应用层直接把数据发给TCP进行传输，现在改成应用层把数据发给TLS/SSL，加密数据，再发给TCP进行传输。

大致如图所示。

事情就是这样。将数据加密后再传输，而不是让数据在复杂危险的网络中裸奔，很大程度上保证了数据的安全性。这样，即使数据被中间节点截获，坏人也无法理解。

HTTPS如何加密数据

了解安全或密码学基础的同学，应该知道常用的加密方法。一般来说，加密分为对称加密和非对称加密(也叫公钥加密)。

对称加密

对称加密意味着用于加密数据的密钥与用于解密数据的密钥相同。

对称加密的优点是加密和解密的效率通常很高。缺点是数据发送方和数据接收方需要协商共享同一个密钥，并保证密钥不被泄露给他人。另外，对于多个有数据交换需求的个体来说，需要在对之间分发和维护一个密钥，这样带来的成本基本上是无法接受的。

非对称加密

非对称加密是指用于加密数据的密钥(公钥)不同于用于解密数据的密钥(私钥)。

什么是公钥？实际上，它的字面意思是——公钥可以被任何人找到。所以非对称加密也叫公钥加密。

相应的，私钥是非公钥，一般由网站的管理员持有。

公钥和私钥是什么关系？

简单来说，用公钥加密的数据只能用私钥解密。用私钥加密的数据只能用公钥解密。

很多同学都知道用公钥加密的数据可以用私钥解密，但是他们忽略了用私钥加密的数据也可以用公钥解密。这对于理解HTTPS完整的加密和授权系统是至关重要的。

举一个不对称加密的例子

登录用户:小明

授权网站:某知名社交网站(以下简称XX)

小明是某知名社交网站XX的用户，XX出于安全考虑，在他登录的地方使用了非对称加密。小明在登录界面输入自己的账号和密码，然后点击“登录”。于是，浏览器用公钥加密小明的账号密码，向XX发送登录请求。XX的登录授权程序通过私钥解密账号和密码，验证通过。之后小明的个人信息(包括隐私)被私钥加密，传回浏览器。通过浏览器的公钥解密数据，给小明看。

第一步:小明输入账号密码-->:用浏览器公钥加密-->向XX发送请求

第二步:XX用私钥解密，验证通过-->获取小明的社交数据，用私钥加密-->用浏览器的公钥解密数据，展示。

非对称加密能否解决数据传输安全问题？特别强调了公钥可以解开私钥加密的数据，公钥是加密的。换句话说，非对称加密只能保证单向数据传输的安全性。

此外，还有如何分发/获取公钥的问题。这两个问题将在下面进一步讨论。

公钥加密:两个明显的问题

举了小明登录社交网站XX的例子，提到只使用公钥加密有两个明显的问题。

如何获取公钥？

数据传输只是单向安全的。

问题1:如何获得公钥

浏览器是怎么得到XX的公钥的？当然，小明灿自己在网上查，XX也可以把公钥贴在自己主页上。但对于一个成败永远在千万的社交网站来说，会给用户造成极大的不便。毕竟大部分用户都不知道什么是“公钥”。

问题二:数据传输只是单向安全的

如前所述，只有私钥才能解锁公钥加密的数据，所以小明的账号和密码是安全的，不怕被中途拦截。

那么就有一个很大的问题:用私钥加密的数据也可以用公钥解密。再加上公钥是公开的，小明的私密数据相当于换了一种方式在网上裸奔。(中间代理服务器拿到公钥后，可以毫不犹豫的解密小明的数据)

以下分别是对这两个问题的回答。

问题1:如何获得公钥

这里涉及到两个非常重要的概念:证书和CA(CertificateAuthority)。

证书

你可以暂时理解为网站的身份z。这张身份z包含了很多信息，包括上面提到的公钥。

也就是说，当小明、小王、小光等用户访问XX时，再也不用满世界寻找XX的公钥了。当他们访问XX时，XX会将证书发送到浏览器，并告诉他们:“要乖，用这里面的公钥加密数据。”

这里有个问题。所谓的“证书”从何而来？这就是下面提到的CA负责的工作。

CA(证书颁发机构)

强调两点:

可以颁发证书的ca有很多(国内外都有)。

只有少数ca被认为是权威和公正的，这些ca颁发的证书被浏览器认为是可信的。比如威瑞信。(并不是CA伪造了自己的证书。。。)

这里不讨论证书颁发的细节。可以简单理解为网站向CA提交申请，CA审核通过后，给网站颁发证书。当用户访问网站时，网站会将证书交给用户。

至于证书的细节，我们后面也会讲到。

问题二:数据传输只是单向安全的

如上所述，用私钥加密的数据可以用公钥解密和恢复。那么，这是否意味着网站传输给用户的数据是不安全的呢？

回答:可以！！！(三个感叹号表示强调的三次方)

看到这里，你心里可能会有这样的想法:有了HTTPS，数据还在裸奔，这么不靠谱，还不如直接用HTTP省事。

然而，为什么业界对网站HTTPS的呼声越来越高？这显然违背了我们的感性认识。

因为:HTTPS虽然使用公钥加密，但是也结合了其他手段，比如对称加密，来保证授权和加密传输的效率和安全性。

总之，整个简化的加密通信过程是:

小明访问XX，XX把自己的证书给了小明(其实是给浏览器的，小明不会有感觉)

浏览器从证书中获取XX的公钥A。

浏览器生成自己的对称密钥B，用公钥A加密，发送给XX(实际上有一个协商过程，这里为了便于理解简化了)

XX用私钥解密得到对称密钥b。

浏览器和XX后的数据通信用密钥b加密。

注意:对于每个访问XX的用户，生成的对称密钥B理论上是不同的。例如，小明、小王和小光可以生成B1、B2和B3。

参考下图:(附上原图出处)

证书可能有哪些问题

了解了HTTPS加密通信的流程后，关于数据裸奔的疑虑应该基本打消了。但是，细心的观众可能会有另一个疑问:如何保证证书合法有效？

可能有两种证书不合法的情况:

证书是伪造的:它根本不是由CA颁发的。

证书被篡改:比如XX网站的公钥被替换。

例如:

我们知道这个世界上有一种东西叫代理，所以小明登录XX网站可能是这样的。小明的登录请求首先到达代理服务器，然后代理服务器将请求转发给授权服务器。

小明->；邪恶代理服务器->:登录授权服务器

小明

然后，世界上坏人太多了。有一天，代理服务器出了个馊主意(也可能是被入侵了)，拦截了小明的请求。同时，退回了一份非法证书。

小明->；邪恶代理服务器-x-->:登录授权服务器

小明:登录授权服务器

如果善良的小明相信这个证明，他会再裸奔一次。当然不是。那么，用什么机制来阻止这类东西的发布呢？

现在，我们先来看看“证明”的内容，然后就可以大致猜出如何防范了。

证书简介

在正式介绍证书的格式之前，先在科普下插播一个小广告，数字签名，摘要，然后对证书做一个不深入的介绍。

为什么？因为数字签名和摘要是证书防伪的关键武器。

数字签名和摘要

简单来说，“摘要”就是通过哈希算法计算出传输内容的固定长度字符串(无论是否与文章摘要关联)。然后，用CA的私钥对这个摘要进行加密，加密的结果就是“数字签名”。(这里提到的是CA的私钥，后面会介绍)

明文->:哈希运算->:摘要->:私钥加密->:数字签名

结合以上，我们知道这个数字签名只能用CA的公钥解密。

接下来，我们来看看神秘的“证书”究竟包含了什么，然后大致猜测一下如何防范非法证书。

请参考这篇文章，进一步了解数字签名和摘要。

证书格式

先恬不知耻地粘贴一大段内容，证书格式来自这篇好文章《OpenSSL和SSL数字证书的概念粘贴》

内容很多，这里需要注意几点:

证书包含颁发机构CA的名称。

证书内容本身的数字签名(用CA私钥加密)

证书持有人的公钥

证书签名中使用的哈希算法

另外，有一点需要补充，那就是:

CA有自己的证书，江湖人称之为“根证书”。这个“根证书”用来证明CA的身份，其本质是一个普通的数字证书。

浏览器通常内置了大多数主流权威ca的根证书。

证书格式

1.证书版本号(Version)版本号指明X.509证书的格式版本，现在的值可以为:1)0:v12)1:v23)2:v3也为将来的版本进行了预定义2.证书序列号(SerialNumber)序列号指定由CA分配给证书的唯一的"数字型标识符"。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中，这也是序列号唯一的原因。3.签名算法标识符(SignatureAlgorithm)签名算法标识用来指定由CA签发证书时所使用的"签名算法"。算法标识符用来指定CA签发证书时所使用的:1)公开密钥算法2)hash算法example:sha256WithRSAEncryption须向国际知名标准组织(如ISO)注册4.签发机构名(Issuer)此域用来标识签发证书的CA的X.500DN(DN-DistinguishedName)名字。包括:1)国家(C)2)省市(ST)3)地区(L)4)组织机构(O)5)单位部门(OU)6)通用名(CN)7)邮箱地址5.有效期(Validity)指定证书的有效期，包括:1)证书开始生效的日期时间2)证书失效的日期和时间每次使用证书时，需要检查证书是否在有效期内。6.证书用户名(Subject)指定证书持有者的X.500唯一名字。包括:1)国家(C)2)省市(ST)3)地区(L)4)组织机构(O)5)单位部门(OU)6)通用名(CN)7)邮箱地址7.证书持有者公开密钥信息(SubjectPublicKeyInfo)证书持有者公开密钥信息域包含两个重要信息:1)证书持有者的公开密钥的值2)公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。8.扩展项(extension)X.509V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指由X.509V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。9.签发者唯一标识符(IssuerUniqueIdentifier)签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串来唯一标识签发者的X.500名字。可选。10.证书持有者唯一标识符(SubjectUniqueIdentifier)持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时，用一比特字符串来唯一标识证书持有者的X.500名字。可选。11.签名算法(SignatureAlgorithm)证书签发机构对证书上述内容的签名算法example:sha256WithRSAEncryption12.签名值(Issuer'sSignature)证书签发机构对证书上述内容的签名值

如何识别非法证书

如上所述，XX证书包含以下内容:

证书包含颁发机构CA的名称。

证书内容本身的数字签名(用CA私钥加密)

证书持有人的公钥

证书签名中使用的哈希算法

浏览器内置的CA的根证书包含以下关键内容:

CA的公钥(非常重要！！！)

好了，下面来说明一下前面说的两个非法证明是怎么识别的。

完全伪造的证书

这种情况比较简单。检查证书:

证书颁发机构是伪造的:浏览器不知道，直接认为是危险证书。

证书颁发机构确实存在，所以根据CA名称，找到对应的内置CA根证书和CA公钥。

用CA的公钥解密伪造证书的摘要，发现无法解决。认为这是一个危险的证书

被篡改的证书

假设代理通过某种方式得到XX的证书，然后偷偷把证书的公钥修改成自己的，然后认为用户要上钩了。然而，这太简单了:

检查证书，根据CA名称找到对应的CA根证书和CA公钥。

用CA的公钥解密证书的数字签名，获得相应的证书摘要AA。

根据证书签名使用的哈希算法，计算当前证书的摘要BB。

对比AA和BB，发现两者不一致->:是危险证书。

HTTPS握手过程

上面有个长篇大论。HTTPS基本上涵盖了如何保证数据加密和传输安全的机制。如果太专业，直接跳过。

还有最后两个问题:

网站如何把证书给用户(浏览器)

上面提到的对称密钥是怎么协商出来的？

以上两个问题实际上是HTTPS握手阶段要做的事情。HTTPS的数据传输过程整体上和HTTP类似，也包括握手和数据传输两个阶段。

握手:证书颁发、密钥协商(此阶段为明文)

数据传输:这个阶段是加密的，使用握手阶段协商的对称密钥。

阮的文章很好，通俗易懂。有兴趣的同学可以看看。

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

写在后面

科普文章，有些不够严谨。如有错误或遗漏，请指出:)