RFC 2964

組織：中國互動出版網（http://www.china-pub.com/） RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：[email protected] 譯者：牛韜（NT [email protected]） 譯文發佈時間：2001-5-11 版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用於非商業用途自由轉載，但必須 保留本文檔的翻譯及版權信息。 Network Working Group K. Moore Request for Comments: 2964 University of Tennessee BCP: 44 N. Freed Category: Best Current Practice Innosoft October 2000 超文本傳輸協議(HTTP)狀態管理的應用 (RFC 2964 Use of HTTP State Management) 本備忘錄的狀態 本文檔描述了Internet社區的最通用的實踐（慣例），需要進一步探討和建議 進行完善。本備忘錄的發佈沒有限制。 版權公告 Copyright (C) The Internet Society (2000). All Rights Reserved. IESG 註解 The IESG 註解這種機制應用於包含.local 頂級域名 (TLD)在內，在處理主機名稱不含任 何點在內的情況下，如果沒有註冊一個真正的.local頂級域的話，這種機制可能無法動作。 摘要 這種機制在“HTTP狀態管理體制”（RFC-2965）中已經描述了，其原描述文檔（RFC-2109）， 能用於許多不同的目標。然而，許多當前的和潛在的對於這個協議的應用存在爭議，因爲它 們有重要的用戶隱私和在安全上的牽連。這個備忘錄識別了那些既不被IETF所推薦，或被認 爲是有害的和不安全的超文本協議（HTTP）在某些細節上的應用。本備忘錄也附加了一個HTTP 狀態管理協議中未曾包含的考慮安全方面的詳細的文檔。 1、介紹 HTTP狀態管理機制非常有用，但也存在着很大的爭議。它的實用性緣於衆多的HTTP應用 程序可以得益於它能保存HTTP傳輸狀態的能力，而不需對這種狀態在統一資源定位器（URL） 中進行編碼。而對它存在爭議是因爲它在成完成任務時的不確定性和較差的兼容性。由於這 些應用導致了大量的公衆的批評因爲他們的存在，導致了網上隱私的保密造成了的威脅。 用戶，確實通過漏洞將一些敏感的信息泄漏給第三方，例如一個用戶訪問了某個網站。而 通過漏洞，將該用戶的信息記錄了下來。那兒同時也有其它的HTTP狀態管理的用戶在，這是 不適當的，即使他們沒有對用戶隱私的威脅。 在RFC-2965文檔中已被詳細說明的的HTTP狀態管理協議IETF並不推薦使用，本備忘錄正是 爲此對其應用進行識別，HTTP狀態管理協議被認爲存在一定的危害性，因此並不被人看好。 本文檔偶爾使用一些用黑體字表示的術語，當下面這些術語如"必須", "不必", "應當", " 不會", 和 "可以"以黑體出現時，說明使用它們在說明書中有特定的要求，有關這些術語含 義的討論，如"必須", "應當", 和 "可以"，請參閱[RFC-1123]；術語"不必" 和 "不會"是在 用法上進行了邏輯的擴展。 2、HTTP狀態管理的應用 HTTP狀態管理的目標是基於HTTP的服務建立一個有狀態的可以持續穿過多重HTTP來處理 事務的“對話”。一個單獨的對話可以包括與多重服務器主機進行事務處理。多個客戶在對於 一個特定的用戶的對話數據被其它客戶共享（例如，通過一個文件系統）時，同樣可以被一 個對話所包括。換句話說，對話保留了用戶與一個服務之間的狀態，面不是兩個特定客戶端 之間的狀態。 使用“無屏蔽”的HTTP協議也同樣以相似的性能完成任務，認識這一點很重要。並且/或 者動態的產生HTML，而沒有狀態管理的擴展。例如，狀態信息能夠從服務到用戶通過嵌入到 一個或在HTTP的重定向中顯現的多個統一資源定位器的對話的標示符中，或動態的產生 HTML；並且狀態信息可以從用戶返回到這個服務當這URL出現一個GET或POST請求時。HTML 表格也能用於傳遞從服務到客戶的狀態信息並返回，而不必要讓用戶知道發生了什麼。 不管怎樣，HTTP狀態管理工具提供功能的確是比普通的HTTP和HTML增加了更多。在實踐中 這些附加的功能包括： （1）在兩個用戶之間互換URL，在有狀態的會話中資源的存取，而沒有與其它會話關聯的 狀態信息的泄漏。（例如，“這兒有FooCorp的網絡目錄入口的URL，而你正想要從這家公司 買拖鞋”） (2) 不用“緩衝猝發”維持會話狀態的能力。那就是，從URL中隔離出會話狀態允許一 個頁面緩衝來維護唯一的一個已命名的資源的副本。如果此狀態在會話細節URL 中維持，緩衝很有可能不得不維持幾個同樣的拷貝。 (3)與其它的維持會話狀態的技術相比，它具有使用最低的服務器配置和最小限度的費用 的優點。 （4）不管是否用戶已經通過一個特定的“主頁”或“入口”進入,都可以在用戶對服務進 行存取的任何時間聯繫用戶與會話。 (5) 能夠將會話信息保存在一個穩定的存儲容器中，因此一個“會話”能夠穿過客戶的 干擾，以及系統的重新起動和客戶端或系統的崩潰。. 2.1. 推薦的應用 當需要穿過多重HTTP處理事務，此時維持用戶與服務之間的狀態使用HTTP狀態的管理是 很合適的。假如： （1） 用戶知道會話正在維持並且用戶對其表示贊成, （2） 用戶可以在任何時間刪除與這樣一個會話相關聯的狀態信息， （3） 通過跟蹤用戶的使用該服務的方法獲取的信息，如果未經用戶的直接允許，是不會透 露給其它的人員的。 （4） 會話信息無法自己獲取敏感信息並且也不能被用於獲取敏感信息，要偷聽者無法從中 得到任何可用信息。 （5） 最後一點很重要因爲cookies 通常是明文發送的，因此，很容易被偷聽者竊取。 一個推薦的應用的例子就是“購物車”，購物車的存在對於用戶來說是非常清楚和明白的， 用戶可以明確的“清空”他或她的購物車（或者通過請求來清空或購買貨物），因此將導致對 共享狀態的放棄，這項服務不會不經用戶允許，而向第三方公開用戶的購物習慣和瀏覽習慣。 注意HTTP狀態管理協議有效的允許一個服務提供者拒供應服務，或提供一個限制級別的服 務，如果說某個用戶或一個用戶的客戶的維持會話狀態的請求無法兌現。相反的，缺少合法 的禁止，服務也許會拒絕提供服務，或者提供一個限制級的服務，在這些條件下。從一個純 實踐的角度考慮，如果說客戶端不提供此項服務，那麼利用HTTP狀態管理設計的服務也許無 法完全的運作。這樣的服務器應當能夠輕鬆的處理這種情形並向用戶解釋爲什麼無法享用全 部的服務。 2.2. 存在問題的應用 下面有關HTTP狀態管理的應用被認爲是不適當的,從反面進行了闡述： 2.2.1. 向第三方泄漏的信息 不經用戶的正式同意，HTTP 狀態管理一定不要應用於泄漏用戶或有關用戶瀏覽習慣的信 息給第三方，除了該用戶和服務外。 這種用法是禁止的，即使是把用戶的名字或其它的可對其進行標識的標識符泄漏給第三方， 因爲此狀態管理機制自己提供了一個可用於編譯有關用戶信息的標識符。 因爲這些實際情況使得HTTP狀態管理機制倍受人們的指責，他們傾向於限制HTTP狀態管 理的效果，因此它被認爲對於網絡的操作是有害的。 2.2.2. 作爲鑑定機制使用Use as an Authentication Mechanism 通常認爲HTTP狀態管理機制作爲鑑定機制使用是不合適的。HTTP狀態管理並不是專門爲 這種應用而設計的，因此它在鑑定認證的保護上的安全措施是缺乏的，不論是協議的說明書 還是對於普遍配置HTTP的客戶或服務器。絕大多數HTTP會話是不加密的，因此“cookies" 可能會因此被泄漏給偷聽者。此外HTTP客戶端和服務器又有這個特點：僅僅經過簡單的甚至 是根本沒有保護就對"cookies"進行明文存儲來防止信息的泄漏。HTTP狀態管理因此應當不 用於鑑定機制來保護信息避免其泄漏給未經授權的第三方，即使是HTTP會話是經過加密的。 對禁止的用於鑑定的HTTP狀態管理既包括使用於保護服務提供的信息又包括有關用戶 交給服務託管的潛在和敏感的信息。例如，如果泄漏一個用戶的名字、地址、電話號碼或賬 單信息給一個擁有先前與該用戶有關係的“cookies”的客戶是不合適的。 同樣的，HTTP狀態管理不應該用於鑑別用戶的請求對於用戶可能會有令人不快的副作用， 除非用戶知道潛在的副作用並明確同意這樣使用。例如，一項允許用戶通過簡單的“點擊” 定購貨物的服務，完全基於用戶存儲的"cookied"， 如果“cookies”會泄漏給第三方的話， 可能會導致一系列的麻煩，如用戶對信用卡上的花費產生懷疑的麻煩，並且/或者發來的不是 自己想要的貨物， 一些HTTP狀態管理在用戶鑑定上的應用可能會導致相關的危害，例如，如果唯一的信息可能 是暴露在服務中，那麼服務也會因這些信息的暴露，而受到一些小小的危害 3. 用戶對於HTTP狀態管理需要考慮的事項 HTTP狀態管理豐存在很大的爭議，這是因爲它有潛在危險，不經過用戶的承認和允許，將 用戶瀏覽習慣的信息泄漏給第三方。雖然這只是一種可能，這種協議本身存在問題相對於在 HTTP客戶端的執行出現錯誤而言是一種較小的錯誤（對於基於HTTP服務的提供者而言）來 保護用戶的興趣。 正如上面所暗示的一樣，還有其它的方法來維持會話狀態而可以不用HTTP狀態管理來實 現， 因此其它的方法也可以跟蹤到用戶的瀏覽習慣。確實，很難設想HTTP協議或一個HTTP 客戶怎麼做才能夠真正的防止服務泄漏用戶的“點擊軌跡”給其它人，如果服務選擇了這麼 做的話。必須保護這些信息不被泄漏，這是這類服務的職責。HTTP客戶端的執行存在不能被 保護的特性，儘管他們能夠採取對策使得HTTP狀態管理更難以應用作此類信息泄漏的機制。 不管通過HTTP狀態管理的使用或其它方法的使用能否更容易導致泄漏，通常HTTP客戶都 可以提供更多的保護來防止不適當的跟蹤信息的泄漏，這是一個值的論證的問題。然而，然 然而，有關其它相關的機制就不屬於本備忘錄討論的範圍了。 3.1. HTTP客戶所必需的性能 用戶自己同意使用HTTP狀態管理很可能不同於對於另一方的的服務，依照是否用戶信任 這項服務來適當地使用這些信息並且限制把它泄漏給它方。用戶因此應當能夠在每一服務的 基礎上，對它的客戶能否使用HTTP狀態管理服務的要求進行控制。特別是： (1) 客戶端一定不要響應HTTP狀態管理的請求，除非確實是被客戶激活。 (2) 在客戶提供任何狀態信息給服器前，客戶端應該提供一個允許用戶回顧的有效的界 面，並且批准或者拒絕來自服務的任何特定請求以維護狀態信息。 (3) 在每一服務的基礎上， 一但響應任何特定的來自服務器的請求，在客戶提供任何狀 態信息給服務器之前，客戶端就應當立即提供一個有效的界面，這個界面允許用戶通知他們 的客戶端忽略所有以維持狀態信息的來自特定服務的請求。 (4) 客戶應當提供一個有效的界面允許用戶禁止未來對服務進行任何狀信息的傳輸。 或者放棄任何已經保存的對於服務的狀態信息，即使是用戶先前認可的維持狀態信息的服務 請求。 (5) 客戶應當提供一個有效的界面，允許用戶去中斷一個先前的請求，而不爲已經給 予的服務保持狀態管理信息 3.2. 域匹配算法的侷限性。 域匹配算法 在 RFC-2965 中第2段中企發性的允許用戶去“猜”是否兩個域是同一個服 務的一部分。關於如何域能被使用的規則很少，並且域名結構和它們如何被從頂級域轉換爲 其它域名（也就是客戶不能說出域名的哪一部分被分配給了服務。因此，沒有字符串比較算 法（包括域名匹配算法）可以從一個屬於其他部分的域名中用來區分屬於特別服務的域名。 作爲上面的說明，每一項服務最終應負責的是負保證用戶的信息不會不適當的泄露給第三方。 通過仔細地選擇域名，或第三方通過維持給主機指定域名，利用狀態管理泄露信息給第三方， 至少通過使用其他方法在信息的泄漏上是一樣的不合適的。 4. 安全考慮 整篇備忘錄都是有關安全考慮的。 5. 作者的地址 Keith Moore University of Tennessee Computer Science Department 1122 Volunteer Blvd, Suite 203 Knoxville TN, 37996-3450 EMail: [email protected] Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 81790 EMail: [email protected] 6. 參考文獻 [RFC 1123] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [RFC 2965] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2965, October 2000. [RFC 2109] Kristol, D. and L. Montulli, "HTTP State Management Mechanism", RFC 2109, February 1997. 7. 版權聲明 Copyright (C) The Internet Society (2000). 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. RFC 2964 Use of HTTP State Management 超文本傳輸協議(HTTP)狀態管理的應用 1 RFC文檔中文翻譯計劃