超文本傳輸安全協定
超文本傳輸安全協定（英語：HyperText Transfer Protocol Secure，縮寫：HTTPS；常稱為HTTP over TLS、HTTP over SSL或HTTP Secure）是一種透過計算機網路進行安全通訊的傳輸協定。HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密封包。HTTPS開發的主要目的，是提供對網站伺服器的身分認證，保護交換資料的隱私與完整性。這個協定由網景公司（Netscape）在1994年首次提出，隨後擴展到網際網路上。
歷史上，HTTPS連接經常用於全球資訊網上的交易支付和企業訊息系統中敏感訊息的傳輸。在2000年代末至2010年代初，HTTPS開始廣泛使用，以確保各類型的網頁真實，保護帳戶和保持使用者通訊，身分和網路瀏覽的私密性。
另外，還有一種安全超文本傳輸協定（S-HTTP）的HTTP安全傳輸實作，但是HTTPS的廣泛應用而成為事實上的HTTP安全傳輸實作，S-HTTP並沒有得到廣泛支援。
主要作用
編輯
HTTPS的主要作用是在不安全的網路上建立一個安全信道，並可在使用適當的加密套件和伺服器憑證可被驗證且可被信任時，對竊聽和中間人攻擊提供合理的防護。
HTTPS的信任基於預先安裝在作業系統中的憑證頒發機構（CA）。因此，與一個網站之間的HTTPS連線僅在這些情況下可被信任：
- 瀏覽器正確地實作了HTTPS且作業系統中安裝了正確且受信任的憑證頒發機構；
- 憑證頒發機構僅信任合法的網站；
- 被訪問的網站提供了一個有效的憑證，也就是說它是一個由作業系統信任的憑證頒發機構簽發的（大部分瀏覽器會對無效的憑證發出警告）；
- 該憑證正確地驗證了被訪問的網站（例如，訪問
https://example.com時收到了簽發給example.com而不是其它域名的憑證）； - 此協定的加密層（SSL/TLS）能夠有效地提供認證和高強度的加密。
不應將HTTPS和在RFC 2660中定義的安全超文本傳輸協定（S-HTTP）相混淆。
統計
編輯截至2018年6月，Alexa排名前100萬的網站中有34.6%使用HTTPS作為預設值[1]，網際網路141387個最受歡迎網站的43.1%具有安全實施的HTTPS[2]，以及45%的頁面載入（透過Firefox紀錄）使用HTTPS[3]。2017年3月，中國註冊域名總數的0.11％使用HTTPS。[4]
根據Mozilla統計，自2017年1月以來，超過一半的網站流量被加密[5][6]。
瀏覽器實作
編輯當連接到一個提供無效憑證的網站時，較舊的瀏覽器會使用一個對話方塊詢問使用者是否繼續，而較新的瀏覽器會在整個窗口中顯示警告。
Google Chrome、Internet Explorer和Firefox等瀏覽器在網站含有由加密和未加密內容組成的混合內容時，會發出警告。
自2018年起，Firefox及Chromium（以及Google Chrome、Microsoft Edge）調整了其顯示網站域名及其安全程度的方式，包括不再突出顯示HTTPS協定下的網頁及將非HTTPS協定下的網頁標註為不安全。電子前線基金會曾經建議「在理想的世界中，任何網路請求都能預設為HTTPS的。」該基金會也曾製作了Firefox擴充組件來推廣這一建議。[7][8]在Chrome瀏覽器上也有類似的擴充功能。[9]
.png)
.png)
.png)
技術細節
編輯
與HTTP的差異
編輯HTTP的URL是由「http://」起始與預設使用埠80，而HTTPS的URL則是由「https://」起始與預設使用埠443。
HTTP不是安全的，而且攻擊者可以透過監聽和中間人攻擊等手段，取得網站帳戶和敏感訊息等。HTTPS的設計可以防止前述攻擊，在正確組態時是安全的。
協定層
編輯HTTP協定和安全協定同屬於應用層（OSI模型的最高層），具體來講，安全協定工作在HTTP之下，傳輸層之上：安全協定向執行HTTP的行程提供一個類似於TCP的通訊端，供行程向其中注入報文，安全協定將報文加密並注入運輸層通訊端；或是從運輸層取得加密報文，解密後交給對應的行程。嚴格地講，HTTPS並不是一個單獨的協定，而是對工作在一加密連接（TLS或SSL）上的常規HTTP協定的稱呼。
HTTPS報文中的任何東西都被加密，包括所有報頭和荷載。除了可能的選擇密文攻擊（參見局限小節）之外，一個攻擊者所能知道的只有在兩者之間有一連接這一事實。
伺服器設定
編輯要使一網路伺服器準備好接受HTTPS連接，管理員必須建立一數位憑證，並交由憑證頒發機構簽章以使瀏覽器接受。憑證頒發機構會驗證數位憑證持有人和其聲明的為同一人。瀏覽器通常都預裝了憑證頒發機構的憑證，所以他們可以驗證該簽章。
獲得憑證
編輯由憑證頒發機構簽發的憑證有免費的[10][11]，也有每年收費數美元到數千美元不等的。
一個組織也可能有自己的憑證頒發機構，尤其是當設定瀏覽器來訪問他們自己的網站時（如，執行在公司或學校區域網路內的網站）。他們可以容易地將自己的憑證加入瀏覽器中。
作為訪問控制
編輯HTTPS也可被用作客戶端認證手段來將一些訊息限制給合法的使用者。要做到這樣，管理員通常會給每個使用者建立憑證（通常包含了使用者的名字和電子郵件位址）。這個憑證會被放置在瀏覽器中，並在每次連接到伺服器時由伺服器檢查。
當私鑰失密時
編輯憑證可在其過期前被吊銷，通常情況是該憑證的私鑰已經失密。較新的瀏覽器如Google Chrome、Firefox[12]、Opera[13]和執行在Windows Vista上的Internet Explorer[14]都實作了線上憑證狀態協定（OCSP）以排除這種情形：瀏覽器將網站提供的憑證的序列號透過OCSP傳送給憑證頒發機構，後者會告訴瀏覽器憑證是否還是有效的。[15]
局限
編輯TLS有兩種策略：簡單策略和互動策略。互動策略更為安全，但需要使用者在他們的瀏覽器中安裝個人的憑證來進行認證。
不管使用了哪種策略，協定所能提供的保護總強烈地依賴於瀏覽器的實作和伺服器軟體所支援的加密演算法。
HTTPS並不能防止站點被網路蜘蛛抓取。在某些情形中，被加密資源的URL可僅透過截獲請求和回應的大小推得，[16]這就可使攻擊者同時知道明文（公開的靜態內容）和密文（被加密過的明文），從而使選擇密文攻擊成為可能。
因為TLS在HTTP之下工作，對上層協定一無所知，所以TLS伺服器只能為一個IP位址/埠組合提供一個憑證。[17]這就意味著在大部分情況下，使用HTTPS的同時支援基於名字的虛擬主機是不很現實的。一種叫伺服器名稱指示（SNI）的方案透過在加密連接建立前向伺服器傳送主機名解決了這一問題。Firefox 2、Opera 8和執行在Windows Vista的Internet Explorer 7都加入了對SNI的支援。[18][19][20]
在TLS版本1.2中，伺服器端傳送的憑證以明文傳輸，因此中國大陸的防火長城可以對特定網站按照匹配的黑名單憑證，檢測到特定憑證即執行TCP重設攻擊，從而導致TLS連接無法建立。[21]這也是一種網際網路訊息審查和封鎖的技術手段。TLS版本1.3中伺服器端憑證被加密[22]，然而伺服器名稱指示仍未被加密，並成為防火長城檢測的新手段。
歷史
編輯網景在1994年建立了HTTPS，並應用在網景領航員瀏覽器中。[24] 最初，HTTPS是與SSL一起使用的；在SSL逐漸演變到TLS時，HTTPS也由在2000年五月公布的RFC 2818正式確定下來。[25]
參見
編輯參考資料
編輯- ^ HTTPS usage statistics on top websites. statoperator.com. [2016-06-28]. （原始內容存檔於2019-02-09）.
- ^ SSL Pulse. Trustworthy Internet Movement. 2015-10-03 [2015-10-19]. （原始內容存檔於2017-05-15）.
- ^ Aas, Josh. Progress Towards 100% HTTPS, June 2016. Lets Encrypt. 22 June 2016 [23 July 2016]. （原始內容存檔於2018-01-12）.
- ^ 中国网络统计 duzli.cn. www.duzli.cn. [2017-03-01]. （原始內容存檔於2017-03-02） （中文）.
- ^ We're Halfway to Encrypting the Entire Web. Electronic Frontier Foundation. 21 February 2017 [3 May 2017]. （原始內容存檔於2021-03-31） （英語）.
- ^ Finley, Klint. Half the Web Is Now Encrypted. That Makes Everyone Safer. WIRED. [1 May 2017]. （原始內容存檔於2021-03-03）.
- ^ Peter Eckersley: Encrypt the Web with the HTTPS Everywhere Firefox Extension （頁面存檔備份，存於網際網路檔案館） EFF blog, 17 June 2010
- ^ HTTPS Everywhere. [2011-01-30]. （原始內容存檔於2011-06-05）.
- ^ KB SSL Enforce. [2014-11-22]. （原始內容存檔於2014-12-25）.
- ^ Free SSL Certificates from a Free Certificate Authority. sslshopper.com. [2009-10-24]. （原始內容存檔於2021-01-22）.
- ^ Justin Fielding. Secure Outlook Web Access with (free) SSL: Part 1. TechRepublic. 2007-07-16 [2009-10-24].[失效連結]
- ^ Mozilla Firefox Privacy Policy. Mozilla基金會. 27 April 2009 [13 May 2009]. （原始內容存檔於2009年5月26日）.
- ^ Opera 8 launched on FTP. Softpedia. 19 April 2005 [13 May 2009]. （原始內容存檔於2009-07-12）.
- ^ Lawrence, Eric. HTTPS Security Improvements in Internet Explorer 7. MSDN. 31 January 2006 [13 May 2009]. （原始內容存檔於2017-07-07）.
- ^ Myers, M; Ankney, R; Malpani, A; Galperin, S; Adams, C. Online Certificate Status Protocol - OCSP. Internet Engineering Task Force. June 1999 [13 May 2009]. （原始內容存檔於2021-03-08）.
- ^ Pusep, Stanislaw. The Pirate Bay un-SSL. 31 July 2008 [6 March 2009]. （原始內容存檔於2009-03-08）.
- ^ Apache FAQ: Why can't I use SSL with name-based/non-IP-based virtual hosts?. [2011-01-30]. （原始內容存檔於2021-05-05）.
- ^ Lawrence, Eric. Upcoming HTTPS Improvements in Internet Explorer 7 Beta 2. Microsoft. 22 October 2005 [12 May 2009]. （原始內容存檔於2013-04-17）.
- ^ Server Name Indication (SNI). [2011-01-30]. （原始內容存檔於2017-06-30）.
- ^ Pierre, Julien. Browser support for TLS server name indication. Bugzilla. Mozilla Foundation. [2010-12-15]. （原始內容 (2001-12-19)存檔於2018-10-08）.
- ^ 翻墙专题：安全加密登入的方法. RFA. 2011-03-18 [2011-03-21]. （原始內容存檔於2020-10-20）.
- ^ rfc8446. IETF. 2018-08 [2021-06-15]. （原始內容存檔於2021-05-14）.
- ^ Pierre, Julien. Mac OS X v10.5, 10.6: About the Parental Controls Internet content filter. Support. Apple, Inc. [2010-12-15]. （原始內容 (2010-03-30)存檔於2014-08-04）.
- ^ Walls, Colin. Embedded software. 2005: 344 [2011-01-30]. （原始內容存檔於2021-04-14）.
- ^ Rescorla, E. HTTP Over TLS. Internet Engineering Task Force. May 2000 [6 May 2009]. （原始內容存檔於2021-05-02）.