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）的方案經過在加密鏈接建立前向服務器發送主機名解決了這一問題。