HTTPS 加密了什么内容？

都说HTTPS安全，看了很多解释，却不知道HTTPS加密了哪些内容。有人能用通俗易于理解的话解释一下吗？

我不解的是：
1、好比说邮箱，登录时进行HTTPS加密了，即使提交时保护了账户信息，但之后的请求，邮件服务器返回的网页源代码，信件内容不是都在上面吗？这些信息同时被加密了吗？
2、我访问了某https网站 ，运营商/HK/GFW能查或不能查到我的哪些信息？比如访问请求，提交表单的内容等等……
3、HK劫持到SESSIONID就能轻易的绕过登录，用HTTPS能否起到保护作用？

Q1: HTTPS到底加密了哪些内容？

HTTPS是HTTP Secured的缩写，表示HTTP被安全加密。

如果把HTTP比作信，那么外层的信封（TLS）将会把信（HTTP）的全部内容安全保护起来。

这里的安全保护指的是：

• Encryption：信的内容加密，防止被第三方偷窥。

• Integrity:       信的内容有完整性保护，防止被篡改

• Anti-Replay：每封信序列号唯一，防止被重复发送

• Authenticity：信的来源认证，Key对方才有

TLS = Transport Layer Security，通俗地说，这是一家保安公司，提供以上4个一条龙的安全保护工作。作为一家服务型的乙方，客户（甲方）名单非常庞大：

• http

• smtp

• pop3

• ftp

• http2

• spdy

跑题了，回到这个问题的本身，到底http哪些内容被加密了？

http全部内容都被加密了，直观的想象就是被信封（TLS）全部封装起来了。不可能因为信封/车身太短，http的2条腿还裸露在外面，这是绝不可能发生的事！

Q2：既然HTTPS加密了HTTP全部内容，为何用HTTPS://xxx访问的网站显示不安全？

用户看到的web html页面，既有https返回的页面，也有http返回的页面。

尽管前者是安全的，但后者不安全，所以被浏览器标记为不安全，通常是一个锁上有一个感叹号。

Web页面既包含https安全内容，又有http不安全内容，称之为混合页面（Mixed Content）。

完全https内容的安全页面是这样的：

完全http内容的不安全页面是这样的：

Q3：即邮箱登录HTTPS加密了，信的内容安全吗？

如果只用HTTPS加密邮箱登录，双方成功认证彼此身份，如果接下来用HTTPS全程加密邮件发送/接收，那么就是安全的，可以理解为全部内容都被HTTPS加密了。

如果邮件的发送接收没有HTTPS，那么就是明文发送，这是不安全的。

最早的邮件的发送接收是没有TLS安全保护的，后来有了startssl可以安全保护邮件。但是这个startssl是一个机会主义者，如果SSL/TLS Client Hello发过去几次，服务器没有相应，就会放弃安全保护，而是采用明文传输邮件。

所以攻击方只要丢TLS Client Hello包，就可以让发送方使用明文传输邮件，攻击方就可以i偷窥邮件明文内容了。

Q4: 我访问了某https网站 ，运营商/HK/GFW能查或不能查到我的哪些信息？比如访问请求，提交表单的内容等等……

运营商/HK/GFW可以知道你在访问哪些网站，流量（Byte Size）是多少，从什么时候开始，到什么时候结束，以及你与网站的互动频率是可以知道的。如果他们愿意，随时可以用TCP Reset将这条HTTPS Session给重置了，你都无法知晓到底是服务器、还是他们在重置HTTPS Session。

他们是怎么知道的？

与网站建立https session，会使用DNS查询服务，暴露你在访问哪些网站。

如果他们没观察到DNS查询Packet，也可以通过服务器的IP地址，查询对应的域名。

他们还可以通过Client Hello SNI（Server Name Indicator）知道你在访问哪些网站。

但是具体HTTPS安全加密的内容，即HTTP应用层（七层）提交给TLS安全加密层（五层）的所有数据都是加密的，请求、响应、表单等等一律加密，不用过分担心。

Q5:HK劫持到SESSIONID就能轻易的绕过登录，用HTTPS能否起到保护作用？

HTTPS SESSIONID，由服务器生成并用只有自己知道的Key加密 + 完整性保护，里面的明文内容可以让服务器知晓用户身份信息，但是SESSIONID只有服务器才能解密并真正知晓内容的含义。对应用户来说是一个不透明的数据块（opaque blob），服务器将SESSIONID推送给用户。

如果服务器与用户之间使用HTTPS安全加密，意味着SESSIONID也会被HTTPS安全保护，第三方是劫持不到的。

但是，如果第三方阻止你和服务器之间建立HTTPS安全连接，比如将Client Hello丢了。作为Client的浏览器如何处理呢？

坚贞不屈，一定要用https建立连接。一直在重传Client，每个版本都重试几下：

TLS 1.3

TLS 1.2

TLS 1.1

TLS.1.0

SSL 3.0

如果每个版本都无法建立HTTPS安全连接，就放弃。。。，那么数据就是安全的。

但是，如果浏览器觉得能连接上比安全性更重要，那么会尝试使用HTTP连接服务器。服务器呢，很佛系，很宽容，连吧，HTTP也行。

明文的HTTP传输，如果服务器推送Session ID给客户端，那么就被第三方捕获了。Session ID包含了用户的身份信息，第三方就可以冒用你的身份信息登录网站。

为了缓解这个不安全传输Session ID，将Session ID的属性设置为Secured，即只有底层的传输是安全的（TLS），才可以推送（服务器到客户端方向），才可以使用（客户端到服务器方向）。否则不能推送/使用，比如底层传输为明文传输的TCP。

最后，HTTPS到底安不安全？

1 http的安全强度是由通信双方（Client/server）cipher suite交集的最弱的一组提供的，攻击方可以将HTTPS降级到最弱的一组，从而减小破解的难度。

2 以国家安全的名义，解密HTTPS安全加密的内容并检查，小菜一碟。只要用一个客户端信任的根证书、或者根证书签发的证书，冒用服务器的证书即可。

针对1，目前已经强制废止 SSL 2.0、 3.0 、TLS 1.0、1.1。意味着目前TLS能够提供的保护强度为TLS 1.2最弱的Cipher Suite。

针对2，其实也有方法，只要限定Client只接受某家、或某几家的CA签发的证书，其它的证书不信任即可。

原文始发于微信公众号（车小胖谈网络）：HTTPS 加密了什么内容？