有朋友在面试字节,被问到这个问题:HTTPS 会加密 URL 吗?
答案是,会加密的。
因为 URL 的信息都是保存在 HTTP Header 中的,而 HTTPS 是会对 HTTP Header + HTTP Body 整个加密的,所以 URL 自然是会被加密的。
下图是 HTTP/1.1 的请求头部,可以看到是包含 URL 信息的。
对应的实际的 HTTP/1.1 的请求头部:
HTTP/1.1 请求的第一行包含请求方法和路径。HTTP/2 用一系列伪头部(pseudo-header)替换了请求行,这五个伪头部很容易识别,因为它们在名称的开头用了一个冒号来表示。
比如请求方法和路径伪头字段如下:
":method" 伪头字段包含了 HTTP 方法;
":path" 伪头字段包含目标 URL 的路径和查询部分;
如下图
上图是我浏览器 F12 开发者工具查看的信息,浏览器显示信息是已经解密后的信息,所以不要误以为 URL 没有加密。
如果你用抓包工具,抓包 HTTPS 的数据的话,你是什么都看不到的,如下图,只会显示“Application Data”,表示这是一个已经加密的 HTTP 应用数据。
HTTPS 可以看到域名吗?
再问大家一个问题,HTTPS 可以看到请求的域名吗?
从上面我们知道,HTTPS 是已经把 HTTP Header + HTTP Body 整个加密的,所以我们是无法从加密的 HTTP 数据中获取请求的域名的。
但是我们可以在 TLS 握手过程中看到域名信息。
比如下图,TLS 第一次握手的 “Client Hello” 消息中,有个 server name 字段,它就是请求的域名地址。
HTTPS 的应用数据是如何保证完整性的?
TLS 的握手协议我相信大家都很熟悉了,我也写过很多相关的文章了:
HTTPS RSA 握手解析
HTTPS ECDHE 握手解析
然后对于 HTTPS 是怎么加密 HTTP 数据的,我没有提到过。
然后很多读者以为 HTTP 数据就用对称加密密钥(TLS 握手过程中协商出来的对称加密密钥)加密后就直接发送了,然后就疑惑 HTTP 数据有没有通过摘要算法来保证完整性?
事实上,TLS 在实现上分为握手协议和记录协议两层:
TLS 握手协议就是我们说的 TLS 四次握手的过程,负责协商加密算法和生成对称密钥,后续用此密钥来保护应用程序数据(即 HTTP 数据);
TLS 记录协议负责保护应用程序数据并验证其完整性和来源,所以对 HTTP 数据加密是使用记录协议;
TLS 记录协议主要负责消息(HTTP 数据)的压缩,加密及数据的认证,过程如下图:
具体过程如下:
首先,消息被分割成多个较短的片段,然后分别对每个片段进行压缩。
接下来,经过压缩的片段会被加上消息认证码(MAC 值,这个是通过哈希算法生成的),这是为了保证完整性,并进行数据的认证。通过附加消息认证码的 MAC 值,可以识别出篡改。与此同时,为了防止重放攻击,在计算消息认证码时,还加上了片段的编码。
再接下来,经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。
最后,上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的加密报文数据。
记录协议完成后,最终的加密报文数据将传递到传输控制协议 (TCP) 层进行传输。
网友评论