• 文章比较长,赠于有缘人

HTTPS简介

  • HTTPS,是一种网络安全传输协议,在HTTP的基础上利用SSL/TLS来对数据包进行加密,以提供对网络服务器的身份认证,保护交换数据的隐私与完整性。
    • TLS(Transport Layer Security)1.0是SSL(Secure Sockets Layer)3.0的升级版,安全套接字层协议,承担的角色都是一样的,是HTTPS方式握手以及传输数据的一个协议。只是改了名字,其中的八卦,感兴趣的朋友可以自己去搜索。
  • HTTP(S)协议是在TCP/IP协议基础上建造的。
  • TCP/IP协议的分层管理,按层次分为:应用层、传输层、网络层、数据链路层。(我们常说的四层协议、四层模型就是指的这个啦)
  • 没有经过加密层时,数据传输的路径是:应用层->传输层->网络层->数据链路层
  • 经过加密层之后,数据传输的路径是:应用层->SSL/TLS层->传输层->网络层->数据链路层
  • 每层常见的协议:
    • 应用层协议有:FTP、Telnet、SMTP、HTTP、RIP、NFS、DNS。
    • 传输层协议有:TCP协议、UDP协议。
    • 网络层协议有:IP协议、ICMP协议、ARP协议、RARP协议。

HTTPS用途

  • 防窃听:HTTPS协议对传输数据的内容加密,保障数据在传输过程的安全(加密传播)
  • 防冒充:确认网站的真实性(身份证书)
  • 防篡改:防止内容被第三方篡改(校验机制)

HTTPS协议安全性

  • HTTPS协议本身是安全的,并且能够保障数据传输安全、两端身份真实、以及检查数据是否被篡改。
  • 但近几年有https相关的漏洞频发,如心血漏洞、中间人攻击、DROWN溺水攻击、FREAK漏洞、降维攻击、POODLE等(近期会将每个漏洞原理进行分析)。不由让人为https的安全性担忧,其实这个协议的逻辑一般是设计的非常安全了,即使出现问题,也会有大版本的升级(如TLS 1.0升级为TLS 1.1)。而且频发漏洞的并不是https协议本身,而是各个开源或商业服务在具体实现https时,出现了安全问题。

https如何进行数据传输的?

  • 大致流程是:进行握手流程建立https连接(此时是明文传输),然后再进行真正的数据传输(此时使用对称加密进行密文传输)
  • 首先需要了解TLS/SSL协议握手的过程

握手过程

  • 整个过程,如访问www.baidu.com
    • 先进行DNS解析,再建立TCP连接,然后进行https握手,最后传输加密数据。

握手消息 动作描述 消息内容
1. Client —> ClientHello —> Server 客户端(浏览器)发送一个hello消息给服务端,发起建立SSL会话的请求。并告诉服务端,自己支持哪些加密算法(Cipher Suite List)。除此之外,还需要产生一个随机数(第一个随机数,用于以后生成对称密钥),发送给服务端。 1)支持的协议版本,如TLS 1.0版
2)由客户端生成的随机数,用于生成后面的“对称密钥”
3)支持的加密方法,比如RSA公钥加密
4)支持的压缩方法
5)请求的域名
2. Server —> ServerHello —> Client 服务端的首次响应,会确定加密协议版本,以及加密的算法,也会生成一个随机数(第二个随机数)给客户端。 1)协议的版本
2)加密的算法
3)服务端生成的随机数
3. Server —> Certificate —> Client 还会把自己的证书发送给客户端,让客户端进行校验。服务端证书中的公钥也可被用于加密后面握手过程中生成的对称密钥。 1)服务端证书
证书颁发机构的名称
证书本身的数字签名
证书持有者公钥
证书签名用到的Hash算法
4. Server --> ServerKeyExchange —> Client 指定使用哪种密钥协商协议。服务端可以在ServerKeyExchange之后立即发送CertificateRequest消息,要求校验客户端的证书。 1)使用哪种密钥协商方式
2)密钥协商时客户端需要的信息
5. Server —> ServerHelloDone —> Client 服务器发送ServerHelloDone消息,告知客户端服务器这边握手相关的消息发送完毕。
6. Client —> ClientKeyExchange —> Server 消息中包含客户端这边的EC Diffie-Hellman算法相关参数,然后服务器和客户端都可根据接收到的对方参数和自身参数运算出对称密钥。 1)密钥协商时服务端需要的信息
7. Client —> ChangeCipherSpec —> Server ChangeCipherSpec消息,通知服务器此消息以后客户端会以加密方式发送数据。 准备好了做加密传输的通知
8. Client —> Finished —> Server 客户端计算生成对称密钥,然后使用该对称密钥加密之前所有收发握手消息的Hash值,发送给服务器,服务器将相同的会话密钥(使用相同方法生成)解密此消息,校验其中的Hash值。
9. Server —> ChangeCipherSpec —> Client ChangeCipherSpec消息,通知客户端此消息以后服务器会以加密方式发送数据。 准备好了做加密传输的通知
10. Server — > Finished —> Client 服务器使用对称密钥加密(生成方式与客户端相同)之前所发送的所有握手消息的hash值,发送给客户端去校验。
11. Application Data 真正的数据传输(使用对称加密)

1. Client Hello

  • 客户端发起TLS握手请求
    struct {
            ProtocolVersion client_version;
            Random random;
            SessionID session_id;     
            CipherSuite cipher_suites<2..2^16-2>;
            CompressionMethod compression_methods<1..2^8-1>;
            select (extensions_present) {
                case false:
                    struct {};
                case true:
                    Extension extensions<0..2^16-1>;
            };
        } ClientHello;
    
  • 数据包括内容:
    • ProtocolVersion/协议版本(客户端期望支持的握手协议版本
    • Random/安全随机数(MasterSecret生成用到,协议文档里面说是28个字节,但是实际抓包看到是32个字节,这里怀疑是各个协议文档版本不同,还有使用加密套件的不同,导致的差异,具体博主就没有在继续深究了,如果有朋友知道可以留言给我)
    • SessionID/会话ID
      • 这个值是被服务端设置的,如果这个值为空,表示客户端与服务端没有存活的https会话,需要与服务端进行完整的握手。
      • 如果这个值存在,则表明客户端期望恢复上一次的https会话,这时候客户端与服务端只需要进行快速的握手过程。(这里我们只会分析完整的握手过程进行学习)
    • CipherSuite/加密套件(客户端支持的加密套件列表)
      • 如果sessionid不为空,可以不传这个值,服务端可以从上一次会话中恢复这个值。
      • 每个加密组件(Cipher Suite)都包括了下面5类算法 TLS Cipher Suite Registry,图中百度使用的是就是 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 这个加密套件:
        • 1、authentication (认证算法):RSA
        • 2、encryption (加密算法 ):AEAD_AES_128_GCM
        • 3、message authentication code (消息认证码算法 简称MAC):SHA256
        • 4、key exchange (密钥交换算法):ECDHE
        • 5、key derivation function (密钥衍生算法)
    • CompressionMethod/压缩方法
      • 加密前进行数据压缩
      • 因为压缩方法被攻击,在TLS1.3协议版本上已经彻底禁止压缩了。(这里有两种攻击方式BREACH、CRIME,有时间博主会来研究)
    • Extension/扩展数据(session ticket在扩展里面,可见下图)
  • 消息内容如下图:

2. Server Hello

  • 服务端回应Client Hello请求
点击收藏 | 1 关注 | 0
登录 后跟帖