diff --git a/加密/1 公钥秘钥加密原理.md b/加密/1 公钥秘钥加密原理.md index 4fa466f3..bf9ce729 100644 --- a/加密/1 公钥秘钥加密原理.md +++ b/加密/1 公钥秘钥加密原理.md @@ -32,8 +32,8 @@ ### 秘钥算法目标 -* 加密,肯定是不希望别人知道我的消息,所以只要我才能解密。所以得出,公钥负责加密,私钥负责解密。 -* 签名,那肯定是不希望有人冒充我发消息,只有我才能发布这个签名, 所以得出,私钥负责签名,公钥负责验证。 +* 加密,保证数据的隐私性。肯定是不希望别人知道我的消息,所以只要我才能解密。所以得出,公钥负责加密,私钥负责解密。 +* 签名,保证数据的完整性。那肯定是不希望有人冒充我发消息,只有我才能发布这个签名, 所以得出,私钥负责签名,公钥负责验证。 ## 2 非对称加密RSA实现 diff --git a/加密/2 TSL加密协议.md b/加密/2 TSL加密协议.md index 76dfa1a0..e1d9a223 100644 --- a/加密/2 TSL加密协议.md +++ b/加密/2 TSL加密协议.md @@ -1,5 +1,6 @@ ## 1 简介 +### 协议简介 SSL/TLS是一种密码通信框架，他是世界上使用最广泛的密码通信方法。SSL/TLS综合运用了密码学中的对称密码，消息认证码，公钥密码，数字签名，伪随机数生成器等，可以说是密码学中的集大成者。 @@ -8,132 +9,215 @@ SSL(Secure Socket Layer)安全套接层，是1994年由Netscape公司设计的 TLS(Transport Layer Security)传输层安全是IETF在SSL3.0基础上设计的协议，实际上相当于SSL的后续版本。 -## 2 应用 - -SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3协议等。下层基于TCP可靠数据连接实现。 - -![](image/2021-06-15-20-11-58.png) +### 加密算法 +* 非对称加密算法：RSA，DSA/DSS,Diffie–Hellman +* 对称加密算法：AES，RC4，3DES +* HASH算法：MD5，SHA1，SHA256 +* Record协议中的MAC(Message Authentication Code)算法 +* premaster secret、master secret生成算法 -## 3 架构 - -![](image/2021-06-15-20-12-34.png) - -TLS主要分为两层 -* 底层的是TLS记录协议，主要负责使用对称密码对消息进行加密。 - -* 上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。 - -* 握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。 -* 密码规格变更协议负责向通信对象传达变更密码方式的信号 -* 警告协议负责在发生错误的时候将错误传达给对方 -* 应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。 - - -## 4 握手协议 -握手协议是TLS协议中非常重要的协议，通过客户端和服务器端的交互，和共享一些必要信息，从而生成共享密钥和交互证书。 -![](image/2021-06-15-23-09-52.png) -![](image/2021-06-15-20-41-00.png) - -### 1 客户端请求SSL内容 - -* client hello客户端向服务器端发送一个client hello的消息，包含下面内容： - 1. 可用版本号 - 2. 当前时间 - 3. 客户端随机数 - 4. 会话ID - 5. 可用的密码套件清单 - 6. 可用的压缩方式清单 - - -我们之前提到了TLS其实是一套加密框架，其中的有些组件其实是可以替换的，这里可用版本号，可用的密码套件清单，可用的压缩方式清单就是向服务器询问对方支持哪些服务。 - -客户端随机数是一个由客户端生成的随机数，用来生成对称密钥。 - - -### 2 服务器响应SSL内容 - -* server hello服务器端收到client hello消息后，会向客户端返回一个server hello消息，包含如下内容： - 1. 使用的版本号。使用的版本号，使用的密码套件，使用的压缩方式是对步骤1的回答。 - 2. 当前时间 - 3. 服务器随机数。服务器随机数是一个由服务器端生成的随机数，用来生成对称密钥。 - 4. 会话ID - 5. 使用的密码套件 - 6. 使用的压缩方式 - -* 可选步骤:certificate服务器端发送自己的证书清单，因为证书可能是层级结构的，所以处理服务器自己的证书之外，还需要发送为服务器签名的证书。客户端将会对服务器端的证书进行验证。如果是以匿名的方式通信则不需要证书。 -* 可选步骤:ServerKeyExchange。如果第三步的证书信息不足，则可以发送ServerKeyExchange用来构建加密通道。ServerKeyExchange的内容可能包含两种形式： - * 如果选择的是RSA协议，那么传递的就是RSA构建公钥密码的参数（E，N）。我们回想一下RSA中构建公钥的公式：密文=明文^E\ mod\ N密文=明文EmodN， 只要知道了E和N，那么就知道了RSA的公钥，这里传递的就是E，N两个数字。具体内容可以参考RSA算法详解 - * 如果选择的是Diff-Hellman密钥交换协议，那么传递的就是密钥交换的参数，具体内容可以参考更加安全的密钥生成方法Diffie-Hellman -* 可选步骤:CertificateRequest如果是在一个受限访问的环境，比如fabric中，服务器端也需要向客户端索要证书。如果并不需要客户端认证，则不需要此步骤。 -* server hello done 服务器端发送server hello done的消息告诉客户端自己的消息结束了。 - -### 3 客户端交换秘钥证书 - - -* 可选步骤:Certificate。对步骤5的回应，客户端发送客户端证书给服务器 -* ClientKeyExchange还是分两种情况： - * 如果是公钥或者RSA模式情况下，客户端将根据客户端生成的随机数和服务器端生成的随机数，生成预备主密码，通过该公钥进行加密，返送给服务器端。 - * 如果使用的是Diff-Hellman密钥交换协议，则客户端会发送自己这一方要生成Diff-Hellman密钥而需要公开的值。具体内容可以参考更加安全的密钥生成方法Diffie-Hellman，这样服务器端可以根据这个公开值计算出预备主密码。 -* 可选步骤:CertificateVerify客户端向服务器端证明自己是客户端证书的持有者。 -* ChangeCipherSpec(准备切换密码)ChangeCipherSpec是密码规格变更协议的消息，表示后面的消息将会以前面协商过的密钥进行加密。 -* finished(握手协议结束)客户端告诉服务器端握手协议结束了。 - - -### 4 服务器交换秘钥证书 -* ChangeCipherSpec(准备切换密码)服务器端告诉客户端自己要切换密码了。 -* finished(握手协议结束)服务器端告诉客户端，握手协议结束了。 -* 切换到应用数据协议。这之后服务器和客户端就是以加密的方式进行沟通了。 - - -### 主密码和预备主密码 -* 上面的步骤8生成了预备主密码，主密码是根据密码套件中定义的单向散列函数实现的伪随机数生成器+预备主密码+客户端随机数+服务器端随机数生成的。 - -* 主密码主要用来生成称密码的密钥，消息认证码的密钥和对称密码的CBC模式所使用的初始化向量。详见分组密码和模式 - - -## 5 记录协议 - -TLS记录协议主要负责消息的压缩，加密及数据的认证： - -![](image/2021-06-15-20-59-12.png) - -消息首先将会被分段，然后压缩，再计算其消息验证码，然后使用对称密码进行加密，加密使用的是CBC模式，CBC模式的初始向量是通过主密码来生成的。 - -得到密文之后会附加类型，版本和长度等其他信息，最终组成最后的报文数据。 - -## 6 加密算法 - - -### 对称密码 -### 消息认证码 -### 公钥密码 -### 数字签名 -### 伪随机数生成器 - - -## 7 协议关系 ### 协议概念 * TCP - TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，是七层协议中的第四层传输层的协议之一，大名鼎鼎的三次握手就发生在这里。 + TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，是七层协议中的第四层传输层的协议之一。 * HTTPS HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。 * SSL - SSL(Secure Sockets Layer 安全套接层)是为网络通信提供安全及数据完整性的一种安全协议。 + SSL(Secure Sockets Layer 安全套接层)是为网络通信提供安全及数据完整性的一种安全协议。当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。 * TLS 安全传输层协议（TLS：Transport Layer Security）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake），是更新、更安全的SSL版本。 -### 关系说明 +### 协议关系 +![](image/2021-06-17-00-10-16.png) * HTTPS是应用层的安全协议，TCP是传输层的协议，但是它不安全，因为它是明文传输的，所以SSL的诞生就是给TCP加了一层保险，使HTTPS和TCP之间使用加密传输。而TLS只是SSL的升级版，他们的作用是一样的。 * SSL 凭证安装于伺服器（例如网站服务器）上，但是在浏览器上，使用者仍可看到网站是否受到SSL 的保护。首先，如果SSL 出现在网站上，使用者看到的网址会是以https:// 开头，而不是http:// （多出的一个s 代表「安全」）。按照企业所获得的验证或凭证等级，安全连接会通过挂锁图标或绿色地址栏来显示。 * HTTPS会在网站受到SSL凭证保护时在网址中出现。该凭证的详细资料包括发行机构与网站拥有人的企业名称，可以通过按一下浏览器列上的锁定标记进行检视。 * 应用最广泛的是TLS1.0，接下来是SSL3.0 。但主流浏览器都已经实现了TLS 1.2 的支持。TLS 1.0有时被标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。TLS和SSL协议理论上属于传输层，在应用层实现，所以我们可以在浏览器中设置是否使用此协议，使用哪一版本的协议。 +## 2 应用 + +SSL/TLS是一个安全通信框架，上面可以承载HTTP协议或者SMTP/POP3协议等。下层基于TCP可靠数据连接实现。 + +![](image/2021-06-15-20-11-58.png) + +### 主要功能 + +* 数据完整性：内容传输经过完整性校验 +* 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥 +* 身份认证：第三方无法伪造服务端（客户端）身份 + +数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。 + +### 安全性 + +- 可以使用非对称或公钥、密码术（例如，RSA [RSA]、DSA [DSS] 等）来验证对等方的身份。此身份验证可以是可选的，但通常需要至少其中一位同行。 + +- 共享机密的协商是安全的：窃听者无法获得协商的机密，并且对于任何经过身份验证的连接，即使攻击者可以将自己置于连接中间，也无法获得该机密。 + +- 协商可靠：任何攻击者都不能在不被通信双方检测到的情况下修改协商通信。 +## 3 架构 + +![](image/2021-06-15-20-12-34.png) + +TLS主要分为两层 +* TLS Record Protocol底层的是TLS记录协议，主要负责使用对称密码（主密钥）对消息进行加密。 + +* TLS Handshake Protocol上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。 + * Handshake protocol握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。 + * Change cipher spec protocol密码规格变更协议负责向通信对象传达变更密码方式的信号 + * Alert protocol警告协议负责在发生错误的时候将错误传达给对方 + * Application data protocol应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。 + + +## 4 握手协议 +握手协议是TLS协议中非常重要的协议，通过客户端和服务器端的交互，和共享一些必要信息，从而生成共享密钥和交互证书。 +![](image/2021-06-15-23-09-52.png) +![](image/2021-06-15-20-41-00.png) +![](image/2021-06-16-22-33-20.png) + + +### 4.1 客户端请求SSL内容 + +* client hello客户端向服务器端发送一个client hello的消息，包含下面内容： +``` +1. 可用版本号：TSL1.0,TSL1.1,TSL1.2 +2. 当前时间 +3. 客户端随机数。 +4. 会话ID +5. 可用的密码套件清单。RSA、AES、MD5 +6. 可用的压缩方式清单。 +``` + +### 4.2 服务器响应SSL内容 + +* server hello服务器端收到client hello消息后，会向客户端返回一个server hello消息，包含如下内容： + +``` +1. 使用的版本号。使用的版本号，使用的密码套件，使用的压缩方式。 +2. 当前时间 +3. 服务器随机数。 +4. 会话ID +5. 使用的密码套件 +6. 使用的压缩方式 +``` + +* 可选步骤:certificate服务器端发送自己的证书清单。因为证书可能是层级结构的，所以处理服务器自己的证书之外，还需要发送为服务器签名的证书。客户端将会对服务器端的证书进行验证。如果是以匿名的方式通信则不需要证书。 +* 可选步骤:ServerKeyExchange。如果第三步的证书信息不足，则可以发送ServerKeyExchange用来构建加密通道。ServerKeyExchange的内容可能包含两种形式： + * 如果选择的是RSA协议，那么传递的就是RSA构建公钥。 + * 如果选择的是Diff-Hellman密钥交换协议，那么传递的就是密钥交换的参数。 +* 可选步骤:CertificateRequest如果是在一个受限访问的环境，比如fabric中，服务器端也需要向客户端索要证书。如果并不需要客户端认证，则不需要此步骤。 +* server hello done 服务器端发送server hello done的消息告诉客户端自己的消息结束了。 + +### 4.3 客户端交换秘钥证书 + + +* 可选步骤:Certificate。客户端发送客户端证书给服务器。 +* ClientKeyExchange还是分两种情况： + * 如果是公钥或者RSA模式情况下，客户端将根据客户端生成的随机数和服务器端生成的随机数，生成预备主密码，通过该公钥进行加密，返送给服务器端。 + * 如果使用的是Diff-Hellman密钥交换协议，则客户端会发送自己这一方要生成Diff-Hellman密钥而需要公开的值。 +* 可选步骤:Certificate Verify客户端向服务器端证明自己是客户端证书的持有者。 +* ChangeCipherSpec。密码规格变更协议的消息，表示后面的消息将会以前面协商过的密钥进行加密。 +* finished(握手协议结束)客户端告诉服务器端握手协议结束了。 + + +### 4.4 服务器交换秘钥证书 +* ChangeCipherSpec。服务器端告诉客户端自己要切换密码了。 +* finished(握手协议结束)服务器端告诉客户端，握手协议结束了。 + + +### 握手协议——RSA握手协议 +![](image/2021-06-17-11-43-17.png) + +### 握手协议——DH握手协议 + +![](image/2021-06-17-11-46-08.png) + +## 5 记录协议 + +TLS记录协议主要负责消息的压缩，加密和认证。当TLS完成握手过程后，客户端和服务端确定了加密，压缩和MAC算法及其参数，数据（Record）会通过指定算法处理。Record首先被加密，然后添加MAC（message authentication code）以保证数据完整性。 + +![](image/2021-06-15-20-59-12.png) + +* 在发送端：将数据（Record）分段，压缩，增加MAC(Message Authentication Code)和加密。消息首先将会被分段，然后压缩，再计算其消息验证码，然后使用对称密码进行加密，加密使用的是CBC模式，CBC模式的初始向量是通过主密码来生成的。 +* 在接收端：将数据（Record）解密，验证MAC，解压并重组得到密文之后会附加类型，版本和长度等其他信息，最终组成最后的报文数据。 + + + + + +## 6 master secret密码计算 +1. [明文] 客户端发送随机数client_random +2. [明文] 服务器返回随机数server_random +3. [RSA] 客户端使用证书中的公钥加密premaster secret发送给服务端 +4. 服务端使用私钥解密premaster secret +5. 两端分别通过client_random，server_random和premaster secret生成master secret，用于对称加密后续通信内容 + +一般的主密码计算方法 +``` +master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)[0..47]; +``` + +扩展的主密码计算方法 +``` +session_hash = Hash(handshake_messages) +master_secret = PRF(pre_master_secret, "extended master secret",session_hash)[0..47]; +``` + +### 三重握手攻击 +三重握手(Triple Handshake) (CVE-2014-1295)：攻击者（A）分别与客户端（C）和服务器（S）握手，协商出同一个主密钥；之后令客户端（C）和服务器（S）之间重新协商（renegotiation）或继续（resumption）会话来握手。可攻破重新协商，TLS Exporter RFC5705和"tls-unique" RFC5929。 + +``` +C：客户端。 A： 攻击者 S：服务端 + +C向A发送“ ClientHello”，A将其转发给S。 + +S向A发送“ ServerHello”，A将其转发给C。 + +S将包含其证书链的“证书”发送给A。 +A用自己的证书链替换它，并将其发送给C。 + +S向A发送“ ServerHelloDone”，A将其转发给C。 + +C向A发送“ ClientKeyExchange”，其中包含 +“ pre_master_secret”，已使用A的公钥加密。解密 +“ pre_master_secret”，使用S的公钥对其重新加密，并且 +将其发送给S。 + +C向A发送“完成”。A计算其“完成” +与S连接并将其发送给S。 + +S向A发送“完成”。A计算其“完成” +与C的连接，并将其发送给C。 +``` +通过以上方式，如果使用无“Extended Master Secret”扩展字段的计算方式将发现，从C->A和从A->S之间使用的会话密钥是一样的，这种叫做未知密钥共享（unkown key-share（UKS））攻击。当使用扩展主密钥的计算方式时，因为有session_hash，计算了所有协商消息的hash，如果中间攻击者A对协商消息进行改动，则客户端和服务端计算的hash值则不一样，最后计算出的主密钥也会不同。 + + +## 7 Cipher suite密码套件 + +### 典型构成 +* key establishment (typically a Diffie-Hellman variant or RSA)密钥建立（通常是 Diffie-Hellman 变体或 RSA） +* authentication (the certificate type)身份验证（证书类型） +* confidentiality (a symmetric cipher)机密性（对称密码） +* integrity (a hash function)完整性（散列函数） + +### “AES128-SHA” + +* RSA for key establishment (implied) +* RSA for authentication (implied) +* 128-bit Advanced Encryption Standard in Cipher Block Chaining (CBC) mode for confidentiality +* 160-bit Secure Hashing Algorithm (SHA) for integrity + +### “ECDHE-ECDSA-AES256-GCM-SHA384” + +* Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange for key establishment 椭圆曲线 Diffie-Hellman Ephemeral ( ECDHE ) 密钥交换 +* Elliptic Curve Digital Signature Algorithms (ECDSA) for authentication 身份验证的椭圆曲线数字签名算法 ( ECDSA ) +* 256-bit Advanced Encryption Standard in Galois/Counter mode (GCM) for confidentiality +* 384-bit Secure Hashing Algorithm for integrity \ No newline at end of file diff --git a/加密/3 TSL协议变迁.md b/加密/3 TSL协议变迁.md index e69de29b..7116a665 100644 --- a/加密/3 TSL协议变迁.md +++ b/加密/3 TSL协议变迁.md @@ -0,0 +1,212 @@ +## 1 TSL1.0 +### 概念 +* TLS(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。 +* TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1(可简单理解为同一事物不同阶段的不同称呼)，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 + +### 特点 +* 对话的内容用”对称加密”,而对于”对称加密”带来的密钥传输问题,则由”非对称加密”来解决,由于客户端没有”非对称加密”的解密能力,所以密钥由客户端来产生并用公钥加密传输给服务端,这样就(在思路上)解决了密钥传输的安全问题和对话数据解密的性能问题 + +### 技术 +``` +CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; + +//RSA 密钥建立、认证套件 +CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; +CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; +CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; +CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; +CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; +CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; +CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; +CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; +CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; +CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; + +//DH 密钥建立 RSA/DSS 认证套件 +CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; +CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; +CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; +CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; +CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; +CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; +CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; +CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; +CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; +CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; +CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; +CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; + +//DH 密钥建立 no 认证套件 +CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; +CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; +CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; +CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; +CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; +``` +## 2 TSL1.1 +### 特点 +相对之前版本的变化 +- 隐式初始化向量（IV）被显式IV替换以防止CBC攻击[CBCATT]。 + +- 填充错误的处理被更改为使用坏的\u记录\u mac警报，而不是解密失败的警报，以防止CBC攻击。 + +- IANA注册表是为协议参数定义的。 + +- 过早关闭不再导致会话不可恢复。 + +- 为TLS上的各种新攻击添加了其他信息注释。 + +### 技术 + + +* 密码套件 +``` +//RSA 加密、认证套件 +CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; +CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; +CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; +CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; +CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; +CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; +CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; + +//DH 加密 RSA/DSS 认证套件 +CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; +CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; +CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; +CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; +CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; +CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; +CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; +CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; + +//DH 加密 no 认证套件 +CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; +CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; +CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; +``` +## 3 TSL1.2 + +### 特点 + +本文件是TLS 1.1[TLS1.1]协议的修订版，其中包含改进的灵活性，特别是对于密码算法的协商。主要变化是： + +- 伪随机函数（PRF）中的MD5/SHA-1组合已被密码套件指定的PRF所取代。本文档中的所有密码套件都使用P_SHA256。 + +- MD5/SHA-1组合在数字电视中的应用.签名元素已被替换为单个哈希。有符号元素现在包含一个字段，该字段显式指定所使用的哈希算法。 + + +- 增加了对附加数据模式的认证加密的支持。 + +- TLS扩展定义和AES密码套件由外部[TLSEXT]和[TLSAES]合并而成。 + +- 更严格地检查加密的premastersecret版本号。 + +- 验证数据的长度现在取决于密码套件（默认值仍然是12）。 + +- 在许多情况下，现在必须发送警报。 + +- 在证书请求之后，如果没有可用的证书，客户端现在必须发送一个空的证书列表。 + +- TLS_RSA_WITH_AES_128_CBC_SHA现在是实现密码套件的必备工具。 + +- 添加HMAC-SHA256密码套件。 + +- 删除IDEA和DES密码套件。它们现在已被弃用，并将记录在一个单独的文档中。 + +- 支持SSLv2 + + +### 技术 + + +* 密码套件 +``` +//RSA 加密、认证套件 + +CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; +CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; +CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; +CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; +CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; +CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; +CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; +CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; +CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; +CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; + +//DH 加密 RSA/DSS 认证套件 +CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; +CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; +CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; +CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; +CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; +CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; +CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; +CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; +CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; +CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; +CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; +CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; +CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; +CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; +CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; +CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; +CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; +CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; +CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; +CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B }; + +//DH 加密 no 认证套件 +CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; +CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; +CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; +CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; +CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; +CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; + +``` +## 4 TSL1.3 + +### 特点 + + +- 受支持的对称加密算法列表已从所有被认为是遗留的算法中删去。剩下的都是使用关联数据（AEAD）算法进行身份验证的加密。密码套件的概念已经改变，将身份验证和密钥交换机制与记录保护算法（包括密钥长度）分开，并将哈希与密钥派生函数和握手消息身份验证码（MAC）一起使用。 + +- 添加了零往返时间（0-RTT）模式，节省了一些应用程序数据在连接设置时的往返时间，但牺牲了某些安全属性。 + +- 删除了静态RSA和Diffie-Hellman密码；所有基于公钥的密钥交换机制现在都提供前向保密性。 + +- ServerHello之后的所有握手消息现在都已加密。新引入EncryptedExtensions消息允许以前在服务器hello中以明文形式发送的各种扩展也享受保密保护。 + +- 重新设计了密钥派生函数。新的设计由于其改进的密钥分离特性，使得密码学家可以更容易地进行分析。基于HMAC的提取和扩展密钥派生函数（HKDF）被用作底层原语。 + +- 握手状态机已经被显著地重新构造为更加一致，并且删除了诸如ChangeCipherSpec之类的多余消息（除了在需要中间盒兼容性时）。 + +- 椭圆曲线算法现在是基本规范，新的签名算法，如EdDSA，包括在内。TLS 1.3删除了点格式协商，支持每条曲线的单点格式。 + +- 进行了其他加密改进，包括更改 RSA 填充以使用 RSA 概率签名方案 (RSASSA-PSS)，以及取消压缩、数字签名算法 (DSA) 和自定义临时 Diffie-Hellman (DHE) 组。 + +- TLS 1.2 版本协商机制已被弃用，以支持扩展中的版本列表。 这增加了与错误实施版本协商的现有服务器的兼容性。 + +- 带有和不带有服务器端状态的会话恢复以及早期 TLS 版本的基于 PSK 的密码套件已被一个新的 PSK 交换所取代。 + +### 技术 +* 新增的加密套件套件 +``` ++------------------------------+-------------+ +| Description | Value | ++------------------------------+-------------+ +| TLS_AES_128_GCM_SHA256 | {0x13,0x01} | +| | | +| TLS_AES_256_GCM_SHA384 | {0x13,0x02} | +| | | +| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} | +| | | +| TLS_AES_128_CCM_SHA256 | {0x13,0x04} | +| | | +| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} | ++------------------------------+-------------+ +``` + + diff --git a/加密/4 TLS1.3特性.md b/加密/4 TLS1.3特性.md new file mode 100644 index 00000000..59fd07e9 --- /dev/null +++ b/加密/4 TLS1.3特性.md @@ -0,0 +1,80 @@ +## 1 TSL1.2---->1.3变化 + +### 密钥协商机制改变 + +密钥协商机制改变，TLS1.3借助扩展进行密钥交换，TLS1.3只需要三次握手交互，TLS1.2则需要四次握手。相比过去的的版本，引入了新的密钥协商机制 — PSK +* TLS1.2，它通过KeyExchange进行密钥协商，即ServerKeyExchange和ClientKeyExchange，那么密钥交换本身就需要一个交互来回，所以总共有四次握手交互。 +![](image/2021-06-17-13-42-45.png) +![](image/2021-06-17-15-16-54.png) + +* TLS1.2 通过会话重建来加速完成密钥协商过程。 +![](image/2021-06-17-15-16-35.png) + +* TLS1.3，通过ClientHello和ServerHello的扩展进行密钥交换，那么就省去了1.2版本中KeyExchange的过程，也就省去了一次握手。 +![](image/2021-06-17-13-44-32.png) +![](image/2021-06-17-15-18-48.png) + +* TLS1.3 0-RTT模式密钥交换。以某些安全属性为代价。当client和server共享一个预共享密钥PSK（从外部获得或通过一个以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息的early data中携带数据，client使用这个PSK来认证server并加密early data。即在握手之前就有了PSK时，在第一次发送ClientHello时就可以发送加密数据，达到0-RTT数据传输的目的。 +![](image/2021-06-17-13-45-46.png) +![](image/2021-06-17-15-15-49.png) + +### 简化与改进 + +* 其他还包括新的密钥派生函数，删除多余的报文消息（ChangeCipherSpec，但我抓包测试时还是有） +* 全面使用ECC密码算法，删除不具有前向安全的密码套件。废弃了 3DES、RC4、AES-CBC 等加密组件，废弃了 SHA1、MD5 等哈希算法 +* 不再允许对加密报文进行压缩、不再允许双方发起重协商 +* DSA 证书不再允许在 TLS 1.3 中使用 +* TLS 1.3 的握手不再支持静态的 RSA 密钥交换，这意味着必须使用带有前向安全的 Diffie-Hellman 进行全面握手。 +* ServerHello之后的所有握手消息都被加密，引入了加密扩展EncryptedExtension。ServerHello 之后的所有握手消息采取了加密操作，可见明文大大减少 + +## 2 密钥交换机制(握手协议) + +### RSA 秘钥交换（TSL1.2） +1. client 发起请求（Client Hello） +2. server 回复 certificate +3. client使用证书中的公钥，加密预主秘钥，发给 server（Client Key Exchange） +4. server 提取出 预主秘钥，计算主秘钥，然后发送对称秘钥加密的finished。 +5. client 计算主秘钥，验证 finished，验证成功后，就可以发送Application Data了。 + +缺点：RSA秘钥交换不是前向安全算法（证书对应私钥泄漏后，之前抓包的报文都能被解密）。所以在 TLS 1.3中 RSA 已经废弃了。 + + +### ECDHE秘钥交换（TSL1.3） +1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。 +2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后 生成私钥（BIGNUM），乘以椭圆曲线的base point得到公钥（POINT），顺便签个名表示自己拥有证书，然后将报文发给client，报文就是Server Key Exchange，其包含了server选择的椭圆曲线参数、自己根据这个参数计算的公钥、自己用证书的私钥对当前报文的签名。 +3. client 收到 Server Key Exchange，获得椭圆曲线参数，生成私钥（BIGNUM）后计算公钥（POINT），然后把公钥发出去Client Key Exchange。client使用自己的私钥（BIGNUM）和server的公钥（POINT）计算出主秘钥。 +4. server 收到 client的公钥（POINT），使用自己的私钥（BIGNUM），计算主秘钥。两端主秘钥是一致。 + + +### 1-RTT模式密钥交换（TSL1.3） + +TLS 1.3 中是这样优化握手的： +1. client 发送请求（Client Hello），extension携带支持的椭圆曲线类型。且对每个自己支持的椭圆曲线类型计算公钥（POINT）。公钥放在extension中的keyshare中。 + 1. 支持的加密套件（该作用和之前一样）。 + 2. supproted_versions 拓展。包含自己支持的TLS协议版本号。（之前协议没有） + 3. supproted_groups 拓展，表示自己支持的椭圆曲线类型。 + 4. key_share拓展。包含supprot_groups中各椭圆曲线对应的public key。（当然可以发送空的，然后server会回复hello request，其中会包含server的key_share，可以用来探测，这里不讨论）。key_share中的椭圆曲线类型必须出现在supproted_groups中。（之前协议没有） +2. server 回复 Server Hello和certificate等；server选择的椭圆曲线参数，然后乘以椭圆曲线的base point得到公钥（POINT）。然后提取Client Hello中的key_share拓展中对应的公钥，计算主秘钥。公钥（POINT）不再和之前的以协议一样放在Server Key Exchange中，而是放在Server Hello的key_share拓展中。client收到server的公钥（POINT）后计算主秘钥。 + 1. （1）：supproted_versions 拓展。包含自己从client的supproted_versions中选择的TLS协议版本号。（之前协议没有） + 2. （2）：key_share拓展。包含自己选中的椭圆曲线，以及自己计算出来的公钥。（之前协议没有） + 3. server 发送Change Cipher Spec。（允许不发送） + 4. server发送Encrypted Extension。（加密的）ServerHello之后必须立刻发送Encrypted Extension。这是第一个被加密的数据数据。显然，放在这里的拓展，是和秘钥协商没关系的拓展。（之前协议没有） + 5. server发送Certificate（加密的）。这个报文和之前的协议没有太大区别，，在证书链中的每个证书后面，都有一个extension。（双向认证时也会有区别，有机会再说）。这个extension目前只能是OCSP Status extension和SignedCertificateTimestamps。 + 6. server发送Certificate Verify（加密的）这个报文并不陌生，但是以前只出现在双向认证（客户端认证）中，以前Certificate Verify生成的逻辑是将当前所有的握手报文解析解析签名（简单的md+非对称加密）。 + 7. server回复Finished（加密的）这个报文的目的和之前协议一样，检验握手报文的完整性。但是计算方法有变化。 + +### 0-RTT模式密钥交换 + +* 以某些安全属性为代价。当client和server共享一个预共享密钥PSK（从外部获得或通过一个以前的握手获得）时，TLS 1.3允许client在第一个发送出去的消息的early data中携带数据，client使用这个PSK来认证server并加密early data。即在握手之前就有了PSK时，在第一次发送ClientHello时就可以发送加密数据，达到0-RTT数据传输的目的。 +![](image/2021-06-17-13-45-46.png) + + +## 3 椭圆曲线 + +然后我们来看下ECDH的秘钥协商过程，首先EC的意思是椭圆曲线，这个EC提供了一个很厉害的性质，你在曲线上找一个点P，给定一个整数K，求解Q=KP很容易，给定一个点P,Q，知道Q =KP，求K却是个难题。在这个背景下，给定一个大家都知道的大数G，client在每次需要和server协商秘钥时，生成一段随机数a，然后发送A=a*G给server，server收到这段消息（a*G）后，生成一段随机数b，然后发送B=b*G给client，然后server端计算(a*G)*b作为对称秘钥，client端收到后b*G后计算a*(G*b)，因为(a*G)*b = a*(G*b)，所以对称秘钥就是a*G*b啦，攻击者只能截获A=a*G和B=b*G，由于椭圆曲线难题，知道A和G是很难计算a和b的，也就无法计算a*G*b了 + + + +## 4 中间人攻击 + +中间人攻击（Man-in-the-MiddleAttack，简称“MITM攻击”）是一种“间接”的入侵攻击，这种攻击模式是通过各种技术手段将受入侵者控制的一台计算机虚拟放置在网络连接中的两台通信计算机之间，这台计算机就称为“中间人”。 \ No newline at end of file diff --git a/加密/5 TLS实验.md b/加密/5 TLS实验.md new file mode 100644 index 00000000..3144a2e5 --- /dev/null +++ b/加密/5 TLS实验.md @@ -0,0 +1 @@ +![](image/2021-06-17-14-34-10.png) diff --git a/加密/6 加密算法.md b/加密/6 加密算法.md new file mode 100644 index 00000000..40248cd2 --- /dev/null +++ b/加密/6 加密算法.md @@ -0,0 +1,6 @@ + +* 非对称加密算法：RSA，DSA/DSS +* 对称加密算法：AES，RC4，3DES +* HASH算法：MD5，SHA1，SHA256 +* Record协议中的MAC(Message Authentication Code)算法 +* premaster secret、master secret生成算法 \ No newline at end of file diff --git a/加密/4 HTTPS协议.md b/加密/7 HTTPS协议.md similarity index 90% rename from 加密/4 HTTPS协议.md rename to 加密/7 HTTPS协议.md index 880f3cc9..05d20dd2 100644 --- a/加密/4 HTTPS协议.md +++ b/加密/7 HTTPS协议.md @@ -2,7 +2,13 @@ ## 1 HTTPS +### 主要功能 +* 数据完整性：内容传输经过完整性校验 +* 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥 +* 身份认证：第三方无法伪造服务端（客户端）身份 + +数据完整性和隐私性由TLS Record Protocol保证，身份认证由TLS Handshaking Protocols实现。 ### 认证过程 HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手，在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议，更是一件经过艺术家精心设计的艺术品，TLS/SSL中使用了非对称加密，对称加密以及HASH算法。握手过程的具体描述如下： diff --git a/加密/image/2021-06-16-22-33-20.png b/加密/image/2021-06-16-22-33-20.png new file mode 100644 index 00000000..2c7342cd Binary files /dev/null and b/加密/image/2021-06-16-22-33-20.png differ diff --git a/加密/image/2021-06-17-00-10-16.png b/加密/image/2021-06-17-00-10-16.png new file mode 100644 index 00000000..46698d9e Binary files /dev/null and b/加密/image/2021-06-17-00-10-16.png differ diff --git a/加密/image/2021-06-17-11-43-17.png b/加密/image/2021-06-17-11-43-17.png new file mode 100644 index 00000000..c2623c41 Binary files /dev/null and b/加密/image/2021-06-17-11-43-17.png differ diff --git a/加密/image/2021-06-17-11-46-08.png b/加密/image/2021-06-17-11-46-08.png new file mode 100644 index 00000000..1f32a288 Binary files /dev/null and b/加密/image/2021-06-17-11-46-08.png differ diff --git a/加密/image/2021-06-17-13-42-45.png b/加密/image/2021-06-17-13-42-45.png new file mode 100644 index 00000000..2f65c739 Binary files /dev/null and b/加密/image/2021-06-17-13-42-45.png differ diff --git a/加密/image/2021-06-17-13-44-32.png b/加密/image/2021-06-17-13-44-32.png new file mode 100644 index 00000000..45ba1eb8 Binary files /dev/null and b/加密/image/2021-06-17-13-44-32.png differ diff --git a/加密/image/2021-06-17-13-45-46.png b/加密/image/2021-06-17-13-45-46.png new file mode 100644 index 00000000..30a45b60 Binary files /dev/null and b/加密/image/2021-06-17-13-45-46.png differ diff --git a/加密/image/2021-06-17-14-34-10.png b/加密/image/2021-06-17-14-34-10.png new file mode 100644 index 00000000..ba576374 Binary files /dev/null and b/加密/image/2021-06-17-14-34-10.png differ diff --git a/加密/image/2021-06-17-15-15-49.png b/加密/image/2021-06-17-15-15-49.png new file mode 100644 index 00000000..50d61caf Binary files /dev/null and b/加密/image/2021-06-17-15-15-49.png differ diff --git a/加密/image/2021-06-17-15-16-35.png b/加密/image/2021-06-17-15-16-35.png new file mode 100644 index 00000000..2ee44901 Binary files /dev/null and b/加密/image/2021-06-17-15-16-35.png differ diff --git a/加密/image/2021-06-17-15-16-54.png b/加密/image/2021-06-17-15-16-54.png new file mode 100644 index 00000000..440ab57d Binary files /dev/null and b/加密/image/2021-06-17-15-16-54.png differ diff --git a/加密/image/2021-06-17-15-18-48.png b/加密/image/2021-06-17-15-18-48.png new file mode 100644 index 00000000..2ee44901 Binary files /dev/null and b/加密/image/2021-06-17-15-18-48.png differ diff --git a/加密/会议记录.md b/加密/会议记录.md new file mode 100644 index 00000000..79dbf343 --- /dev/null +++ b/加密/会议记录.md @@ -0,0 +1,7 @@ +网络流量高维特征-------神经网络、深度学习-------分类。 + +课题3 + +1. 密码学-dpi + +视频、分类。 \ No newline at end of file