HTTPS和HTTP的主要區(qū)別

HTTPS的主干層次介紹

客戶端在使用HTTPS方式與Web服務(wù)器通信時的步驟

SSL與TLS 歷史

HTTPS的缺點

如何優(yōu)化HTTPS的速度

HTTP與HTTPS介紹

超文本傳輸協(xié)議HTTP協(xié)議" />

国产成人精品无码青草_亚洲国产美女精品久久久久∴_欧美人与鲁交大毛片免费_国产果冻豆传媒麻婆精东

18143453325 在線咨詢 在線咨詢
18143453325 在線咨詢
所在位置: 首頁 > 營銷資訊 > 建站知識 > HTTP與HTTPS的區(qū)別,詳細介紹

HTTP與HTTPS的區(qū)別,詳細介紹

時間:2023-02-13 15:06:01 | 來源:建站知識

時間:2023-02-13 15:06:01 來源:建站知識



HTTP與HTTPS的區(qū)別

HTTPS和HTTP的主要區(qū)別

HTTPS的主干層次介紹

客戶端在使用HTTPS方式與Web服務(wù)器通信時的步驟

SSL與TLS 歷史

HTTPS的缺點

如何優(yōu)化HTTPS的速度


HTTP與HTTPS介紹

超文本傳輸協(xié)議HTTP協(xié)議被用于在Web瀏覽器和網(wǎng)站服務(wù)器之間傳遞信息,HTTP協(xié)議以明文方式發(fā)送內(nèi)容,不提供任何方式的數(shù)據(jù)加密,如果攻擊者截取了Web瀏覽器和網(wǎng)站服務(wù)器之間的傳輸報文,就可以直接讀懂其中的信息,因此,HTTP協(xié)議不適合傳輸一些敏感信息,比如:信用卡號、密碼等支付信息。

為了解決HTTP協(xié)議的這一缺陷,需要使用另一種協(xié)議:安全套接字層超文本傳輸協(xié)議HTTPS,為了數(shù)據(jù)傳輸?shù)陌踩琀TTPS在HTTP的基礎(chǔ)上加入了SSL/TLS協(xié)議,SSL/TLS依靠證書來驗證服務(wù)器的身份,并為瀏覽器和服務(wù)器之間的通信加密。

HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議,要比http協(xié)議安全

HTTPS協(xié)議的主要作用可以分為兩種:一種是建立一個信息安全通道,來保證數(shù)據(jù)傳輸?shù)陌踩?;另一種就是確認網(wǎng)站的真實性。

HTTPS和HTTP的主要區(qū)別

1.https協(xié)議需要到申請證書,一般免費證書較少,因而需要一定費用,JoySSL是個不錯的選擇

2.http是超文本傳輸協(xié)議,信息是明文傳輸,https則是具有安全性的ssl/tls加密傳輸協(xié)議。

3.http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。

4.http的連接很簡單,是無狀態(tài)的;HTTPS協(xié)議是由SSL/TLS+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議,比http協(xié)議安全。




HTTPS的主干層次介紹

這部分內(nèi)容作為前提點綴,如果你是初次了解HTTPS,看不懂這里不要緊,只要把文章后面看完,再回過頭來看這里的內(nèi)容,就能恍然大悟了。第一層:HTTPS本質(zhì)上是為了實現(xiàn)加密通信,理論上,加密通信就是雙方都持有一個對稱加密的秘鑰,然后就可以安全通信了

但是,無論這個最初的秘鑰是由客戶端傳給服務(wù)端,還是服務(wù)端傳給客戶端,都是明文傳輸,中間人都可以知道。那就讓這個過程變成密文就好了唄,而且還得是中間人解不開的密文。

第二層使用非對稱加密 加密客戶端與服務(wù)端協(xié)商生成對稱秘鑰之前各種鹽值、種子。

但是,在使用非對稱加密秘鑰之前,比如由服務(wù)端生成非對稱秘鑰,它需要將生成的公鑰給到客戶端,這個時候公鑰就會在網(wǎng)絡(luò)中明文傳輸,任何人都可以更改,會有中間人攻擊的問題。




客戶端在使用HTTPS方式與Web服務(wù)器通信時的步驟

(1)客戶使用https的URL訪問Web服務(wù)器,要求與Web服務(wù)器建立SSL連接。

(2)Web服務(wù)器收到客戶端請求后,會將網(wǎng)站的證書信息(證書中包含公鑰)傳送一份給客戶端。

(3)客戶端的瀏覽器與Web服務(wù)器開始協(xié)商SSL/TLS連接的安全等級,也就是信息加密的等級。

(4)客戶端的瀏覽器根據(jù)雙方同意的安全等級,建立會話密鑰,然后利用網(wǎng)站的公鑰將會話密鑰加密,并傳送給網(wǎng)站。

(5)Web服務(wù)器利用自己的私鑰解密出會話密鑰。

(6)Web服務(wù)器利用會話密鑰加密與客戶端之間的通信。

盡管HTTPS并非絕對安全,掌握根證書的機構(gòu)、掌握加密算法的組織同樣可以進行中間人形式的攻擊,但HTTPS仍是現(xiàn)行架構(gòu)下最安全的解決方案,他大幅增加了中間人攻擊的成本



SSL與TLS

SSL:(Secure Socket Layer,安全套接字層),位于可靠的面向連接的網(wǎng)絡(luò)層協(xié)議和應(yīng)用層協(xié)議之間的一種協(xié)議層。SSL通過互相認證、使用數(shù)字簽名確保完整性、使用加密確保私密性,以實現(xiàn)客戶端和服務(wù)器之間的安全通訊。該協(xié)議由兩層組成:SSL記錄協(xié)議和SSL握手協(xié)議。




TLS:(Transport Layer Security,傳輸層安全協(xié)議),用于兩個應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成:TLS記錄協(xié)議和TLS握手協(xié)議。TLS是HTTP與TCP協(xié)議之間的一層,通常TLS發(fā)生在TCP三次握手之后,此時進行TLS四次握手,然后再進行HTTP通信




SSL/TLS歷史

1994年,NetScape公司設(shè)計了SSL協(xié)議(Secure Sockets Layer)的1.0版,但是未發(fā)布。1995年,NetScape公司發(fā)布SSL 2.0版,很快發(fā)現(xiàn)有嚴重漏洞。1996年,SSL 3.0版問世,得到大規(guī)模應(yīng)用。1999年,互聯(lián)網(wǎng)標準化組織ISOC接替NetScape公司,發(fā)布了SSL的升級版TLS 1.0版。2006年和2008年,TLS進行了兩次升級,分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版,在2018年也發(fā)布了TLS1.3版本。TLS 1.0通常被標示為SSL 3.1,TLS 1.1為SSL 3.2,TLS 1.2為SSL 3.3。目前應(yīng)用的最廣泛的 TLS 是 1.2,而之前的協(xié)議(TLS1.1/1.0、SSLv3/v2)都已經(jīng)被認為是不安全的了




HTTPS的缺點

雖然說HTTPS有很大的優(yōu)勢,但其相對來說,還是存在不足之處的:

(1)HTTPS協(xié)議握手階段比較費時,會使頁面的加載時間延長近50%,增加10%到20%的耗電;

(2)HTTPS連接緩存不如HTTP高效,會增加數(shù)據(jù)開銷和功耗,甚至已有的安全措施也會因此而受到影響;

(3)SSL證書需要錢,功能越強大的證書費用越高,個人網(wǎng)站、小網(wǎng)站沒有必要一般不會用。

(4)SSL證書通常需要綁定IP,不能在同一IP上綁定多個域名,IPv4資源不可能支撐這個消耗。

(5)HTTPS協(xié)議的加密范圍也比較有限,在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的,SSL證書的信用鏈體系并不安全,特別是在某些國家可以控制CA根證書的情況下,中間人攻擊一樣可行。

實踐中建議保留http。所以我們在切換的時候可以做http和https的兼容,具體實現(xiàn)方式是,去掉頁面鏈接中的http頭部,這樣可以自動匹配http頭和https頭。例如:將http://www.joyssl.com改為//http://www.joyssl.com。然后當用戶從http的入口進入訪問頁面時,頁面就是http。




如何優(yōu)化HTTPS的速度

HTTPS連接大致可以劃分為兩個部分:第一個是建立連接時的非對稱加密握手,第二個是握手后的對稱加密報文傳輸。

由于目前流行的 AES、ChaCha20 性能都很好,還有硬件優(yōu)化,報文傳輸?shù)男阅軗p耗可以說是非常地小,小到幾乎可以忽略不計了。所以,通常所說的“HTTPS 連接慢”指的就是剛開始建立連接的那段時間。

在 TCP 建連之后,正式數(shù)據(jù)傳輸之前,HTTPS 比 HTTP 增加了一個 TLS 握手的步驟,這個步驟最長可以花費兩個消息往返,也就是 2-RTT(TLS1.3只需1-RTT)。而且在握手消息的網(wǎng)絡(luò)耗時之外,還會有其他的一些“隱形”消耗,比如:

產(chǎn)生用于密鑰交換的臨時公私鑰對(ECDHE);

驗證證書時訪問 CA 獲取 CRL 或者 OCSP;

非對稱加密解密處理“Pre-Master”。

1、HSTS重定向技術(shù)

HSTS(HTTP Strict Transport Security,HTTP 嚴格傳輸安全)技術(shù),啟用HSTS后,將保證瀏覽器始終連接到網(wǎng)站的 HTTPS 加密版本。這相當于告訴瀏覽器:我這個網(wǎng)站必須嚴格使用 HTTPS 協(xié)議,在半年之內(nèi)(182.5 天)都不允許用 HTTP,你以后就自己做轉(zhuǎn)換吧,不要再來麻煩我了。

1. 用戶在瀏覽器里輸入 HTTP 協(xié)議進行訪問時,瀏覽器會自動將 HTTP 轉(zhuǎn)換為 HTTPS 進行訪問,確保用戶訪問安全;

2. 省去301跳轉(zhuǎn)的出現(xiàn),縮短訪問時間;

3. 能阻止基于 SSL Strip 的中間人攻擊,萬一證書有錯誤,則顯示錯誤,用戶不能回避警告,從而能夠更加有效安全的保障用戶的訪問。




2、TLS握手優(yōu)化

在傳輸應(yīng)用數(shù)據(jù)之前,客戶端必須與服務(wù)端協(xié)商密鑰、加密算法等信息,服務(wù)端還要把自己的證書發(fā)給客戶端表明其身份,這些環(huán)節(jié)構(gòu)成 TLS 握手過程。

使用 ECDHE 橢圓曲線密碼套件,可以節(jié)約帶寬和計算量,還能實現(xiàn)“False Start”,采用 False Start (搶先開始)技術(shù),瀏覽器在與服務(wù)器完成 TLS 握手前,就開始發(fā)送請求數(shù)據(jù),服務(wù)器在收到這些數(shù)據(jù)后,完成 TLS 握手的同時,開始發(fā)送響應(yīng)數(shù)據(jù)。

開啟 False Start 功能后,數(shù)據(jù)傳輸時間將進一步縮短。




3、Session Identifier(會話標識符)復用

如果用戶的一個業(yè)務(wù)請求包含了多條的加密流,客戶端與服務(wù)器將會反復握手,必定會導致更多的時間損耗。或者某些特殊情況導致了對話突然中斷,雙方就需要重新握手,增加了用戶訪問時間。

(1)服務(wù)器為每一次的會話都生成并記錄一個 ID 號,然后發(fā)送給客戶端;

(2)如果客戶端發(fā)起重新連接,則只要向服務(wù)器發(fā)送該 ID 號;

(3)服務(wù)器收到客戶端發(fā)來的 ID 號,然后查找自己的會話記錄,匹配 ID 之后,雙方就可以重新使用之前的對稱加密秘鑰進行數(shù)據(jù)加密傳輸,而不必重新生成,減少交互時間(只用一個消息往返就可以建立安全連接)。

但它也有缺點,服務(wù)器必須保存每一個客戶端的會話數(shù)據(jù),對于擁有百萬、千萬級別用戶的網(wǎng)站來說存儲量就成了大問題,加重了服務(wù)器的負擔。于是又出現(xiàn)了第二種“Session Ticket”的方案。

它有點類似 HTTP 的 Cookie,存儲的責任由服務(wù)器轉(zhuǎn)移到了客戶端,服務(wù)器加密會話信息,用“New Session Ticket”消息發(fā)給客戶端,讓客戶端保存。重連的時候,客戶端使用擴展“session_ticket”發(fā)送“Ticket”而不是“Session ID”,服務(wù)器解密后驗證有效期,就可以恢復會話,開始加密通信。不過“Session Ticket”方案需要使用一個固定的密鑰文件(ticket_key)來加密 Ticket,為了防止密鑰被破解,保證“前向安全”,密鑰文件需要定期輪換,比如設(shè)置為一小時或者一天。




4、開啟OSCP Stapling(OSCP裝訂),提高TLS握手效率

客戶端的證書驗證其實是個很復雜的操作,除了要公鑰解密驗證多個證書簽名外,因為證書還有可能會被撤銷失效,客戶端有時還會再去訪問 CA,下載 CRL (Certificate revocation list,證書吊銷列表,用于確認證書是否有效,體積較大,現(xiàn)基本不用)或者 OCSP 數(shù)據(jù),這又會產(chǎn)生 DNS 查詢、建立連接、收發(fā)數(shù)據(jù)等一系列網(wǎng)絡(luò)通信,增加好幾個 RTT。

采用OCSP Stapling ,提升 HTTPS 性能。服務(wù)端主動獲取 OCSP 查詢結(jié)果并隨著證書一起發(fā)送給客戶端,從而客戶端可直接通過 Web Server 驗證證書,提高 TLS 握手效率。

服務(wù)器模擬瀏覽器向 CA 發(fā)起請求,并將帶有 CA 機構(gòu)簽名的 OCSP 響應(yīng)保存到本地,然后在與客戶端握手階段,將 OCSP 響應(yīng)下發(fā)給瀏覽器,省去瀏覽器的在線驗證過程。由于瀏覽器不需要直接向 CA 站點查詢證書狀態(tài),這個功能對訪問速度的提升非常明顯。




5、完全前向加密PFS,保護用戶數(shù)據(jù),預(yù)防私鑰泄漏

非對稱加密算法 RSA,包含了公鑰、私鑰,其中私鑰是保密不對外公開的,由于此算法既可以用于加密也可以用于簽名,所以用途甚廣,但是還是會遇到一些問題:

(1) 假如我是一名黑客,雖然現(xiàn)在我不知道私鑰,但是我可以先把客戶端與服務(wù)器之前的傳輸數(shù)據(jù)(已加密)全部保存下來

(2)如果某一天,服務(wù)器維護人員不小心把私鑰泄露了,或者服務(wù)器被我攻破獲取到了私鑰

(3)那我就可以利用這個私鑰,破解掉之前已被我保存的數(shù)據(jù),從中獲取有用的信息,即所謂的“今日截獲,明日破解”。

所以為了防止上述現(xiàn)象發(fā)生,我們必須保護好自己的私鑰。

如果私鑰確實被泄漏了,那我們改如何補救呢?那就需要PFS(perfect forward secrecy)完全前向保密功能,此功能用于客戶端與服務(wù)器交換對稱密鑰,起到前向保密的作用,也即就算私鑰被泄漏,黑客也無法破解先前已加密的數(shù)據(jù)。維基解釋是:長期使用的主密鑰泄漏不會導致過去的會話密鑰泄漏




實現(xiàn)此功能需要服務(wù)器支持以下算法和簽名組合:

(1)ECDHE 密鑰交換、RSA 簽名;

(2)ECDHE 密鑰交換、ECDSA 簽名;

ECDHE 算法在每次握手時都會生成一對臨時的公鑰和私鑰,每次通信的密鑰對都是不同的,也就是“一次一密”,即使黑客花大力氣破解了這一次的會話密鑰,也只是這次通信被攻擊,之前的歷史消息不會受到影響,仍然是安全的。

使用ECDHE算法的TLS交換過程具有如下優(yōu)點:運算速度快,安全性高,還支持“False Start”,能夠把握手的消息往返由 2-RTT 減少到 1-RTT

所以現(xiàn)在主流的服務(wù)器和瀏覽器在握手階段都已經(jīng)不再使用 RSA,改用 ECDHE,而 TLS1.3 在協(xié)議里明確廢除 RSA 和 DH 則在標準層面保證了“前向安全”。

綜合上述講解,我們在選擇更好的服務(wù)器瀏覽器的同時更要注重平臺的選擇,像上述提到的JoySSL,擁有這個各種國內(nèi)外知名品牌,還有著除了單域名證書外的通配符證書免費使用,下面是JoySSL官網(wǎng)以及免費證書申請鏈接,大家可以參考免費下載使用。



關(guān)鍵詞:詳細,區(qū)別

74
73
25
news

版權(quán)所有? 億企邦 1997-2025 保留一切法律許可權(quán)利。

為了最佳展示效果,本站不支持IE9及以下版本的瀏覽器,建議您使用谷歌Chrome瀏覽器。 點擊下載Chrome瀏覽器
關(guān)閉