HTTPS-透彻学习汇总
配合这边文章《看完还不懂 HTTPS 我直播吃翔》学习效果更佳！
一、SSL的作用
不使用SSL/TLS的HTTP通信，就是不加密的通信。所有信息明文传播，带来了三大风险。
窃听风险（eavesdropping）：第三方可以获知通信内容。
篡改风险（tampering）：第三方可以修改通信内容。
冒充风险（pretending）：第三方可以冒充他人身份参与通信。
SSL/TLS协议是为了解决这三大风险而设计的，希望达到：
所有信息都是加密传播，第三方无法窃听。
具有校验机制，一旦被篡改，通信双方会立刻发现。
配备身份证书，防止身份被冒充。
具体解决原理请继续往下阅读。
二、SSL的历史
1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。 1996年，SSL 3.0版问世，得到大规模应用。 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。 2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。最新的变动是2011年TLS 1.2的修订版。 目前，应用最广泛的是TLS 1.0，接下来是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。 TLS 1.0通常被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
通俗的讲，TLS、SSL是个加密套件，负责对HTTP(或其他协议)的数据进行加密。TLS是SSL的升级版。现在提到HTTPS，加密套件基本指的是TLS。
传输加密的流程
原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。
三、HTTP缺陷
HTTP在网络上都是以明文传输的，很容易遭受中间人攻击。也就意味着，监听发送端、接收端中间的任意节点都可以知道你们传输的内容是什么。这些节点可能是路由器、代理等。
在发送端对密码进行加密？没用的，虽然别人不知道你原始密码是多少，但能够拿到加密后的账号密码，照样能登陆。
四、HTTPS是如何保障安全的
HTTP是应用层协议，位于HTTP协议之下是传输协议TCP。TCP负责传输，HTTP则定义了数据如何进行包装。
HTTP –> TCP （明文传输)
HTTPS相对于HTTP有哪些不同呢？其实就是在HTTP跟TCP中间加多了一层加密层TLS/SSL。
传输加密的流程
原先是应用层将数据直接给到TCP进行传输，现在改成应用层将数据给到TLS/SSL，将数据加密后，再给到TCP进行传输。如图:
在原来的五层模型中嵌入了SSL/TSL层，用来为传输中的数据进行加密的服务，从这张图上可以看出，当数据从HTTP层往下流的时候经过SSL层的加密服务，然后再把数据组合到TCP层进而传输，而当数据从另一端的TCP层向上流的时候，将加密后的数据往上交付，SSL层会为其解密，然后再交付给HTTP层。
概括的讲，就是一个端到端的加、解密流程而已
就是这么回事。将数据加密后再传输，而不是任由数据在复杂而又充满危险的网络上明文裸奔，在很大程度上确保了数据的安全。这样的话，即使数据被中间节点截获，坏人也看不懂。
五、非对称加密与证书
可参考这篇文章《密码学-数字证书原理》
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。这就存在了两个问题：
1.公钥如何获取？
浏览器是怎么获得XX的公钥的？当然，用户可以自己去网上查，XX也可以将公钥贴在自己的主页。然而，对于一个动不动就成败上千万的社交网站来说，会给用户造成极大的不便利，毕竟大部分用户都不知道“公钥”是什么东西。
2.数据传输仅单向安全
公钥加密的数据，只有私钥能解开，于是用户发给服务器的账号、密码是安全了，半路不怕被拦截。但是有个很大的问题：服务器用私钥加密的数据，公钥也能解开。加上公钥是公开的，服务器发给用户的隐私数据相当于在网上换了种方式裸奔。（中间代理服务器拿到了公钥后，毫不犹豫的就可以解密用户的数据）
解决问题1:
这里要涉及两个非常重要的概念：证书、CA（证书颁发机构）。
证书，可以暂时把它理解为网站的身份证。这个身份证里包含了很多信息，其中就包含了上面提到的公钥。
也就是说，当小明、小王、小光等用户访问XX的时候，再也不用满世界的找某个服务器的公钥了。当他们访问某服务器的时候，这台服务器就会把证书发给浏览器，告诉他们说，乖，用这个里面的公钥加密数据。
这里有个问题，所谓的“证书”是哪来的？这就是下面要提到的CA负责的活了。
CA（证书颁发机构），可以颁发证书的CA有很多（国内外都有），但是只有少数CA被认为是权威、公正的，这些CA颁发的证书，浏览器才认为是信得过的，我们的操作系统中会预先安装好一些证书发布机构的证书。比如VeriSign。（CA自己伪造证书的事情也不是没发生过。。。）证书颁发的细节这里先不展开，可以先简单理解为，网站向CA提交了申请，CA审核通过后，将证书颁发给网站，用户访问网站的时候，网站将证书给到用户。
可以这样说，数字证书就是经过CA认证过的公钥，而私钥一般情况都是由证书持有者在自己本地生成的，由证书持有者自己负责保管。具体使用时，签名操作是发 送方用私钥进行签名，接受方用发送方证书来验证签名；加密操作则是用接受方的证书进行加密，接受方用自己的私钥进行解密。
证书发布机构CA持有与自己的数字证书对应的私钥，使用此私钥对其发布的数字证书做签名。
浏览器/操作系统内置CA的数字证书（证书内含有CA的公钥），且为信任。浏览器获取到服务器的证书后，用CA的公钥解密，获取服务器的公钥（随的理解）。所以如果自己发放证书，需要首先信任该CA的数字证书（curl中需要指定CA证书、服务器证书、服务器私钥）。
解决问题2:
上面提到，通过私钥加密的数据，可以用公钥解密还原。那么，这是不是就意味着，网站传给用户的数据是不安全的？
答案是：是！！！（三个叹号表示强调的三次方）
看到这里，可能你心里会有这样想：用了HTTPS，数据还是裸奔，这么不靠谱，还不如直接用HTTP来的省事。但是，为什么业界对网站HTTPS化的呼声越来越高呢？这明显跟我们的感性认识相违背啊。因为：HTTPS虽然用到了公开密钥加密，但同时也结合了其他手段，如对称加密，来确保授权、加密传输的效率、安全性。
概括来说，整个简化的加密通信的流程就是：
1.小明访问XX，XX将自己的证书给到小明（其实是给到浏览器，小明不会有感知） 2.浏览器从证书中拿到XX的公钥A 2.浏览器生成一个只有自己自己的对称密钥B，用公钥A加密，并传给XX（其实是有协商的过程，这里为了便于理解先简化） 4.XX通过私钥解密，拿到对称密钥B 5.浏览器、XX 之后的数据通信，都用密钥B进行加密 注意：对于每个访问XX的用户，生成的对称密钥B理论上来说都是不一样的。比如小明、小王、小光，可能生成的就是B1、B2、B3.
证书有两种: 某个网站的证书，CA的证书。
六、证书可能存在的问题
证书非法可能有两种情况：
证书是伪造的：压根不是CA颁发的
证书被篡改过：比如将XX网站的公钥给替换了
举个例子：这个世界上存在一种东西叫做代理，于是，上面小明登陆XX网站有可能是这样的，小明的登陆请求先到了代理服务器，代理服务器再将请求转发到的授权服务器。
小明 –> 邪恶的代理服务器 –> 登陆授权服务器
然后，这个世界坏人太多了，某一天，代理服务器动了坏心思（也有可能是被入侵），将小明的请求拦截了。同时，返回了一个非法的证书。如果善良的小明相信了这个证书，那他就再次裸奔了。因为这个证书中有邪恶服务器的公钥，而不是授权服务器的公钥，小明会使用邪恶服务器的公钥加密，此时邪恶服务器就可以使用自己的私钥获取数据包中内容。当然不能这样，那么，是通过什么机制来防止这种事情的发生的呢。
下面，我们先来看看”证书”有哪些内容，然后就可以大致猜到是如何进行预防的了。
七、证书内容
在正式介绍证书的格式前，先插播个小广告，科普下数字签名和摘要，然后再对证书进行非深入的介绍。为什么呢？因为数字签名、摘要是证书防伪非常关键的武器。
数字签名与摘要
“摘要”就是对传输的内容，通过hash算法计算出一段固定长度的串（是不是联想到了文章摘要），供下载者验证下载后的文件是否完整，或者说是否和服务器上的文件”一模一样“，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致，“数字摘要“是https能确保数据完整性和防篡改的根本原因。
“签名”，通过CA的私钥对这段摘要进行加密，加密后得到的结果就是“数字签名”。数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围。
明文 –> hash运算 –> 摘要 –> CA的私钥加密 –> 数字签名
结合上面内容，我们知道，这段数字签名只有CA的公钥才能够解密。
接下来，我们再来看看神秘的“证书”究竟包含了什么内容，然后就大致猜到是如何对非法证书进行预防的了。内容非常多，这里我们需要关注的有几个点：
证书包含了颁发证书的机构的名字 — CA（可用来拿到此CA的根证书）
证书内容本身的数字签名（用CA私钥加密）
证书持有者的公钥（对应服务器的私钥）
证书签名用到的hash算法（使用同一个hash算法来验证签名）
CA本身有自己的证书，江湖人称“根证书”。这个“根证书”是用来证明CA的身份的，本质是一份普通的数字证书。浏览器通常会内置大多数主流权威CA的根证书。
证书格式，由于是服务器发送给用户的，所以用户端可以看到此证书，safari中点击小锁即可查看。
1. 证书版本号(Version) 版本号指明X.509证书的格式版本，现在的值可以为: 1) 0: v1 2) 1: v2 3) 2: v3 也为将来的版本进行了预定义 2. 证书序列号(Serial Number) 序列号指定由CA分配给证书的唯一的”数字型标识符”。当证书被取消时，实际上是将此证书的序列号放入由CA签发的CRL中， 这也是序列号唯一的原因。 3. 签名算法标识符(Signature Algorithm) 签名算法标识用来指定由CA签发证书时所使用的”签名算法”。算法标识符用来指定CA签发证书时所使用的: 1) 公开密钥算法 2) hash算法 example: sha256WithRSAEncryption 须向国际知名标准组织(如ISO)注册 4. 签发机构名(Issuer) 此域用来标识签发证书的CA的X.500 DN(DN-Distinguished Name)名字。包括: 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. 证书持有者公开密钥信息(Subject Public Key Info) 证书持有者公开密钥信息域包含两个重要信息: 1) 证书持有者的公开密钥的值 2) 公开密钥使用的算法标识符。此标识符包含公开密钥算法和hash算法。 8. 扩展项(extension) X.509 V3证书是在v2的基础上一标准形式或普通形式增加了扩展项，以使证书能够附带额外信息。标准扩展是指 由X.509 V3版本定义的对V2版本增加的具有广泛应用前景的扩展项，任何人都可以向一些权威机构，如ISO，来 注册一些其他扩展，如果这些扩展项应用广泛，也许以后会成为标准扩展项。 9. 签发者唯一标识符(Issuer Unique Identifier) 签发者唯一标识符在第2版加入证书定义中。此域用在当同一个X.500名字用于多个认证机构时，用一比特字符串 来唯一标识签发者的X.500名字。可选。 10. 证书持有者唯一标识符(Subject Unique Identifier) 持有证书者唯一标识符在第2版的标准中加入X.509证书定义。此域用在当同一个X.500名字用于多个证书持有者时， 用一比特字符串来唯一标识证书持有者的X.500名字。可选。 11. 签名算法(Signature Algorithm) 证书签发机构对证书上述内容的签名算法 example: sha256WithRSAEncryption 12. 签名值(Issuer’s Signature) 证书签发机构对证书上述内容的签名值
如何辨别非法证书，由于浏览器会内置大多数主流CA的根证书，而证书中有CA的公钥（非常重要！！！），下面介绍两种非法场景:
1.完全伪造的证书，这种情况比较简单，对证书进行检查即可
a).证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
b).证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了。认为是危险证书。
2.篡改的证书
假设代理通过某种途径，拿到XX的证书，然后将证书的公钥偷偷修改成自己的，然后喜滋滋的认为用户要上钩了。然而太单纯了：
检查证书，根据CA名，找到对应的CA根证书，以及CA的公钥。用CA的公钥，对证书的数字签名进行解密，得到对应的证书摘要AA，根据证书签名使用的hash算法，计算出当前证书的摘要BB，对比AA跟BB，发现不一致，判定是危险证书。
八、SSL/TSL基本流程
第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。 第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。 第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。 第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。 第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
步骤 0. TCP三次握手 步骤 1. Client Hello – 客户端发送所支持的 SSL/TLS 最高协议版本号、所支持的加密算法集合及压缩方法集合和随机数A等信息给服务器端。 步骤 2. Server Hello – 服务器端收到客户端信息后，选定双方都能够支持的 SSL/TLS 协议版本和加密方法及压缩方法、 随机数B和服务器证书返回给客户端。 步骤 3. 客户端主动再生成一个随机数C，开始生成秘钥，这个生成秘钥的算法是客户端跟服务器端共享的，因为之前协商的时候已经确定了算法了，生成秘钥后就可以加密一段内容，试着跟服务区通信了，这个内容是经过先散列，散列后将原内容和散列集一起用刚才的密钥加密；接着用服务器端证书中的公钥对随机数C加密。 步骤 4. 然后把加密过的内容和加密好的随机数一起发向服务器端。 步骤 5. 服务器用私钥解密得到随机数C，这样服务器端也同时拥有了随机数A、B、C，即刻生成密钥，再用密钥对加密的内容进行解密，然后解开后对其中的明文内容进行散列，与客户端发过来的散列值进行比较，如果相等，说明就是客户端发过来的，通信成功。 步骤 6. 用步骤3中同样的方式发一段加密过的内容给客户端。 步骤 7. 用步骤5一样的方式对服务器发来的内容进行验证。 步骤 8. 客户端确定开始通信。 步骤 9. 服务端确定开始通信。
1.浏览器将自己支持的一套加密规则发送给网站。 2.网站从中选出一组加密算法与HASH算法，并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址，加密公钥，以及证书的颁发机构等信息。 3.浏览器获得网站证书之后浏览器要做以下工作： a) 验证证书的合法性（颁发证书的机构是否合法，证书中包含的网站地址是否与正在访问的地址一致等），如果证书受信任，则浏览器栏里面会显示一个小锁头，否则会给出证书不受信的提示。 b) 如果证书受信任，或者是用户接受了不受信的证书，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密。 c) 使用约定好的HASH算法计算握手消息，并使用生成的随机数对消息进行加密，最后将之前生成的所有信息发送给网站。 4.网站接收浏览器发来的数据之后要做以下的操作： a) 使用自己的私钥将信息解密取出密码，使用密码解密浏览器发来的握手消息，并验证HASH是否与浏览器发来的一致。 b) 使用密码加密一段握手消息，发送给浏览器。 5浏览器解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。
过程:
握手: 证书下发，秘钥协商（协商出对称秘钥），整个过程是明文的
数据传输：这个阶段才是加密的，用的就是握手阶段协商出来的对称密钥
九、使用Wireshark分析
参考:
