HTTPS原理及握手过程 #1
Comments
|
Client Key Exchange那步应该是客户端再次生成一个随机数，并用服务器公钥加密发送给服务端。此时双方各持有三个随机数，之后双方各自用这三个随机数（random1 + random2 + random3作为主密钥）和协商好的加密算法对后续通讯内容加密。 |
|
Client Key Exchange 阶段，不同的加密算法做的事情会有所不同。 |
|
|
|
RFC5246 |
数字证书申请流程
|
浏览器验证证书
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
什么是 HTTPS
HTTPS，比 HTTP 多了一个 S，这个 S 可以认为是 secure，即 HTTPS 是安全的 HTTP。
我们知道，HTTP 是运行在 TCP 层之上的，而 HTTPS 则是在 HTTP 和 TCP 层直接多加了一个 SSL/TSL 层，SSL 层向上提供加密和解密的服务，对 HTTP 来说是透明的。
对称加密 vs 非对称加密
加密和解密都使用同一种算法的加密方法，称之为对称加密。加密和解密使用不同的算法，则为非对称加密。
对称加密需要一把钥匙就够了，因为加密和解密使用的是同一把钥匙。
非对称加密算法需要两把钥匙，公钥和私钥，它们是一对。用公钥加密的密文只能用相应的私钥解开，用私钥加密的密文只能用相应的公钥解开。其中，公钥是公开的，私钥是不对外公开的。
两者的主要区别在于密钥的长度不同，长度越长，相应的加/解密花费的时间就会更长，对称加密使用的密钥长度会短一些。
SSL 结合了这两种加密算法的有点。利用非对称加密算法来协商生成对称加密的密钥，然后之后就用对称加密来进行通信。
握手过程
以下主要讨论不需要身份验证的客户端和需要身份验证的服务端之间的握手。
client --> server
Client Hello
握手开始时，总是由先客户端会发送
Client Hello信息给服务端，主要包含Version Number
客户端支持的协议版本
Randomly Generated Data
32 字节长度的随机值，用于之后生成主密钥。
Session Identification
Session ID，第一次连接时为空。
Cipher Suite
客户端支持的加密算法列表，按优先级顺序排列。
server --> client
Server Hello
接着，服务端收到客户端发来的消息之后，会返回
Server Hello信息给客户端，告知客户端接下来使用的一些参数Version Number
通信协议版本
Randomly Generated Data
32 字节长度的随机值，用于之后生成主密钥
Session Identification
Session ID
Cipher Suite
加密算法
Server Certificate
服务端还会带上证书返回给客户端。证书中含有服务端的公钥、网站地址、证书的颁发机构等信息。
客户端收到服务端返回的证书之后，会验证该证书的真实合法性。
Server Key Exchange
这个是可选的，取决于使用的加密算法。主要是携带密钥交换的额外数据。
Server Hello Done
表示服务端已经发送完毕，并等待客户端回应。
client --> server
Client Key Exchange
客户端使用之前发送给服务端及服务端返回的随机数，生成预主密钥，然后用服务端返回的公钥进行加密。
Change Cipher Spec
告诉服务端，之后的所有信息都会使用协商好的密钥和算法加密
Client Finished
客户端的握手工作已经完成。这条信息是握手过程中所有消息的散列值。
server --> client
Change Cipher Spec Message
告知客户端，会使用刚刚协商的密钥来加密信息
Server Finished Message
表示服务端的握手工作已经完成
完整的握手过程
完整的握手过程如上图所示。
参考资料
The text was updated successfully, but these errors were encountered: