本備忘錄的狀態
本文檔為Internet社區提供信息。它不指定一個Internet標準。本備忘錄的發布不
受任何限制。
版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要
本文檔描述如何在Internet上使用TLS保護HTTP連接。當前的通行做法是HTTP
位于SSL（TLS的前輩）之上，通過使用一個不同的服務器端口來區別受保護的通信
量和不安全的通信。本文檔描述了使用TLS的實踐。一個伴侶文檔描述一種在正常的
HTTP端口之上使用HTTP/TLS[RFC2817]的方法。

目錄
1.介紹 2
相關術語 2
2.TLS之上的HTTP 2
2.1.初始化連接 2
2.2.關閉連接 2
2.2.1客戶行為 3
2.2.2服務器行為 3
2.3端口號 3
2.4URI格式 4
3端標識 4
3.1服務器身份 4
3.2客戶身份 4
參考 5
安全考慮 5
作者地址： 5
版權說明 6
致謝 6


1.介紹
HTTP[RFC2616]最初是在INTERNET上不用密碼的應用。但隨著HTTP的敏感性應
用日益增加，對安全性的要求也隨之增加。SSL及其后繼TLS[RFC2246]提供了面向通
道的安全性。本文介紹怎樣在TLS之上應用HTTP。
相關術語
在本文中的要害字“必須”，“必須不”，“要求”，“應該”，“不應該”和“可
能”的解釋見[RFC2119]。
2.TLS之上的HTTP
從概念上講，HTTP/TLS非常簡單。簡單地在TLS上應用HTTP，如同在TCP上應
用HTTP一樣。
2.1.初始化連接
作為HTTP客戶的代理同時也應作為TLS的客戶。它應該向服務器的適當端口發
起一個連接，然后發送TLSClientHello來開始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-LinePRodUCtion。TLS服務器期
望最先收到的數據是ClientHello。因此，一般做法是在一個單獨的端口上運行
HTTP/TLS，以區分是在使用哪種協議。當在TCP/ip連接上運行HTTP/TLS時，缺省端口是
443。這并不排除HTTP/TLS運行在其它傳輸上。TLS只假設有可靠的、面向連接的數據
流。

2.4URI格式
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字段中必須使用CommonName字段。雖然使用CommonName是通常的做法，
但不受贊成，而CertificationAuthorities被鼓勵使用dNSName。
使用[RFC2459]中的匹配規則進行匹配。若在證書中給定類型的身份標識超過一個
（也就是，超過一個dNSName和集合中的相匹配），名字可以包括通配符＊表示和單個域
名或其中的一段相匹配。例如：＊.a.com和foo.a.com匹配但和bar.foo.a.com不匹配。
f＊.com和foo.com匹配但和bar.com不匹配。
在某些情況下，URI定義的不是主機名而是IP地址。在這種情況下，證書中必須有
iPAddresssubjectAltName字段且必須精確匹配在URI中的IP地址。
若主機名和證書中的標識不相符，面向用戶的客戶端必須或者通知用戶(客戶端可以
給用戶機會來繼續連接)或終止連接并報證書錯。自動客戶端必須將錯誤記錄在適當的審
計日志中(若有的話)并應該終止連接(帶一證書錯)。自動客戶端可以提供選項禁止這種檢
查，但必須提供選項使能它。
注重，在很多情況下URI本身是從不可信任的源得到的。以上描述的檢查并未提供對
危害源的攻擊的保護。例如，若URI是從一個未采用HTTP/TLS的HTML頁面得到的，某個
人可能已在中間已替換了URI。為防止這種攻擊，用戶應仔細檢查服務器提供的證書是否
是期望的。
3.2客戶標識
典型情況下，服務器并不知道客戶的標識是什么也就無法檢查(除非有合適的CA證
書)。若服務器知道的話(通常是在HTTP和TLS之外的源得到的)，它應該象上面描述的那
樣檢查。
參考
[RFC2459]Housley,R.,Ford,W.,Polk,W.andD.Solo,"Internet
PublicKeyInfrastructure:PartI:X.509Certificateand
CRLProfile",RFC2459,January1999.

[RFC2616]Fielding,R.,Gettys,J.,Mogul,J.,Frystyk,H.,
Masinter,
L.,Leach,P.andT.Berners-Lee,"HypertextTransfer
Protocol,HTTP/1.1",RFC2616,June1999.

[RFC2119]Bradner,S.,"KeyWordsforuseinRFCstoindicate
RequirementLevels",BCP14,RFC2119,March1997.

[RFC2246]Dierks,T.andC.Allen,"TheTLSProtocol",RFC2246,
January1999.

[RFC2817]Khare,R.andS.Lawrence,"UpgradingtoTLSWithin
HTTP/1.1",RFC2817,May2000.

安全考慮
整個文檔是關于安全的。
作者地址：
EricRescorla
RTFM,Inc.
30NewellRoad,#16
EastPaloAlto,CA94303

Phone:(650)328-8631
EMail:<Ahref="mailto:ekr@rtfm.com">ekr@rtfm.com</A>


版權說明
Copyright(C)TheInternetSociety(2001).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlain
it
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraph
are
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedon
an
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.