版权声明 本站原创文章 由 萌叔 发表
转载请注明 萌叔 | 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 就是为了防范这些攻击

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. 记录协议 The TLS Record Protocol: 让我们再来回顾一下,首先记录协议工作在表示层, 发送端 fragment -> compresses -> mac -> encrypt 数据在发送端被分段,压缩,生成校验码,加密 接收端 decrypt-> verified -> decompress -> reassemble 在接收端,解密,验证校验码,解压,重新装配
可见在这个协议中,至少出现了3种算法
- 压缩算法
- 校验码生成算法
- 加密算法 通讯双方必须事先确定他们共同使用的这三种算法
2. 握手协议 The TLS shakehand Protocol: 记录协议所需确认的算法都是在握手协议中完成的 并且在HTTP在实际传输应用层数据时使用的对称加密算法进行加密(表示层),只有在握手阶段才会用到非对称加密算法
握手协议的执行过程:

关于图中的各个阶段,各类型包的说明,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 下才可以获得详细的握手过程 可以获得详细的通讯记录

可以看出因为多个一个握手环节,https 比http的包至少多出8个包
另外像 ECDHE-RSA-WITH-AES-128-GCM-SHA256 是密码套件的类型码,我们在介绍记录协议时讲过,它需要至少用到三种算法
- 压缩算法
- 校验码生成算法
- 加密算法
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
请我喝瓶饮料
