进阶|15分钟轻松理解HTTPS

前端爱好者的知识盛宴

嗨

这里是IMWEB

一个想为更多的前端人

享知识 

助发展

觅福利

有情怀有情调的公众号

欢迎关注转发

让更多的前端技友一起学习发展~

导语

它很深奥吗？你肯定常常见过它，使用它，甚至离不开它... 它很浅显吗？你可能觉得看透它，理解它，甚至懂它... 让我们用15分钟，不那么学术地将它的深挖到底~

举

    栗

    子

什么？如何证明我是我？本文要上升到这样的哲学高度了吗？吓得作者笔都掉了，不，是键盘按键都飞出来了… HTTPS的身份认证机制还真的是一个“如何证明我是我”的问题，并且巧妙地使用了“零知识证明”。

先来看个故事吧！

我知道某带密码门锁房间的密码，如何证明我有这个密码呢？下面有两种方式：

①我把密码告诉你，你用密码打开该房间的锁。

②我们都知道房间内有某一物体，我用密码打开房间的门，然后把物体拿出来给你看。

方式①的结果是密码泄漏了，如果换作二战被俘的情报员或者被四十大盗劫持的阿里巴巴身上，他们的结局一定是被无情杀害了。

方式②是零知识证明。它指的是证明者能够在不向验证者提供任何有用的信息的情况下，使验证者相信某个论断是正确的。

那下面我们来挖一挖HTTPS如何借鉴这种思想进行身份认证的。不过，先来看一眼目录吧！没有目录的长文都是耍流氓…

目录

1.HTTPS原理概述

        1.1什么是HTTPS？

        1.2HTTPS保证安全通信的原理

        （加密|签名|证书）

        1.3一次完整的HTTPS过程

2.HTTPS实践与应用

        2.1从HTTP升级到HTTPS

        2.2Fiddler抓包HTTPS

        2.3局限性和使用场景

正文

01

 part1.HTTPS原理概述

1.1什么是HTTPS？

一句话：超文本传输安全协议（Hypertext Transfer Protocol Secure, HTTP）是在应用层和传输层中间多了安全层的HTTP协议。

安全层协议是SSL或者TLS。

为什么要有HTTPS呢？

因为HTTP通信是明文传输，有以下风险，而HTTPS完美地解决了这些风险。

1.2HTTPS保证安全通信的原理

（一）加密——防窃听

举一个最简单的加密，abc->bcd。其中：

1.加密函数f：将加密过程抽象成函数。

2.密钥： f(n)中的参数n。上例中n=1。

3.对称加密：加密和解密的密钥相同。计算量小，速度快。

4.非对称加密：加密和解密的密钥不同，一般地，服务器方存有私钥不外传，而把对应公钥开放给客户端。客户端用公钥加密内容，服务器用私钥解密。计算量大，速度慢。

HTTPS的真正加密过程是：用非对称加密方式协商对称密钥；通信时使用协商好的对称密钥。这段话在看完1.3会更加清晰明了。

对称加密非常好理解。HTTPS关键技术之一的非对称加密是如何实现的呢？以比较具有代表性的RSA算法为例，解剖下非对称加密实现原理：

首先，存在这样一个事实（1）。其次，非对称加密是公钥私钥计算过程大致如（2）所述。然后，（3）利用两个式子可以进行加密和解密。

那么，RSA实现非对称加密的原理问题，可以简化为（3）中两个式子的m是否相等。将(1)中的等式带入（3）中公式，加以不长不短的数学证明，结果显示两式相等。Done! 总结来说，RSA的实现基于的是数学世界中存在的两个质数之间不对称关系。（文末附有证明的参考资料）

(1)两个互质数之间存在一个等式

      如果两个正整数a和n互质，那么一定可以找到整数b，使得 ab-1 被n整除，或者说ab被n除的余数是1。这时，b就叫做a的“模反元素”。这个等式可以由“欧拉定理”证明。

(2)利用这两个互质数产生一对公钥私钥

(3)加密和解密

  加密：m是要加密信息，用(n,e)计算出加密后信息c。  

  解密：用(n,d)计算出原始信息m。                      

（二）签名——防篡改

签名如何证明信息没有被纂改？举个栗子：

开发gg小猴很帅，到处发自己的公钥给妹子。

有一天，他中意一个妹子，想私下给妹子加密写信。

为了防止信被他的好哥们乱改，他这样做的：

把信的内容哈希得到摘要，摘要进行私钥加密得到签名，签名附到信后面。

妹子收到了信，熟练地把信内容哈希得到摘要，把签名公钥解密得到摘要，对比两个摘要相同，相信了这信没被别人纂改过。

防止篡改的原理就是，外人只改动内容会对不上签名中的摘要，而签名又是加密过的无法和内容修改的一致。

1.3一次完整的HTTPS过程

整体流程：

         1.客户端向服务器索要公钥，并验证

         2.双方协商生成对话密钥（对称加密）

         3.采用对称加密通信

步骤1和2称为握手过程。握手的详细过程如下图所示：

（三）证书——防冒充

 可惜，妹子还是套路不够深….

小猴的哥们小猪也喜欢这个妹子，不敢表白，偷偷冒充了小猴。

他盗用小猴电脑，把小猴公钥换成自己公钥，用自己的私钥给妹子写信。

妹子以为自己拿着小猴的公钥，验证了信没被纂改过。

而实际上这公钥是小猪的，信也是小猪写的。

要避免这样的悲剧，“数字证书”就出场了。

既然无法确信“小猴的公钥是小猴的“，那只好找权威机构帮忙认证了。

小猴去证书中心(CA)申请证书，CA用自己的私钥对小猴的公钥和相关信息一起加密，生成“数字证书“。小猴再写信时，附上签名和证书。

妹子收到信，用CA的公钥(这个不好冒充)解密证书，确信得到的是小猴的公钥了。

再来看开始提到的零知识证明。

它的一个应用是Guillo-Ouisquater身份认证，这种认证方式主要基于了RSA公钥算法的基本思想。

换句话说，前述的签名和证书的身份认证属于零知识证明的应用。

过程需要一个权威CA，认证可靠，并没有提供任何有用信息，也不会因认证次数增加而安全性降低。

1.3一次完整的HTTPS过程

整体流程：

         1.客户端向服务器索要公钥，并验证

         2.双方协商生成对话密钥（对称加密）

         3.采用对称加密通信

步骤1和2称为握手过程。握手的详细过程如下图所示：

验证证书时，浏览器一般存有大型可信CA的公钥。验证证书是否为真，是否过期等。

如验证不通过，浏览器会显示警告，用户可以选择继续访问。

当最后一次握手结束后，客户端和服务都有了随机数①②③，用它们三个形成相同的对称密钥，用于接下来通信。回过头来再看这句话，是不是更清晰了？HTTPS的真正加密过程是：用非对称加密方式协商对称密钥；通信时使用协商好的对称密钥

Session恢复

如果出于某种原因，对话中断，就需要恢复对话。简单介绍两种Session恢复的方式：

Session ID：session ID保存在一台服务器中，如果客户端能提供上次的session ID，就不再需要重新握手。

Session ticket：不局限于一台服务器， session ticket是上次对话中服务器发送的，内容是加密过的密钥和解密方法等，客户端如果能提供session ticket，也可以恢复对话。

。

02

part2.HTTPS实践与应用

2.1从HTTP升级到HTTPS

（一）申请证书

一般证书是不免费的，尤其是权威机构颁发的证书。

认证级别

域名认证：最低级别认证，可以确认申请人拥有这个域名。对于这种证书，浏览器会在地址栏显示一把锁。

公司认证：确认域名所有人是哪一家公司，证书里面会包含公司信息。

扩展认证：最高级别的认证，浏览器地址栏会显示公司名。

证书类型

单域名证书：只能用于单一域名，com的证书不能用于www.foo.com

通配符证书：可以用于某个域名及其所有一级子域名，比如*.foo.com的证书可以用于com，也可以用于www.foo.com

多域名证书：可以用于多个域名，比如com和bar.com

（二）证书安装和配置

一般地，这部分工作被运维的同事做了。

（三）修改链接

通常直接去掉协议名称，根据用户输入的协议为准。如：//vip.qq.com

当用户使用http请求时还是不走https，这时还可以：

不修改链接，修改web服务器配置，使用301重定向，如:

部门实践：

（坑）下面两种情况需要写全协议，不能省略：

•带有gulp-inline标签的url

•mqq.ui.openUrl打开的url

2.2Fiddler抓包HTTPS

（一）开启fiddler支持https抓包

（二）访问fiddler代理IP：端口，点击安装证书

（三）对证书授信

ios：设置-通用-描述文件与设备管理-点进去选择信任

android：设置-安全和隐私-受信任的凭据-用户-点进去选择信任

2.3HTTPS的局限性和使用场景

https由于过程复杂，耗时稍慢，需要证书等因素，使得需要高安全性的网站才应用它，或者只在注册、登陆、支付等关键页面才使用。

但https如果经过合理优化，不会明显影响性能，理论上所有场景都适合使用。

03

参考链接

《RSA算法原理（一）》

《RSA算法原理（二）》

《零知识证明及其应用》

《身份识别和零知识证明》

《数字签名是什么？》

《SSL/TLS协议运行机制的概述》

关注小编

留言夸夸小编

转发文章给小编加鸡腿

跟更多的人一起学习

让我们又爱又恨的前端