TLS之上的HTTP

1.介紹

HTTP[RFC2616]最初是在INTERNET上不用密碼的應用。但隨着HTTP的敏感性應用日益增長，對安全性的要求也隨之增長。SSL及其後繼TLS[RFC2246]提供了面向通道的安全性。本文介紹怎樣在TLS之上應用HTTP。

相關術語

在本文中的關鍵字「必須」，「必須不」，「要求」，「應該」，「不該該」和「可能」的解釋見[RFC2119]。

2. TLS之上的HTTP

從概念上講，HTTP/TLS很是簡單。簡單地在TLS上應用HTTP，如同在TCP上應用HTTP同樣。

2.1 初始化鏈接

做爲HTTP客戶的代理同時也應做爲TLS的客戶。它應該向服務器的適當端口發起一個鏈接，而後發送TLS ClientHello來開始TLS握手。當TLS握手完成，客戶能夠初始化第一個HTTP請求。全部的HTTP數據必須做爲TLS的「應用數據」發送。正常的HTTP行爲，包括保持鏈接，應當被遵照。

2.2 關閉鏈接

TLS提供了安全關閉鏈接的機制。當收到一個有效的關閉警告時，實現上必須保證在這個鏈接上再也不接收任何數據。TLS的實如今關閉鏈接以前必須發起交換關閉請求。TLS實現可能在發送關閉請求後，不等待對方發送關閉請求即關閉該鏈接，產生一個「不徹底的關閉」。注意：這樣的實現可能選擇重用該對話。這隻應在應用瞭解（典型的是經過檢測HTTP的消息邊界）它已收到全部它關心的數據的狀況下進行。

如[RFC2246]中所定義的，任何未接收一個有效的關閉警告（一個「未成熟關閉」）即接到一個鏈接關閉必須不重用該對話。注意：一個未成熟請求並不質疑數據已被安全地接收，而僅意味着接下來數據可能被截掉。因爲TLS並不知道HTTP的請求/響應邊界，爲了解數據截斷是發生在消息內仍是在消息之間，有必要檢查HTTP數據自己（即Content-Length頭）。

2.2.1 客戶行爲

因爲HTTP使用鏈接關閉表示服務器數據的終止，客戶端實現上對任何未成熟的關閉要做爲錯誤對待，對收到的數據認爲有可能被截斷。在某些狀況下HTTP協議容許客戶知道截斷是否發生，這樣若是客戶收到了完整的應答，則在遵循「嚴出鬆入[RFC1958]」的原則下可容忍這類錯誤，常常數據截斷不體如今HTTP協議數據中；有兩種狀況特別值得注意：

一個無Content-Length頭的HTTP響應。在這種狀況下數據長度由鏈接關閉請求通知，咱們沒法區分由服務器產生的未成熟關閉請求及由網絡攻擊者僞造的關閉請求。

一個帶有有效Content-Length頭的HTTP響應在全部數據被讀取完以前關閉。因爲TLS並不提供面向文檔的保護，因此沒法知道是服務器對Content-Length計算錯誤仍是攻擊者已截斷鏈接。

以上規則有一個例外。當客戶遇到一個未成熟關閉時，客戶把全部已接收到的數據同Content-Length頭指定的同樣多的請求視爲已完成。

客戶檢測到一個未完成關閉時應予以有序恢復，它可能恢復一個以這種方式關閉的TLS對話。

客戶在關閉鏈接前必須發送關閉警告。未準備接收任何數據的客戶可能選擇不等待服務器的關閉警告而直接關閉鏈接，這樣在服務器端產生一個不徹底的關閉。

2.2.2 服務器行爲

RFC2616容許HTTP客戶在任什麼時候候關閉鏈接，並要求服務器有序地恢復它。特別是，服務器應準備接收來自客戶的不徹底關閉，由於客戶每每可以判斷服務器數據的結束。服務器應樂於恢復以這種方式關閉的TLS對話。

實現上注意：在不使用永久鏈接的HTTP實現中，服務器通常指望能經過關閉鏈接通知數據的結束。可是，當Content-Length被使用時，客戶可能早已發送了關閉警告並斷開了鏈接。

服務器必須在關閉鏈接前試圖發起同客戶交換關閉警告。服務器可能在發送關閉警告後關閉鏈接，從而造成了客戶端的不徹底關閉。

2.3端口號

HTTP服務器指望最早從客戶收到的數據是Request-Line production。TLS服務器指望最早收到的數據是ClientHello。所以，通常作法是在一個單獨的端口上運行HTTP/TLS，以區分是在使用哪一種協議。當在TCP/IP鏈接上運行HTTP/TLS時，缺省端口是443。這並不排除HTTP/TLS運行在其它傳輸上。TLS只假設有可靠的、面向鏈接的數據流。

2.4 URI格式

HTTP/TLS和HTTP的URI不一樣，使用協議描述符https而不是http。使用HTTP/TLS的一個URI例子是：

https://www.example.com/~smith/home.html

3 端標識

3.1 服務器身份

一般，解析一個URI產生HTTP/TLS請求。結果客戶獲得服務器的主機名。若主機名可用，爲防止有人在中間攻擊，客戶必須把它同服務器證書信息中的服務器的身份號比較檢查。

若客戶有相關服務器標誌的外部信息，主機名檢查能夠忽略。（例如：客戶可能鏈接到一個主機名和IP地址都是動態的服務器上，但客戶瞭解服務器的證書信息。）在這種狀況下，爲防止有人攻擊，儘量縮小可接受證書的範圍就很重要。在特殊狀況下，客戶簡單地忽略服務器的身份是能夠的，但必須意識到鏈接對攻擊是徹底敞開的。

若dNSName類型的subjectAltName擴展存在，則必須被用做身份標識。不然，在證書的Subject字段中必須使用Common Name字段。雖然使用Common Name是一般的作法，但不受同意，而Certification Authorities被鼓勵使用dNSName。

使用[RFC2459]中的匹配規則進行匹配。若在證書中給定類型的身份標識超過一個（也就是，超過一個dNSName和集合中的相匹配），名字能夠包括通配符＊表示和單個域名或其中的一段相匹配。例如：＊.a.com和foo.a.com匹配但和bar.foo.a.com不匹配。f＊.com和foo.com匹配但和bar.com不匹配。

在某些狀況下，URI定義的不是主機名而是IP地址。在這種狀況下，證書中必須有iPAddress subjectAltName字段且必須精確匹配在URI中的IP地址。

若主機名和證書中的標識不相符，面向用戶的客戶端必須或者通知用戶(客戶端能夠給用戶機會來繼續鏈接)或終止鏈接並報證書錯。自動客戶端必須將錯誤記錄在適當的審計日誌中(如有的話)並應該終止鏈接(帶一證書錯)。自動客戶端能夠提供選項禁止這種檢查，但必須提供選項使能它。

注意，在不少狀況下URI自己是從不可信任的源獲得的。以上描述的檢查並未提供對危害源的攻擊的保護。例如，若URI是從一個未採用HTTP/TLS的HTML頁面獲得的，某我的可能已在中間已替換了URI。爲防止這種攻擊，用戶應仔細檢查服務器提供的證書是不是指望的。

3.2 客戶標識

典型狀況下，服務器並不知道客戶的標識是什麼也就沒法檢查(除非有合適的CA證書)。若服務器知道的話(一般是在HTTP和TLS以外的源獲得的)，它應該象上面描述的那樣檢查。

文檔下載    《RFC2818-TLS之上的HTTP.doc》

原創文章，轉載請註明： 轉載自成長的企鵝

本文連接地址： TLS之上的HTTP

關於我：成長的企鵝簡介