HTTPS协议之SSL/TLS详解（下）

Posted 小小太空人w

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了HTTPS协议之SSL/TLS详解（下）相关的知识，希望对你有一定的参考价值。

目录

前言：

SSL/TLS详解

HTTP协议传输安全性分析

对称加密

非对称加密

证书

小结：

前言：

    在网络世界中，存在着运营商劫持和一些黑客的攻击。如果明文传输数据是很危险的操作，因为我们不清楚中间传输过程中就被哪个服务器偷梁换柱了。

    现在网络中大多数使用的都是HTTPS协议。HTTP协议没有加密的概念，就意味着将会进行明文传输，数据很容易就被劫持了。HTTPS协议是HTTP协议的加强版本（S就是SSL或者TLS），引入了证书的概念，很大程度上保证了数据的安全性。

SSL/TLS详解

HTTP协议传输安全性分析

注意：

    明文传输，当数据经过中间黑客控制的服务器时，数据就可以直接被篡改。服务器得到的请求就是篡改后的请求。当响应经过黑客服务器时同样也可以被篡改，那么客户端和服务器所得到的数据就是黑客说了算。就不存在安全性可言。

对称加密

    所谓对称加密就是：同一个密钥既可以加密也可以解密。

    a(明文) + key = b(密文)

    b(密文) + key = a(明文)

    不同的客户端肯定要使用不同的对称密钥来对数据进行加密。那么当客户端生成对称密钥后，就需要将对称密钥和数据一起传输到服务器，服务器才能解密数据。

问题：

    这次传输当经过中间黑客控制的服务器时，那么黑客也可以劫持到密钥，对数据解密进行篡改。那么我们只要解决对称密钥的传输数据就是安全的。

非对称加密

    生成一对密钥，公钥和私钥。用公钥加密，私钥解密（公钥是公开的，密钥是私有的）。

    明文 + 公钥 = 密文

    密文 + 私钥 = 明文

注意：

    服务器生成一对非对称密钥，公钥是公开的，密钥只有自己知道。客户端使用公钥对对称密钥加密传输到服务器。由于黑客控制的服务器不知道私钥，就没有办法解密。当服务器得到数据后，用私钥解密得到对称密钥。那么以后的传输就可以直接使用对称密钥对数据进行加密了。

    为什么有非对称加密还要使用对称加密呢？

    答：非对称加密是比较耗时，而对称加密效率高。如果每次都使用非对称加密，效率会很低。使用非对称加密将对称密钥传输到服务器后，就可以使用对称加密了。效率会有显著提升。

问题：

    中间人攻击，黑客模仿服务器也生成一对公钥和密钥，发给客户端（偷梁换柱得到明文）。由于客户端的公钥也是服务器生成好传输过去的。

注意：

    客户端需要发起请求得到服务器生成的公钥。服务器返回响应时说：公钥是pub1。经过黑客控制的服务器时，黑客保存pub1。并且自己也生成一对非对称密钥（pub2，pri2）。然后返回响应说：公钥是pub2。

    客户端用pub2对对称密钥加密。黑客服务器收到后，使用pri2解密得到对称密钥。然后又使用之前保存的pub1加密，传输到服务器。服务器任然可以使用pri1解密。黑客神不知鬼不觉黑客就得到了对称密钥。

证书

    解决中间人攻击的核心方法就是：让客户端能够辨别得到的公钥是否为服务器发来的公钥。引入一个“证书”（本质上是第三方的公证机构）。

    服务器（网站）在设立之初，需要向公证机构申请证书，服务器生成的公钥也就包含在证书中。客户端向服务器不在是请求公钥了，而是把整个证书都请求过来。

    客户端拿到证书后，就会对证书进行校验。验证一下证书是否是被篡改过的（证书中存在一个加密的签名）。如果证书是无效的，浏览器就会直接弹窗告警。

注意：

    服务器在建立时向认证机构申请证书（提交一些信息，包含公钥），认证机构就会向服务器颁发证书，包含认证机构用自己私钥加密的签名。客户端向服务器请求证书就会获得证书（包含公钥）。

    客户端用认证机构提供的公钥解密签名进行校验（校验的过程类似tcp/udp校验和）。签名是根据证书中内容来生成的，客户端得到数据后，重新根据数据计算一次签名，与之前的签名进行对比。辨别数据是否被篡改。

    黑客如果把证书中的公钥篡改了，客户端计算的签名就会和证书中的签名不一致。黑客根据自己的算法重新生成签名（把签名篡改了）。由于黑客不知道认证机构的私钥，就算生成了也无法加密。黑客直接模仿认证机构重新生成证书，也由于黑客不知道认证机构的私钥，无法生成。

    整个过程就类似于我们使用身份证来证明身份，警察局就是第三方认证机构。这个身份证无法被别人生成，别人就可以通过身份证来辨别我们的身份。

小结：

    理解HTTPS协议的加密过程，当我们使用其协议时就会比较得心应手了。

Python Web学习笔记之SSL,TLS,HTTPS

一、 SSL

1. SSL简介

SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：

SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。

SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

SSL协议提供的服务主要有：1）认证用户和服务器，确保数据发送到正确的客户机和服务器；2）加密数据以防止数据中途被窃取；3）维护数据的完整性，确保数据在传输过程中不被改变。
SL协议使用不对称加密技术实现会话双方之间信息的安全传递。可以实现信息传递的保密性、完整性，并且会话双方能鉴别对方身份。

 

目的是在两个通信应用程序之间提供私密信和可靠性。这个过程通过3个元素来完成：

1、握手协议。这个协议负责协商被用于客户机和服务器之间会话的加密参数。当一个SSL客户机和服务器第一次开始通信时，它们在一个协议版本上达成一致，选择加密算法，选择相互认证，并使用公钥技术来生成共享密钥。

2、记录协议。这个协议用于交换应用层数据。应用程序消息被分割成可管理的数据块，还可以压缩，并应用一个MAC（消息认证代码）；然后结果被加密并传输。接受方接受数据并对它解密，校验MAC，解压缩并重新组合它，并把结果提交给应用程序协议。

3、警告协议。这个协议用于指示在什么时候发生了错误或两个主机之间的会话在什么时候终止。

 

握手的目的

1. 客户端与服务器需要就一组用于保护数据的算法达成一致；
2. 它们需要确立一组由那些算法所使用的加密密钥；
3. 握手还可以选择对客户端进行认证。

 

2. SSL流程

服务器认证阶段：

1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；

【协商用于加密的消息加密算法和用于完整性检查的哈希函数。通常由客户机提供它支持的所有算法列表，然后由服务器选择最强健的加密算法。】

2）服务器根据客户的信息确定是否需要生成新的主密钥，如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；

3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；

4）服务器回复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。

 

用户认证阶段：

在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。

经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。

 

详细步骤：

1. 用户浏览器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送到服务器。(协商用于加密的消息加密算法和用于完整性检查的哈希函数。通常由客户机提供它支持的所有算法列表，然后由服务器选择最强健的加密算法)

2. 服务器将其SSL版本号、加密设置参数、与session有关的数据以及其它一些必要信息发送给浏览器，同时发给浏览器的还有服务器的证书。如果配置服务器的SSL需要验证用户身份，还要发出请求要求浏览器提供用户证书。
3. 客户端检查服务器证书，如果检查失败，提示不能建立SSL连接。如果成功，那么继续。
4. 客户端浏览器为本次会话生成pre-master secret（比如随机数），并将其用服务器公钥加密后发送给服务器。
5. 如果服务器要求鉴别客户身份，客户端还要再对另外一些数据签名后并将其与客户端证书一起发送给服务器。
6. 如果服务器要求鉴别客户身份，则检查签署客户证书的CA是否可信。如果不在信任列表中，结束本次会话。如果检查通过，服务器用自己的私钥解密收到的pre-master secret，并用它通过某些算法生成本次会话的master secret。
7. 客户端与服务器均使用此master secret生成本次会话的会话密钥(对称密钥)。在双方SSL握手结束后传递任何消息均使用此会话密钥。这样做的主要原因是对称加密比非对称加密的运算量低一个数量级以上，能够显著提高双方会话时的运算速度。
8. 客户端通知服务器此后发送的消息都使用这个会话密钥进行加密。并通知服务器客户端已经完成本次SSL握手。 
9. 服务器通知客户端此后发送的消息都使用这个会话密钥进行加密。并通知客户端服务器已经完成本次SSL握手。
10. 本次握手过程结束，会话已经建立。双方使用同一个会话密钥分别对发送以及接受的信息进行加、解密。

 

SSL协议的优点是它提供了连接安全，具有3个基本属性：

l 连接是私有的。在初始握手定义了一个密钥之后，将使用加密算法。对于数据加密使用了对称加密（例如DES和RC4）。

l 可以使用非对称加密或公钥加密（例如RSA和DSS）来验证对等实体的身份。

l 连接时可靠的。消息传输使用一个密钥的MAC，包括了消息完整性检查。其中使用了安全哈希函数（例如SHA和MD5）来进行MAC计算。

对于SSL的接受程度仅仅限于HTTP内。它在其他协议中已被表明可以使用，但还没有被广泛应用。

 

二、 TLS

1. TLS简介

TLS：安全传输层协议 
  （TLS：Transport Layer Security Protocol） 
  安全传输层协议（TLS）用于在两个通信应用程序之间提供保密性和数据完整性。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。 TLS 记录协议提供的连接安全性具有两个基本特性：   

私有――对称加密用以数据加密（DES 、RC4 等）。对称加密所产生的密钥对每个连接都是唯一的，且此密钥基于另一个协议（如握手协议）协商。记录协议也可以不加密使用。   
可靠――信息传输包括使用密钥的 MAC 进行信息完整性检查。安全哈希功能（ SHA、MD5 等）用于 MAC 计算。记录协议在没有 MAC 的情况下也能操作，但一般只能用于这种模式，即有另一个协议正在使用记录协议传输协商安全参数。   
  TLS 记录协议用于封装各种高层协议。作为这种封装协议之一的握手协议允许服务器与客户机在应用程序协议传输和接收其第一个数据字节前彼此之间相互认证，协商加密算法和加密密钥。 TLS 握手协议提供的连接安全具有三个基本属性：   

可以使用非对称的，或公共密钥的密码术来认证对等方的身份。该认证是可选的，但至少需要一个结点方。 
共享加密密钥的协商是安全的。对偷窃者来说协商加密是难以获得的。此外经过认证过的连接不能获得加密，即使是进入连接中间的攻击者也不能。 
协商是可靠的。没有经过通信方成员的检测，任何攻击者都不能修改通信协商。 
  TLS 的最大优势就在于：TLS 是独立于应用协议。高层协议可以透明地分布在 TLS 协议上面。然而， TLS 标准并没有规定应用程序如何在 TLS 上增加安全性；它把如何启动 TLS 握手协议以及如何解释交换的认证证书的决定权留给协议的设计者和实施者来判断。 


协议结构 

  TLS 协议包括两个协议组―― TLS 记录协议和 TLS 握手协议――每组具有很多不同格式的信息。在此文件中我们只列出协议摘要并不作具体解析。具体内容可参照相关文档。

  TLS 记录协议是一种分层协议。每一层中的信息可能包含长度、描述和内容等字段。记录协议支持信息传输、将数据分段到可处理块、压缩数据、应用 MAC 、加密以及传输结果等。对接收到的数据进行解密、校验、解压缩、重组等，然后将它们传送到高层客户机。

  TLS 连接状态指的是 TLS 记录协议的操作环境。它规定了压缩算法、加密算法和 MAC 算法。

  TLS 记录层从高层接收任意大小无空块的连续数据。密钥计算：记录协议通过算法从握手协议提供的安全参数中产生密钥、 IV 和 MAC 密钥。 TLS 握手协议由三个子协议组构成，允许对等双方在记录层的安全参数上达成一致、自我认证、例示协商安全参数、互相报告出错条件。

 

2. TLS流程

Simple TLS handshake

A simple connection example follows, illustrating a handshake where the server (but not the client) is authenticated by its certificate:

  1. Negotiation phase:
    • A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested CipherSuites and suggested compression methods. If the client is attempting to perform a resumed handshake, it may send a session ID.
    • The server responds with a ServerHello message, containing the chosen protocol version, a random number, CipherSuite and compression method from the choices offered by the client. To confirm or allow resumed handshakes the server may send a session ID. The chosen protocol version should be the highest that both the client and server support. For example, if the client supports TLS1.1 and the server supports TLS1.2, TLS1.1 should be selected; SSL 3.0 should not be selected.
    • The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).[31]
    • The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
    • The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.) This PreMasterSecret is encrypted using the public key of the server certificate.
    • The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed pseudorandom function.
  2. The client now sends a ChangeCipherSpecrecord【change_cipher_spec消息表示记录加密及认证的改变。一旦握手商定了一组新的密钥，就发送change_cipher_spec来指示此刻将启用新的密钥。】, essentially telling the server, "Everything I tell you from now on will be authenticated (and encrypted if encryption parameters were present in the server certificate)." The ChangeCipherSpec is itself a record-level protocol with content type of 20.
    • Finally, the client sends an authenticated and encrypted Finished message, containing a hash and MAC over the previous handshake messages.
    • The server will attempt to decrypt the client\'s Finished message and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
  3. Finally, the server sends a ChangeCipherSpec, telling the client, "Everything I tell you from now on will be authenticated (and encrypted, if encryption was negotiated)."Application phase: at this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will also be authenticated and optionally encrypted exactly like in their Finished message. Otherwise, the content type will return 25 and the client will not authenticate. 
    • The server sends its authenticated and encrypted Finished message.
    • The client performs the same decryption and verification.

交换key：

 

全部流程

 

 **SSL与TLS的差异

最新版本的TLS（Transport Layer Security，传输层安全协议）是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。在TLS与SSL3.0之间存在着显著的差别，主要是它们所支持的加密算法不同，所以TLS与SSL3.0不能互操作。
1．TLS与SSL的差异
1）版本号：TLS记录格式与SSL记录格式相同，但版本号的值不同，TLS的版本1.0使用的版本号为SSLv3.1。
2）报文鉴别码：SSLv3.0和TLS的MAC算法及MAC计算的范围不同。TLS使用了RFC-2104定义的HMAC算法。SSLv3.0使用了相似的算法，两者差别在于SSLv3.0中，填充字节与密钥之间采用的是连接运算，而HMAC算法采用的是异或运算。但是两者的安全程度是相同的。
3）伪随机函数：TLS使用了称为PRF的伪随机函数来将密钥扩展成数据块，是更安全的方式。
4）报警代码：TLS支持几乎所有的SSLv3.0报警代码，而且TLS还补充定义了很多报警代码，如解密失败（decryption_failed）、记录溢出（record_overflow）、未知CA（unknown_ca）、拒绝访问（access_denied）等。
5）密文族和客户证书：SSLv3.0和TLS存在少量差别，即TLS不支持Fortezza密钥交换、加密算法和客户证书。
6）certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息计算MD5和SHA-1散列码时，计算的输入有少许差别，但安全性相当。
7）加密计算：TLS与SSLv3.0在计算主密值（master secret）时采用的方式不同。
8）填充：用户数据加密之前需要增加的填充字节。在SSL中，填充后的数据长度要达到密文块长度的最小整数倍。而在TLS中，填充后的数据长度可以是密文块长度的任意整数倍（但填充的最大长度为255字节），这种方式可以防止基于对报文长度进行分析的攻击。
2．TLS的主要增强内容
TLS的主要目标是使SSL更安全，并使协议的规范更精确和完善。TLS 在SSL v3.0 的基础上，提供了以下增强内容：
1）更安全的MAC算法；
2）更严密的警报；
3）“灰色区域”规范的更明确的定义；
3．TLS对于安全性的改进
1）对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
2）增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
3）改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
4）一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
5）特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。

 

三、HTTPS

1. 简介

用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的完全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。。

https是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，https的安全基础是SSL，因此加密的详细内容请看SSL。
 
它是一个URI scheme(抽象标识符体系)，句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
 

HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密套件和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护。

HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）。因此，一个到某网站的HTTPS连接可被信任，当且仅当：

  1. 用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构；
  2. 用户相信证书颁发机构仅信任合法的网站；
  3. 被访问的网站提供了一个有效的证书，意即，它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）；
  4. 该证书正确地验证了被访问的网站（如，访问https://example时收到了给“Example Inc.”而不是其它组织的证书）；
  5. 或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃听者破坏。

2. 与HTTP的差别

与HTTP的URL由“http://”起始且默认使用端口80不同，HTTPS的URL由“https://”起始且默认使用端口443。

HTTP是不安全的，且攻击者通过监听和中间人攻击等手段，可以获取网站帐户和敏感信息等。HTTPS被设计为可防止前述攻击，并（在没有使用旧版本的SSL时）被认为是安全的。

3. 网络层

HTTP工作在应用层（OSI模型的最高层），但安全协议工作在一个较低的子层：在HTTP报文传输前对其加密，并在到达时对其解密。严格地讲，HTTPS并不是一个单独的协议，而是对工作在一加密连接（TLS或SSL）上的常规HTTP协议的称呼。

HTTPS报文中的任何东西都被加密，包括所有报头和荷载。除了可能的CCA（参见限制小节）之外，一个攻击者所能知道的只有在两者之间有一连接这一事实。

4. 服务器设置

要使一网络服务器准备好接受HTTPS连接，管理员必须创建一数字证书，并交由证书颁发机构签名以使浏览器接受。证书颁发机构会验证数字证书持有人和其声明的为同一人。浏览器通常都预装了证书颁发机构的证书，所以他们可以验证该签名。

5. 获得证书

由证书颁发机构签发的证书有免费的[3][4]，也有每年收费13美元[5]到1500美元[6]不等的。

一个组织也可能有自己的证书颁发机构，尤其是当设置浏览器来访问他们自己的网站时（如，运行在公司局域网内的网站，或大学的）。他们可以容易地将自己的证书加入浏览器中。

此外，还存在一个人到人的证书颁发机构，CAcert。

6. 作为访问控制

HTTPS也可被用作客户端认证手段来将一些信息限制给合法的用户。要做到这样，管理员通常会给每个用户创建证书（通常包含了用户的名字和电子邮件地址）。这个证书会被放置在浏览器中，并在每次连接到服务器时由服务器检查。

7.当私钥失密时

证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Google Chrome、Firefox[7]、Opera[8]和运行在Windows Vista上的Internet Explorer[9]都实现了在线证书状态协议（英语：Online Certificate Status Protocol）（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。[10]

8. 局限

TLS有两种策略：简单策略和交互策略。交互策略更为安全，但需要用户在他们的浏览器中安装個人的证书来进行认证。

不管使用了哪种策略，协议所能提供的保护总强烈地依赖于浏览器的实现和服务器软件所支持的加密算法。

HTTPS并不能防止站点被网络蜘蛛抓取。在某些情形中，被加密资源的URL可仅通过截获请求和响应的大小推得，[11]这就可使攻击者同时知道明文（公开的静态内容）和密文（被加密过的明文），从而使选择密文攻击成为可能。

因为SSL在HTTP之下工作，对上层协议一无所知，所以SSL服务器只能为一个IP地址/端口组合提供一个证书。[12]这就意味着在大部分情况下，使用HTTPS的同时支持基于名字的虚拟主机是不很现实的。一种叫Server Name Indication（英语：Server Name Indication）（SNI）的方案通过在加密连接创建前向服务器发送主机名解决了这一问题。

 

以上是关于HTTPS协议之SSL/TLS详解（下）的主要内容，如果未能解决你的问题，请参考以下文章

SSL/TLS 握手过程详解***

Python Web学习笔记之SSL,TLS,HTTPS

详解 HTTPSTLSSSLHTTP区别和关系

HTTP，SSL/TLS和HTTPS协议的区别与联系

Http协议之Https&SSL/TLS&DNS

https详解