資訊專欄INFORMATION COLUMN
摘要：握手協(xié)議它建立在記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認證協(xié)商加密算法交換加密密鑰等。包括握手協(xié)議，改變密碼協(xié)議，警告協(xié)議。配備身份證書，防止身份被冒充。鑒定依賴認證體系和加密算法。
面對愚昧，神們自己也緘口不言 ?！痘亍?/strong>
2019年8月11日，IETF 終于發(fā)布了 RFC 8446，標志著 TLS 1.3 協(xié)議大功告成 。這是該協(xié)議的第一次重大改革，帶來了重大的安全性和性能改進。
本來想寫一篇簡短介紹...結(jié)果越寫越長，干脆拆分開慢慢寫，慢慢發(fā)。
HTTP 是一個網(wǎng)絡(luò)協(xié)議，是專門用來幫你傳輸 Web 內(nèi)容的。
比如瀏覽器地址欄打開任意網(wǎng)址http://http://ulyc.github.io/
加了粗體的部分就是指 HTTP 協(xié)議。大部分網(wǎng)站都是通過 HTTP 協(xié)議來傳輸 Web 頁面、以及 Web 頁面上包含的各種東西（圖片、CSS 樣式、JS 腳本）。
如果你有一些網(wǎng)絡(luò)基礎(chǔ)知識，就知道http協(xié)議存在于四層網(wǎng)絡(luò)結(jié)構(gòu)中的應(yīng)用層。
HHTP協(xié)議為明文傳輸，所有信息均為可見的，很不安全，信息極易被篡改和劫持，也因此衍生出了相對更為安全的HTTPS。
SSL（Secure Sockets Layer），即安全套接層，是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信提供安全及數(shù)據(jù)完整性保障。
網(wǎng)景公司（Netscape）在1994年推出HTTPS協(xié)議，以SSL進行加密，這是SSL的起源。 到了1999年，SSL 因為應(yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實標準。IETF 就在那年把 SSL 標準化。標準化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”。
很多相關(guān)的文章都把這兩者并列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。
SSL又分為兩層：
HTTPS（Hyper Text Transfer Protocol Secure），即超文本傳輸安全協(xié)議，也稱為http over tls等，是一種網(wǎng)絡(luò)安全傳輸協(xié)議。
相當于工作在應(yīng)用層（osi七層模型）的http，只不過是在會話層和表示層利用ssl/tls來加密了數(shù)據(jù)包，說白了就是“HTTP 協(xié)議”和“SSL/TLS 協(xié)議”的組合，你可以把 HTTPS 大致理解為——“HTTP over SSL”或“HTTP over TLS” 。
有位大神做過一個很形象的比喻：
如果原來的 HTTP 是塑料水管，容易被戳破；那么如今新設(shè)計的 HTTPS 就像是在原有的塑料水管之外，再包一層金屬水管。
一來，原有的塑料水管照樣運行；
二來，用金屬加固了之后，不容易被戳破。
訪問時以https://開頭，默認443端口，同時需要證書?，F(xiàn)在大部分網(wǎng)站都已經(jīng)支持https協(xié)議，如果經(jīng)常訪問的支持https的網(wǎng)站突然只能以http訪問，就要小心了。
不使用SSL/TLS的HTTP通信，就是不加密的通信。
所有信息明文傳播，帶來了三大風(fēng)險：
SSL/TLS協(xié)議是為了解決這三大風(fēng)險而設(shè)計的，希望達到：
互聯(lián)網(wǎng)是開放環(huán)境，通信雙方都是未知身份，這為協(xié)議的設(shè)計帶來了很大的難度。而且，協(xié)議還必須能夠經(jīng)受所有匪夷所思的攻擊，這使得SSL/TLS協(xié)議變得異常復(fù)雜。
SSL/TLS協(xié)議對于以上風(fēng)險的防護分別作了以下實現(xiàn)：
客戶端（瀏覽器、爬蟲程序等）向服務(wù)器發(fā)送符合http協(xié)議的請求（http發(fā)送的是明文請求，https是經(jīng)過安全層加密的密文請求），得到服務(wù)器返回的響應(yīng)（同樣http是明文響應(yīng)，https是密文響應(yīng)），并在本地解析渲染。
此層是是SSL/TLS所在的位于傳輸層與應(yīng)用層之間的一個抽象層，在TCP/IP協(xié)議族中勉強可以劃分到_傳輸層_，在osi七層網(wǎng)絡(luò)模型中沒有嚴格的對應(yīng)，一般認為屬于 _會話層_和_表達層_。
http與https主要區(qū)別就在于是否存在此安全層，本層實現(xiàn)了_加密(encryption)（非對稱加密），認證(verification)，鑒定(identification)。_
基本過程是：
上面過程的前兩步，稱為"握手階段"，即SSL四次握手。
http與https協(xié)議都是基于傳輸層的TCP協(xié)議。
連接時會進行“三次握手”，斷開連接時客戶端與服務(wù)器進行”四次揮手“。
本文作者：UCloud后臺研發(fā)工程師 Hughes.Chen
文章來源：UCloud云計算 知乎官方技術(shù)專欄
https://www.zhihu.com/column/ucloud
更多干貨，移步查閱哦！
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://m.hztianpu.com/yun/126005.html
摘要：王蒙沒那么淺地談?wù)勁c二四加密算法和密鑰管理介紹密鑰交換機制之前先普及一些加密算法基本知識以及為什么要有密鑰管理機制。證書證書，顧名思義，就是頒發(fā)的證書。公鑰基礎(chǔ)設(shè)施公鑰基礎(chǔ)設(shè)施，簡稱是目前網(wǎng)絡(luò)安全建設(shè)的基礎(chǔ)與核心。**玫瑰與荊棘共生，香菇與毒菇同長，真實與假冒比翼騰飛?！趺?*沒那么淺地談?wù)凥TTP與HTTPS【二】四、加密算法和密鑰管理介紹密鑰交換機制之前先普及一些加密算法基本知識以及...
摘要：公開密鑰加密的出現(xiàn)大大減輕了交換對稱密鑰的困難，公鑰可以公開透過不安全可被竊聽的渠道發(fā)送，用以加密明文。當與配合使用，稱之為，與配合則稱為，以此類推。這步?jīng)]有簽名，服務(wù)端收到數(shù)據(jù)后不會發(fā)現(xiàn)被篡改。對于認證機構(gòu)，一旦私鑰外泄，將可能導(dǎo)致整未濟，亨。小狐汔濟，濡其尾，無攸利?！兑住妨?、密鑰管理當不再擔(dān)心身份會被冒充、篡改之后，我們再來詳細談?wù)劸W(wǎng)絡(luò)通信中對于加密算法的密鑰管理。在密鑰被簽發(fā)后，...
摘要：上篇鏈接年，用更現(xiàn)代的方法使用上年，用更現(xiàn)代的方法使用中公鑰的發(fā)布與交換討論公鑰安全交換的中文文章比較少，而這一環(huán)是整個加密體系的重中之重。年月，有攻擊者惡意向公鑰服務(wù)器提交了對兩個著名網(wǎng)友的簽名背書。此事件中的受害者的證書就被簽名了次。上篇鏈接:2021年，用更現(xiàn)代的方法使用PGP（上）2021年，用更現(xiàn)代的方法使用PGP（中）PGP 公鑰的 發(fā)布 與 交換討論公鑰安全交換的中文文章比較少...
摘要：它允許惡意用戶將代碼注入到網(wǎng)頁上，其他用戶在觀看網(wǎng)頁時就會受到影響。這類攻擊通常包含了以及用戶端腳本語言。更偏向于方法論，更偏向于一種形式，只要是偽造用戶發(fā)起的請求，都可成為攻擊。 這兩個關(guān)鍵詞也是老生常談了，但是還總是容易讓人忘記與搞混~。XSS與CSRF這兩個關(guān)鍵詞時常被拉出來一起比較（尤其是面試），我在這里也在寫一篇掃盲文，也幫自己整理一下知識脈絡(luò)。 這篇文章會用盡量人話的語言解...
摘要：它允許惡意用戶將代碼注入到網(wǎng)頁上，其他用戶在觀看網(wǎng)頁時就會受到影響。這類攻擊通常包含了以及用戶端腳本語言。更偏向于方法論，更偏向于一種形式，只要是偽造用戶發(fā)起的請求，都可成為攻擊。 這兩個關(guān)鍵詞也是老生常談了，但是還總是容易讓人忘記與搞混~。XSS與CSRF這兩個關(guān)鍵詞時常被拉出來一起比較（尤其是面試），我在這里也在寫一篇掃盲文，也幫自己整理一下知識脈絡(luò)。 這篇文章會用盡量人話的語言解...
閱讀 3670·2023-04-25 20:09
閱讀 3831·2022-06-28 19:00
閱讀 3193·2022-06-28 19:00
閱讀 3227·2022-06-28 19:00
閱讀 3341·2022-06-28 19:00
閱讀 2999·2022-06-28 19:00
閱讀 3236·2022-06-28 19:00
閱讀 2777·2022-06-28 19:00
