目录
6.2、服务器收到客户端请求后，向客户端发出响应，叫做Sever Hello。
6.3、服务端发送服务端电子证书（CA），密钥交换（server key exchange），及server hello done三个握手消息
6.4、客户端发送密钥交换信息（client key exchange）、编码改变协议消息(change cipher spec)。
一、概述
SSL 是“Secure Sockets Layer”的缩写，中文叫做“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。
SSL/TLS是同一种协议，只不过是在不同阶段的不同称呼。
SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：
1、SSL记录协议（SSL Record Protocol）：主要负责对上层的数据（SSL握手协议、SSL密码变化协议、SSL警告协议和应用层协议报文）进行分块、计算并添加MAC值、加密，并把处理后的记录块传输给对端。
2、SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
3、SSL密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
SSL警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。
二、SSL/TLS的作用
1、认证用户和服务器，确保数据发送到正确的客户机和服务器。
2、加密数据以防止数据中途被窃取。
3、维护数据的完整性，确保数据在传输过程中不被改变。
而SSL证书指的是在SSL通信中验证通信双方身份的数字文件，一般分为服务器证书和客户端证书，我们通常说的SSL证书主要指服务器证书，SSL证书由受信任的数字证书颁发机构CA（如VeriSign，GlobalSign，WoSign等），在验证服务器身份后颁发，具有服务器身份验证和数据传输加密功能，分为扩展验证型(EV)SSL证书、组织验证型(OV)SSL证书、和域名验证型（DV）SSL证书。
三、SSL/TLS协议结构体
四、SSL/TLS协议基本原理
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密，但是这里有两个问题：
1、如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中，只要证书是可信的，公钥就是可信的。
2、公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
1、客户端向服务器端索要并验证公钥。
2、双方协商生成“对话密钥”。
3、双方采用“对话密钥”进行加密通信。
五、SSL/TLS认证方式
5.1、单向认证：
1、客户端向服务器发送消息。
2、服务器接到消息后，用服务器端的密钥库中的私钥对数据进行加密，然后把加密后的数据和服务器端的公钥一起发送到客户端。
3、客户端用服务器发送来的公钥对数据解密，然后在用传到客户端的服务器公钥对数据加密传给服务器端，服务器用私钥对数据进行解密，这就完成了客户端和服务器之间通信的安全问题，但是单向认证没有验证客户端的合法性。
5.2、双向认证：
1、客户端向服务器发送消息，首先把消息用客户端证书加密然后连同时把客户端证书一起发送到服务器端。
2、服务器接到消息后用首先用客户端证书把消息解密，然后用服务器私钥把消息加密，把服务器证书和消息一起发送到客户端。
3、客户端用发来的服务器证书对消息进行解密，然后用服务器的证书对消息加密，然后在用客户端的证书对消息在进行一次加密，连同加密消息和客户端证书一起发送到服务器端。
4、到服务器端首先用客户端传来的证书对消息进行解密，确保消息是这个客户发来的，然后用服务器端的私钥对消息在进行解密这个便得到了明文数据。
六、TLS握手协议
握手协议是TLS握手协议的一部分，负载生成共享密钥以及交换证书。其中，生成共享密钥是为了进行密码通信，交换证书是为了通信双方相互进行认证。
握手协议这一名称中的“握手”，是服务器和客户端在密码通信之间交换一些必要信息这一过程比喻。
由于握手协议的信息交换是在没有加密的情况下进行的（即使用“不加密”这一密码套件），也就是说，在这一协议中所收发的所有数据都可能被窃听者窃听，因此在这一过程中必须使用公钥密码或DH密钥交换。
6.1、客户端发出请求（ClientHello)
客户端与服务端通过tcp三次握手建立tcp连接后，客户端首先向服务器发出建立加密通信的请求，发送ClientHello请求，从消息体结构看，tls/ssl是基于tcp连接之上，应用层之下的协议，封装的消息体内容如下:
1、此时握手协议(handshake protocol)的消息类型为:client hello。
2、支持的TLS协议版本，比如TLS 1.0版。握手协议的版本为TLS 1.2。
3、一个客户端生成的随机数，稍后用于生成"对话密钥"。
4、支持的加密套件，如Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)。
5、支持的压缩方法。
6、扩展属性如：服务器名称（例子中为baidu.com)，支持的签名算法等。
2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。
6.2、服务器收到客户端请求后，向客户端发出响应，叫做Sever Hello。
服务器的响应包含以下内容：
1、确认使用的加密通信协议版本，这里确认使用tls1.2，而不是client hello中的tls1.1。响应握手协议消息 server hello。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
2、一个服务器生成的随机数，稍后用于生成"对话密钥"。
3、确认使用的加密套件,这里为rsa+aes128+sha256
4、压缩方法为空。
5、一些列扩展信息
除了上面这些信息，如果服务器需要确认客户端的身份，就会再包含一项请求，要求客户端提供”客户端证书”。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
6.3、服务端发送服务端电子证书（CA），密钥交换（server key exchange），及server hello done三个握手消息
客户端接收到server hello握手消息后，及时反馈ack消息。服务端接收客户端ack消息后，发送服务端电子证书，密钥交换，及server hello done三个握手消息。
包含两层ssl协议体信息，头一个为服务端证书，后面跟着公共密钥交换和hello done消息体，具体如下：
1、详细的电子证书信息和CA认证机构信息。
2、密钥交换信息，包括DH算法计算出的pubkey公钥，电子签名的hash算法值。
3、server hello done消息体。
涉及到两个问题：
如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。所以上面报文中就将服务端CA证书和公共密钥交换消息放在同一个tcp连接进行传输。
公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），整个对话密钥是通过公共密钥和生成的3个随
6.4、客户端发送密钥交换信息（client key exchange）、编码改变协议消息(change cipher spec)。
客户端发送ack消息给服务端，确认收到server hello done消息，然后发送客户端的密钥交换信息和修改密钥的协议消息。
主要内容如下：
1、发送DH算法计算的pubkey，用于服务端计算生成解密私钥。
2、发送编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
3、发送加密后的握手消息，一个随机数。该随机数用服务器公钥加密，防止被窃听。
4、客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。（可能在加密消息中，未确认）
客户端收到服务器所有响应消息后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没有问题，客户端就会从证书中取出服务器的公钥，即server key exchange消息中携带的pubkey值。然后，根据根据已经收到的三个随机数计算书加密密钥，对握手信息进行加密通信，然后向服务器发送上面抓包中三项信息内容。
该步骤中的随机数，是整个握手阶段出现的第三个随机数，又称”pre-master key”。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把”会话密钥”。
至于为什么一定要用三个随机数，来生成"会话密钥"，dog250解释得很好：
"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。
对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。
pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素。
那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。"
此外，如果前一步，服务器要求客户端证书，客户端会在这一步同样也发送证书及相关信息。
6.5、服务器的最后回应
服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的”会话密钥”。然后，向客户端最后发送下面信息。
1、编码改变协议，表示随后的信息都将用双方商定的加密方法和密钥发送。
2、服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用”会话密钥”加密内容。
最后从抓包的报文我们可以看到：Http请求处理响应结束后，客户端会发送加密的alert消息给服务端，告知如果异常产生变化，就要发出告警。最后就是客户和服务端发送fin/ack tcp消息关闭tcp连接。
七、SSL证书申请的3个主要步骤
7.1、制作CSR文件
所谓CSR就是由申请人制作的Certificate Secure Request证书请求文件，制作过程中，系统会产生2个密钥，一个是公钥就是这个CSR文件；另外一个是私钥，存放在服务器上。
要制作CSR文件，申请人可以参考WEB SERVER的文档，一般APACHE等，使用OPENSSL命令行来生成KEY+CSR2个文件，Tomcat，JBoss，Resin等使用KEYTOOL来生成JKS和CSR文件，IIS通过向导建立一个挂起的请求和一个CSR文件。
7.2、CA认证
将CSR提交给CA，CA一般有2种认证方式：
1、域名认证：一般通过对管理员邮箱认证的方式，这种方式认证速度快，但是签发的证书中没有企业的名称。
2、企业文档认证：需要提供企业的营业执照，一般需要3-5个工作日。
也有需要同时认证以上2种方式的证书，叫EV证书，这种证书可以使IE7以上的浏览器地址栏变成绿色，所以认证也最严格。
7.3、证书的安装
在收到CA的证书后，可以将证书部署上服务器，一般APACHE文件直接将KEY+CER复制到文件上，然后修改HTTPD.CONF文件；TOMCAT等，需要将CA签发的证书CER文件导入JKS文件后，复制上服务器，然后修改SERVER.XML；IIS需要处理挂起的请求，将CER文件导入。
而需要复杂证书的往往是大中型网站，诸如个人博客之类的小型站点完全可以先尝试免费SSL证书。
1084
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
