HTTPS如何确保安全
- 什么是Https
- Https的作用
- Https的劣势
- HTTPS和HTTP的区别
- https的整个架构
- SSL (Secure Socket Layer)
- TLS (Transport Layer Security，传输层安全协议)
- SSL/TLS协议作用
- TLS比SSL的优势
- SSL、TLS的握手过程
- 总结
- 一点点数学
什么是Https
- HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP 通道，简单讲是HTTP的安全版
- HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL
Https的作用
- 内容加密 建立一个信息安全通道，来保证数据传输的安全；
- 身份认证 确认网站的真实性
- 数据完整性 防止内容被第三方冒充或者篡改
Https的劣势
- 对数据进行加解密决定了它比http慢：需要进行非对称的加解密，且需要三次握手。首次连接比较慢点，当然现在也有很多的优化
- 出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令， HTTPS是可以缓存的。Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control: Public，缓存就会被写到硬盘上。 IE只要http头允许就可以缓存https内容，缓存策略与是否使用HTTPS协议无关
HTTPS和HTTP的区别
- https协议需要到CA申请证书
- http是超文本传输协议，信息是明文传输；https则是具有安全性的ssl加密传输协议
- http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
- http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全
https的整个架构
对称加密
- 对称加密(也叫私钥加密)指加密和解密使用相同密钥的加密算法。有时又叫传统密码算法，就是加密密钥能够从解密密钥中推算出来，同时解密密钥也可以从加密密钥中推算出来。而在大多数的对称算法中，加密密钥和解密密钥是相同的， 所以也称这种加密算法为秘密密钥算法或单密钥算法。
- 常见的对称加密有：DES（Data Encryption Standard） 、 AES（Advanced Encryption Standard）、RC4、IDEA
非对称加密
- 与对称加密算法不同，非对称加密算法需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）；并且加密密钥和解密密钥是成对出现的。非对称加密算法在加密和解密过程使用了不同的密钥，非对称加密也称为公钥加密， 在密钥对中，其中一个密钥是对外公开的，所有人都可以获取到，称为公钥，其中一个密钥是不公开的称为私钥
- 非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048 位，意味着待加密内容不能超过 256 个字节
摘要算法
- 数字摘要是采用单项Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文， 这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的， 而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因
数字签名
- 数字签名技术就是对“非对称密钥加解密”和 “数字摘要“两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同， 则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性
- 数字签名的过程如下：
- 明文 --> hash运算 --> 摘要 --> 私钥加密 --> 数字签名
- 数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围
数字证书
- 为什么要有数字证书？
- 对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有被篡改过呢？亦或者请求的目标主机本本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构(一般是由*审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生
- 数字证书的颁发过程
- 用户首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。用户就可以使用自己的数字证书进行相关的各种活动。数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度
- 证书包含哪些内容
- 证书颁发机构的名称
- 证书本身的数字签名
- 证书持有者公钥
- 证书签名用到的Hash算法
- 验证证书的有效性
- 浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥
- 证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
- 证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了，认为是危险证书
- 对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A，然后再根据签名的Hash算法计算出证书的摘要B，对比A 与B，若相等则正常，若不相等则是被篡改过的
- 证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形： 浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发 机构，后者会告诉浏览器证书是否还是有效的
SSL (Secure Socket Layer)
- SSL (安全套接字层)为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3.0版本
- SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP） 之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在 实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等
TLS (Transport Layer Security，传输层安全协议)
- 用于两个应用程序之间提供保密性和数据完整性
- TLS 1.0是IETF（Internet Engineering Task Force， Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了RFC 的。该协议由两层组成： TLS 记录协议（TLS Record） 和TLS 握手协议（TLS Handshake）。较低的层为TLS 记录协议，位于某个可靠的传输协议（例如TCP）上面
SSL/TLS协议作用
- 认证用户和服务器，确保数据发送到正确的客户机和服务器
- 加密数据以防止数据中途被窃取
- 维护数据的完整性，确保数据在传输过程中不被改变
TLS比SSL的优势
- 对于消息认证使用密钥散列法： TLS 使用“ 消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会 被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码） MAC 功能更安全
- 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF 使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露， 则数据仍然是安全的
- 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息 认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上， 这也比SSLv3.0更安全
- 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型
- 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录
SSL、TLS的握手过程
- 客户端首次发出请求
- 由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret
- 客户端需要提供如下信息：
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数，稍后用于生成”对话密钥”
- 支持的加密方法，比如RSA公钥加密
- 支持的压缩方法
- 服务端首次回应
- 服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端，这里的随机数是整个过程的第二个随机数
- 服务端需要提供的信息：
- 协议的版本
- 加密的算法
- 随机数
- 服务器证书
- 客户端再次回应
- 客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器， 确保正式通信前无误
- 客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret
- 服务器再次响应
- 服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功
- 后续客户端与服务器间通信
- 确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了
总结
- https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
一点点数学
- 公钥算法的特点就是很容易由算子计算出结果， 而基本上不可能作逆向运算。这也就是使用了两个质数的所要达到的目的
- 现在假设Alice和Bob分别是参与DH式密钥交换过程的两方，他们一开始会商议确定一个小质数
（一般是2,3,5这样的小数字）和一个大质数
（有300位以上）作为加密的原始信息。小质数和大质数都可以直接传输，不必担心交换过程中的不安全 - 需要明白的是，Alice和Bob各自都持有着自己的私钥（100多位的数），而且也永远不应该共享自己的私钥。不光是两人之间，也包括其他不相关的人都不应该拥有这两组私钥。网络中传输的是他们的私钥、小质数和大质数混合运算得到的结果。更确切来说，就是：
- Alice的结果 = （小质数Alice的密码）% 大质数
- Bob的结果 = （小质数Bob的密码）% 大质数
- （“%” 符号表示取模运算，即取得除法运算的余数）
- 所以Alice使用大质数和小质数加上自己的私钥运算，就会得出结果，而Bob做同样的计算，也能得到相同的结果。当他们接收到对方的运算结果时，他们可以由数学计算导出会话中所要传输的信息，也就是说：Alice计算的是
- （Bob的结果Alice的密码）% 大质数而Bob则计算
- （Alice的结果Bob的密码）% 大质数
- Alice和Bob得出来的数字相同，这个数字也就是会话中所要共享的密码。请注意，双方都没有向对方传输各自的私钥，而连接过程中也没有明文传递保密信息。这一点真是太棒了！
- 请注意图中一开始的颜色（黄色）最后都会有Alice和Bob的颜色参与计算。这就是双方会得到同样结果的原因。对于观看中间过程的人来说，唯一在连接中发送的半合成信息是毫无意义的