深入研究SSL【第一章】-什么是SSL，SSL如何工作

前段时间项目的关系学习了下SSL，有一些心得体会和疑惑打算一并记录下来和大家分享和讨论一下。

这部分内容打算分成如下一些章节来写：

1. 第一章. 对SSL的基本概念和框架的介绍
2. 第二章.对SSL握手协议的研究（part-1 ）
3. 第三章.对SSL握手协议的研究（part-2）
4. 第四章.对SSL握手协议细节和实现的介绍
5. 第五章.对SSL记录协议细节和实现的介绍
6. 第六章.对SSL的安全性分析
7. 第七章.举例一种将usbkey融入java JSSE框架的解决方案

先写第一章内容，后面的慢慢写，在学习过程中也遇到一些困惑，希望大家也能给点提示。

SSL 缩写 Secure Socket Layer ，是几十年前网景公司制定的保证服务器和客户端安全通信的一种协议，大量使用在http的安全通信中，这里的安全通信有两层含义：

• 通信双方身份的认证

• 通信数据的保密

简单说就是首先要对通信两端的身份进行认证确保是真实的，接下来就是确保通信双方交换的数据进行加密确保只有真实的对手方才能看到，任何其他的人即便拿到数据也无法获得有效信息。这里要注意， SSL 并不包含或实现身份认证的方法和数据加密方法， SSL 只是制定了一套可靠的 C-S 之间的协商办法，来确定通信双方如何身份认证和加密。现在 SSL 里头基本使用 PKI 数字证书方式认证，加密的算法很多，对称非对称，这些网上资料很多自己 google 之。

SSL 是如何工作的呢？基本上 SSL 的工作分为两个阶段：握手阶段和数据传输阶段，若通信期间检测到不安全因素，比如握手时候发现另一端无法支持选择的协议或加密算法，或者发现数据被篡改，这时通信一方会发送警告消息，不安全因素影响比较大两端之间的通信就会终止，必须重新协商建立连接。

SSL 协议结构如下：

 

通过 SSL 分成三个子协议， HandShake( 握手) ChangeCipherSpec( 更改密钥规格 ), Alert( 告警 ) 。

 

SSL 的告警协议是用来为通信对方发送一条告警消息，告警分为两个层次： fatal 和 warning, 如果是 fatal 级别的如 MAC 计算出错或协商密钥算法失败则马上断开连接，要建立连接的话需要重新握手； warning 类型的消息一般只会记录日志，并不会断开连接。

 

SSL 更换密钥规格 (change cipher spec) 协议独立于握手协议，单独属于一类，也是其中最简单的一个。协议由单个消息组成 , 该消息只包含一个值为 1 的单个字节。该消息由客户端和服务器端各自发出用来通知对方，从这个消息以后要开始使用之前协商好的密钥套件了，这个消息一般是在握手到发出 Finish 消息之前发出。

 

SSL 握手协议主要负责如下工作：

―― 算法协商：首次通信时，双方通过握手协议协商密钥加密算法，数据加密算法和文摘算法。
―― 身份验证：在密钥协商完成后，客户端与服务器端通过证书互相验证对方的身份。
―― 确定密钥：最后使用协商好的密钥交换算法产生一个只有双方知道的秘密信息，客户端和服务器各自根据这个秘密信息计算出加密密钥，在接下来的记录协议中用来对应用数据进行加密；

 

如果说握手协议是 C/S 双方的协商的话记录协议就是利用协商结果对上层应用提供两种服务：

―― 机密性：使用协商好的通信密钥对业务数据加解密；

―― 数据完整性：利用协商好的 MAC 算法计算消息 HASH ，防止消息被篡改；

协议规定每个记录层的协议数据包长度不能超过 2^14(16K) ，因此记录协议接收到层应用业务数据若超长会将业务数据分块，压缩 ( 可选 ) ，计算 MAC ，加密，按上记录层协议头发出去。

疑问：

1.SSL协议中为什么change cipher spec消息要单独属于一类而不归类到握手消息中？

2.若将change cipher spec消息去掉，服务器端和客户端可以直接根据收到或发送Finished消息来让通信双方切换到使用协商好的密钥通信的状态中去好像也没什么影响，为什么一定要整出这么个change cipher spec协议来？

ssl，呵呵，很高深的一个东西，记得原来的一个项目差点被他搞死。

学习ssl，可以参考下openssl、java keytool、https。

不错的资料.

原来还真没注意到有 Change Cipher Spec，但根据整个SSL实现过程理解，我觉得可能是实现密钥更换作用的；因为原来在SSL协议的资料上看到过，客户端和服务端完成SSL握手后，为了保证信道的安全性，可以设置会话密钥的生命周期：例如密钥使用多长时间后主动更换密钥或密钥加密多大数据流量后主动更换密钥；
更换密钥是在双份身份确认完以后，为了保证信道安全做的额外工作，不需要再完全做一遍 HAND SHAKE 过程，所以可能这个就是独立出 Change Cipher Spec 的意图。
个人见解，如果不对欢迎指出更正；

================
我也是这么想的，好像在SSL协议RFC草稿里头看到过，这个change cipher spec消息的使用可以由实现者定制，在通信过程中无需重新走握手流程，简单的发一个消息实现双方更换密钥，但这个消息只有一个字节，生成密钥的材料
不用重新协商就能重新生成双方共享的对称加密密钥？如何能实现？
SSLV3协议白皮书中对这个changecipherspec消息为什么不归类到握手协议中有一句说明，原文如下：
To help avoid pipeline stalls, ChangeCipherSpec is an independent SSL Protocol content type, and is not actually an SSL handshake message
为什么不搞到握手协议中了就能防止信道延迟？这个也还没理解。

写着写着发现第二章搞的太长了，打算将第二章分两部分来写，SSL并没有那么可怕，就是陌生的术语比较多，把那些加密，认证，加密算法涉及到得数学方面术语好好熟悉下你会发现这东西没那么拗口了

没研究到那么深，XD的研究精神值得佩服！在研究协议的同时可以参考好多SSL的开源实现，理论和实践结合起来就更容易理解了