HTTPS相关

发表于 | 更新于: | 分类于

最近遇到了一件事, 让我又多熟悉了下HTTPS的相关内容, 先看看HTTPS的结构

通常的HTTP网络结构如下

1
2
3
4
5
6
7
8
+------+
| HTTP |
+------+
| TCP  |
+------+
|  IP  |
+------+
  ...

HTTP的的相关内容是通过TCP明文传输的, 如果有中间监听者, 可以直接看结相关内容.

HTTPS的结构

1
2
3
4
5
6
7
8
9
10
+------+
| HTTP |
+------+
| TLS  |
+------+
| TCP  |
+------+
|  IP  |
+------+
  ...

TCP和HTTP之前多了一次处理, 会将HTTP的内容加密后再通过TCP传输.
TLS握手过程中, 会协商使用的TLS版本, 加密方式及密钥, 会通过证书确认身份, 生成的密钥也会加密, 不想被看见握手过程的话, 目前还可以采用ESNI.
这里并不能完全匿名, 因为还是能通过网络层知道你的目的地址, 但是具体请求的内容就不会被看见了.

以下案例纯虚假编造的, 如有雷同, 纯属巧合.
客户需求大概是这样, 希望在前后端传输过程中密码等敏感内容不要明文暴露, 不被中间劫持获取.
x公司x高级架构师采用的是这样的方案:

  • 前后端使用HTTP通信
  • 前端对相关敏感内容对称加密后传给后端, 后端解密获取内容

不采用TLS的理由如下:

  • 可以通过浏览器漏洞获取
  • HTTPS可以被暴力破解

先说下采用的方案和不合理, 目前产品是传统的BS模式, 也就是说网页会从后端获取.
因为网页是从后端获取的, 而且是HTTP, 也就是说中间劫持者也可以获取网页内容, 通过分析js就能获取具体的加密方式, 即使对js进行混淆也最多是花的时间稍微长那么一点, 所以说这个方案完全无用, 当然欺骗一下不懂技术的客户还是可以的, 但是从技术角度是完全不可行的.
这里我们可以改一下产品的模式还是可行的, 使用electron等类似的技术将网页包装成一个客户端, 不通过后端获取网页还是可行的, 可能在使用上麻烦了一点, 但是这才能真正让前端的加密具有意义.

再分析下不采用TLS的理由:

  • 可以通过浏览器漏洞获取
    这句话是废话, 浏览器真有漏洞不管是HTTP还是HTTPS都无用的.

  • HTTPS可以被暴力破解

这里我们先分析下, 目前HTTPS可能被破解的几种方式.

  1. 第一种, 在握手阶段使用虚假的证书进行握手, 这里需要在浏览器或者是客户端的系统上导入虚假的证书, 不过我认为一个安全意识很高的公司是不会随意导入不认识的证书的.
  2. 第二种, 暴力破解TLS的加密, 不计时间情况下当然能被破解, 但是现代密码学, 即使使用超级计算机暴力破解都要花费很长很长时间.

总上所述, 这句话也是废话.