在介绍HTTPS之前，首先需要了解为什么要引入HTTPS。简单来说是HTTP协议不安全，在传输过程中传输明文，使得整个传输过程完全透明，如果请求被截获，请求/响应报文都可能被修改，因此数据不具有可信性。
要讨论安全就得先定义安全。通常来讲，如果通信过程具备了四个特性，就可以认为是安全的：
- 机密性：其他人不可见；
- 完整性：数据从发送端到接收端保持一致，未被篡改；
- 身份认证：可确认对方真实身份，保证消息只能发给可信的人；
- 不可否认：无法否认请求发生；
HTTPS中的SSL/TLS
在HTTPS中，HTTP下层的传输协议由TCP/IP换成了SSL/TLS。SSL（Secure Sockets Layer）发展到v3时改名为TLS（Transport Layer Security），版本号从1.0重新算起，所以TLS1.0实际上就是SSL v3.1。目前主要应用的是1.2，之前的协议都已被认为是不安全的了。
TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。TLS 的密码套件格式：“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”。
当浏览器和服务器在使用TLS建立连接时，需要选择一组恰当的加密算法来实现安全通信。这些算法的组合叫做密码/加密套件（cipher suite）。
SSL/TLS的具体实现，体现在OpenSSL中。OpenSSL是著名的开源密码学工具包，几乎支持所有公开的加密算法和协议，许多应用软件会使用它作为底层库来实现TLS功能。包括常用的Web服务器Apache、Nginx等。
HTTPS中的机密性
实现机密性的常用方法是加密encrypt，就是把为传输的信息上锁（转换成乱码），只有有钥匙的人，才能解锁信息（解密信息）。在这里的描述中，钥匙就是密钥key，加密前的信息叫明文plain text/clear text，加密后的乱码叫密文cipher text，解锁信息的过程叫解密decrypt。整个操作用到的就是加密算法。
密钥是一长串数字，如果密钥长度是 128，就是 16 字节的二进制串，如果密钥长度 1024，就是 128 字节的二进制串。
1字节byte = 8位bit
加密方式主要有三种。如果加密和解密使用了同一个密钥，叫对称加密。如果加密和解密使用了不同的密钥，叫非对称加密。如果既使用了对称加密又使用了非对称加密，这种方式叫混合加密。
对称加密：有很多加密算法，但大都被证明不安全，目前通常使用AES（Advanced Encryption Standar 密钥长度可以是 128、192 或 256）和ChaCha20（Google设计 密钥长度固定为 256 位）。对称加密算法中还有一个分组模式的概念，即让算法用固定长度的密钥加密任意长度的明文，通常使用的分组模式为GCM、CCM 和 Poly1305。比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM。
但是这里存在一个问题，如何把密钥安全地传递给对方，即如何密钥交换？因为如果在传递消息时包含密钥，那被劫持后就可以直接解密信息，加密就没意义了。如果再采用加密密钥的方法，传输加密后的密钥，外层的密钥依然会面临同意的问题。所以只是用对称加密算法，是绝对无法解决密钥交换问题的。
这就出现了非对称加密（公钥加密算法）。非对称加密算法中有两个密钥：公钥public key和私钥private key。
算法规则：公钥加密后只能用私钥解密，私钥加密后只能用公钥解密。
在应用场景中，某服务在网上任意分发公钥，而秘密保管私钥。请求发起时，客户端使用公钥加密信息就可以了，因为除了服务提供商，其他人没有解密的私钥。这就保证了安全传输。非对称加密中目前主要使用的算法是RSA（Rivest–Shamir–Adleman 三位发明者名字）和EEC（Elliptic Curve Cryptography）。
- RSA：加密解密基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。正是这种计算上的困难，确保了解密的困难程度，从而保证了安全性。随着硬件设备算力的提高，目前普遍认为RSA至少要2048位才能安全加密。
- ECC：加密解密基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥。比起 RSA，ECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的 RSA，而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短，所以相应的计算量、消耗的内存和带宽也就少，加密解密的性能就上去了。
基于以上对称加密和非堆成加密的比较，似乎只需要使用非对称加密就能满足机密性了，那对称加密存在的意义是什么？其实在非对称加密中，存在一个明显的问题，即他们都是基于非常复杂的数学难题，需要大量计算。如果用非对称加密加密全部信息，那通信速度会受到影响。请看如下不同算法加密解密1000次花费的时间：
对称加密跟非堆成加密差了几百倍。
基于以上的困境，网络/密码专家们结合了以上两种算法，取长补短，采用了混合加密解决方案。即使用非对称加密算法中的公钥加密一个对称算法中的’会话密钥‘，使用这个对称算法中的’会话密钥‘真正加密发送的信息/数据。这样的好处是，解密对称算法上锁的数据/信息会来得比较快，对称算法的’会话密钥‘又被非对称算法中的’公钥‘安全加密。
如此，安全和性能得以兼顾。
HTTPS中完整性、身份认证、不可否认
为什么完整性是必要的？
机密性被保证之后，黑客拿到的的确是密文，但如果黑客收集到了足够多的密文，再将这些密文修改/重组后发送给服务端，如果没有完整性保证，服务端依然会接受黑客的请求，这样，黑客就可能通过服务端的响应来获得线索并破解明文。
为什么身份认证是必要的？
黑客伪造身份发布公钥，你拿到公钥之后加密信息。对于黑客来说相当于没有加密。即黑客可以伪装成服务端/客户端。
解决完整性痛点的方案是引入摘要算法Digest Algorithm（通常有散列函数、哈希函数，目前TLS推荐使用的是SHA-2）。使用摘要算法把传递的信息/数据转换成一个’摘要‘，然后发送传递的信息+摘要。基于摘要算法的雪崩效应，即原文微小的变动就会使得生成的摘要完全不同。这样，在服务端收到信息+摘要之后，只需要使用同样的算法，把信息再转换成摘要，然后和发送过来的摘要进行比较。如果完全相同，则保证了发送数据的完整性。
考虑一种情况，如果不使用加密算法，仅使用摘要算法是否可以保证传输安全？
如果不对信息加密，黑客完全可以修改消息之后把摘要也改了，这样服务端会认为消息是完整的。因此，完整性需要建立在机密性之上。
解决身份认证痛点的方案是引入数字签名。数字签名的原理，就是使用非对称加密里的私钥，加密上面提到的摘要，加密后的结果就是数字签名。私钥加密后的摘要，如果能够使用公钥解密，则就能证明来源/身份，因为私钥是完全保密的。在发送请求时，客户端和服务端互相交换公钥，就可以用“数字签名”和“验签”来确认消息的真实性，如此同时实现“身份认证”和“不可否认”。
但这里存在一个公钥是否可信的问题。比如黑客发布了公钥，我们如何判断这个公钥是否安全？这就引出了数字证书Certificate和CA Certificate Authority 证书认证机构。
证书认证机构CA会对各个公钥签名。格式包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。换句话说，签名，就是用私钥加密。证书，就是由私钥加密的公钥+相关信息，验证，就是能够用公钥解密。
主要的几家CA： DigiCert、VeriSign、Entrust、Let’s Encrypt
小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。
关于验证证书的过程：
服务器返回的是证书链（不包括根证书，根证书预置在浏览器中和操作系统中），然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书（根私钥加密的一级证书的公钥）得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书（一级私钥加密的二级证书公钥）拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书（验证），得到服务器的公钥和摘要验签。验证过程结束。
注意：以上内容全部来自于罗剑锋老师关于HTTP的课程，属于个人学习笔记，切勿用做商业用途。
