SSL/TSL

2019独角兽企业重金招聘Python工程师标准>>>

SSL基本概念

SSL（Secure Socket Layer） 　　为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密（Encryption）技术，可确保数据在网络上之传输过程中不会被截取。 TLS：（Transport Layer Security，传输层安全协议），用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。 　　TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。SSL最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL 3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL 3.0不能互操作，TLS的版本1.0使用的版本号为SSLv3.1 TSL1.2 RFC:http://www.ietf.org/rfc/rfc5246.txt SSL/TLS协议 • 记录协议 • 握手协议 SSL握手链接过程 SSL 握手协议主要负责如下工作： • 算法协商：首次通信时，双方通过握手协议协商密钥加密算法，数据加密算法和文摘算法。 • 身份验证：在密钥协商完成后，客户端与服务器端通过证书互相验证对方的身份。 • 确定密钥：最后使用协商好的密钥交换算法产生一个只有双方知道的秘密信息，客户端和服务器各自根据这个秘密信息计算出加密密钥，在接下来的记录协议中用来对应用数据进行加密； ContentType指示SSL的通信阶段：Handshake,ChangeCipherSpec，Alert,Application Handshake Type是在handshanke阶段中的具体哪一步，见下图

SSL • oneway • two way 单项oneway的ssl握手过程：

1.client发送ClientHello，指定版本，随机数(RN)，会话ID，所有支持的密码套件(CipherSuites)，支持的压缩算法 2.server回应ServerHello，指定版本，RN，选择CipherSuites，会话ID(Session ID)，压缩算法 3.server发送Certificate 4.Server发送ServerHelloDone 5.Client发送ClientKeyExchange，用于与server交换session key 6.Client发送ChangeCipherSpec，指示Server从现在开始发送的消息都是加密过的 7.Client发送Finishd，包含了前面所有握手消息的hash，可以让server验证握手过程是否被第三方篡改 8.Server发送ChangeCipherSpec，指示Client从现在开始发送的消息都是加密过的 9.Server发送Finishd，包含了前面所有握手消息的hash，可以让client验证握手过程是否被第三方篡改，并且证明自己是Certificate密钥的拥有者，即证明自己的身份

1. Client Hello SSL客户端通过Client Hello消息向SSL服务端发送:
   1. 支持的SSL版本
   2. 客户端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成)
   3. 会话ID
   4. 加密套件 3.1) 加密算法 3.2) 密钥交换算法 3.3) MAC算法 3.4) 加密方式(流、分组) 　　密码套件格式：每个套件都以“SSL”开头，紧跟着的是密钥交换算法。用“With”这个词把密钥交换算法、加密算法、散列算法分开，例 如：SSL_DHE_RSA_WITH_DES_CBC_SHA, 表示把DHE_RSA(带有RSA数字签名的暂时Diffie-HellMan)定义为密钥交换算法；把DES_CBC定义为加密算法；把SHA定义为散 列算法。

5. 压缩算法(如果支持压缩的话)

ClientHello附带的数据随机数据RN 会在生成session key时使用，Cipher suite列出了client支持的所有加密算法组合，可以看出每一组包含3种算法，一个是非对称算法，如RSA，一个是对称算法如DES，3DES，RC4等，一个是Hash算法，如MD5，SHA等，server会从这些算法组合中选取一组，作为本次SSL连接中使用。 2. Server Hello SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会 话ID，并通过Server Hello消息发送给SSL客户端。 1) 服务端采纳的本次通讯的SSL版本 2) 服务端生成的一个用于生成主密钥(master key)的32字节的随机数(主密钥由客户端和服务端的随机数共同生成) 3) 会话ID 3) 服务端采纳的用于本次通讯的加密套件(从客户端发送的加密套件列表中选出了一个) 3.1) 加密算法 3.2) 密钥交换算法 3.3) MAC算法 3.4) 加密方式(流、分组) 4) 压缩算法(如果支持压缩的话)

　　这个阶段之后，客户端&服务端知道了下列内容： 　　（1）SSL版本 　　（2）密钥交换、信息验证和加密算法 　　（3）压缩方法 　　（4）有关密钥生成的两个随机数。 3.Certificate,Server Key Exchange,Server Hello Done

1. Certificate SSL服务器将"携带自己公钥信息的数字证书"和到根CA整个链发给客户端通过Certificate消息发送给SSL客户端(整个公钥文件都发送过去)，客户端使用这个公钥完成以下任务:
   1. 客户端可以使用该公钥来验证服务端的身份，因为只有服务端有对应的私钥能解密它的公钥加密的数据
   2. 用于对"premaster secret"进行加密，这个"premaster secret"就是用客户端和服务端生成的Ramdom随机数来生成的，客户端用服务端的公钥对其进行了加密后发送给服务端
2. Server Key Exchange 密钥交换阶段(可选步骤)，之所以说是可选步骤，是因为只有在下列场景下这个步骤才会发生
   1. 协商采用了RSA加密，但是服务端的证书没有提供RSA公钥
   2. 协商采用了DH加密，但是服务端的证书没有提供DH参数
   3. 协商采用了fortezza_kea加密，但是服务端的证书没有提供参数 总结来说，"Server Key Exchange"这个步骤是对上一步"Certificate"的一个补充，为了让整个SSL握手过程能正常进行
3. Server Hello Done SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束

4.Client Key Exchange,Change Cipher Spec, Encrypted Handshake Message

1. 客户机密钥交换（Pre-master-secret）：这里客户端将预备主密钥发送给服务端，注意这里会使用服务端的公钥进行加密。 客户端会利用证书中的公钥加密SSL客户端随机生成的premaster secret（通过之前客户端和服务器端的随机数生成的）这一阶段结束后客户端和服务器端都保存了主秘钥，该主秘钥将用于通信数据加密（该秘钥是对称算法，对数据加密效率比非对称高）
2. Change Cipher Spec SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的"主密钥"和加密套件进行加密和MAC计算。
3. Finished SSL客户端计算已交互的握手消息(除Change Cipher Spec消息外所有已交互的消息)的Hash值，利用协商好的密钥和加密套件处理Hash值(计算并添加MAC值、加密等)，并通过Finished 消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

4.New Session Ticket,Change Cipher Spec, Encrypted Handshake Message 1.NewSessionTicket 消息 服务器在握手过程中，发ChangeCipherSpec之前发送NewSessionTicket消息。 如果服务器在ServerHello中包含了一个SessionTicket扩展，那就必须发送NewSessionTicket消息。 如果服务器没有包含SessionTicket扩展，那绝对不能发送NewSessionTicket消息。 2. Change Cipher Spec 同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。 3. Finished 这一步对应的是 Server Finish 消息，服务端也会将握手过程的消息生成摘要再用秘钥加密，这是服务端发出的第一条加密消息。客户端接收后会用秘钥解密，能解出来说明协商的秘钥是一致的。 SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从 Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

SessionTicket 定义在 RFC5077 标准里面，2008年发布。 SessionTicket是一种不需要服务器端状态的，恢复TLS session的方式。 SessionTicket可以用于任何CipherSuite。 TLS 1.0, TLS 1.1, TLS 1.2 都适用。 主要用在如下场景中： 用户量巨大，session id的方式耗费服务器内存过多 服务器希望长时间缓存session 服务器有多台，不希望服务器间有共享状态 服务器内存不足 客户端在 ClientHello中设置一个 SessionTicket 扩展来标识自己支持 SessionTicket。如果客户端本地没有存之前收到的ticket，就把这个扩展设为空。 如果服务器希望使用 SessionTicket 机制，服务器把本地的 session 状态存入一个ticket中，ticket会被加密，并被MAC保护，无法篡改，加密和算MAC用的key只有服务器知道。 加密并MAC过的ticket用 NewSessionTicket 消息分发给客户端，NewSessionTicket 消息应该在 ChangeCipherSpec 消息之前，在服务器验证通过客户端的Finished消息之后发送

转载于:https://my.oschina.net/tanghaoo/blog/2997008