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