在HTTP/1.1中升級到TLS

本備忘錄的狀態

本文檔為Inte.net社區定義Internet標準協議，同時征求改進意見和建議。關于本
協議的現狀和標準化狀態請參閱“Internet官方協議標準”(STD1)。本備忘錄的發布不受
任何限制。

版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

摘要

本文檔描述如何使用HTTP/1.1的升級機制在一個現存的TCP連接上發起安全傳輸
層(TLS)。這樣就允許安全的和不安全的HTTP通信共享同一個眾所周知的端口（在這
個例子中，http在80端口而不是在像https在443端口）。這種做法也支持“虛擬主
機”，因此一個HTTP+TLS服務器能區分發往在同一個IP地址上的幾個主機的消息。
HTTP/1.1[1]中將升級定義為逐跳的機制，本備忘錄也描述了用于跨越HTTP代理
建立端到端隧道的HTTPCONNECT機制。最后，本備忘錄為公用HTTP狀態碼和公用或
私有升級產品符號建立了新的IANA注冊。
本備忘錄不影響到當前“https”URI方案的定義，該方案已經定義了一個單獨的
名字空間（http://example.org/和https://example.org/不等價）。







目錄
1.動機 2
2．介紹 3
2.1.相關術語 3
3.客戶請求升級到TLS之上的HTTP 3
3.1.可選的升級 3
3.2.強制升級 4
3.3服務器對升級請求的確認 4
4服務器請求升級到TLS之上的HTTP 4
4.1選項通知 4
4.1強制通知 4
5通過代理的升級 5
6使用4xx（客戶錯誤）狀態碼的原理 6
7IANA的考慮 6
7.1HTTP狀態碼登記 7
安全考慮 7
7.1https:URI方案含義 8
7.2CONNECT的安全考慮 8
參考 8
作者地址 9
附錄A　致謝 10
完整版權聲明 10
致謝 11


1.動機
過去在SSL3[3]上配置HTTP是用一個唯一的URI及TCP端口號，這樣同單獨的
HTTP相區分。方案“http”意味著在80端口單獨的HTTP協議，而“https”表示在
443端口的SSL之上的HTTP協議。類似的，其它應用協議（例如：snews，ftps）為區
分安全和不安全的使用，要求使用二個端口號。這個方法使得可用的眾所周知的端口
數減半。
在1997年12月華盛頓特區IETF會議上，應用區主管及IESG重申不贊成使用并行
的“安全”端口號。HTTP/1.1的升級機制可以在一個打開的HTTP連接上建立傳輸層安
全[6]。
自最近兩年來，大家已經廣泛接受了這個建議，但對實現一個取代通常的用于網
絡瀏覽的443端口沒有多大興趣。實際上，本備忘錄不影響當前對https:URI的解
釋。但是，在HTTP之上建立的新的應用協議如Internet打印協議[7]，需要這樣的機
制使得IETF標準化進程前進一步。
升級機制也解決了“虛擬主機”問題。HTTP/1.1服務器不是給一個主機分配多個
IP地址，而是使用主機：頭來區分web服務。由于HTTP/1.1的使用日益流行，越來越
多的ISP提供基于名字的虛擬主機，使得IP地址空間不會馬上耗盡。
TLS（及SSL）和HTTP的早期版本一樣受制于：初始化的握手不指定需要的主機
名，而只依賴于IP地址。使用明文的HTTP/1.1升級：作為TLS握手的序幕，――基于
初始的主機：頭選擇證書，――可使得ISP同樣能提供基于名字的安全虛擬主機。
2．介紹
TLS又名SSL（安全套接字層），建立一個私有端到端連接，選項包括使用多種密碼系
統的相互之間的強認證。開始時，一次握手過程使用三個子協議來設置一個記錄層，認證
端點，設置參數，和報告錯誤。然后，由一個分層記錄協議處理加密，壓縮和重組連接的
剩余部分。后者希望做成完全透明。例如，在TLS的記錄標記或認證和HTTP/1.1的大塊編
碼或認證之間沒有關聯。
客房和服務器都能使用HTTP/1.1[1]升級機制（14.42節）來指示TLS安全連接是必要
的。本備忘錄定義了“TLS/1.0”升級記號和一個新的HTTP狀態碼，“426－需要升級”。
小節3和小節4描述了直接相連的客房和服務器的操作。如小節5中闡述的，在實施任
何操作之前中間代理必須建立端到端的隧道。
2.1.相關術語
在本文中的關鍵字“必須”，“必須不”，“要求”，“應該”，“不應該”和“可
能”的解釋見[RFC2119]。
3.客戶請求升級到TLS之上的HTTP
當客戶發送一個有包含記號“TLS/1.0”的升級包頭的HTTP/1.1請求，它表示請
求服務器在轉換到TLS/1.0之后完成當前的HTTP/1.1請求。
3.1.可選的升級
當一個不安全的響應可接受時，一個客戶在任何明文的HTTP請求期間可以要求轉
換到安全的操作流程：

GEThttp://example.bank.com/acct_stat.html?749394889300HTTP/1.1
Host:example.bank.com
Upgrade:TLS/1.0
Connection:Upgrade

在這個例子中，服務器可以對明文的HTTP請求作正常響應或是轉換到安全的操作中
（細節見下一小節）。
注意在HTTP/1.1[1]中定義“無論在HTTP/1.1消息中何時出現升級關健字，該關健字
必須出現在一個連接頭的域中（14.10小節）”。
3.2.強制升級
若無法接受一個不安全的響應，客戶必須首先發送一個選項請求來完成到TLS/1.0的
切換（若可能的話）。

OPTIONS*HTTP/1.1
Host:example.bank.com
Upgrade:TLS/1.0
Connection:Upgrade

3.3服務器對升級請求的確認
如HTTP/1.1[1]中定義的，如果服務器準備初始化TLS握手，必須發送中間的“101轉
換協議”且必須包括一個定義它要轉換到的協議棧記號的升級響應頭：

HTTP/1.1101SwitchingProtocols
Upgrade:TLS/1.0,HTTP/1.1
Connection:Upgrade

注意在101轉換協議升級頭中列出的協議記號定義了一個自底向上的棧。
如HTTP/1.1[1]，10.1.2小節中定義的：“服務器將在收到終止101響應的空行后立
即將協議轉換至響應的升級頭域定義的協議。
一旦TLS握手成功完成，服務器必須繼續對原來請求的應答。任何TLS握手失敗必須
通過TLS錯誤告警規范導致連接中斷，。
4服務器請求升級到TLS之上的HTTP
升級響應頭域宣告一個服務器可能接受的協議升級。和“426升級請求”狀態碼相結
合，服務器能發送一個客戶必須接受的協議升級來完成請求。
4.1選項通知
如在HTTP/1.1[1]中定義的，服務器可以在任何除了101或426的響應中包含一個升級
頭表示轉換到任何列出的協議（組合）。
4.1強制通知
服務器可以使用“426需要升級”表示沒有TLS無法完成客戶請求，這個響應必須包含
一個定義了需要的TLS版本記號的升級頭域。

HTTP/1.1426UpgradeRequired
Upgrade:TLS/1.0,HTTP/1.1
Connection:Upgrade

服務器應該在426響應中包含一個消息體以一種可讀形式指示錯誤原因和描述另外對用
戶可用的路線。
注意，即使客戶愿意使用TLS，它出必須使用在第3節中的操作來進行；在426響應之
后TLS握手不能馬上開始。
5通過代理的升級
作為一個逐跳的頭部，HTTP的每一對參加者間要協商升級。若一個用戶代理發送一個
帶升級頭的請求給代理，它要求的是在自己和代理之間的改變而不是端與端之間的改變。
因為TLS特別要求端到端的連接提供認證并防備中間人攻擊，本備忘錄定義了CONNECT
方法用以建立一個跨越代理的隧道。
隧道一旦建立，第3節描述的操作都可用于建立TLS連接。

5.1逐跳升級的含義
當一個源服務器從代理收到一個升級頭并以101轉換協議響應，它只是改變自己和代
理之間連接的協議。同樣，一個代理可以返回給客戶101響應來改變該連接上的協議，該
協議獨立于與源服務器通信的協議。
這種情況使得診斷426響應變得更加復雜。由于升級是一個逐跳的頭部，一個不識別
426響應的代理可能會刪去相隨的升級頭部，使得客戶無法決定如何進行協議轉換。若客戶
端收到一個沒有相隨的升級頭部的426狀態碼，它將如5.2節中描述的那樣請求一個端到端
隧道連接并一直請求以獲得需要的升級信息。
這個端到端的升級定義是一個深思熟慮的選擇。這允許代理每端的增量實施，和在級
聯的代理間的優化協議，而無需知道改變之外的部分。

5.2用CONNECT請求一隧道

CONNECT方法請求代理代表它建立一個連接通道。請求命令行的請求URI部分總是如URI通
用語法[2]定義的一個‘authority'，該定義指明請求連接的目的主機名和端口號，由冒
號分隔：

CONNECTserver.example.com:80HTTP/1.1
Host:server.example.com:80

其它HTTP機制能和CONNECT方法一起正常使用――除了端到端的協議升級請求――由于必
須先建立隧道這是當然的。
例如，proxyauthentication可被用來建立創建隧道的機構：

CONNECTserver.example.com:80HTTP/1.1
Host:server.example.com:80
Proxy-Authorization:basicaGVsbG86d29ybGQ=

如同任何其它的管道HTTP/1.1請求，由隧道通過的數據可以在空行后立即發送。通常的警
告是：若最終的響應是拒絕的話，數據可以被丟棄，若有超過一個TCP數據段未完成，則
連接可以不做任何響應而被復位。

5.3使用CONNECT建立一個隧道
對CONNECT請求的任何成功（2xx）的響應都表示代理已經和被請求的主機及相應端口
建立了連接，并且已經切換到在同該服務器的連接上開通隧道。
代理本身可能必須通過另一個代理才能到達請求的源服務器。在這種情況下，第一個
代理應該生成同下一個代理建立連接的請求，請求一個同authority的通道。代理絕不能
對2xx狀態碼響應，除非它已經有一個到authority直接的或隧道的連接。
一個源服務器接收到對自己的連接請求可以用2xx狀態碼響應，表示連接已經建立。
如果在任何時候任何一方斷連，任何來自于該端的數據將傳送到另一方，之后另一方
的連接也被代理終止。若有到先斷連一端的數據未傳送，這些數據都將被丟棄。


6使用4xx（客戶錯誤）狀態碼的原理
可靠的，共同協商的升級特性需要一個明確的失敗信號。426升級請求狀態碼允許服務
器明確地聲明必須提供一個給定資源想要的協議擴展。
起先看起來，響應應具有重定向的某種形式(3xx碼)，類似到一個https:URI的舊式重
定向。但不理解升級機制的用戶代理使得不能這樣做。
設想某個3xx代碼已被賦與“需要升級”的含義；一個不能識別它的用戶代理將把它
當做300。它可能在響應中尋找一個“Location”頭并試圖重復對頭部域中的URL的請求。
由于它不知道升級以合并TLS層，它最終在新的URL上會再次失敗。

7.IANA的考慮
如BCP26[10]中描述的，IANA將為二種名字空間登記：
HTTP狀態碼
HTTP升級記號

7.1HTTP狀態碼登記
HTTP狀態碼的登記定義了在HTTP響應的狀態行中的狀態碼記號。這個名字空間的初始
值是由這些定義的：
1. HTTP/1.1標準草案
2. Web分布式創作及版本[4][定義420-424]
3. WebDAV高級集合[5]（正在制訂）[定義425]
4. 第6節[定義426]
要加入到該名字空間的值應該以標準記錄文檔格式提交IETF應用組。任何這種文檔應該通
過HTTP/1.1[1]草案的狀態詞“過時”或“更新”使得可追蹤來源。

7.2HTTP升級記號登記

HTTP升級記號登記為產品記號定義了名字空間，該名字空間用于在升級HTTP頭部域中
分辯協議。每一個登記的記號應該同一個或一組規范相聯系并有相聯系的信息。
HTTP/1.1[1]標準草案定義了這些遵從產品生產的記號：
產品（product）=記號["/"產品版本]
產品版本=記號

如BCP26[10]中描述的，登記應該基于先來先服務的原則。這些定義不需要是IETF文
檔或是IESG關注的課題，但應該遵守下列原則：
1. 一個記號一旦登記，就永遠是登記了的。
2. 登記必須指定一個負責登記的團體。
3. 登記必須指定一個聯系辦法。
4. 登記必須指定記號需要的文檔。
5. 負責的團體可以隨時改變登記項。IANA將記錄下所有這種改變，并使它對需要的人可
用。
6. 對一個“產品”記號第一次登記負責的團體在他們能夠登記前必須同意同“產品”記號
一起的“版本”記號的晚些時候的登記。
7. 若確實需要，IESG可以重新指定一個記號的負責團體。通常這只是在負責團體無法聯
系到時才會這樣。

本規范定義協議記號“TLS/1.0”作為TLS協議[6]定義的協議的標識符號。
并不要求升級記號的定義是公眾可用的，但登記的聯系信息應該是。

8.安全考慮
潛在的中間人攻擊（刪除升級頭部）和目前http/https混用一樣：
.移去升級頭與重寫網頁來將https://links改變為http://links類似。
.只有在服務器首先通過安全或不安全的通道公開這類信息才會造成這種風險。
.若客戶知道服務器可處理TLS，它就會堅持發送不帶選項如OPTIONS的升級請求。
.最后如https:定義警告的，“用戶應該仔細檢查服務器提供的證書以確定是否符合他
們的期望。

此外，對于未明確激活TLS的客戶，服務器可在響應中使用除了101或426的升級頭來
通告TLS能力。既然TLS能力應該作為服務器的特性而不是就在手邊的資源，它應一次發送
就足夠，讓客戶知道這個事實以在需要時使用。

8.1https:URI方案含義

本備忘錄沒有影響‘https’的含義，廣泛采用的超文本內容可以使用‘http’來區分
安全和不安全的資源。
連接時安全特性的選擇留給客戶和服務器。這允許每一方用任何可用的信息作出決
定。例如，用戶代理可以依靠有關網絡安全方面的用戶設置，如“對不在我的本地網絡上
的所有POST操作都要求使用TLS”，或服務器可應用如‘本頁面的FORM的提交和處理必須
用TLS’等資源存取規則。

8.2CONNECT的安全考慮

一個類屬的TCP通道是充滿安全風險的。首先，這種授權應該被限制在一小部分端
口。這里定義的升級機制只是在80端口的隧道上需要。第二，既然隧道數據對代理不透
明，對其它眾所周知和保留端口的隧道有額外的風險。例如，假定一個HTTP客戶連接到25
端口，他可以通過SMTP傳播垃圾郵件。

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

[2]Berners-Lee,T.,Fielding,R.andL.Masinter,"URIGeneric
Syntax",RFC2396,August1998.

[3]Rescorla,E.,"HTTPOverTLS",RFC2818,May2000.

[4]Goland,Y.,Whitehead,E.,Faizi,A.,Carter,S.andD.Jensen,
"WebDistributedAuthoringandVersioning",RFC2518,February
1999.

[5]Slein,J.,Whitehead,E.J.,etal.,"WebDAVAdvancedCollections
Protocol",WorkInProgress.

[6]Dierks,T.andC.Allen,"TheTLSProtocol",RFC2246,January
1999.

[7]Herriot,R.,Butler,S.,Moore,P.andR.Turner,"Internet
PrintingProtocol/1.0:EncodingandTransport",RFC2565,April
1999.

[8]Luotonen,A.,"TunnelingTCPbasedprotocolsthroughWebproxy
servers",WorkInProgress.(Alsoavailablein:Luotonen,Ari.
WebProxyServers,Prentice-Hall,1997ISBN:0136806120.)

[9]Rose,M.,"WritingI-DsandRFCsusingXML",RFC2629,June
1999.

[10]Narten,T.andH.Alvestrand,"GuidelinesforWritinganIANA
ConsiderationsSectioninRFCs",BCP26,RFC2434,October1998.

[11]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

作者地址
RohitKhare
4KAssociates/UCIrvine
3207PaloVerde
Irvine,CA92612
US

Phone:+16268067574
EMail:rohit@4K-associates.com
URI:http://www.4K-associates.com/

ScottLawrence
AgranatSystems,Inc.
5ClocktowerPlace
Suite400
Maynard,MA01754
US

Phone:+197846100
EMail:lawrence@agranat.com
URI:http://www.agranat.com/

附錄A　致謝
TheCONNECTmethodwasoriginallydescribedinaWorkinProgress
titled,"TunnelingTCPbasedprotocolsthroughWebproxyservers",
[8]byAriLuotonenofNetscapeCommunicationsCorporation.Itwas
widelyimplementedbyHTTPproxies,butwasnevermadeapartofany
IETFStandardsTrackdocument.ThemethodnameCONNECTwasreserved,
butnotdefinedin[1].

Thedefinitionprovidedhereisderiveddirectlyfromthatearlier
memo,withsomeeditorialchangesandconformancetothestylistic
conventionssinceestablishedinotherHTTPspecifications.

AdditionalThanksto:

oPaulHoffmanforhisworkontheSTARTTLScommandextensionfor
ESMTP.
oRoyFieldingforassistancewiththerationalebehindUpgrade:
anditsinteractionwithOPTIONS.
oEricRescorlaforhisworkonstandardizingtheexistinghttps:
practicetocomparewith.
oMarshallRose,forthexml2rfcdocumenttypedescriptionandtools
[9].
oJimWhitehead,forsortingoutthecurrentrangeofavailableHTTP
statuscodes.
oHenrikFrystykNielsen,whoseworkontheMandatoryextension
mechanismpointedoutahop-by-hopUpgradestillrequires
tunneling.
oHaraldAlvestrandforimprovementstothetokenregistration
rules.

完整版權聲明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.