白话Https原理

一、回顾http

    HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）的应用层传输协议。
说到http就离不开老生常谈的3次握手和4次挥手.

三次握手

    我们用打电话场景来描述3次握手,线上业务出现告警了,老板给员工A打电话:

①拨号类似于客户端向服务端发送请求连接,第一次握手,如果拨错号码,和请求错ip或者域名类似

②接听电话可以理解为客户端到服务器的网络是通的,但是此时客户端到服务端的网络通只有服务端知道,回复用于告诉客户端网络畅通,并发送seq确认服务端到客户端的网络是否通,否则只能接收请求无法发送响应

③客户端接收到服务端的需求后,能确认客服端到服务端和服务端到客户端网络都是通的,但是服务端目前还不知道其到客户端的网络是否通,所以客户端接收到消息后然后发送消息seq告诉服务端,服务端收到客户端发送的seq后,就能保证双端的来回网络都是畅通的,然后就能进行通信和数据交互了

④就是客户端发送请求和接受响应的交互过程

四次挥手

    有很多人会有疑问,为什么建立链接是3次握手,而断开链接需要4次挥手,那么带着疑问继续使用上述例子来说明:

①老板有点尿急,想挂掉电话去厕所,就询问处理进度,对应于网络交互就是客户端想断开链接,发送close请求.

②员工A告诉老板说马上处理完,对应于服务端发送ack响应,告诉客户端数据还没发送完毕,然后服务端进入close_wait状态.

③员工A经过一番努力后终于处理完了,告诉老板处理好了,类似于服务端处理和发送数据完成后发送给客户端客户关闭的seq消息.

④老板收到处理完成消息,然后挂掉了电话,对应于客户端收到服务端的发送完成seq消息断开链接.

特点

1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、POST等。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

5、支持B/S及C/S模式。

    当然他的缺点也很明显。

缺点

1.通信使用明文（不加密）:内容可能会被窃听。

2.不验证通信方的身份:因此有可能遭遇伪装。

3.无法证明报文的完整性:内容有可能已遭篡改。

二、什么是https

    对于https的官方定义和介绍如下:

Hypertext Transfer Protocol Secure (HTTPS) is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on the Internet.[1][2] In HTTPS, the communication protocol is encrypted using Transport Layer Security (TLS) or, formerly, Secure Sockets Layer (SSL). The protocol is therefore also referred to as HTTP over TLS,[3] or HTTP over SSL.

    HTTPS （全称：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全为目标的 HTTP 通道，在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性 [1] 。HTTPS 在HTTP 的基础下加入SSL，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL。

    HTTPS 并非是应用层的一种新协议。是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。

    HTTPS和http一样也都是应用层网络传输协议,同样需要三次握手和四次挥手来建立连接和关闭连接,如下图:

三、加密算法

    HTTPS解决数据传输安全问题的方案就是使用加密算法，具体来说是混合加密算法，也就是对称加密和非对称加密的混合使用，这里先了解一下这两种加密算法的区别和优缺点。

对称加密

    对称加密，也就是加密和解密都是使用同一个密钥，常见的对称加密算法有 DES、3DES和AES 等,举个例子来说就是学校大门的锁有一把钥匙,不管是老师还是学生,只要有钥匙,就能打开锁,那当然如果钥匙丢了被其他人捡到了或者偷走了,在更换锁之前持有钥匙的人都可以打开,这也就暴露了其优缺点:
1.优点:简单轻便、容易理解、效率高
2.缺点:容易被截获,这样安全性就无从保证

    如果网络交互单纯使用对称加密就会有如下效果:

    从图中可以清晰看出如果密钥没有被截获,如果内容被三方截获,拿到的也是一堆乱码没有意义,但是有一个致命的问题，那就是既然双方要使用相同的密钥，那就必然要在传输数据之前先由一方把密钥传给另一方，那么在此过程中密钥就很有可能被截获，如果密钥被截获,数据传输形同裸奔.

非对称加密

    非对称加密，也就是加密和解密需要使用两个不同的密钥：公钥（public key）和私钥（private key）。公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。

    非对称加密算法实现信息交换的过程是：A生成一对密钥并将其中的一把作为公钥对外公开；得到该公钥的B使用公钥对机密信息进行加密后再发送给A；A方再用自己保存的私钥对加密后的信息进行解密。

    用白话来说就是你在超市买了一把锁,只有你拥有钥匙能打开锁头,你把锁送给别人,别人用锁锁住重要的物品然后发给你,然后只有你拥有钥匙,物品在发送过程到收到,只有你才能打开并看到里边的物品。

    常用的非对称加密算法是 RSA 算法,其优缺点如下:

1.优点:算法公开，加密和解密使用不同的钥匙，私钥不需要通过网络进行传输，安全性高

2.缺点:计算量比较大，加密和解密速度相比对称加密慢得多

    非对称加密安全性高,完美地解决了对称加密过程中密钥泄漏问题,大致过程如下:

    可以看到客户端在拿到服务器的公钥后，会生成一个随机码 (密钥KEY，KEY就是后续双方用于对称加密的密钥)，然后客户端使用公钥把KEY加密后再发送给服务器，服务器使用私钥解密后拿到KEY，这样双方就有了同一个密钥 KEY，然后双方再使用KEY进行对称加密交互数据。在非对称加密传输KEY的过程中,即便第三方获取了公钥和加密后的 KEY，在没有私钥的情况下也无法破解KEY (私钥存在服务器,基本不会泄漏)，也就保证了接下来对称加密的数据安全。基于前边两边都持有密钥KEY,具体数据传输会使用对称加密来提供更好的性能和效率,所以HTTPS的加密方式是非对称加密和对称加密混合使用(使用非对称的安全性和使用对称加密的高性能)。

四、https工作原理

    从https基本概念描述中我们大概知道https不是一个新的物种,是基于http通信协议新增了TLS或者SSL加密,也即是HTTPS = HTTP + SSL / TLS。

1.传输原理

    HTTPS 的整个通信过程可以分为两大阶段：证书验证和数据传输阶段，数据传输阶段又可以分为非对称加密和对称加密两个阶段.

①.客户端请求 HTTPS 网址，然后连接到 server 的 443 端口 (HTTPS 默认端口443),并告诉server自己支持的加密规则

②③server从中选出双方都支持的一组加密算法和哈希算法,并将自己的身份信息以证书的形式发送给客户端,证书中包含域名,公钥以及证书的办法机构和有效期信息。点击浏览器左上角的锁标志可以看到证书信息


④验证证书的有效性与合法性,如果不受信息则会给出警告是否要继续,如果证书受信任,浏览器左侧会有一个锁标识,然后生成一个随机码KEY(密钥),然后使用公钥加密

⑤客户端把加密后的密钥KEY发送给服务端

⑥服务端使用自己持有的私钥将客户端发送过来的加密信息解密得到密钥KEY,这样就解决了密钥泄漏的问题了

⑦⑧服务端使用密钥KEY加密数据发送给客户端，客户端使用密钥KEY进行对称解密,这样双方就可以使用对称加密的方式进行数据交互了

    https对应的通信时序图大致如下:

2.证书

    证书也叫数字证书,是在 Internet 上唯一地标识人员和资源的电子文件。证书使两个实体之间能够进行安全、保密的通信。

    证书就好像一本护照：它可以标识持有者并提供其他重要信息。证书由称为证书授权机构 (Certification Authority, CA) 的可信赖第三方发布。CA 类似于护照申领办公室：它将验证证书持有者的身份并对证书进行签名，以使他人无法伪造或篡改证书。CA 对证书进行签名之后，持有者可以提供该证书作为身份证明并建立经过加密的保密通信。

    证书是向CA(Certificate Authority证书授权中心)机构申请的,证书将公钥绑定到有关其拥有者的信息。除了公钥以外，证书通常还包括以下信息：

• 持有者的姓名和其他标识，例如使用证书的 Web 服务器的 URL 或个人的电子邮件地址。
• 发布证书的 CA 的名称。
• 失效日期。

五、中间人攻击与解决方案

什么是中间人攻击

中间人攻击（Man-in-the-middle attack，缩写：MITM）是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。

    简单来说攻击者就是一个介入通信的传话员，攻击者知道通信双方的所有通信内容，而且可以任意偷窥、增加、删除和修改双方的通信内容，而双方对此并不知情。

    中间人攻击不仅仅局限于针对HTTPS，对于开放性的连接，中间人攻击非常容易。比如在一个未加密的Wi-Fi网络中，攻击者可以很容易地将自己插入双方的通信之中以截取或者修改通信的内容。

    用一个网上的案例来通俗形象的来描述中间人攻击.

1.假设 Tom 想和 Jerry 交换一些秘密信息，然而 Tom 又不想跑到 Jerry 家里，于是 Tom 叫来了邮递员，给了邮递员一封信。信的内容是希望 Jerry 给 Tom 一个盒子（这个盒子有两把钥匙）和其中一把钥匙（另一把在 Jerry 手里）。

2.邮递员在拿到 Tom 给的信件以后，把 Tom 的信拆开看了一遍，了解到 Tom 希望 Jerry 给 Tom 一个有锁的盒子，又用另一个信封装了回去，并交给了 Jerry。
3.Jerry 在收到 Tom 的信（实际已经被邮递员拆阅过了）之后，给了邮递员一个有锁的盒子和其中一把钥匙。

4.邮递员想知道他们的通信内容，于是他把 Jerry 给 Tom 的盒子换成了他自己的盒子，并附上了自己盒子中的一把钥匙，并在之后将自己的盒子交给了 Tom。

5.Tom 在收到盒子之后，以为这个盒子是 Jerry 给他的，于是就把秘密的信件放进了盒子里，并把钥匙留下了，之后又交给了邮递员。

6.邮递员在拿到盒子之后，用自己的另一把钥匙打开盒子，看了里面的信件。之后将信件调换之后放进了 Jerry 给的盒子，交给了 Jerry。

7.Jerry 在拿到邮递员给他的盒子之后，并不知道这个盒子里的信件其实已经被邮递员调换过了，所以 Jerry 认为盒子里的信件是来自 Tom 且未被修改过的。之后 Jerry 把回信放进了盒子里，又交给了邮递员。

8.邮递员再次调换盒子里的信件，交给了 Tom。

    这就是典型的中间人攻击的过程。在HTTPS网络交互中，Tom就是客户端，Jerry是服务端，而邮递员就是客户端和服务端之间的任何实体（包括代理服务器、路由器、反向代理服务器等等），两把钥匙分别是公钥和私钥。通信双方并不知道（且通常很难发觉）自己其实在和中间人通信而非直接和对方通信。在通信过程中，Tom 和 Jerry 并没有验证对方的身份，这就导致了邮递员可以任意查看、修改或者丢弃双方的通信内容。

如何防范中间人攻击

    首先如果要确认通信数据没有被拦截篡改,需要保证信息内容来自他声称的那个人，且没有被修改过,前边我们有分析过https在http协议的基础上做了加密,非对称加密过程传递的密钥是无法被第三方截获的,好像是这样子,但是我们换个角度想一下,那如果客户端连接服务端的时候被中间网络拦截,换成了自己的证书和公钥,而中间人又冒充客户端的方式与服务端交互,那么客户端拿到的公钥就是中间人的,而服务端拿到的密钥也是中间人的,替换方式如下图:

1.中间人拿到客户端的连接请求,返回自己的证书和公钥,自己持有私钥,然后中间人冒充客户端向服务端发送连接请求,中间人拿到服务端的证书和公钥

2.客户端生成密钥,然后用中间人的公钥加密并发送,中间人拦截到请求后,用自己的私钥解密拿到客户端的密钥,然后用服务端的公钥加密密钥并发送给服务端

3.服务端用自己的私钥解密中间人发过来的信息,解密拿到客户端的密钥,到这里客户端、中间人和服务端都持有了密钥,也就是说后边的对称加密数据交互对于中间人完全是公开的.

4.客户端使用密钥加密发送数据,中间人拿到之后用密钥解密,拿到原始数据,修改后在用密钥加密发送给服务端

5.服务端用密钥解密中间人发来的数据,拿到的是被篡改过的数据

6.服务端返回响应给客户端和4,5一样,也同样会被中间人篡改

    那怎么办呢,我们再举个比较形象的例子,在古代邮官署收发官文,官员收到朝廷或者上级官员的书信,都要有公章或者署名来作为官方认证,想要成为官方认证或者认可的章印或者署名,首先要有广泛认可度和权威性,再者接收官文或者书信的机构和个人要有识别度,比如官署肯定能够分得清朝廷的任免通知的上官印是否真实,也就是其身份和声明的身份是否匹配,另外个人也会对其真实性做考量,这样在确定身份和声明相符的前提下保证官文或者书信内容的真实性。

    对应于互联网,用户就是前边提到的个人,浏览器或者其他客户端就是官署,发起https请求拿到服务端证书和公钥时,浏览器会去CA机构确认域名与证书是否匹配,如果不匹配就会出现前边所说的警告,如果匹配说明域名和证书是匹配的,网络连接和交互是安全的,就前边中间网络而言,假如访问的百度的域名,被中间人挟持后返回的是中间网络的证书和公钥,而非经过CA机构认证的百度证书和公钥,浏览器会出现警告信息,这样就通过浏览器与CA机构认证证书的方式防范了中间人攻击。

中间人攻击案例

    使用FreeHttp搭建中间人服务器,手机连上Fiddler代理,不要让手机安装或信任任何第三方证书,试着访问一些移动端应用:

    继续访问出现：

    大部分应用出现了无法访问，弹出式安全提示等反应
不过仍然有一些应用无视了证书的保护，直接与危险的中间人服务器建立了连接，并向用户正常的显示了页面等数据。下面列几个代表性强的常用APP进行说明
1：知乎 （IOS版 4.34.1（1228） ）


    可以看到知乎是完全无视了证书不匹配的错误，与没有受到MITM时表现是一样的，正常访问和提交数据。但事实却是所有流量都是通过中间人服务器转发到知乎的，中间服务器解密了所有流量，并且可以对其进行篡改。更糟的是这一切发生的时候，用户是完全不知情的。简单的说就是当您在使用知乎APP浏览或发帖时，网络节点中的任何别有用心的人都是可以获取您在浏览的内容，并对其进行修改。

2：360浏览器（IOS版本360浏览器 4.0.10）
    其实某款特定APP由于自身安全问题不能抵御MITM,最多也只会影响到自己的APP及自己的用户，不过浏览器如果出现这种问题就会对使用者所有浏览的网站都有影响,
特别是以安全为一大卖点的360，其自家浏览器的安全策略让人捏了一把鼻涕。

六、扩展

https代理

    https代理可以在浏览器配置,其本质是先链接到代理服务器,然后代理服务器像目标服务器发送请求,其实这里代理服务器充当了“中间人”的角色.

双向认证

    前边介绍的https认证方式是单向认证,是客户端验证服务端证书,检查其合法性和可靠性,所谓的双向认证也就是服务端同样也要验证客户端的合法性,典型的应用场景是银行网站的u盾,我们看一下双向认证流程:

• 1.客户端发起建立HTTPS连接请求，将加密协议版本的信息发送给服务端
• 2.服务器端将本机的公钥证书(server.crt)发送给客户端
• 3.客户端读取公钥证书(server.crt)，取出了服务端公钥
• 4.客户端将客户端公钥证书(client.crt)发送给服务器端
• 5.服务器端使用根证书(root.crt)解密客户端公钥证书，拿到客户端公钥
• 6.客户端发送自己支持的加密方案给服务器端
• 7.服务器端根据自己和客户端的能力，选择一个双方都能接受的加密方案，使用客户端的公钥加密8. 后发送给客户端
• 8.客户端使用自己的私钥解密加密方案，生成一个随机数R，使用服务器公钥加密后传给服务器端
• 9.服务端用自己的私钥去解密这个密文，得到了密钥R
• 10.服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了
      简单来说双向认证进一度提升了https网络交互的安全性.

七、总结

    本篇文章介绍了https的概念、工作原理以及中间人攻击防范,那么这玩意儿就是完美无缺了吗,从http切换到https不需要做出牺牲吗？

    答案肯定是no,https从网络交互安全性角度来说确实比http好很多,但是也有它的缺点：

1.在相同网络环境中，HTTPS相比HTTP无论是响应时间还是耗电量都有大幅度上升,中间加入了认证环节,验证根证书有效性、非对称加密和对称加密

2.在现有的证书机制下，中间人攻击依然有可能发生

3.增加了成本,HTTPS需要更多的服务器资源，并且企业级别申请证书费用昂贵

参考

https://www.codenong.com/cs109111119/

https://segmentfault.com/a/1190000021494676

https://www.cnblogs.com/lulianqi/p/10558719.html