• 1. 概览
• 2. 握手协议 Shakehand
• 3. 解答几个网上常见的问题：
  • 1. SSL 和 TLS 的区别
  • 2. TLS (Transport Layer Security) 是传输层协议吗？
  • 3. SSL 和 TLS，应该选用哪个作为服务器端的安全策略的一部分？
  • 4. 怎么知道我用的浏览器和某网站支持什么版本的 SSL/TLS 协议？
  • 5. 为什么连 alipay.com 这样的网站还保留 SSL 3.0？不是说 SSL3.0 不安全了吗？

1. 概览

在构建网络应用，特别是暴露在 internet 中的应用时，通常都会使用 SSL/TLS 协议增强数据传输的安全性，其结构如下：

2. 握手协议 Shakehand

其中最重要，最复杂（未必是被理解最清楚的）的是握手协议 Shakehand。本来想找一张清晰易懂的 Shakehand 流程图，看到 wikipedia 的这张图很好，有人持续更新它，但就是字体太小，眼睛都瞪瞎了_，索性操起超超超强大的 DRAW.io（需先科学上网，Why?），从新做轮子，期间参考了《图解密码技术》的相关章节，加入了便于理解的对话。希望这图对大家有帮助。

另外，大家可以留意一下 Client 和 Server 证书（cert.）的交换时机（Phase 2 和 3），这就是我们平时在客户端和服务器端所安装的证书的使用时刻，这里是典型的双向证书验证，通常在搭建SSL/TLS应用的时候都这么做，目的是确保双方都是可信的（因为双方都安装了某 CA 的 root cert，且双方的 cert 都由这个 CA所 trust，所 issue）。

握手完成后，Client 和 Server 端就会使用应用数据协议和 TLS 记录协议进行加密通信。 从结果来看，握手协议完成了下列操作：

1. Client 端获得了 Server 端的合法公钥，完成了 Server 认证。
2. Server 获得了客户端的合法公钥，完成了 Client 认证 （当需要客户端认证时）。
3. Client 和 Server 生成了消息认证码(MAC：Message Authentication Code)中使用的共享密钥。
4. Client 和 Server 生成了加密通信中使用的共享密钥（上图的 MS）。

3. 解答几个网上常见的问题：

1. SSL 和 TLS 的区别

TLS 是 SSL 的继承者，SSL3.0，之后的 TLS1.0 相当于 “SSL3.1”。

2. TLS (Transport Layer Security) 是传输层协议吗？

不是。它是一套应用层协议：

TLS: In the Internet Protocol Suite, TLS and SSL encrypt the data of network connections in the application layer. In OSI model equivalences, TLS/SSL is initialized at layer 5 (session layer) and works at layer 6 (the presentation layer).[citation needed]

它在会话层被初始化，然后工作在表示层。另外，不仅是HTTP，其他应用层协议（例如：FTP, SMTP 等）都可以使用 TLS，而常见的 UDP 使用的是 DTLS。

3. SSL 和 TLS，应该选用哪个作为服务器端的安全策略的一部分？

尽量用最新的 TLS 1.2，它修复了之前版本的许多漏洞。当前大部分 WS（Web Server）产品都已经支持，如从Nginx，Tomcat 6.0.43和IIS 7.5开始。即使你当前用的WS不支持 TLS 1.2，也尽可能使用支持 TLS 1.0的WS版本，并且禁用 Client 和 Server 端的 SSL 3.0，因为去年底爆出的 POODLE安全缺陷说明仅仅升级到 TLS 1.x是不够的。

利用该缺陷进行攻击主要分两步：

1. 攻击者先通过Version rollback attacks使 TLS shakehand 失败，C/S就会协商降级使用SSL 3.0 再次shakehand。
2. 然后就可以利用 POODLE 进行攻击啦。

有鉴于此，在 POODLE 缺陷被证实后，主流浏览器大厂已经在自家产品中强制使用 TLS 并禁用了 SSL 3.0，杜绝 rollback 回 SSL 3.0。如果你的浏览器已经禁用 SSL 3.0 的话，浏览只支持 SSL 3.0 的网站会看到类似的警告：

4. 怎么知道我用的浏览器和某网站支持什么版本的 SSL/TLS 协议？

• 简单的
• 服务端 SSL 支持检测
• 本地 SSLv3 支持检测
• 复杂的
• Linux/OSX: nmap --script ssl-enum-ciphers -p 443 www.alipay.com
• Windows: Zenmap

Output

username@yourhostname:[~]
nmap --script ssl-enum-ciphers -p 443 www.alipay.com
Starting Nmap 6.40 ( http://nmap.org ) at 2015-05-05 08:36 HKT
Nmap scan report for www.alipay.com (110.75.142.111)
Host is up (0.091s latency).
DNS record for 110.75.142.111: host-111.alipay.com
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers: 
|   SSLv3: 
|     ciphers: 
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     compressors: 
|       NULL
~~~~~~~~~~（此处省略多行）~~~~~~~~~~
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA - strong
|       TLS_RSA_WITH_AES_128_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_128_GCM_SHA256 - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA - strong
|       TLS_RSA_WITH_AES_256_CBC_SHA256 - strong
|       TLS_RSA_WITH_AES_256_GCM_SHA384 - strong
|       TLS_RSA_WITH_RC4_128_SHA - strong
|     compressors: 
|       NULL
|_  least strength: strong
Nmap done: 1 IP address (1 host up) scanned in 3.82 seconds

5. 为什么连 alipay.com 这样的网站还保留 SSL 3.0？不是说 SSL3.0 不安全了吗？

问得好！它不但保留了 SSL 3.0，还保留了已经不安全的 RC4 加密算法（速度极快的算法，8bit 的机器都能很快算出伪随机数(图上的 RNc)）。

这不是阿里的疏忽，而是像许多网站那样想兼容那些旧版浏览器（虽然的数量已经很少很少），比如像我 XP 里那万年不升级的 IE6 和老旧的功能手机 Candy bar phone的内置浏览器。