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

1、 SSL

1. SSL简介

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

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

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

SSL协议提供的服务主要有：1）认证用户和服务器，确保数据发送到正确的客户机和服务器；2）加密数据以防止数据中途被窃取；3）维护数据的完整性，确保数据在传输过程当中不被改变。

SL协议使用不对称加密技术实现会话双方之间信息的安全传递。能够实现信息传递的保密性、完整性，而且会话双方能鉴别对方身份。

 

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

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

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

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

 

握手的目的

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内。它在其余协议中已被代表可使用，但尚未被普遍应用。

 

2、 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还对什么时候应该发送某些警报进行记录。

 

3、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）的方案经过在加密链接建立前向服务器发送主机名解决了这一问题。