一、背景知识
1.1.基本术语HTTP|HTTPS|SSL|TLS
1.2.HTTP和TCP的关系，如长连接和短连接等
1.3.加密算法的大概知识(对称加密和非对称加密)
1.4.CA证书的用途
二、基本术语
2.1、"HTTP"：
是一个专门用来传输web内容的协议。
版本历史：
0.9 90年代推出时候为0.9版本
1.0 之后推出了1.0版本 该版本曾被广泛应用过
1.1 这个 1.1 版本是1995年底开始起草的（技术文档是 RFC2068），并在1999年正式发布（技术文档是 RFC2616）
2.0 2015年发布
2.1.1、响应体
响应行一般由协议版本、状态码及其描述组成 比如 HTTP/1.1 200 OK
其中协议版本HTTP/1.1或者HTTP/1.0，200就是它的状态码，OK则为它的描述。
//常见状态码：
100~199：表示成功接收请求，要求客户端继续提交下一次请求才能完成整个处理过程。
200~299：表示成功接收请求并已完成整个处理过程。常用200
300~399：为完成请求，客户需进一步细化请求。例如：请求的资源已经移动一个新地址、常用302(意味着你请求我，我让你去找别人),307和304(我不给你这个资源，自己拿缓存)
400~499：客户端的请求有错误，常用404(意味着你请求的资源在web服务器中没有)403(服务器拒绝访问，权限不够)
500~599：服务器端出现错误，常用500
2.2、"SSL":
是Secure Sockets Layer的缩写，翻译成中文叫做安全套接字层。上世界90年代由网景公司设计（该公司还发明了"!!!，js脚本等）
HTTP协议在传输数据的时候是明文传输的，可能存在数据泄露（被嗅探）和篡改的问题。
而SSL协议就是为了解决上述问题而提出的。到了1999年，SSL 因为应用广泛，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层安全协议”。所以，SSL和TLS可以视作同一个东西的不同阶段。
2.3、"HTTPS":即 HTTP + SSL
三、HTTP和TCP的关系
3.1、"HTTP协议和TCP协议"
TCP协议是HTTP协议的基石，即HTTP协议需要依靠TCP协议来传输数据。
HTTP是应用层协议之一。
TCP是传输层协议之一。
有很多应用层的协议（如HTTP|SMTP等）都以TCP协议为基础来进行数据传输。
传输层协议主要有TCP和UDP两种，区别在于TCP协议是可靠的。
3.2、"短连接和长连接"
HTTP 对TCP连接的使用，分为两种方式：俗称“短连接”和“长连接”（“长连接”又称“持久连接”，英文为“Keep-Alive”或“Persistent Connection”）
3.3、HTTP各个版本中TCP的连接方式
假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。在“短连接”的模式下，浏览器会先发起一个 TCP 连接，拿到该网页的 HTML 源代码（拿到 HTML 之后，这个 TCP 连接就关闭了）。然后，浏览器开始分析这个网页的源码，知道这个页面包含很多外部资源（图片、CSS、JS）。然后针对【每一个】外部资源，再分别发起一个个 TCP 连接，把这些文件获取到本地（同样的，每抓取一个外部资源后，相应的 TCP 就断开）
相反，如果是“长连接”的方式，浏览器也会先发起一个 TCP 连接去抓取页面。但是抓取页面之后，该 TCP 连接并不会立即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。然后浏览器分析 HTML 源码之后，发现有很多外部资源，就用刚才那个 TCP 连接去抓取此页面的外部资源。
HTTP1.0 版本默认使用短连接，也叫作一次性连接。因为那个时候网页简单。
HTTP1.1 版本中默认使用长连接，因为此时网页已经变得足够复杂，如果继续使用短连接的方式效率太低（因为建立TCP连接需要时间和CPU成本）
四、加密和解密
加密：给你一个明文，可以通过一定的加密算法得到一串密文的过程。明文————>密文
解密：给你一个密文，可以通过对应的解密算法得到初始原文的过程。密文————>明文
对称加密：加密和解密使用相同的密钥。"速度快|效率高|存在密钥传输安全的问题"
非对称加密：加密和解密使用不同的密钥。拥有一个公钥一个私钥，使用公钥进行加密使用私钥来进行解密。"速度慢|安全性强"
对称加密和非对称加密的特点也影响到了SSL协议的设计。
五、HTTPS协议为什么要设计成这样？（WHY）
5.1、兼容性问题
①已有的web应用应该尽可能无缝的迁移到HTTPS，最好是做到零成本。②浏览器厂家改动应该尽可能的小
①"HTTPS协议还是基于TCP来进行传输"
②"把HTTP协议包裹起来成为一个新的协议"
③好比以前的HTTP协议是塑料水管容易戳破，现在就在以前塑料水管的基础上再包上一层金属管。这样就可以做到，原有的管道能够照常运行，且不再容易被戳破。
5.2、可扩展性
SSL/TLS 可以跟很多常用的应用层协议（比如：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性
如果把SSL看成是一层金属管，那么他不仅能够对输水管道进行加固，而且也能对输电管道，输煤气管道进行加固。
5.3、保密性
说白了以前是透明的塑料管道，随便花点功夫就能够知道传输的内容，而现在能够做到足够好的保密性。
5.4、完整性
能够确保HTTP协议的内容不被修改。
因为你的网络流量需要经过 ISP 的线路才能到达公网。如果你使用的是明文的 HTTP，ISP 很容易就可以在你访问的页面中植入广告
5.5、真实性
HTTPS 协议必须有某种机制来确保“真实性”的需求。
如何确定我们访问的网站是真实的，关于这一点仅仅根据域名来判断是不靠谱的。因为我们的DNS系统本身就是不可靠的（域名欺骗和域名劫持），所以我们看到的网址里面的域名未必是真实的。
5.6、性能
使用HTTPS的时候性能不能太差，因此在设计的时候需要考虑两个问题：
① 加密和解密采用什么样的方式来进行：对称加密还是非对称加密？
② 采用什么样的连接方式：短连接还是长连接
六、 设计HTTPS协议的难点
个人认为最难的地方在于对传输数据进行加密和解密这一块，也就是密钥交换。
如果客户端和服务器端需要进行HTTPS通信，那么首先需要协商双方应该采用什么样的加密算法，确定了加密算法之后还需要传输加密和解密中可能涉及到的密钥，而此时尚处于握手阶段，所有的数据传输都还是明文的，那么应该如何安全的传输密钥成为最大的问题。
七、解决密钥安全传输的问题
1、单独使用对称加密来传输
完全使用对称加密来传输"不具备可行性"，因为如果要使用对称加密，那么浏览器和客户端之间势必需要先交换"对称加密的密钥"。如果这个密钥直接用明文来传输，则很有可能会被攻击者偷窥到。
2、使用非对称加密来传输 效率太低
3、使用非对称加密+对称加密：存在中间人攻击隐患（需要具备篡改通信数据的能力）[伪造公钥][MITM]
4、正是因为"缺乏身份认证机制"，所以我们需要考虑身份认证的问题。
八、身份认证的几种方式
1、基于某些私密共享的信息 |前提——通信双方认识彼此熟悉
2、基于双方都信任的公证人 |如果通信双方都不认识彼此，那么就只能采用该模式（如C2C）
那么，谁来充当这个公证人呢？"CA"华丽登场
如何解决SSL的身份认证问题：使用CA
CA数字证书在技术实现上依赖于非对称加密技术
九、维基百科中对HTTPS的定义
超文本传输安全协议（英语："Hypertext Transfer Protocol Secure"，缩写：HTTPS，也被称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种网络安全传输协议。在计算机网络上，HTTPS经由超文本传输协议进行通信，但利用SSL/TLS来对数据包进行加密。HTTPS开发的主要目的，是'提供对网络服务器的身份认证，保护交换数据的隐私与完整性'。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。
十、扩充知识：
网景（英语：Netscape）是一个自1994年开始的品牌。"1994年4月4"日它最初成立的名字是'马赛克通信公司'。该公司有一款名称为"网景导航者"的浏览器，因此"网景"也是是网景通信公司（Netscape Communications Corporation）的常用简称。网景通信公司曾经是一家美国的电脑服务公司，以其生产的同名网页浏览器而闻名。1998年11月，网景被美国在线（AOL）收购，2003年7月网景被解散，网景大部分的程序员被解雇，2008年3月1日美国在线宣布停止对网景浏览器的技术支持。
网景公司（Netscape）在1994年推出首版网页浏览器，网景导航者时，推出HTTPS协议，以SSL进行加密，这是SSL的起源。IETF将SSL进行标准化，1999年公布了第一版TLS标准文件
IETF:互联网工程任务小组（英语：Internet Engineering Task Force，缩写为 IETF）负责互联网标准的开发和推动.
该网站提供免费的安全证书：https://letsencrypt.org
十一、SSL协议握手的过程：
通过握手，客户端和服务器协商各种参数用于创建安全连接：
① 当客户端连接到支持TLS协议的服务器要求创建安全连接并列出了受支持的密码组合（加密密码算法和加密哈希函数），握手开始。
② 服务器从该列表中决定加密和散列函数，并通知客户端。
③ 服务器发回其数字证书，此证书通常包含服务器的名称、受信任的证书颁发机构（CA）和服务器的公钥。
④ 客户端确认其颁发的证书的有效性。
⑤ 为了生成会话密钥用于安全连接，客户端使用服务器的公钥加密随机生成的密钥，并将其发送到服务器，只有服务器才能使用自己的私钥解密。
⑥ 利用随机数，双方生成用于加密和解密的对称密钥。
以上就是TLS协议的握手，握手完毕后的连接是安全的，直到连接（被）关闭。如果上述任何一个步骤失败，TLS握手过程就会失败，并且断开所有的连接。
十二、TLS 1.2在 RFC 5246 中定义，于2008年8月发表。它基于更早的TLS 1.1规范。主要区别包括：
① 可使用密码组合选项指定伪随机函数使用SHA-256替换MD5-SHA-1组合。
② 可使用密码组合选项指定在完成消息的哈希认证中使用SHA-256替换MD5-SHA-1算法，但完成消息中哈希值的长度仍然被截断为96位。
③ 在握手期间MD5-SHA-1组合的数字签名被替换为使用单一Hash方法，默认为SHA-1。
④ 增强服务器和客户端指定Hash和签名算法的能力。
⑤ 扩大经过身份验证的加密密码，主要用于GCM和CCM模式的AES加密的支持。
⑥ 添加TLS扩展定义和AES密码组合。
⑦ 所有TLS版本在2011年3月发布的RFC 6176中删除了对SSL的兼容，这样TLS会话将永远无法协商使用SSL 2.0以避免安全问题。
十三、HTTPS协议中关于SSL/TLS层握手过程的说明
阶段一：协商加密方式等参数
客户端 ① 我想要和你[服务端]进行安全的通话，我这里的支持的对称加密算法有DES|AES|RC5,密钥交换算法有RSA和DH,消息摘要算法有MD5和SHA1|SHA256
② [我说完了]
服务端 ① 我们使用AES-RSA-SHA256的组合方式吧。
② 服务器端证书发送给客户端，并说[这是我的证书，里面有我的信息和公钥，你拿去验证一下我的身份吧]。
③ [我说完了]
"——————该阶段双方已经协商好了加密[AES]__会话密钥交换[RSA]_消息校验[SHA256]的一套方法。
'阶段二：验证证书的有效性并交换会话密钥
客户端 ① 检查证书上面的信息，并通过已有的CA证书验证服务器端证书的真实性，如果有误则发出警告并断开连接。
② 客户端从接收到的证书中提取出公钥
③ 生成随机数作为会话密钥，即session key,该密钥将被在建立安全通道后用作对称加密的密钥。
④ 使用提取出来的公钥加密之前生成的会话密钥，封装成一个ClientKeyExchange消息[其实就是使用公钥对会话密钥进行加密之后的密文]。
⑤ 以后我就要使用session key对消息进行加密来和你进行通信了！
⑥ [我说完了]
服务端 ① 使用自己的私钥对收到ClientKeyExchange消息进行解密，得到会话密钥，即session key。
"【注】该消息由客户端使用服务器端发送给其的公钥进行加密，所以服务器端可以使用私钥来解密。
② 使用会话密钥加密初始化向量
"【注】如果采用的是CBC分组模式进行加密处理则需要用到初始向量
③ 加密HMAC的密钥
④ 以后我也要使用session key对消息进行加密来和你进行通信了！
⑤ [我说完了]
"——————该阶段完成会话密钥session key的安全交换。
'阶段三：使用会话密钥加密消息，所有的消息在安全的信道中传输
客户端 ① 要发送给服务端的消息是CMsg:我的小秘密是....
② 使用会话秘钥对CMsg进行对称加密得到密文CMsg1:xxxxxooooooo
③ 把CMsg1发送给服务器端
服务端 ① 接收到客户端发送来的消息CMsg1:xxxxxooooooo
② 使用本地的私钥对收到的消息Msg1进行解密，得到原文为CMsg:我的小秘密是....
③ 对客户端的消息进行响应，要发送给客户端的消息为SMsg:其它人不会听到的，我也有个小秘密...
④ 使用会话密钥对SMsg进行对称加密得到密文SMsg1:oooooxxxxxxx
⑤ 把SMsg1发送给客户端
"——————该阶段在传输之前使用会话密钥对所有的消息进行对称加密处理。