|
本文檔描述如何在Internet上使用TLS保護(hù)HTTP連接。當(dāng)前的通行做法是HTTP
位于SSL（TLS的前輩）之上，通過使用一個(gè)不同的服務(wù)器端口來區(qū)別受保護(hù)的通信 量和不安全的通信。本文檔描述了使用TLS的實(shí)踐。一個(gè)伴侶文檔描述一種在正常的 HTTP端口之上使用HTTP/TLS[RFC2817]的方法。 1. 介紹 HTTP[RFC2616]最初是在INTERNET上不用密碼的應(yīng)用。但隨著HTTP的敏感性應(yīng) 用日益增加，對(duì)安全性的要求也隨之增加。SSL及其后繼TLS[RFC2246]提供了面向通 道的安全性。本文介紹怎樣在TLS之上應(yīng)用HTTP。 相關(guān)術(shù)語 在本文中的關(guān)鍵字"必須"，"必須不"，"要求"，"應(yīng)該"，"不應(yīng)該"和"可 能"的解釋見[RFC2119]。 2. TLS之上的HTTP 從概念上講，HTTP/TLS非常簡(jiǎn)單。簡(jiǎn)單地在TLS上應(yīng)用HTTP，如同在TCP上應(yīng) 用HTTP一樣。 2.1. 初始化連接 作為HTTP客戶的代理同時(shí)也應(yīng)作為TLS的客戶。它應(yīng)該向服務(wù)器的適當(dāng)端口發(fā) 起一個(gè)連接，然后發(fā)送TLS ClientHello來開始TLS握手。當(dāng)TLS握手完成，客戶可 以初始化第一個(gè)HTTP請(qǐng)求。所有的HTTP數(shù)據(jù)必須作為TLS的"應(yīng)用數(shù)據(jù)"發(fā)送。正 常的HTTP行為，包括保持連接，應(yīng)當(dāng)被遵守。 2.2. 關(guān)閉連接 TLS提供了安全關(guān)閉連接的機(jī)制。當(dāng)收到一個(gè)有效的關(guān)閉警告時(shí)，實(shí)現(xiàn)上必須保證在 這個(gè)連接上不再接收任何數(shù)據(jù)。TLS的實(shí)現(xiàn)在關(guān)閉連接之前必須發(fā)起交換關(guān)閉請(qǐng)求。TLS 實(shí)現(xiàn)可能在發(fā)送關(guān)閉請(qǐng)求后，不等待對(duì)方發(fā)送關(guān)閉請(qǐng)求即關(guān)閉該連接，產(chǎn)生一個(gè)"不完全 的關(guān)閉"。注意：這樣的實(shí)現(xiàn)可能選擇重用該對(duì)話。這只應(yīng)在應(yīng)用了解（典型的是通過檢 測(cè)HTTP的消息邊界）它已收到所有它關(guān)心的數(shù)據(jù)的情況下進(jìn)行。 如[RFC2246]中所定義的，任何未接收一個(gè)有效的關(guān)閉警告（一個(gè)"未成熟關(guān)閉"） 即接到一個(gè)連接關(guān)閉必須不重用該對(duì)話。注意：一個(gè)未成熟請(qǐng)求并不質(zhì)疑數(shù)據(jù)已被安全地 接收，而僅意味著接下來數(shù)據(jù)可能被截掉。由于TLS并不知道HTTP的請(qǐng)求/響應(yīng)邊界，為 了解數(shù)據(jù)截?cái)嗍前l(fā)生在消息內(nèi)還是在消息之間，有必要檢查HTTP數(shù)據(jù)本身（即Content- Length頭）。 2.2.1 客戶行為 由于HTTP使用連接關(guān)閉表示服務(wù)器數(shù)據(jù)的終止，客戶端實(shí)現(xiàn)上對(duì)任何未成熟的關(guān)閉 要作為錯(cuò)誤對(duì)待，對(duì)收到的數(shù)據(jù)認(rèn)為有可能被截?cái)唷Ｔ谀承┣闆r下HTTP協(xié)議允許客戶知 道截?cái)嗍欠癜l(fā)生，這樣如果客戶收到了完整的應(yīng)答，則在遵循"嚴(yán)出松入[RFC1958]"的 原則下可容忍這類錯(cuò)誤，經(jīng)常數(shù)據(jù)截?cái)嗖惑w現(xiàn)在HTTP協(xié)議數(shù)據(jù)中；有兩種情況特別值得 注意： 一個(gè)無Content-Length頭的HTTP響應(yīng)。在這種情況下數(shù)據(jù)長(zhǎng)度由連接關(guān)閉請(qǐng)求通 知，我們無法區(qū)分由服務(wù)器產(chǎn)生的未成熟關(guān)閉請(qǐng)求及由網(wǎng)絡(luò)攻擊者偽造的關(guān)閉請(qǐng)求。 一個(gè)帶有有效Content-Length頭的HTTP響應(yīng)在所有數(shù)據(jù)被讀取完之前關(guān)閉。由于 TLS并不提供面向文檔的保護(hù)，所以無法知道是服務(wù)器對(duì)Content-Length計(jì)算錯(cuò)誤還是攻 擊者已截?cái)噙B接。 以上規(guī)則有一個(gè)例外。當(dāng)客戶遇到一個(gè)未成熟關(guān)閉時(shí)，客戶把所有已接收到的數(shù)據(jù)同 Content-Length頭指定的一樣多的請(qǐng)求視為已完成。 客戶檢測(cè)到一個(gè)未完成關(guān)閉時(shí)應(yīng)予以有序恢復(fù)，它可能恢復(fù)一個(gè)以這種方式關(guān)閉的 TLS對(duì)話。 客戶在關(guān)閉連接前必須發(fā)送關(guān)閉警告。未準(zhǔn)備接收任何數(shù)據(jù)的客戶可能選擇不等待服 務(wù)器的關(guān)閉警告而直接關(guān)閉連接，這樣在服務(wù)器端產(chǎn)生一個(gè)不完全的關(guān)閉。 2.2.2 服務(wù)器行為 RFC2616允許HTTP客戶在任何時(shí)候關(guān)閉連接，并要求服務(wù)器有序地恢復(fù)它。特別是， 服務(wù)器應(yīng)準(zhǔn)備接收來自客戶的不完全關(guān)閉，因?yàn)榭蛻敉軌蚺袛喾?wù)器數(shù)據(jù)的結(jié)束。服 務(wù)器應(yīng)樂于恢復(fù)以這種方式關(guān)閉的TLS對(duì)話。 實(shí)現(xiàn)上注意：在不使用永久連接的HTTP實(shí)現(xiàn)中，服務(wù)器一般期望能通過關(guān)閉連接通 知數(shù)據(jù)的結(jié)束。但是，當(dāng)Content-Length被使用時(shí)，客戶可能早已發(fā)送了關(guān)閉警告并斷 開了連接。 服務(wù)器必須在關(guān)閉連接前試圖發(fā)起同客戶交換關(guān)閉警告。服務(wù)器可能在發(fā)送關(guān)閉警告 后關(guān)閉連接，從而形成了客戶端的不完全關(guān)閉。 2.3端口號(hào) HTTP服務(wù)器期望最先從客戶收到的數(shù)據(jù)是Request-Line production。TLS服務(wù)器期 望最先收到的數(shù)據(jù)是ClientHello。因此，一般做法是在一個(gè)單獨(dú)的端口上運(yùn)行 HTTP/TLS，以區(qū)分是在使用哪種協(xié)議。當(dāng)在TCP/IP連接上運(yùn)行HTTP/TLS時(shí)，缺省端口是 443。這并不排除HTTP/TLS運(yùn)行在其它傳輸上。TLS只假設(shè)有可靠的、面向連接的數(shù)據(jù) 流。 2.4 URI格式 HTTP/TLS和HTTP的URI不同，使用協(xié)議描述符https而不是http。使用HTTP/TLS 的一個(gè)URI例子是： https://www./~smith/home.html 3 端標(biāo)識(shí) 3.1 服務(wù)器身份 通常，解析一個(gè)URI產(chǎn)生HTTP/TLS請(qǐng)求。結(jié)果客戶得到服務(wù)器的主機(jī)名。若主機(jī)名 可用，為防止有人在中間攻擊，客戶必須把它同服務(wù)器證書信息中的服務(wù)器的身份號(hào)比較 檢查。 若客戶有相關(guān)服務(wù)器標(biāo)志的外部信息，主機(jī)名檢查可以忽略。（例如：客戶可能連接 到一個(gè)主機(jī)名和IP地址都是動(dòng)態(tài)的服務(wù)器上，但客戶了解服務(wù)器的證書信息。）在這種 情況下，為防止有人攻擊，盡可能縮小可接受證書的范圍就很重要。在特殊情況下，客戶 簡(jiǎn)單地忽略服務(wù)器的身份是可以的，但必須意識(shí)到連接對(duì)攻擊是完全敞開的。 若dNSName類型的subjectAltName擴(kuò)展存在，則必須被用作身份標(biāo)識(shí)。否則，在證 書的Subject字段中必須使用Common Name字段。雖然使用Common Name是通常的做法， 但不受贊成，而Certification Authorities被鼓勵(lì)使用dNSName。 使用[RFC2459]中的匹配規(guī)則進(jìn)行匹配。若在證書中給定類型的身份標(biāo)識(shí)超過一個(gè) （也就是，超過一個(gè)dNSName和集合中的相匹配），名字可以包括通配符＊表示和單個(gè)域 名或其中的一段相匹配。例如：＊.a.com和foo.a.com匹配但和bar.foo.a.com不匹配。 f＊.com和foo.com匹配但和bar.com不匹配。 在某些情況下，URI定義的不是主機(jī)名而是IP地址。在這種情況下，證書中必須有 iPAddress subjectAltName字段且必須精確匹配在URI中的IP地址。 若主機(jī)名和證書中的標(biāo)識(shí)不相符，面向用戶的客戶端必須或者通知用戶(客戶端可以 給用戶機(jī)會(huì)來繼續(xù)連接)或終止連接并報(bào)證書錯(cuò)。自動(dòng)客戶端必須將錯(cuò)誤記錄在適當(dāng)?shù)膶?br>計(jì)日志中(若有的話)并應(yīng)該終止連接(帶一證書錯(cuò))。自動(dòng)客戶端可以提供選項(xiàng)禁止這種檢 查，但必須提供選項(xiàng)使能它。 注意，在很多情況下URI本身是從不可信任的源得到的。以上描述的檢查并未提供對(duì) 危害源的攻擊的保護(hù)。例如，若URI是從一個(gè)未采用HTTP/TLS的HTML頁面得到的，某個(gè) 人可能已在中間已替換了URI。為防止這種攻擊，用戶應(yīng)仔細(xì)檢查服務(wù)器提供的證書是否 是期望的。 3.2 客戶標(biāo)識(shí) 典型情況下，服務(wù)器并不知道客戶的標(biāo)識(shí)是什么也就無法檢查(除非有合適的CA證 書)。若服務(wù)器知道的話(通常是在HTTP和TLS之外的源得到的)，它應(yīng)該象上面描述的那 樣檢查。 參考 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet Public Key Infrastructure: Part I: X.509 Certificate and CRL Profile", RFC 2459, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol, HTTP/1.1", RFC 2616, June 1999. [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999. [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. 安全考慮 整個(gè)文檔是關(guān)于安全的。 作者地址： Eric Rescorla RTFM, Inc. 30 Newell Road, #16 East Palo Alto, CA 94303 Phone: (650) 328-8631 EMail: <A href="mailto:ekr@rtfm.com">ekr@rtfm.com</A> 版權(quán)說明 Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 致謝 Funding for the RFC Editor function is currently provided by the Internet Society. RFC2818 HTTP Over TLS (http://www.) |
|
|
