We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
密码技术
来看一下通过http发送请求的场景:
但是此种情况下,信用卡号就很有可能被窃听。于是,我们可以使用SSL或者TLS作为对通信进行加密的协议,然后在此之上承载http。通过对此两种协议的叠加,我们就对HTTP的通信进行加密,防止窃听。
以上面的例子为例,如果我们想要达到安全的通信,必须达到以下几点:
以上问题抽象出来就是:
通过文章最开始提到的密码技术,我们可以想到机密性可以用对称密码解决(这里的窃听不是指发送内容不能被攻击者得到,而是攻击者即使得到发送内容也不能理解或者破译)。由于对称密码不能被攻击者预测,因此我们使用伪随机数生成器来生成密钥。若要将对称密码的密钥发送给通信方而不被攻击者窃听,可以使用公钥密码或者Diffie-Hellman密钥交换。 识别篡改可以使用消息认证码技术. 对通信对象的认证,可以使用对公钥加上数字签名所生成的证书。
我们需要一个“框架”将上述工具组合起来,SSL/TLS协议就扮演了这样一个框架的角色。
上面的例子是SSL/TLS承载HTTP协议,其实SSL/TLS还可以承载很多协议,例如:SMTP、POP3。
SSL是1994年网景公司设计的一种协议,并在该公司的Web浏览器中进行了实现。随后很多Web浏览器都采用了这一种协议,使其成为了事实上的行业标准。SSL已经于1995年发布了3.0版本。 TLS是IETF在SSL3.0的基础上设计的协议。在1999年作为RFC2246发布的TLS1.0,实际上相当于SSL3.1。
TLS协议分为TLS记录协议和TLS握手协议。位于底层的TLS记录协议负责进行加密,位于上层的TLS握手协议负责加密以外的其他操作。而上层的TLS握手协议又分为4个子协议。
负责消息的压缩、加密以及数据的认证。 处理过程如下:
负责生产共享密钥以及交换证书。 握手协议主要分为4个子协议:握手协议、密码规格变更协议、警告协议和应用数据协议。
负责在客户端和服务器之间协商决定密码算法和共享密钥。基于证书的认证也在这一步完成。这段协议相当于下面的会话: 客户端:“你好,我能理解的密码套件有RSA/3DES,或者DSS/AES,请问我们使用哪一种?” 服务器:“你好,我们使用RSA/3DES吧,这是我的证书。” 协商之后,就会互相发出信号来切换密码。负责发出信号的就是下面介绍的密码规格变更协议。
负责向通信对象传达变更密码方式的信号。 客户端:“我们按照刚才的约定切换密码吧。1,2,3” 中途发生错误时,就会通过下面的警告协议传达给对方。
服务器:“刚才的消息无法正确解析哦。”
将TLS上面承载的应用数据传达给通信对象的协议。
(图片太长了,截了两次,o(╯□╰)o)
一些重要握手过程:
客户端向服务器发出加密通信的请求。 在这一步,客户端主要向服务器提供以下信息。
“会话ID”是当客户端和服务器希望重新使用之前建立的会话(通信路径)时所使用的信息。
服务器收到客户端请求后,向客户端发出回应。服务器的回应包含以下内容。
服务器发送Certificate消息。包含以下内容
当Certificate消息不足以满足需求时(例如匿名方式通信),服务器会通过ServerKeyExchange消息向客户端发送一些必要信息。 当使用RSA时,服务器发送N与E,也就是公钥。 当使用DH算法时,服务器发送P、G、G的x次方modP(DH算法的公开参数)
客户端从服务器的证书中取出服务器的公钥,然后向服务器发送以下信息。
非常重要的一个数值,TLS密码通信的机密性和数据的认证全部依靠这个数值。
主密码依赖如下信息计算出来:
当使用RSA公钥密码时,客户端在发送ClientKeyExchange消息时,将经过加密的预备主密码一起发送给服务器。 当使用DH密钥交换时,客户端在发送ClientKeyExchange消息时,将DH的公开值一起发送给服务器。根据这个值,客户端和服务器会各自生成预备主密码。 当根据预备主密码计算主密码时,会使用两个单向散列函数(MD5和SHA-1)组合而成的伪随机数生成器。之所以用两个单向散列函数,是为了提高安全性。
引用dog250的理解
不管是客户端还是服务器,都需要随机数,这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的,因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。 对于RSA密钥交换算法来说,pre-master-key本身就是一个随机数,再加上hello消息中的随机,三个随机数通过一个密钥导出器最终导出一个对称密钥。 pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数,如果随机数不随机,那么pre master secret就有可能被猜出来,那么仅适用pre master secret作为密钥就不合适了,因此必须引入新的随机因素,那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了,一个伪随机可能完全不随机,可是是三个伪随机就十分接近随机了,每增加一个自由度,随机性增加的可不是一。
主密码用于生成下列6种信息:
这部分还没涉猎过,先找个文章mark下。 https://imququ.com/post/optimize-tls-handshake.html
参考资料:《图解密码技术》 http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
The text was updated successfully, but these errors were encountered:
thx!
Sorry, something went wrong.
No branches or pull requests
复习基本概念
密码技术
什么是SSL/TLS
来看一下通过http发送请求的场景:
但是此种情况下,信用卡号就很有可能被窃听。于是,我们可以使用SSL或者TLS作为对通信进行加密的协议,然后在此之上承载http。通过对此两种协议的叠加,我们就对HTTP的通信进行加密,防止窃听。
以上面的例子为例,如果我们想要达到安全的通信,必须达到以下几点:
以上问题抽象出来就是:
通过文章最开始提到的密码技术,我们可以想到机密性可以用对称密码解决(这里的窃听不是指发送内容不能被攻击者得到,而是攻击者即使得到发送内容也不能理解或者破译)。由于对称密码不能被攻击者预测,因此我们使用伪随机数生成器来生成密钥。若要将对称密码的密钥发送给通信方而不被攻击者窃听,可以使用公钥密码或者Diffie-Hellman密钥交换。
识别篡改可以使用消息认证码技术.
对通信对象的认证,可以使用对公钥加上数字签名所生成的证书。
我们需要一个“框架”将上述工具组合起来,SSL/TLS协议就扮演了这样一个框架的角色。
上面的例子是SSL/TLS承载HTTP协议,其实SSL/TLS还可以承载很多协议,例如:SMTP、POP3。
SSL与TLS的区别
SSL是1994年网景公司设计的一种协议,并在该公司的Web浏览器中进行了实现。随后很多Web浏览器都采用了这一种协议,使其成为了事实上的行业标准。SSL已经于1995年发布了3.0版本。
TLS是IETF在SSL3.0的基础上设计的协议。在1999年作为RFC2246发布的TLS1.0,实际上相当于SSL3.1。
为什么使用SSL/TLS
SSL/TLS的层次化协议
TLS协议分为TLS记录协议和TLS握手协议。位于底层的TLS记录协议负责进行加密,位于上层的TLS握手协议负责加密以外的其他操作。而上层的TLS握手协议又分为4个子协议。
记录协议
负责消息的压缩、加密以及数据的认证。
![image](https://camo.githubusercontent.com/ddea22ab0e63c2effc5b47c42252277e2dcdab4f02f6e54e50d3f270663b749e/687474703a2f2f7777332e73696e61696d672e636e2f6d773639302f37303165646630336a7731663537793572726e64326a32306a6c30623874396b2e6a7067)
处理过程如下:
握手协议
负责生产共享密钥以及交换证书。
握手协议主要分为4个子协议:握手协议、密码规格变更协议、警告协议和应用数据协议。
握手协议
负责在客户端和服务器之间协商决定密码算法和共享密钥。基于证书的认证也在这一步完成。这段协议相当于下面的会话:
客户端:“你好,我能理解的密码套件有RSA/3DES,或者DSS/AES,请问我们使用哪一种?”
服务器:“你好,我们使用RSA/3DES吧,这是我的证书。”
协商之后,就会互相发出信号来切换密码。负责发出信号的就是下面介绍的密码规格变更协议。
密码规格变更协议
负责向通信对象传达变更密码方式的信号。
客户端:“我们按照刚才的约定切换密码吧。1,2,3”
中途发生错误时,就会通过下面的警告协议传达给对方。
警告协议
负责向通信对象传达变更密码方式的信号。
客户端:“我们按照刚才的约定切换密码吧。1,2,3”
中途发生错误时,就会通过下面的警告协议传达给对方。
警告协议
服务器:“刚才的消息无法正确解析哦。”
应用数据协议
将TLS上面承载的应用数据传达给通信对象的协议。
使用SSL/TLS进行通信
(图片太长了,截了两次,o(╯□╰)o)
一些重要握手过程:
ClientHello
客户端向服务器发出加密通信的请求。
在这一步,客户端主要向服务器提供以下信息。
“会话ID”是当客户端和服务器希望重新使用之前建立的会话(通信路径)时所使用的信息。
ServerHello
服务器收到客户端请求后,向客户端发出回应。服务器的回应包含以下内容。
Certificate
服务器发送Certificate消息。包含以下内容
首先发送的是服务器的证书,然后会按顺序发送对服务器证书签名的认证机构的证书。
当以匿名方式通信时,不发送Certificate消息。
ServerKeyExchange
当Certificate消息不足以满足需求时(例如匿名方式通信),服务器会通过ServerKeyExchange消息向客户端发送一些必要信息。
当使用RSA时,服务器发送N与E,也就是公钥。
当使用DH算法时,服务器发送P、G、G的x次方modP(DH算法的公开参数)
ClientKeyExchange
客户端从服务器的证书中取出服务器的公钥,然后向服务器发送以下信息。
当使用RSA时,会随ClientKeyExchange一起发送经过加密的预备主密码。
当使用DH算法时,会随ClientKeyExchange一起发送DH的公开值,即Y(G的x次方模P),之后双方也能算出相同的pre-master key。
主密码
非常重要的一个数值,TLS密码通信的机密性和数据的认证全部依靠这个数值。
主密码的计算
主密码依赖如下信息计算出来:
当使用RSA公钥密码时,客户端在发送ClientKeyExchange消息时,将经过加密的预备主密码一起发送给服务器。
![image](https://camo.githubusercontent.com/323d9658878b965a1343a461390311c602cf5d8056aac123d1f2927a8a9ce013/687474703a2f2f7777332e73696e61696d672e636e2f6d773639302f37303165646630336a77316635387773336634626f6a32306a3530633264676c2e6a7067)
当使用DH密钥交换时,客户端在发送ClientKeyExchange消息时,将DH的公开值一起发送给服务器。根据这个值,客户端和服务器会各自生成预备主密码。
当根据预备主密码计算主密码时,会使用两个单向散列函数(MD5和SHA-1)组合而成的伪随机数生成器。之所以用两个单向散列函数,是为了提高安全性。
为什么一定要三个随机数
引用dog250的理解
主密码的目的
主密码用于生成下列6种信息:
SSL/TLS密码技术小结
对SSL/TLS的攻击
要验证证书必须使用CRL(证书作废清单)。如果客户端没有安装最新版的CRL,那么SSL/TLS也无法保证通信的安全。
TLS握手优化
这部分还没涉猎过,先找个文章mark下。
https://imququ.com/post/optimize-tls-handshake.html
参考资料:《图解密码技术》
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
The text was updated successfully, but these errors were encountered: