Fork me on GitHub

版权声明 本站原创文章 由 萌叔 发表
转载请注明 萌叔 | http://vearne.cc

起因:周四下午要在公司做关于https的分享,就顺便结合已经写好的PPT,在CSDN 中也分享下。

参考资料:

  • 加密与解密 电子工业出版社
  • HTTP Over TLS RFC2818
  • The Transport Layer Security (TLS) Protocol RFC5246
  • https://en.wikipedia.org/wiki/Transport_Layer_Security
  • 大型网站的 HTTPS 实践 http://blog.jobbole.com/86660/

上面的参考资料都挺好的,尤其后面4个,如果想彻底了解https必须得读一下

HTTPS是什么?

HTTPS (also called HTTP over TLS, HTTP over SSL and HTTP Secure) is a protocol for secure communication over a computer network which is widely used on the Internet. HTTPS consists of communication over Hypertext Transfer Protocol (HTTP) within a connection encrypted by Transport Layer Security or its predecessor, Secure Sockets Layer.

它解决了什么问题?

  • 内容加密 防止中间人攻击(man-in-the-middle attacks)
  • 身份认证 防止DNS 劫持
  • 数据完整性检查 防止内容被第三方冒充或者篡改

其实我们经常会听到某个消息,就是某些地方性的网络运营商恶意劫持门户网站,在网站上加入未经授权的广告。还有DNS劫持后,网站被指向钓鱼网站。
https 就是为了防范这些攻击

image_1d5tpvbbt1r6hc4p1u7417e419lgvn.png-259.6kB

HTTPS 可以被简单的理解为HTTP + TLS
如果OSI网络模型来理解
HTTP 协议工作在7层应用层, TLS协议工作在5层会话层,6层表示层

In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer).The session layer has a handshake using an asymmetric cipher in order to establish cipher settings and a shared key for that session; then the presentation layer encrypts the rest of the communication using a symmetric cipher and that session key. In both models, TLS and SSL work on behalf of the underlying transport layer, whose segments carry encrypted data

我们知道在网络分层协议中,出于底层的协议会对上一层协议传来的数据包进行封装(增加头信息,校验码等等)
因此当使用https 协议时,所有的http数据包都是被加密传输的(承载在TLS数据包中),无法被直接抓取。

TLS 分为2个主要的子协议
1. 记录协议
2. 握手协议

1. 记录协议 The TLS Record Protocol:
让我们再来回顾一下,首先记录协议工作在表示层,
发送端
fragment -> compresses -> mac -> encrypt
数据在发送端被分段,压缩,生成校验码,加密
接收端
decrypt-> verified -> decompress -> reassemble
在接收端,解密,验证校验码,解压,重新装配

可见在这个协议中,至少出现了3种算法
1. 压缩算法
2. 校验码生成算法
3. 加密算法
通讯双方必须事先确定他们共同使用的这三种算法

2. 握手协议 The TLS shakehand Protocol:
记录协议所需确认的算法都是在握手协议中完成的
并且在HTTP在实际传输应用层数据时使用的对称加密算法进行加密(表示层),只有在握手阶段才会用到非对称加密算法

握手协议的执行过程:

image_1d5tq00rqo0n1n8812id1dv51i3h104.png-30.1kB

关于图中的各个阶段,各类型包的说明,RFC5246中已有详细说明不再赘述,需要强调的是
Certificate server 端向client端提供证书
ServerKeyExchange server 将公钥提供给client端
ClientKeyExchange client 会将 premaster key 用公钥加密后发送给server端

大家可以看到,由于premaster key是由client端生成的,所以该key的值只有client 和server(有私钥可以解出)能够知道,
即使它们中间存在中间人,也无法获知这个key。premaster key 最终会被用于生成对称加密算法所需的key

另外从 Finished 包开始数据包就已经开始加密传输了,所以在抓包时,无法直接分辨出这个包

使用curl -v https://www.baidu.com/
注: ubuntu 下才可以获得详细的握手过程
可以获得详细的通讯记录

image_1d5tq1ddcp8417old6f1f93avv121.png-64.8kB

可以看出因为多个一个握手环节,https 比http的包至少多出8个包

另外像 ECDHE-RSA-WITH-AES-128-GCM-SHA256
是密码套件的类型码,我们在介绍记录协议时讲过,它需要至少用到三种算法
1. 压缩算法
2. 校验码生成算法
3. 加密算法
client 和 server 端是一次性确定这三种算法的具体类型的
对于 ECDHE-RSA-AES-128-GCM-SHA256 它表示
握手阶段的非对称加密算法使用ECDHE
数字证书的算法使用RSA
实际数据通讯的对称加密算法使用 AES--GCM mode
校验码生成算法使用 SHA256

PS:
std.pcapng 是用wireshark 的抓包结果文件,请使用wireshark 打开
使用时可以使用下面的filter语句过滤出TLS 相关协议包
tcp.port eq 443 and ip.addr == 180.149.132.47

std.pcapng 下载地址:
http://download.csdn.net/detail/woshiaotian/8947611


如果我的文章对你有帮助,你可以给我打赏以促使我拿出更多的时间和精力来分享我的经验和思考总结。

微信支付码

发表评论

电子邮件地址不会被公开。

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据