HTTPS(HyperText Transfer Protocol Secure, 超文本傳輸安全協(xié)議)：是一種透過計算機網(wǎng)絡進行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進行通信，但利用SSL/TLS來加密數(shù)據(jù)包。HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務器的身份認證，保護交換數(shù)據(jù)的隱私與完整性。這個協(xié)議由網(wǎng)景公司(Netscape)在1994年首次提出，隨后擴展到互聯(lián)網(wǎng)上。

歷史上，HTTPS連接經(jīng)常用于萬維網(wǎng)上的交易支付和企業(yè)信息系統(tǒng)中敏感信息的傳輸。在2000年代晚期和2010年代早期，HTTPS開始廣泛使用于保護所有類型網(wǎng)站上的網(wǎng)頁真實性，保護賬戶和保持用戶通信，身份和網(wǎng)絡瀏覽的私密性。

HTTPS的主要思想：是在不安全的網(wǎng)絡上創(chuàng)建一安全信道，并可在使用適當?shù)募用馨头掌髯C書可被驗證且可被信任時，對竊聽和中間人攻擊提供合理的防護。

HTTPS的信任繼承基于預先安裝在瀏覽器中的證書頒發(fā)機構(gòu)(如Symantec、Comodo、GoDaddy和GlobalSign等)(意即”我信任證書頒發(fā)機構(gòu)告訴我應該信任的”)。因此，一個到某網(wǎng)站的HTTPS連接可被信任，當且僅當：

(1). 用戶相信他們的瀏覽器正確實現(xiàn)了HTTPS且安裝了正確的證書頒發(fā)機構(gòu)；

(2). 用戶相信證書頒發(fā)機構(gòu)僅信任合法的網(wǎng)站；

(3). 被訪問的網(wǎng)站提供了一個有效的證書，意即，它是由一個被信任的證書頒發(fā)機構(gòu)簽發(fā)的(大部分瀏覽器會對無效的證書發(fā)出警告)；

(4). 該證書正確地驗證了被訪問的網(wǎng)站(如，訪問https://example.com 時收到了給example.com而不是其它組織的證書）；

(5). 或者互聯(lián)網(wǎng)上相關(guān)的節(jié)點是值得信任的，或者用戶相信本協(xié)議的加密層(TLS或SSL)不能被竊聽者破壞。

HTTPS不應與在RFC 2660中定義的安全超文本傳輸協(xié)議(S-HTTP)相混淆。

瀏覽器實現(xiàn)：當連接到一個提供無效證書的網(wǎng)站時，較舊的瀏覽器會使用一對話框詢問用戶是否繼續(xù)，而較新的瀏覽器會在整個窗口中顯示警告；較新的瀏覽器也會在地址欄中凸顯網(wǎng)站的安全信息(如，擴展驗證證書在Firefox里會使地址欄出現(xiàn)綠鎖標志）。Google Chrome、Internet Explorer、Firefox等瀏覽器在網(wǎng)站含有由加密和未加密內(nèi)容組成的混合內(nèi)容時，會發(fā)出警告。

HTTPS與HTTP的差異：與HTTP的URL由”http://”起始且默認使用端口80不同，HTTPS的URL由”https://”起始且默認使用端口443。HTTP是不安全的，且攻擊者通過監(jiān)聽和中間人攻擊等手段，可以獲取網(wǎng)站帳戶和敏感信息等。HTTPS被設計為可防止前述攻擊，并在正確配置時被認為是安全的。

協(xié)議層：HTTP協(xié)議和安全協(xié)議同屬于應用層(OSI模型的最高層)，具體來講，安全協(xié)議工作在HTTP之下，運輸層之上：安全協(xié)議向運行HTTP的進程提供一個類似于TCP的套接字，供進程向其中注入報文，安全協(xié)議將報文加密并注入運輸層套接字；或是從運輸層獲取加密報文，解密后交給對應的進程。嚴格地講，HTTPS并不是一個單獨的協(xié)議，而是對工作在一加密連接(TLS或SSL)上的常規(guī)HTTP協(xié)議的稱呼。

HTTPS報文中的任何東西都被加密，包括所有報頭和荷載。除了可能的選擇密文攻擊之外，一個攻擊者所能知道的只有在兩者之間有一連接這一事實。

服務器設置：要使一網(wǎng)絡服務器準備好接受HTTPS連接，管理員必須創(chuàng)建一數(shù)字證書，并交由證書頒發(fā)機構(gòu)簽名以使瀏覽器接受。證書頒發(fā)機構(gòu)會驗證數(shù)字證書持有人和其聲明的為同一人。瀏覽器通常都預裝了證書頒發(fā)機構(gòu)的證書，所以他們可以驗證該簽名。

(1). 獲得證書：由證書頒發(fā)機構(gòu)簽發(fā)的證書有免費的，也有每年收費數(shù)美元到數(shù)千美元不等的。一個組織也可能有自己的證書頒發(fā)機構(gòu)，尤其是當設置瀏覽器來訪問他們自己的網(wǎng)站時(如，運行在公司或?qū)W校局域網(wǎng)內(nèi)的網(wǎng)站)。他們可以容易地將自己的證書加入瀏覽器中。

(2). 作為訪問控制：HTTPS也可被用作客戶端認證手段來將一些信息限制給合法的用戶。要做到這樣，管理員通常會給每個用戶創(chuàng)建證書(通常包含了用戶的名字和電子郵件地址)。這個證書會被放置在瀏覽器中，并在每次連接到服務器時由服務器檢查。

(3). 當私鑰失密時：證書可在其過期前被吊銷，通常情況是該證書的私鑰已經(jīng)失密。較新的瀏覽器如Google Chrome、Firefox、Opera和運行在Windows Vista上的Internet Explorer都實現(xiàn)了在線證書狀態(tài)協(xié)議(OCSP)以排除這種情形：瀏覽器將網(wǎng)站提供的證書的序列號通過OCSP發(fā)送給證書頒發(fā)機構(gòu)，后者會告訴瀏覽器證書是否還是有效的。

局限：TLS有兩種策略：簡單策略和交互策略。交互策略更為安全，但需要用戶在他們的瀏覽器中安裝個人的證書來進行認證。不管使用了哪種策略，協(xié)議所能提供的保護總強烈地依賴于瀏覽器的實現(xiàn)和服務器軟件所支持的加密算法。

HTTPS并不能防止站點被網(wǎng)絡蜘蛛抓取。在某些情形中，被加密資源的URL可僅通過截獲請求和響應的大小推得，這就可使攻擊者同時知道明文(公開的靜態(tài)內(nèi)容)和密文(被加密過的明文)，從而使選擇密文攻擊成為可能。

因為SSL在HTTP之下工作，對上層協(xié)議一無所知，所以SSL服務器只能為一個IP地址/端口組合提供一個證書。這就意味著在大部分情況下，使用HTTPS的同時支持基于名字的虛擬主機是不很現(xiàn)實的。一種叫域名指示(SNI)的方案通過在加密連接創(chuàng)建前向服務器發(fā)送主機名解決了這一問題。Firefox 2、Opera 8和運行在Windows Vista的Internet Explorer 7都加入了對SNI的支持。

因為HTTPS連接所用的公鑰以明文傳輸，因此中國大陸的防火長城可以對特定網(wǎng)站按照匹配的黑名單證書，通過偽裝成對方向連接兩端的計算機發(fā)送RST包干擾兩臺計算機間正常的TCP通訊，以打斷與特定IP地址之間的443端口握手，或者直接使握手的數(shù)據(jù)包丟棄，導致握手失敗，從而導致TLS連接失敗。這也是一種互聯(lián)網(wǎng)信息審查和屏蔽的技術(shù)手段。

HTTPS是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL。凡是使用了HTTPS的網(wǎng)站，都可以通過點擊瀏覽器地址欄的鎖頭標志來查看網(wǎng)站認證之后的真實信息，也可以通過CA機構(gòu)頒發(fā)的安全簽章來查詢。

HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務器之間傳遞信息。HTTP協(xié)議以明文方式發(fā)送內(nèi)容，不提供任何方式的數(shù)據(jù)加密，如果攻擊者截取了Web瀏覽器和網(wǎng)站服務器之間的傳輸報文，就可以直接讀懂其中的信息，因此HTTP協(xié)議不適合傳輸一些敏感信息，比如信用卡號、密碼等。為了數(shù)據(jù)傳輸?shù)陌踩?#xff0c;HTTPS在HTTP的基礎上加入了SSL協(xié)議，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。

不使用SSL/TLS的HTTP通信，就是不加密的通信，所有信息明文傳播，帶來三大風險：(1). 竊聽風險：第三方可以獲知通信內(nèi)容；(2). 篡改風險：第三方可以修改通信內(nèi)容；(3). 冒充風險：第三方可以冒充他人身份參與通信。

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

HTTP/2協(xié)議只有在HTTPS環(huán)境下才會生效。

傳輸層安全性協(xié)議(Transport Layer Security，TLS)，及其前身安全套接層(Secure Sockets Layer，SSL)是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信提供安全及數(shù)據(jù)完整性保障。網(wǎng)景公司(Netscape)在1994年推出首版網(wǎng)頁瀏覽器，網(wǎng)景導航者時，推出HTTPS協(xié)議，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化，1999年公布第一版TLS標準文件。隨后又公布RFC 5246(2008年8月)與RFC 6176(2011年3月)。在瀏覽器、郵箱、即時通信、VoIP、網(wǎng)絡傳真等應用程序中，廣泛支持這個協(xié)議。主要的網(wǎng)站，如Google、Facebook等也以這個協(xié)議來創(chuàng)建安全連線，發(fā)送數(shù)據(jù)。目前已成為互聯(lián)網(wǎng)上保密通信的工業(yè)標準。

SSL包含記錄層(Record Layer)和傳輸層，記錄層協(xié)議確定傳輸層數(shù)據(jù)的封裝格式。傳輸層安全協(xié)議使用X.509認證，之后利用非對稱加密演算來對通信方做身份認證，之后交換對稱密鑰作為會談密鑰(Session key)。這個會談密鑰是用來將通信兩方交換的數(shù)據(jù)做加密，保證兩個應用間通信的保密性和可靠性，使客戶與服務器應用之間的通信不被攻擊者竊聽。

TLS協(xié)議采用主從式架構(gòu)模型，用于在兩個應用程序間透過網(wǎng)絡創(chuàng)建起安全的連線，防止在交換數(shù)據(jù)時受到竊聽及篡改。

TLS協(xié)議的優(yōu)勢是與高層的應用層協(xié)議(如HTTP、FTP、Telnet等)無耦合。應用層協(xié)議能透明地運行在TLS協(xié)議之上，由TLS協(xié)議進行創(chuàng)建加密通道需要的協(xié)商和認證。應用層協(xié)議傳送的數(shù)據(jù)在通過TLS協(xié)議時都會被加密，從而保證通信的私密性。

TLS協(xié)議是可選的，必須配置客戶端和服務器才能使用。主要有兩種方式實現(xiàn)這一目標：一個是使用統(tǒng)一的TLS協(xié)議通信端口(例如：用于HTTPS的端口443)；另一個是客戶端請求服務器連接到TLS時使用特定的協(xié)議機制(例如：郵件、新聞協(xié)議和STARTTLS)。一旦客戶端和服務器都同意使用TLS協(xié)議，他們通過使用一個握手過程協(xié)商出一個有狀態(tài)的連接以傳輸數(shù)據(jù)。通過握手，客戶端和服務器協(xié)商各種參數(shù)用于創(chuàng)建安全連接：

(1). 當客戶端連接到支持TLS協(xié)議的服務器要求創(chuàng)建安全連接并列出了受支持的密碼組合(加密密碼算法和加密哈希函數(shù))，握手開始。

(2). 服務器從該列表中決定加密和散列函數(shù)，并通知客戶端。

(3). 服務器發(fā)回其數(shù)字證書，此證書通常包含服務器的名稱、受信任的證書頒發(fā)機構(gòu)(CA)和服務器的公鑰。

(4). 客戶端確認其頒發(fā)的證書的有效性。

(5). 為了生成會話密鑰用于安全連接，客戶端使用服務器的公鑰加密隨機生成的密鑰，并將其發(fā)送到服務器，只有服務器才能使用自己的私鑰解密。

(6). 利用隨機數(shù)，雙方生成用于加密和解密的對稱密鑰。

這就是TLS協(xié)議的握手，握手完畢后的連接是安全的，直到連接(被)關(guān)閉。如果上述任何一個步驟失敗，TLS握手過程就會失敗，并且斷開所有的連接。

SSL(Secure Sockets Layer)是網(wǎng)景公司(Netscape)設計的主要用于Web的安全傳輸協(xié)議，這種協(xié)議在Web上獲得了廣泛的應用。SSL 1.0版本從未公開過，因為存在嚴重的安全漏洞。SSL 2.0在1995年2月發(fā)布，已于2011年棄用。SSL 3.0在1996年發(fā)布，已于2015年棄用。較新版本的SSL/TLS基于SSL 3.0。

IETF將SSL標準化，即RFC 2246，并將其稱為TLS。從技術(shù)上講，TLS 1.0與SSL 3.0的差異非常微小。TLS 1.0在1996年發(fā)布，計劃于2020年棄用。TLS 1.1在RFC 4346中定義，于2006年4月發(fā)表，計劃于2020年棄用。TLS 1.2在RFC 5246中定義，于2008年8月發(fā)表。TLS 1.3在RFC 8846中定義，于2018年8月發(fā)布。

密鑰交換和密鑰協(xié)商：在客戶端和服務器開始交換TLS所保護的加密信息之前，他們必須安全地交換或協(xié)定加密密鑰和加密數(shù)據(jù)時要使用的密碼。用于密鑰交換的方法包括：使用RSA算法生成公鑰和私鑰(在TLS握手協(xié)議中被稱為TLS_RSA)，Diffie-Hellman(在TLS握手協(xié)議中被稱為TLS_DH)，臨時Diffie-Hellman(在TLS握手協(xié)議中被稱為TLS_DHE)，橢圓曲線迪菲-赫爾曼(在TLS握手協(xié)議中被稱為TLS_ECDH)，臨時橢圓曲線Diffie-Hellman(在TLS握手協(xié)議中被稱為TLS_ECDHE)，匿名Diffie-Hellman(在TLS握手協(xié)議中被稱為TLS_DH_anon)和預共享密鑰(在TLS握手協(xié)議中被稱為TLS_PSK)。TLS_DH_anon和TLS_ECDH_anon的密鑰協(xié)商協(xié)議不能驗證服務器或用戶，因為易受中間人攻擊因此很少使用。只有TLS_DHE和TLS_ECDHE提供前向保密能力。在交換過程中使用的公鑰/私鑰加密密鑰的長度和在交換協(xié)議過程中使用的公鑰證書也各不相同，因而提供的強健性的安全。2013年7月，Google宣布向其用戶提供的TLS加密將不再使用1024位公鑰并切換到2048位，以提高安全性。

數(shù)據(jù)完整性：消息認證碼(MAC)用于對數(shù)據(jù)完整性進行認證。HMAC用于CBC模式的塊密碼和流密碼，AEAD用于身份驗證加密，例如GCM模式和CCM模式。

在應用程序設計中，TLS通常在傳輸層協(xié)議之上實現(xiàn)，加密協(xié)議的所有協(xié)議相關(guān)數(shù)據(jù)，如HTTP，FTP，SMTP，NNTP和XMPP。

大多數(shù)SSL和TLS編程庫都是自由及開放源代碼軟件，如：

(1). Botan：是一個用C++11實現(xiàn)的加解密庫，License為BSD-2-Clause，code下載地址為https://libraries.io/github/randombit/botan；

(2). OpenSSL：TSL/SSL加解密庫，License為Apache License，code下載地址為https://github.com/openssl/openssl；

簡單郵件傳輸協(xié)議(SMTP)也可以通過TLS保護，這些應用程序使用公開密鑰認證來驗證端點的身份。

SSL協(xié)議的工作方式：客戶端要收發(fā)幾個握手信號：

(1). 發(fā)送一個”ClientHello”消息，內(nèi)容包括：支持的協(xié)議版本，比如TLS1.0版，一個客戶端生成的隨機數(shù)(稍后用于生成”會話密鑰”)，支持的加密算法(如RSA公鑰加密)和支持的壓縮算法。

(2). 然后收到一個”ServerHello”消息，內(nèi)容包括：確認使用的加密通信協(xié)議版本，比如TLS 1.0版本(如果瀏覽器與服務器支持的版本不一致，服務器關(guān)閉加密通信)，一個服務器生成的隨機數(shù)(稍后用于生成”對話密鑰”)，確認使用的加密方法(如RSA公鑰加密)，服務器證書。

(3). 當雙方知道了連接參數(shù)，客戶端與服務器交換證書(依靠被選擇的公鑰系統(tǒng))。這些證書通常基于X.509，不過已有草案支持以OpenPGP為基礎的證書。

(4). 服務器請求客戶端公鑰。客戶端有證書即雙向身份認證，沒證書時隨機生成公鑰。

(5). 客戶端與服務器通過公鑰保密協(xié)商共同的主私鑰(雙方隨機協(xié)商)，這通過精心謹慎設計的偽隨機數(shù)功能實現(xiàn)。結(jié)果可能使用Diffie-Hellman交換，或簡化的公鑰加密，雙方各自用私鑰解密。所有其他關(guān)鍵數(shù)據(jù)的加密均使用這個”主密鑰”。數(shù)據(jù)傳輸中記錄層(Record layer)用于封裝更高層的HTTP等協(xié)議。記錄層數(shù)據(jù)可以被隨意壓縮、加密，與消息驗證碼壓縮在一起。每個記錄層包都有一個Content-Type段用以記錄更上層用的協(xié)議。

TLS利用密鑰算法在互聯(lián)網(wǎng)上提供端點身份認證與通訊保密，其基礎是公鑰基礎設施。不過在實現(xiàn)的典型例子中，只有網(wǎng)絡服務者被可靠身份驗證，而其客戶端則不一定。這是因為公鑰基礎設施普遍商業(yè)運營，電子簽名證書通常需要付費購買。協(xié)議的設計在某種程度上能夠使主從架構(gòu)應用程序通訊本身預防竊聽、干擾和消息偽造。

TLS包含三個基本階段：

(1). 對等協(xié)商支持的密鑰算法

(2). 基于非對稱密鑰的信息傳輸加密和身份認證、基于PKI證書的身份認證

(3). 基于對稱密鑰的數(shù)據(jù)傳輸保密

在第一階段，客戶端與服務器協(xié)商所用密碼算法。當前廣泛實現(xiàn)的算法選擇如下：

(1). 公鑰私鑰非對稱密鑰保密系統(tǒng)：RSA、Diffie-Hellman、DSA;

(2). 對稱密鑰保密系統(tǒng)：RC2、RC4、IDEA、DES、Triple DES、AES以及Camellia；

(3). 單向散列函數(shù)：MD5、SHA1以及SHA256。

TLS/SSL有多樣的安全保護措施：所有的記錄層數(shù)據(jù)均被編號，用于消息驗證碼校驗。

以上整理的內(nèi)容主要來自：維基百科_SSL??維基百科_HTTPS?阮一峰的網(wǎng)絡日志

GitHub：?https://github.com/fengbingchun/OpenSSL_Test?

總結(jié)

以上是生活随笔為你收集整理的HTTPS协议简介的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。