本文檔描述如何在Internet上使用TLS保護HTTP連接。當前的通行做法是HTTP
位于SSL（TLS的前輩）之上，通過(guò)使用一個(gè)不同的服務(wù)器端口來(lái)區別受保護的通信
量和不安全的通信。本文檔描述了使用TLS的實(shí)踐。一個(gè)伴侶文檔描述一種在正常的
HTTP端口之上使用HTTP/TLS[RFC2817]的方法。
1. 介紹
HTTP[RFC2616]最初是在INTERNET上不用密碼的應用。但隨著(zhù)HTTP的敏感性應
用日益增加，對安全性的要求也隨之增加。SSL及其后繼TLS[RFC2246]提供了面向通
道的安全性。本文介紹怎樣在TLS之上應用HTTP。
相關(guān)術(shù)語(yǔ)
在本文中的關(guān)鍵字"必須"，"必須不"，"要求"，"應該"，"不應該"和"可
能"的解釋見(jiàn)[RFC2119]。
2. TLS之上的HTTP
從概念上講，HTTP/TLS非常簡(jiǎn)單。簡(jiǎn)單地在TLS上應用HTTP，如同在TCP上應
用HTTP一樣。
2.1. 初始化連接
作為HTTP客戶(hù)的代理同時(shí)也應作為T(mén)LS的客戶(hù)。它應該向服務(wù)器的適當端口發(fā)
起一個(gè)連接，然后發(fā)送TLS ClientHello來(lái)開(kāi)始TLS握手。當TLS握手完成，客戶(hù)可
以初始化第一個(gè)HTTP請求。所有的HTTP數據必須作為T(mén)LS的"應用數據"發(fā)送。正
常的HTTP行為，包括保持連接，應當被遵守。
2.2. 關(guān)閉連接
TLS提供了安全關(guān)閉連接的機制。當收到一個(gè)有效的關(guān)閉警告時(shí)，實(shí)現上必須保證在
這個(gè)連接上不再接收任何數據。TLS的實(shí)現在關(guān)閉連接之前必須發(fā)起交換關(guān)閉請求。TLS
實(shí)現可能在發(fā)送關(guān)閉請求后，不等待對方發(fā)送關(guān)閉請求即關(guān)閉該連接，產(chǎn)生一個(gè)"不完全
的關(guān)閉"。注意：這樣的實(shí)現可能選擇重用該對話(huà)。這只應在應用了解（典型的是通過(guò)檢
測HTTP的消息邊界）它已收到所有它關(guān)心的數據的情況下進(jìn)行。
如[RFC2246]中所定義的，任何未接收一個(gè)有效的關(guān)閉警告（一個(gè)"未成熟關(guān)閉"）
即接到一個(gè)連接關(guān)閉必須不重用該對話(huà)。注意：一個(gè)未成熟請求并不質(zhì)疑數據已被安全地
接收，而僅意味著(zhù)接下來(lái)數據可能被截掉。由于TLS并不知道HTTP的請求/響應邊界，為
了解數據截斷是發(fā)生在消息內還是在消息之間，有必要檢查HTTP數據本身（即Content-
Length頭）。
2.2.1 客戶(hù)行為
由于HTTP使用連接關(guān)閉表示服務(wù)器數據的終止，客戶(hù)端實(shí)現上對任何未成熟的關(guān)閉
要作為錯誤對待，對收到的數據認為有可能被截斷。在某些情況下HTTP協(xié)議允許客戶(hù)知
道截斷是否發(fā)生，這樣如果客戶(hù)收到了完整的應答，則在遵循"嚴出松入[RFC1958]"的
原則下可容忍這類(lèi)錯誤，經(jīng)常數據截斷不體現在HTTP協(xié)議數據中；有兩種情況特別值得
注意：
一個(gè)無(wú)Content-Length頭的HTTP響應。在這種情況下數據長(cháng)度由連接關(guān)閉請求通
知，我們無(wú)法區分由服務(wù)器產(chǎn)生的未成熟關(guān)閉請求及由網(wǎng)絡(luò )攻擊者偽造的關(guān)閉請求。
一個(gè)帶有有效Content-Length頭的HTTP響應在所有數據被讀取完之前關(guān)閉。由于
TLS并不提供面向文檔的保護，所以無(wú)法知道是服務(wù)器對Content-Length計算錯誤還是攻
擊者已截斷連接。
以上規則有一個(gè)例外。當客戶(hù)遇到一個(gè)未成熟關(guān)閉時(shí)，客戶(hù)把所有已接收到的數據同
Content-Length頭指定的一樣多的請求視為已完成。
客戶(hù)檢測到一個(gè)未完成關(guān)閉時(shí)應予以有序恢復，它可能恢復一個(gè)以這種方式關(guān)閉的
TLS對話(huà)。
客戶(hù)在關(guān)閉連接前必須發(fā)送關(guān)閉警告。未準備接收任何數據的客戶(hù)可能選擇不等待服
務(wù)器的關(guān)閉警告而直接關(guān)閉連接，這樣在服務(wù)器端產(chǎn)生一個(gè)不完全的關(guān)閉。
2.2.2 服務(wù)器行為
RFC2616允許HTTP客戶(hù)在任何時(shí)候關(guān)閉連接，并要求服務(wù)器有序地恢復它。特別是，
服務(wù)器應準備接收來(lái)自客戶(hù)的不完全關(guān)閉，因為客戶(hù)往往能夠判斷服務(wù)器數據的結束。服
務(wù)器應樂(lè )于恢復以這種方式關(guān)閉的TLS對話(huà)。
實(shí)現上注意：在不使用永久連接的HTTP實(shí)現中，服務(wù)器一般期望能通過(guò)關(guān)閉連接通
知數據的結束。但是，當Content-Length被使用時(shí)，客戶(hù)可能早已發(fā)送了關(guān)閉警告并斷
開(kāi)了連接。
服務(wù)器必須在關(guān)閉連接前試圖發(fā)起同客戶(hù)交換關(guān)閉警告。服務(wù)器可能在發(fā)送關(guān)閉警告
后關(guān)閉連接，從而形成了客戶(hù)端的不完全關(guān)閉。
2.3端口號
HTTP服務(wù)器期望最先從客戶(hù)收到的數據是Request-Line production。TLS服務(wù)器期
望最先收到的數據是ClientHello。因此，一般做法是在一個(gè)單獨的端口上運行
HTTP/TLS，以區分是在使用哪種協(xié)議。當在TCP/IP連接上運行HTTP/TLS時(shí)，缺省端口是
443。這并不排除HTTP/TLS運行在其它傳輸上。TLS只假設有可靠的、面向連接的數據
流。
2.4 URI格式
HTTP/TLS和HTTP的URI不同，使用協(xié)議描述符https而不是http。使用HTTP/TLS
的一個(gè)URI例子是：
https://www.example.com/~smith/home.html
3 端標識
3.1 服務(wù)器身份
通常，解析一個(gè)URI產(chǎn)生HTTP/TLS請求。結果客戶(hù)得到服務(wù)器的主機名。若主機名
可用，為防止有人在中間攻擊，客戶(hù)必須把它同服務(wù)器證書(shū)信息中的服務(wù)器的身份號比較
檢查。
若客戶(hù)有相關(guān)服務(wù)器標志的外部信息，主機名檢查可以忽略。（例如：客戶(hù)可能連接
到一個(gè)主機名和IP地址都是動(dòng)態(tài)的服務(wù)器上，但客戶(hù)了解服務(wù)器的證書(shū)信息。）在這種
情況下，為防止有人攻擊，盡可能縮小可接受證書(shū)的范圍就很重要。在特殊情況下，客戶(hù)
簡(jiǎn)單地忽略服務(wù)器的身份是可以的，但必須意識到連接對攻擊是完全敞開(kāi)的。
若dNSName類(lèi)型的subjectAltName擴展存在，則必須被用作身份標識。否則，在證
書(shū)的Subject字段中必須使用Common Name字段。雖然使用Common Name是通常的做法，
但不受贊成，而Certification Authorities被鼓勵使用dNSName。
使用[RFC2459]中的匹配規則進(jìn)行匹配。若在證書(shū)中給定類(lèi)型的身份標識超過(guò)一個(gè)
（也就是，超過(guò)一個(gè)dNSName和集合中的相匹配），名字可以包括通配符＊表示和單個(gè)域
名或其中的一段相匹配。例如：＊.a.com和foo.a.com匹配但和bar.foo.a.com不匹配。
f＊.com和foo.com匹配但和bar.com不匹配。
在某些情況下，URI定義的不是主機名而是IP地址。在這種情況下，證書(shū)中必須有
iPAddress subjectAltName字段且必須精確匹配在URI中的IP地址。
若主機名和證書(shū)中的標識不相符，面向用戶(hù)的客戶(hù)端必須或者通知用戶(hù)(客戶(hù)端可以
給用戶(hù)機會(huì )來(lái)繼續連接)或終止連接并報證書(shū)錯。自動(dòng)客戶(hù)端必須將錯誤記錄在適當的審
計日志中(若有的話(huà))并應該終止連接(帶一證書(shū)錯)。自動(dòng)客戶(hù)端可以提供選項禁止這種檢
查，但必須提供選項使能它。
注意，在很多情況下URI本身是從不可信任的源得到的。以上描述的檢查并未提供對
危害源的攻擊的保護。例如，若URI是從一個(gè)未采用HTTP/TLS的HTML頁(yè)面得到的，某個(gè)
人可能已在中間已替換了URI。為防止這種攻擊，用戶(hù)應仔細檢查服務(wù)器提供的證書(shū)是否
是期望的。
3.2 客戶(hù)標識
典型情況下，服務(wù)器并不知道客戶(hù)的標識是什么也就無(wú)法檢查(除非有合適的CA證
書(shū))。若服務(wù)器知道的話(huà)(通常是在HTTP和TLS之外的源得到的)，它應該象上面描述的那
樣檢查。
參考
[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>
版權說(shuō)明
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.fanqiang.com)
