SSL，HTTPS相关概念总结

在互联网安全通信方式上，目前用的最多的就是https配合ssl和数字证书来保证传输和认证安全了。

基本概念

信息加密，对信息进行加解密，加密算法有对称加密和非对称加密；

鉴别，消息接受者确认消息发送者确实为发送者本人，而非入侵者，---》数字证书技术；

完整性，确保信息没被修改，---》数字签名技术；

抗抵赖，数字鉴别技术；

对称加密：即加解密的密钥能相互推算出来，或一样。算法要求通信双方开始通信时，要先商量一个用于加解密的密钥。优点，加密解密速度快；缺点：需要事先商量密钥，若通过网络传输，则可被监听；若存放在数据库，则当有n个Client时，需要n(n-1)/2个。

非对称加密: 亦叫公开密钥算法，有一公钥和一私钥。算法有两种典型应用：1，普通数字加密，公钥加密，私钥解密，好处是通信双方不需要事先协商加密秘钥，有n个Client时，需要1个公钥1个私钥，劣势是加解密时间消耗比对称加密长；2，数字签名，私钥解密，公钥解密。如果公钥解密结果正确，则可说明是该私钥对信息进行的加密。

混合密码通信：

1.通过网络协商要使用的公开密钥匙算法和对称加密算法；

2.A通过网络将自己的公开密钥（加密密钥）发送给B；

3.B产生一个会话密钥，并使用A的公开密钥和协商好的公开密钥算法加密该会话密钥，并通过网络传输给A；

4.A使用自己的私钥解密出B发送过来的会话密钥；

5.B使用会话密钥和已协商好的对称加密算法加密要发送的信息，再发送给A；

6.A使用会话密钥作为解密密钥和已协商好的对称加密算法解密Ｂ发送的信息。

中间人攻击

１.Ａ将自己的公钥传给Ｂ，攻击者截获Ａ的公钥，并用自己的公钥代替Ａ的公钥发给Ｂ；

２.Ｂ将自己的公钥传给Ａ，攻击者截获Ｂ的公钥，并用自己的公钥替代Ｂ的公钥发给Ａ；

３.Ａ，Ｂ开始用“对方”的公钥加密信息并传输，而实际上ＡＢ所使用的公钥都是攻击者的，攻击者只要简单地监视两者通信，并用自己的私钥解密双方信息，就可以得到全部信息。

　　当然如果通信双方早就互相拥有对方的公钥，则攻击者就不能进行中间人攻击。但这种情况是特殊的。

　　中间人攻击出现的原因是，公开密钥没跟个人身份联系证明在一起，故使用证书的密钥交换协议。数字证书或数字签名技术可以讲公开的密钥跟某人的身份关联在一起。一个可信任的第三方用自己的私钥对一个用户的公钥和其个人信息进行签名，形成一个数字证书，可信任的第三方的公钥是任何用户都可以获取的，这样任何用户都可以通过验证这个第三方的数字签名开确定通信对方发过来的公钥是不是真的是他自己公钥。这样攻击者想要冒充第三方就很困难，因为他没有可信任第三方的私钥，没办法伪造他的签名。

数字证书，有一可信任的第三方签发的，除公钥外，一般还包括使用人的姓名，地址等信息，然后可信任的第三方用自己的私人密钥对这所有这些信息签名，这样可防止攻击者替换公钥行为，用户只要用可信任的第三方公钥验证证书的签名即确定证书是否可信。数字证书，实现身份鉴别与识别，不可否认性安全服务。是个实体的网上身份的证明。

CA（Certification Authority）认证机构，为电子商务环境中各个实体颁发电子证书，即对实体身份信息和对应公钥数据进行数字签名，用以捆绑改实体的公钥和身份，以证实各实体在网上身份真实性，并负责在交易中检验和管理证书。是权威性，可信赖性和公正性的第三方机构。

数字签名技术 = 数字摘要技术 + 非对称加密（私钥加密）技术；用以保证信息完整性，不可否认性，防伪造

　　数字签名操作一般采用非对称加密算法，其实质是使用非对称加密算法密钥的私钥对数据进行加密，而数字签名的验证操作则是使用公钥对数据进行解密操作，然后比较加解密所得到文件信息是否一致，如果一致，则认为数字签名有效，从而认为文件的有效性。但是对一个非常大的文件，几乎是难以忍受的，因为非对称加密算法加解密的速度很慢。故信息摘要算法跟非对称加密算法的结合可以解决上述问题。

　　信息摘要算法，一般被用于保证数据完整性。单项散列函数。散列函数，将输入长度可变的字符串映射成一个固定长度的字符串，即散列值；单项函数计算容易，但求逆很难或不可能。

一个使用的数字签名的操作流程如下：

1.对要签名的原始文件做信息摘要操作；得到信息摘要M_F；

2.使用私钥对M_F加密得到S_F

3.SF就是原始文件的签名信息

对上述数字签名验证：

1.验证者接收到File和S_F，首先对文件File采用相同的信息摘要算法，得到摘要信息M_FN；

2.使用公钥对S_F解密得到M_^F

3.比较M_F和M_FN，如果相同，则验证成功，证书文件File没有更改，且数字签名S_F有效；

SSL 协议的具体过程简单举例
①客户端的浏览器向服务器传送客户端 SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。

②服务器向客户端传送 SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。

③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的 CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。

④用户端随机产生一个用于后面通讯的“预主密码 ”pre master secret，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码 ”传给服务器。

⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。

⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行 CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密码 ”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码 master secret）。

⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于 SSL 协议的安全数据通讯的加解密通讯。同时在 SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。

⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。

⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。
⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。

――SSL 握手协议：是 SSL 协议非常重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和 MAC算法等）、在服务器和客户端之间安全地交换密钥、实现服务器和客户端的身份验证。

――SSL 密码变化协议：客户端和服务器端通过密码变化协议通知对端，随后的报文都将使用新协商的加密套件和密钥进行保护和传输。

――SSL 警告协议：用来向通信对端报告告警信息，消息中包含告警的严重级别和描述。

――SSL 记录协议：主要负责对上层的数据（SSL 握手协议、SSL 密码变化协议、SSL 警告协议和应用层协议报文）进行分块、计算并添加 MAC 值、加密，并把处理后的记录块传输给对端。

CipherSpec中定义了加密算法和消息验证MAC算法等。更改加密说明的协议在加密策略中用来来通知参与各方这一改变。

SSL认证详解

第一阶段：建立安全协商

1.客户发送一个client_hello消息，包括以下参数：
　　SSL版本、随机数(32位时间戳+28字节随机序列)、会话ID、客户支持的密码算法列表(CipherSuite)（包括密钥交换的方法，加密算法（对称加密算法）和类型(流还是分组密码算法)，HMAC算法，MD5还是SHA-1 ）、客户支持的压缩方法列表；

2.然后，客户等待服务器的server_hello消息；

3.服务器发送server_hello消息，参数：
　　客户建议的低版本以及服务器支持的最高版本、服务器产生的随机数、会话ID、服务器从客户建议的密码算法中挑出一套、服务器从客户建议的压缩方法中挑出一个；

第二阶段：服务器认证和密钥交换

1.服务器发送自己的证书，消息包含一个X.509证书，或者一条证书链

－－除了匿名DH之外的密钥交换方法都需要

2.服务器发送server_key_exchange消息

　－－可选的，有些情况下可以不需要。只有当服务器的证书没有包含必需的数据的时候才发送此消息。（如果他们的服务器没有证书，或其证书仅用来进行签名，将发出一个server key exchange）

　－－消息包含签名，被签名的内容包括两个随机数以及服务器参数

3.服务器发送certificate_request消息

　－－可选，非匿名server可以向客户请求一个证书

　－－包含证书类型和CAs

4.服务器发送server_hello_done, 然后等待应答。这表明握手过程中的问候消息阶段已经结束。

第三阶段：客户认证和密钥交换

１.客户收到server_done消息后，它根据需要检查服务器提供的证书，并判断server_hello的参数是否可以接受，如果都没有问题的话，发送一个或多个消息给服务器；

２.如果服务器请求证书的话，则客户首先发送一个certificate消息，若客户没有证书，则发送一个no_certificate警告

３.然后客户发送client_key_exchange消息，消息的内容取决于客户端问候消息（client hello message）和服务器问候消息（server hello message）之间所选择的公钥算法（用于规定密钥交换的方法）。（客户产生一个pre master secret，）

４.最后，客户发送一个certificate_verify消息，其中包含一个签名，对从第一条消息以来的所有握手消息的HMAC值(用master_secret)进行签名。（？？？？RFC上写此消息用来对客户端的证书提供明细那的验证，如果客户端已经发出了一个具备签名能力的证书，一个数字签名后的证书验证消息certificate verify message将被发送已确认此证书的合法性）

第四阶段：结束

1.第四阶段建立起一个安全的连接

2.客户发送一个change_cipher_spec消息，并且把协商得到的CipherSuite拷贝到当前连接的状态之中（？？RFC上写客户端将未决的Cipher Spec 复制到当前Cipher Spec ）

3.然后，客户用新的算法、密钥参数发送一个finished消息，这条消息可以检查密钥交换和认证过程是否已经成功。其中包括一个校验值，对所有以来的消息进行校验。

4.服务器同样发送change_cipher_spec消息作为回应和finished消息。

5.握手过程完成，客户和服务器可以交换应用层数据。

其中：

1.TLS记录协议需要：CipherSuite, master secret, and the client and server random values

2.在hello消息中，交换随机数以及各种算法

3.对于各种密钥交换算法，从pre_master_secret计算得到master_secret，然后从内存中删除，公式：
　　master_secret = PRF(pre_master_secret, “master secret”, ClientHello.random + ServerHello.random)[0..47]
－－PRF(secret, label, seed)为伪随机函数

4.Master_secret总是48字节长，而pre_master_secret长度不定，取决于密钥交换算法

5.两类密钥交换算法：

－RSA，客户产生一个48字节的pre_master_secret，然后通过服务器的公钥传递给服务器

－Diffie-Hellman，双方协商得到的密钥被用作pre_master_secret