HTTPS
HTTPS 其实是一个“非常简单”的协议，RFC 文档很小，只有短短的 7 页，里面规定了新的协议名“https”，默认端口号 443，至于其他的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP，没有任何新的东西。
也就是说，除了协议名“http”和端口号 80 这两点不同，HTTPS 协议在语法、语义上和 HTTP 完全一样，优缺点也“照单全收”（当然要除去“明文”和“不安全”）。
SSL/TLS是位于TCP、IP7层协议中的会话层，用于认证用户和服务端，加解密数据以及维护数据的完整性，确保数据传输过程中不会被修改。
SSL 有 v2 和 v3 两个版本，而 v1 因为有严重的缺陷从未公开过。SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1
到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和去年（2018）的 1.3，每个新版本都紧跟密码学的发展和互联网的现状，持续强化安全和性能，已经成为了信息安全领域中的权威标准。
目前应用的最广泛的 TLS 是 1.2，而之前的协议（TLS1.1/1.0、SSLv3/v2）都已经被认为是不安全的，各大浏览器即将在 2020 年左右停止支持，所以接下来的讲解都针对的是 TLS1.2。
TLS由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。浏览器和服务器在使用TLS建立连接时需要选中一组恰当的加密算法来实现安全通信，这些算法的组合被称为“密码套件”（也叫加密条件）。
SSL/TLS分为对称加密和非对称加密两种方式。
对称加密
对称加密是指加密和解密都用同一份秘钥。
AES（Adavanced Encryption Standard）,秘钥长度可以是128.192或256.它是DES算法替代者，安全强度很高
非对称加密对应于一对秘钥，称为私钥和公钥，用私钥加密后需要用公钥解密，用公钥加密后需要用私钥解密
对称加密看上去好像完美地实现了机密性，但其中有一个很大的问题：如何把秘钥安全地传递给对方，术语叫“密钥交换”。
所以就出现了非对称加密（也叫公钥加密算法）
它有两个秘钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个秘钥是不同的，“不对称”，公钥可以公开给任何人使用，而秘钥必须严格保密。
公钥和私钥有个特别的“单向”性，虽然都可以用来加解密，但公钥加密后只用只能用私钥解密，反过来，私钥加密后也只能用公钥解密。
非对称加密可以解决秘钥交换的问题。网站秘密保管私钥，在网上任意分发公钥，你想要登录网站只要用公钥加密就行了，密文只能由私钥持有者才能解密
比起RSA，ECC在安全强度和性能上都有明显的优势。160位的ECC相当于1024位的RSA，秘钥短消耗的内存和宽带也就少，
TLS把对称加密和非对称加密结合起来，两者相互取长补短，既能高效的加密解密，又能安全地秘钥交换。
在通信刚开始的时候使用非对称算法，解决秘钥交换的问题。
然后用随机数产生对称算法使用的“会话秘钥”，再用公钥加密。因为会话秘钥很短，16字节或32字节，慢一点无所谓。
对方拿到密文后用私钥解密，取出会话秘钥。这样，双发就实现了对称秘钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。
这样混合加密就解决了对称加密算法的秘钥交换问题，而且安全和性能兼顾，完美地实现了机密性
不过这只是“万里长征的第一步”，后面还有完整性、身份认证、不可否认等特性没有实现，所以现在的通信还不是绝对安全。
数字签名与证书
黑客虽然拿不到会话秘钥，无法破解米粉，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。因为没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。
另外，黑客也可以伪造身份发布公钥。如果你拿到了假的公钥，混合加密就完全失效了，你以为自己是在和“某宝”通信，实际上网线的另一端却是黑客，一些敏感信息被窃取
所以，在机密性的基础上还必须加上完整性，身份认证等特性，才能实现真正的安全。
摘要算法
实现完整性的手段主要是摘要算法（Digest Algorithm）,也就是常说的散列函数、哈希函数。
你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度，而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”；
换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有秘钥，加密后的数据无法解密，不能从摘要逆推出愿望
摘要算法实际上是把数据从一个“大空间”映射到了“小空间”，所以就存在“冲突”的可能性，就如同现实中的指纹一样，可能会有两份不同的原文对应相同的摘要。好的摘要算法必现能够“抵抗冲突”，让这种可能性尽量地小。
因为摘要算法对输入具有“单向性”和雪崩效应，输入的微小不同会导致剧烈的变化，也被TLS用来生成伪随机数。
MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它们就是最常用的两个摘要算法，能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低，不够安全，在 TLS 里已经被禁止使用了。
目前 TLS 推荐使用的是 SHA-1 的后继者：SHA-2。
SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。
完整性
摘要算法保证了“数字摘要”和原文完全是等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。
比如，你发了条消息：“转账100元”，然后加上一个SHA-2的摘要。网站收到后也计算一下消息的摘要，把这两份“指纹”做个对比，如果一致。就说明消息是完整可信的，没有被修改。
如果黑客在中间哪怕改动了一个标点符号，摘要也会完全不同，网站计算比对就会发现消息被篡改，是不可信的。不过摘要算法不具有机密性，如果明文传输，那么黑客可以修改消息后把摘要也一起改了，网站还是鉴别不出完整性。
所以，真正的完整性必须建立在机密性上，在混合加密系统里用会话秘钥加密消息和摘要。
数字签名
加密算法结合摘要算法，我们的通信过程可以说是比较安全了。但这里还有漏洞，就是通信的两个端点（endpoint）。
就像一开始所说的，黑客可以伪装网站来窃取信息。而反过来，它也可以伪装成你，向网站发送支付、转账等消息，网站没有办法确认你的身份，钱可能就这么飞走了。
现实生活中，解决身份认证的手段是签名加印章，只要在纸上写下签名或者盖个章，就能够证明这份文件确实是由本人而不是其他人发出的。
在这里，使用非对称加密里的“私钥”再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”。
数字签名的原理其实很简单，就是把公钥私钥的用法反过来，之前是公钥加密，私钥解密，现在是私钥加密，公钥解密。
但又因为非对称加密效率太低，所以私钥只加密原文的摘要，这样运算量就小的多，而且得到的数字签名也很小，方便保管和传输。
签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再对比原文验证完整性，可以像签署文件一样证明消息确实是你发的。
刚才的这两个行为也有专用术语，叫做“签名” 和 “验签”。
只要你和网站互相交换公钥，就可以用“签名” 和 “验签” 来确认消息的真实性，因为私钥保密，黑客不能伪造签名，就能够保证通信双方的身份。
比如，你用自己的私钥签名一个消息“我是小明”。网站收到后用你的公钥验签，确认身份没问题，于是也用它的私钥签名消息“我是某宝”。你收到后再用它的公钥验一下，也没问题，这样你和网站就都知道双方不是假冒的，后面就可以混合加密进行安全通信了。
数字证书和CA
（到现在，综合使用对称加密，非对称加密和摘要算法，是不是已经完美了呢？）
不是的，这里还有一个“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说怎么判断这个公钥就是你或者某宝的公钥呢？
我们可以用类似秘钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，又会陷入“无穷递归”。但是这次实在是“没招”了，要终结这个“死循环”，就必须引入“外力”，招一个公认的可信的第三方，让它作为"XI信任的起点，递归的终点"，构建起公钥的信任链。
这个“第三方”就是我们常说的CA（“Certifivate Authority”, 证书认证机构）。它就像网络世界里的公证中心，由它给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。CA对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。
知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。
DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。
不过，CA 怎么证明自己呢？
这还是信任链的问题。小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了。
有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。
证书体系的弱点
证书体系（PKI，Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，还是关键的“信任”二字。
如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。
还有一种更危险的情况，CA 被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。
这两种事情并不是“耸人听闻”，都曾经实际出现过。所以，需要再给证书体系打上一些补丁。
针对第一种，开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。
对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。
