1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        張三李四手摸手教你 HTTPS 的原理(通俗易懂!)

        共 3433字,需瀏覽 7分鐘

         ·

        2021-09-14 01:00

         大廠技術(shù)  高級前端  Node進(jìn)階

        點擊上方 程序員成長指北,關(guān)注公眾號

        回復(fù)1,加入高級Node交流群

        作者:DBCdouble 

        原文:https://juejin.cn/post/6872276748570984455

        一、前言

        一開始去真正接觸HTTPS是由于在上線小程序的時候,小程序官方限定接口必須需是https協(xié)議,后面就去弄了騰訊云的云服務(wù)器,還有免費的https證書等,跟著官方的教程去配置https等等,讓我知道:

        • https默認(rèn)端口號是443
        • https協(xié)議比http協(xié)議更加安全
        • 需要將CA機(jī)構(gòu)頒布的https證書安裝在服務(wù)器上
        • nginx服務(wù)的一些配置(轉(zhuǎn)發(fā)、入口文件html、gzip壓縮)

        最終,小程序也完美上線,但是好像我對HTTPS的底層原理和流程還是不清楚。下面先通過李四給張三發(fā)消息的例子先來說明HTTPS相對HTTP做了哪些工作

        二、使用HTTP協(xié)議時

        先看下面一個例子(需要掌握非對稱加密的概念),李四想要給張三發(fā)消息:

        李四:
        “hi哥們,我想給你發(fā)個密文,把你的公鑰給我發(fā)過來用用?!?br style="outline: 0px;">
        張三:
        “沒問題的,這是我的公鑰:d#8yHE8eU#hb*!neb,用這個公鑰加密你的信息后給我發(fā)過來吧”

        李四:
        “這是我想對你說的話:*&#@uehuu(**#eehu&$##bfeu&&”

        分析:上面是一個典型的非對稱加密的案例,張三把自己的公鑰給了李四,李四拿到張三的公鑰把自己的消息加密發(fā)送給張三,張三收到密文用自己的私鑰解密

        提問:有朋友會問,李四怎么確認(rèn)對方是張三的?因為很有可能,李四發(fā)給張三的消息被黑客小劉攔截了(如本地host文件被修改,dns攔截),也就是說李四拿到的公鑰是黑客小劉的公鑰,那么李四發(fā)過去的密文,黑客小劉就能用自己的私鑰去解密

        結(jié)論:HTTP協(xié)議之所以不安全是因為請求發(fā)起方無法確認(rèn)響應(yīng)方的真實身份

        三、使用HTTPS協(xié)議時

        接著上面一個例子:

        黑客小劉:四兒,最近有什么新計劃沒?。
        李四:沒。。。有。。。。
        黑客小劉:沒有?我是你三哥,你說吧。
        李四:那你先把你的證書給我看看?
        黑客小劉:....神馬證...書..?
        --- 李四已下線 ---

        分析:原來,李四自從上次被坑了之后私下里去找了一個叫“王五”的大哥,想尋求幫助,王五說這個事不難,王五對李四說:“如果你相信我,那么我就來作證人證明張三是張三”。

        李四說:“那沒問題,那你怎么證明張三是他本人?”。

        “我可以給張三頒發(fā)一個證書!只要他給你看到這個電子證書,證書上有我的的電子簽名,你就相信他是張三”,王五說。

        李四思考了片刻又問道:“那我怎么證明這個證書不是偽造的呢?”

        王五說:“因為我可以給你一個神器,這個神器能夠讓你分辨這個證書確實是我頒發(fā)的!”。

        “哇!這么吊!那快給我!”,李四渴望的眼神中又閃爍著對王五的崇拜!

        其實,這個神奇呢,很簡單,你想到了嗎?嗯,于是,王五就把這個神器交給了李四,這個神器是:“王五的公鑰”!。

        哈哈哈哈哈哈。。。

        結(jié)論:

        • 以上這種方式就是https的授信機(jī)制,加入第三方公證人來證明身份
        • 王五就相當(dāng)于頒發(fā)https證書的CA機(jī)構(gòu)(類似于授信的公證處)
        • 李四持有的王五的公鑰就是個根證書,用于驗證張三的證書是否是否合法,是否是王五頒發(fā)
        • 電子證書上的電子簽名,是使用王五使用自己的私鑰將張三的公鑰和個人信息加密得到的,所以李四使用張三的公鑰去解密張三的電子證書上的電子簽名得到張三的公鑰,和張三傳過來的公鑰作對比,確認(rèn)張三的身份

        詳細(xì)看圖解,如下:

        四、HTTPS的實現(xiàn)原理

        大家可能都聽說過 HTTPS 協(xié)議之所以是安全的是因為 HTTPS 協(xié)議會對傳輸?shù)臄?shù)據(jù)進(jìn)行加密,而加密過程是使用了非對稱加密實現(xiàn)。但其實,HTTPS 在內(nèi)容傳輸?shù)募用苌鲜褂玫氖菍ΨQ加密,非對稱加密只作用在證書驗證階段。

        HTTPS的整體過程分為證書驗證和數(shù)據(jù)傳輸階段,具體的交互過程如下:

        ① 證書驗證階段
        1. 瀏覽器發(fā)起 HTTPS 請求
        2. 服務(wù)端返回 HTTPS 證書
        3. 客戶端驗證證書是否合法,如果不合法則提示告警
        ② 數(shù)據(jù)傳輸階段
        1. 當(dāng)證書驗證合法后,在本地生成隨機(jī)數(shù)
        2. 通過公鑰加密隨機(jī)數(shù),并把加密后的隨機(jī)數(shù)傳輸?shù)椒?wù)端
        3. 服務(wù)端通過私鑰對隨機(jī)數(shù)進(jìn)行解密
        4. 服務(wù)端通過客戶端傳入的隨機(jī)數(shù)構(gòu)造對稱加密算法,對返回結(jié)果內(nèi)容進(jìn)行加密后傳輸

        為什么數(shù)據(jù)傳輸是用對稱加密?

        首先,非對稱加密的加解密效率是非常低的,而 http 的應(yīng)用場景中通常端與端之間存在大量的交互,非對稱加密的效率是無法接受的;

        另外,在 HTTPS 的場景中只有服務(wù)端保存了私鑰,一對公私鑰只能實現(xiàn)單向的加解密,所以 HTTPS 中內(nèi)容傳輸加密采取的是對稱加密,而不是非對稱加密。

        五、從網(wǎng)絡(luò)模型來認(rèn)識HTTPS

        網(wǎng)絡(luò)模型一般是指OSI七層參考模型和TCP/IP五層模型的協(xié)議,這個模型是干嘛的呢?就是將計算機(jī)和計算機(jī)之間信息交換“概念化”成不同的層次,每層分別有它自己的“實現(xiàn)”,每層有它自己的任務(wù),同時“向上”提供“抽象”的“接口”供上層使用。一般分成7層或者5層。為了簡便期間我這里按照5層架構(gòu)說一下,這五層分別是:

        • 應(yīng)用層(application layer)
        • 傳輸層(transport layer)
        • 網(wǎng)絡(luò)層(network layer)
        • 數(shù)據(jù)鏈路層(data link layer)
        • 物理層(physical layer)

        舉個例子,當(dāng)張三用QQ向李四發(fā)送一條信息時,首先QQ屬于應(yīng)用層,應(yīng)用層需要將信息發(fā)送給傳輸層,傳輸層經(jīng)過處理之后傳給網(wǎng)絡(luò)層,以此類推傳給物理層,這樣一層層向下“包裝”,每層有對應(yīng)的協(xié)議,這樣最后通過物理層傳出去,傳到李四的物理層,然后李四那邊通過一層層向上按照協(xié)議“解包”,最后到應(yīng)用層,傳到李四的qq里。

        所以每層都有相對應(yīng)的協(xié)議比如我們的物理層和數(shù)據(jù)鏈路層通過無線網(wǎng)傳輸使用的802.2傳輸協(xié)議,有線網(wǎng)的Ethernet(以太網(wǎng))傳輸協(xié)議,還有網(wǎng)絡(luò)層的IPv4, IPv6協(xié)議,傳輸層的TCP, UDP協(xié)議,而我們熟悉的HTTP協(xié)議其實屬于應(yīng)用層,所以HTTP是建立在TCP/IPv4或v6/以太網(wǎng)基礎(chǔ)上進(jìn)一步細(xì)化用于傳輸“超文本”信息的協(xié)議,比如FTP也屬于應(yīng)用層,也是在下面各層協(xié)議基礎(chǔ)上進(jìn)行細(xì)化,專門用于“文件傳輸”的協(xié)議。

        大家可以看到,協(xié)議越往上越具體,越往下約抽象,其實計算機(jī)技術(shù)的發(fā)展就是一層層的向上抽象,這樣上層的可以直接使用下層的“成果”(API)!

        我們再來說一下TLS/SSL,SSL(secure sockets layer)是TLS(transport layer security)的前身,為什么將他們合起來的,大家可以理解成都屬于同一東西的不同階段吧,比如該協(xié)議之前叫SSL后來改名成TLS了。

        為什么要有這種協(xié)議呢?因為HTTP是使用明文傳輸,隨著網(wǎng)絡(luò)的發(fā)展,安全性越來越重要,所以大家就要想辦法讓傳輸更加安全,同時使用密碼學(xué)的成果,利用“非對稱加密算法”的思想以及OSI模型,來對HTTP的信息進(jìn)行加密。

        因為上面我們說了,根據(jù)OSI模型,如果向外傳輸信息就是要從上到下挨個層進(jìn)行,TLS/SSL也是位于應(yīng)用層,所以為了加密HTTP的內(nèi)容,那么TLS/SSL必須位于HTTP下面,可以看成這樣:

        HTTP
        TLS/SSL
        TCP
        Ip
        ..

        信息從HTTP經(jīng)過TLS/SSL非對稱加密后傳出去,而在接收方,接收到信息是需要一層層向上進(jìn)行,經(jīng)過每層的“解包/解密”,最終通過HTTP轉(zhuǎn)換成超文本信息。

        結(jié)論

        • 網(wǎng)絡(luò)協(xié)議上來說,HTTPS = HTTP + TLS/SSL
        • 功能上來說,HTTPS = HTTP + 非對稱加密的證書身份驗證 + 對稱加密的傳輸信息加密
        Node 社群


        我組建了一個氛圍特別好的 Node.js 社群,里面有很多 Node.js小伙伴,如果你對Node.js學(xué)習(xí)感興趣的話(后續(xù)有計劃也可以),我們可以一起進(jìn)行Node.js相關(guān)的交流、學(xué)習(xí)、共建。下方加 考拉 好友回復(fù)「Node」即可。


           “分享、點贊、在看” 支持一波 

        瀏覽 60
        點贊
        評論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報
        評論
        圖片
        表情
        推薦
        點贊
        評論
        收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            章子怡大尺度做爰未删减 | 国产99热 | 精品国产999 | 在公车上拨开内裤进入图片 | 在线观看中文字幕 | 无码精品一区二区三区四区爱奇艺 | 黑白操逼片 | 叶子楣裸体69xx | 天天射综合 | 中国免费一级无码成人片 |