HTTPS协议三次握手——通过抓包工具wireshake来观察握手过程

  • TCP是英特网上的可靠连接，TCP为HTTP提供了一条可靠地比特传输通道，从TCP连接一端填入的字节会从另一端以原有的顺序、正确的传送出来。

    TCP会按序、无差错的承载HTTP数据，如下图：

     

    2、TCP流是分段的，由IP分组传送

    TCP的数据是通过名为IP分组的小数据块发送的，HTTP就是“HTTP over TCP over IP”这个“协议栈”中的最顶层，其安全版本HTTPS就是在HTTP和TCP之间插入一个（TLS或SSL）密码加密层。

    如下图所示：

  • https：在http(超文本传输协议)基础上提出的一种安全的http协议，因此可以称为安全的超文本传输协议。http协议直接放置在TCP协议之上，而https提出在http和TCP中间加上一层加密层。从发送端看，这一层负责把http的内容加密后送到下层的TCP，从接收方看，这一层负责将TCP送来的数据解密还原成http的内容。
  • SSL(Secure Socket Layer)：是Netscape公司设计的主要用于WEB的安全传输协议。从名字就可以看出它在https协议栈中负责实现上面提到的加密层。因此，一个https协议栈大致是这样的：
  • 数字证书：一种文件的名称，好比一个机构或人的签名，能够证明这个机构或人的真实性。其中包含的信息，用于实现上述功能。
  • 加密和认证：加密是指通信双方为了防止铭感信息在信道上被第三方窃听而泄漏，将明文通过加密变成密文，如果第三方无法解密的话，就算他获得密文也无能为力；认证是指通信双方为了确认对方是值得信任的消息发送或接受方，而不是使用假身份的骗子，采取的确认身份的方式。只有同时进行了加密和认真才能保证通信的安全，因此在SSL通信协议中这两者都被应。用邮局的例子来解释下对称加密

    Alice 在盒子里放有信息，盒子上有挂锁，她有钥匙。通过邮局她把这个盒子寄给Bob。Bob收到盒子后，用相同的钥匙打开盒子(钥匙之前就得到了，可能是Alice面对面给他的)。然后Bob可以用同样的方法回复。

    理解SSL(https)中的对称加密与非对称加密

    对称加密可以分为两种：一种是一个一个加密信息，另一种是分块加密信息，通常分为64位加密为一块。块Twofish, Serpent, AES (Rijndael), Blowfish, CAST5, RC4, TDES, and IDEA.

    非对称加密

    Bob和Alice各有自己的盒子。Alice要跟Bob秘密通信，她先让Bob把开着的盒子通过邮局发给她。Alice拿到盒子后放入信息锁上，然后发给Bob。Bob就可以用他自己的钥匙打开了。回复的话就用同样的方法。

    理解SSL(https)中的对称加密与非对称加密

    此法最大的好处是你不必得到对方的“钥匙”，以防别人在钥匙发送过程中偷偷复制钥匙，进而窃取信息。而且就算Bob的钥匙被窃取复制了，Alice跟别人的通信也是安全的，因为Alice用的是别人的钥匙。

    非对称算法在加密和解密时用的是不同的钥匙。信息接受者有两把钥匙：一把“公匙”，一把“私匙”。公匙是给信息发送者用来加密的，私匙是自己用来解密的这样最大的好处是：不必通过不安全的渠道发送私密的东西。公匙本来就是给别人用的，不用藏好。你的私匙在你产生私匙的电脑里保存着。

    网站如何通过加密和用户安全通信

    SSL (Secure Sockets Layer) 是用来保障你的浏览器和网站服务器之间安全通信，免受网络“中间人”窃取信息。SSL原理很简单。

    一、当你的浏览器向服务器请求一个安全的网页(通常是 https://)

    理解SSL(https)中的对称加密与非对称加密

    二、服务器就把它的证书和公匙发回来

    理解SSL(https)中的对称加密与非对称加密

    三、浏览器检查证书是不是由可以信赖的机构颁发的，确认证书有效和此证书是此网站的。

    理解SSL(https)中的对称加密与非对称加密

    四、浏览器中随机生成一对对称秘钥，并使用公钥（服务器端的）加密该对称秘钥，将它和对称加密后的URL一起发送到服务器

    理解SSL(https)中的对称加密与非对称加密

    五、服务器用自己的私匙解密了你发送的钥匙。然后用这把对称加密的钥匙给你请求的URL链接解密。

    理解SSL(https)中的对称加密与非对称加密

    六、服务器用你发的对称钥匙给你请求的网页加密。你也有相同的钥匙就可以解密发回来的网页了

    理解SSL(https)中的对称加密与非对称加密
    ---------------------

    原文：https://blog.csdn.net/mooncom/article/details/60140372

 

 

SSL/TLS握手过程可以分成两种类型：

1）SSL/TLS 双向认证，就是双方都会互相认证，也就是两者之间将会交换证书。
2）SSL/TLS 单向认证，客户端会认证服务器端身份，而服务器端不会去对客户端身份进行验证。

我们知道，握手过程实际上就是通信双方协商交换一个用于对称加密的密钥的过程，而且握手过程是明文的。
这个过程实际上产生三个随机数:client random, server random, pre-master secret. 参考图解SSL/TLS协议 .

前两个随机数都是明文传送的，只有pre-master secret是加密的（RSA或者DH)。
一般生成证书的时候，签名算法可以选择RSA或者DSA算法。
如果server使用RSA证书，RSA即可以用作签名也可以用作不对称加密，pre-master secret就是用server的RSA证书中包含的公钥加密的。
如果server使用DSA证书，DSA只能用作签名，所以还需要使用DH算法来交换密钥。

以下是其流程图（摘自rfc5246），括号中的步骤是可选的。
如果是单向认证，那么蓝色字体部分是不需要的。
4 server_key_exchange这一步只有在选择了某些密钥交换算法例如DH算法的时候才需要。

Client
    

Server
1 Client Hello     
    

2 Server Hello
3 certificate
4 (server_key_exchange)
5 (certificate_request)
6 server_hello_done
7 (certificate)
8 client_key_exchange
9 (certifiate_verify)
10 change_cypher_spec
----finished----     
    11 change_cypher_spec
----finished----


下面使用wireshark抓取握手过程的报文。server/client使用JAVA7/JSSE编码。
server证书签名算法RSA-双向认证

可见包括了除了4以外的所有步骤。因为采取了RSA算法，所以步骤4是不需要的。

(一) 首先,客户端向服务器提供以下信息

client_hello
（1）支持的协议版本，比如TLS 1.0
（2）支持的加密算法(Cipher Specs)
（3）客户端生成的随机数1(Challenge)，稍后用于生成"对话密钥"。

(二)服务器回答给客户端以下信息

server_hello
（1） 确认使用的协议版本
（2） 服务器生成的随机数2，稍后用于生成"对话密钥"
（3） session id
（4） 确认使用的加密算法
certificate
服务器证书
server_key_exchange
如果是DH算法，这里发送服务器使用的DH参数。RSA算法不需要这一步。
certificate_request
要求客户端提供证书，包括
（1） 客户端可以提供的证书类型
（2）服务器接受的证书distinguished name列表，可以是root CA或者subordinate CA。如果服务器配置了trust keystore, 这里会列出所有在trust keystore中的证书的distinguished name。
server_hello_done
server hello结束

(三)客户端发送给服务器

certificate
客户端证书
client_key_exchange
包含pre-master secret。客户端生成第三个随机数。如果是采用RSA算法，会生成一个48字节随机数，然后用server的公钥加密之后再放入报文中；如果是DH算法，这里发送的就是客户端的DH参数，之后服务器和客户端根据DH算法，各自计算出相同的pre-master secret。
certificate_verify
发送使用客户端证书给到这一步为止收到和发送的所有握手消息签名结果。
change_cipher_spec
客户端通知服务器开始使用加密方式发送报文。客户端使用上面的3个随机数client random, server random, pre-master secret, 计算出48字节的master secret, 这个就是对称加密算法的密钥。
finished
客户端发送第一个加密报文。使用HMAC算法计算收到和发送的所有握手消息的摘要，然后通过RFC5246中定义的一个伪函数PRF计算出结果，加密后发送。

(四) 服务器发送给客户端
服务器端发送change_cipher_spec和finished消息。到这里握手结束。

server证书签名算法DSA-双向认证

下面是一个server证书采用DSA算法的握手过程。由于采用了DH算法交换密钥，多了server_key_exchange这一步。

 
server证书签名算法RSA-单向认证

和双向认证相比，server端少了certificate_request，client端少了certificate 和 certificate_verify。

---------------------
作者：fw0124
来源：CSDN
原文：https://blog.csdn.net/fw0124/article/details/40983787
版权声明：本文为博主原创文章，转载请附上博文链接！

 

posted on 2020-09-22 17:18  qiaoli  阅读(757)  评论(0)  编辑  收藏  举报

导航