SSL握手过程详解

转载自http://xeseo.blog.163.com/blog/static/5632431620132843532672/

1. 客户端发送一个Hello消息给服务器,该消息包含以下参数:

* 客户端支持的SSL的版本列表

* 客户端所支持的加密算法列表

* 随机数 ClientHello.random

2.1 服务器端回应一个Hello消息给客户端,该消息包含以下内容:

* 握手期间使用的SSL的版本

* 握手期间将使用的密钥交换算法 (Deffie-Hellman算法,基于RSA的密钥交换算法等)

* 握手期间将使用的加密算法 (DES,RC4,RC2,DES3等)

* 握手最后使用的MAC算法 (MD5或SHA-1)

* 随机数 ServerHello.random

2.2 服务端发送自己的X.509证书或证书链 (除了匿名DH交换算法都需要)

2.3 服务器发送server_key_exchange请求

- 可选,仅三种情况需要:

a. 服务器无证书

b. 服务器有证书,但是仅能当作签名 (RSA算法中步骤3中发出去的证书里包含的是DSS或DSA公钥,不能拿来加密)

c. 使用fortezza/DMS密码交换

2.4 服务器发送certificate_request请求,要求客户端提供它的证书 (可选)

2.5 服务器发送server_done,等待应答

3.1 客户端检查服务器证书,做校验

3.2 如果服务端请求证书,客户端发送自己的证书过去

3.3 客户端发送client_key_exchange请求

- 若采用RSA,会产生一个新的随机数作为premaster secret,将该随机数通过证书中公钥或者server_key_exchange消息内的临时RSA密钥加密发过去

客户端根据premaster secret, ClientHello.random, ServerHello.random三个值算出master secret作为对称密钥

服务器端收到premaster secret以后,也根据这三个值算出master secret

- 若采用DH,证书中已包含了DH算法需要的两个整数p,g,直接通过算法根据已经交换的两个随机数可以算出premaster secret,服务器端也可以算出同样的premaster secret

3.4 如果客户端发送了自己的证书,那么它还会发一个certificate_verify消息,对第一条消息以来所有的握手消息的HMAC值用master secret进行签名。

3.5 客户端发送一个change_cipher_spec消息,并将协商好的加密信息拷贝到当前连接的状态中,保证以后所有的消息都用新的密码规范加解密和认证

3.5 客户端发送一个finished消息

4. 服务端同样发送change_ciper_spec消息和finish消息

至此,握手完成,客户端和服务器可以进行数据通信了。

握手时用非对称加密算法,保证安全;通信时用对称算法,保证效率。

参考资料:

http://mqc173.blog.163.com/blog/static/3089909320079232195306/

http://pg.zhku.edu.cn/inforwork/kejian/COURSE/ch13/3.htm

http://www.cnblogs.com/happyhippy/archive/2006/12/23/601357.html

http://rrsongzi-gmail-com.iteye.com/blog/603015

https://www.phonefactor.com/sslgapdocs/Renegotiating_TLS_pd.pdf

http://tools.ietf.org/html/rfc2246

http://docs.oracle.com/cd/B28196_01/core.1014/b28185/ssl_intro.htm

时间: 2024-10-30 22:21:48

SSL握手过程详解的相关文章

SSL 握手协议详解

RSA作为身份认证,ECDHE来交换加密密钥,AES/DES等作为加密. 如果RSA来加解密,那么身份认证后,直接用认证后的RSA公钥解密.不需要再额外交换加密密钥了. 相关报文: 报文类型 参数 hello_request 空 client_hello 版本.随机数.会话ID.密文族.压缩方法 server_hello 版本.随机数.会话ID.密文族.压缩方法 certificate x.509V3证书链 server_key_exchange 参数.签名 certificate_reques

理论经典:TCP协议的3次握手与4次挥手过程详解

1.前言 尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务.TCP提供一种面向连接的.可靠的字节流服务. 面向连接意味着两个使用TCP的应用(通常是一个客户和一个服务器)在彼此交换数据之前必须先建立一个TCP连接.这一过程与打电话很相似,先拨号振铃,等待对方摘机说"喂",然后才说明是谁. 本文将分别讲解经典的TCP协议建立连接(所谓的"3次握手")和断开连接(所谓的"4次挥手")的过程.有关TCP协议的权威

加密、解密原理和openssl自建CA过程详解

一.加密和解密相关知识简介 1.信息安全标准 NIST(National Institute of Standards and Technology)美国国家标准与技术研究院,制定了网络信息安全与保密的三个要素: 保密性(confidentiality):信息不泄露给非授权用户.实体或过程,或供其利用的特性.(一般包括数据保密性.隐私性.) 完整性(Integrity):数据未经授权不能进行改变的特性.即信息在存储或传输过程中保持不被修改.不被破坏和丢失的特性.(一般包括数据完整性.系统完整性.

SSL/TLS 原理详解

本文大部分整理自网络,相关文章请见文后参考. SSL/TLS作为一种互联网安全加密技术,原理较为复杂,枯燥而无味,我也是试图理解之后重新整理,尽量做到层次清晰.正文开始. 1. SSL/TLS概览 1.1 整体结构 SSL是一个介于HTTP协议与TCP之间的一个可选层,其位置大致如下: tls-ssl-_tcp-ip_protocol.png SSL:(Secure Socket Layer,安全套接字层),为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(En

SSL/TLS原理详解与WCF中的WS-Security

SSL/TLS作为一种互联网安全加密技术 1. SSL/TLS概览 1.1 整体结构 SSL是一个介于HTTP协议与TCP之间的一个可选层,其位置大致如下: SSL:(Secure Socket Layer,安全套接字层),为Netscape所研发,用以保障在Internet上数据传输之安全,利用数据加密(Encryption)技术,可确保数据在网络上之传输过程中不会被截取.当前版本为3.0.它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输.SSL协议位于TCP/IP协议与各种应

加密 解密过程详解及openssl自建CA  

            加密 解密过程详解及openssl自建CA 为了数据信息能够安全的传输要求数据要有一定的安全性那么数据的安全性包含哪些方面的特性呢?    NIST(美国信息安全署)做了如下的定义:    保密性:       1,数据的保密性 指的是数据或隐私不向非授权者泄漏                   2,隐私性  信息不被随意的收集    完整性:       1,数据的的完整性:信息或程序只能被指定或授权的方式改变不能被随意的             修改        

Nginx搭建反向代理服务器过程详解 - Windows

本文主要是Nginx做一个简单的反向服务器代理和静态文件缓存. 反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器 我们就开始动手吧. 1. Vistudio 创建两个简单的 WebApplication (Web Forms),一个叫WebApplication1,一个叫 WebApplication2. 为了区别

使用HeartBeat实现高可用HA的配置过程详解

使用HeartBeat实现高可用HA的配置过程详解 一.写在前面 HA即(high available)高可用,又被叫做双机热备,用于关键性业务.简单理解就是,有2台机器 A 和 B,正常是 A 提供服务,B 待命闲置,当 A 宕机或服务宕掉,会切换至B机器继续提供服务.常见的实现高可用的开源软件有 heartbeat 和 keepalived. 这样,一台 web 服务器一天24小时提供web服务,难免会存在 web 服务挂掉或服务器宕机宕机的情况,那么用户就访问不了服务了,这当然不是我们期望

Nginx实现集群的负载均衡配置过程详解

Nginx实现集群的负载均衡配置过程详解 Nginx 的负载均衡功能,其实实际上和 nginx 的代理是同一个功能,只是把代理一台机器改为多台机器而已. Nginx 的负载均衡和 lvs 相比,nginx属于更高级的应用层,不牵扯到 ip 和内核的修改,它只是单纯地把用户的请求转发到后面的机器上.这就意味着,后端的 RS 不需要配置公网. 一.实验环境 Nginx 调度器 (public 172.16.254.200 privite 192.168.0.48)RS1只有内网IP (192.168