您現在的位置: 365建站網 > 365學習 > HTTP到HTTPS升級 什么是 HTTPS和證書

HTTP到HTTPS升級 什么是 HTTPS和證書

文章來源:365jz.com     點擊數:183    更新時間:2018-07-30 23:42   參與評論

HTTPS是互聯網 web 大勢所趨。各大網站都已陸續部署了 HTTPS,這篇文章我們來探討什么是HTTPS以及為什么要部署HTTPS。

讀完本文,你能明白

  • 什么是HTTPS,TLS(SSL),TLS和HTTPS是什么關系

  • 什么是證書和數字簽名,它們是如何傳遞信任的

  • HTTPS有什么樣的功能,它是如何實現這樣的功能的

簡介

HTTPS,也稱作HTTP over TLS。TLS的前身是SSL,TLS 1.0通常被標示為SSL 3.1,TLS 1.1為SSL 3.2,TLS 1.2為SSL 3.3。本文著重描述TLS協議的1.2版本

下圖描述了在TCP/IP協議棧中TLS(各子協議)和HTTP的關系

tcp ip model

HTTP

當你在瀏覽器輸入一個網址 (例如 http://365jz.com)的時候,瀏覽器發起一個 HTTP 請求,帶著請求信息 (參見 HTTP Headers),連接到服務器,把請求信息遞給服務器,服務器收到信息之后,解析相關的信息,然后進行處理,再返回瀏覽器請求的數據。

簡單來說是這么一個流程:

  1. 小明 跟 瀏覽器爸爸 說我想要去中關村某個店家拿一些東西 (發起請求)

  2. 瀏覽器爸爸 就把 小明 要的東西記在一張清單上 (生成HTTP協議)

  3. 然后 瀏覽器爸爸 派出一個 線程小弟,噌噌噌跑到中關村的店里,把清單遞給 店家,說小明要這些東西 (進行傳輸)

  4. 店家 讓 線程小弟 稍等,然后去屋子里面拿小明的這些東西 (服務器收到請求)

  5. 店家 把東西拿出來后,并且也打印了一份清單,讓 線程小弟 帶著清單和東西一起拿回去 (服務器處理請求完畢)

  6. 然后 線程小弟 回到 瀏覽器爸爸 那邊,把服務器給的清單和物品交給瀏覽器爸爸,瀏覽器爸爸根據清單核對物品 (瀏覽器處理響應)

  7. 然后把物品打包交給了 小明 (瀏覽器渲染并呈現界面)

這其中有個問題,瀏覽器爸爸和服務器都沒有驗證清單信息的有效性和對方的身份。萬一有人在中間把線程小哥攔下來,暴揍一頓,然后把物品清單給換了怎么辦?或者有人把線程小哥在半路上暴揍一頓,拿了清單換了另外一個小哥怎么辦?

這是個很嚴肅的問題:假如服務器要把一些東西鎖在柜子里,需要小明給密碼才可以打開柜子。然后小明把密碼寫在清單上讓瀏覽器爸爸交給服務器。這時候,如果這張清單被人攔截下來,不就得到了小明的密碼?

簡單來說,傳輸的信息中包含用戶密碼,被攔截了怎么辦?

HTTPS

正因為HTTP請求有這些安全性的問題,所以HTTPS誕生了,致力于解決了這些安全性問題,我們進行一下對比:

安全性HTTPHTTPS
竊聽風險傳遞的信息是明文的,可能會被有心人攔截下來竊聽信息加密傳播
篡改風險傳遞的信息可能會被篡改信息校驗,一旦被篡改立刻就會被發現
偽裝風險沒有驗證通信另外一頭對方的身份,可能遭遇偽裝身份校驗

那么HTTPS是如何做到更安全的呢?

簡單來說,HTTPS 即是在 HTTP 下加入了一層 SSL 加密,所以被稱為HTTPS。具體的加密過程則是 公匙加密法:

  • 客戶端向服務器索要公匙,然后使用公匙加密信息

  • 服務器收到加密后的信息,用自己的私匙解密

公匙密碼和算法都是公開的,而私匙則是保密的。加密使用的公匙和解碼使用的密匙都是不相同的,因此這是一個 非對稱加密 算法。

數字證書

提及 HTTPS ,就會聽到大家說需要證書才能部署,那么什么是證書呢?

因為互聯網不安全,公匙也是信息的一部分,也是會有被篡改的風險的。所以引入了互聯網權威機構 - CA 機構,又稱為證書授權 (Certificate Authority) 機構,瀏覽器會內置這些"受信任的根證書頒發機構" (即 CA)。

服務端向權威的身份鑒定 CA 機構申請數字證書,CA 機構驗證了網站之后,會把網站錄入到內部列表,采用 Hash 把服務端的一些相關信息生成摘要,然后 CA 機構用自己的私匙,把服務端的公匙和相關信息一起加密,然后給申請證書的服務端頒發數字證書,用于其他客戶端 (比如瀏覽器) 認證這個網站的公匙。

客戶端通過服務端下發的證書,找到對應的 CA,然后向 CA 驗證這個證書是否有效,CA 驗證通過之后,下發服務端的公匙。

因為 CA 是權威并且可信的,所以客戶端 (瀏覽器) 信任 CA,而 CA 又信任經過認證的服務端 ,所以客戶端 (瀏覽器) 也信任這個服務端,這就是信任鏈 (Chain Of Trust)。

而 CA 頒發的數字證書,一般包含這些信息:

CA info

簡單來說:為了保證公匙是安全的,所以通過數字證書驗證公匙。

加密通信

一條完整的HTTPS請求應該是這樣的:

  1. 客戶端 (瀏覽器) 發起 HTTP 請求,請求連接服務端,發送支持的加密通信協議 (和版本),并且生成一個隨機數,后續用于生成"對話密鑰"。

  2. 服務端確認加密通信協議 (和版本),同時也生成一個隨機數,后續用于生成"對話密匙",并且將 CA 頒發的數字證書,一起發送給客戶端。

  3. 客戶端收到數字證書后,檢測內置的"受信任的根證書頒發機構",查看解開數字證書的公匙是否在。

  4. 如果解開數字證書的公匙存在,則使用它解開數字證書,得到正確的服務器公匙,同時再次生成一個隨機數,用于服務器公匙加密,并發送給服務器。

  5. 此時本地和服務器同時將三個隨機數,根據約定的加密方法進行加密,各自生成本次會話的所使用的同一把 "會話密匙" 。

  6. 到這里,認證階段已經完畢,數據傳輸從 非對稱加密 換成了 對稱加密 (因為考慮到性能),接下來所有的數據傳輸都是使用HTTP協議進行傳輸,只不過使用了 "會話密匙" 來加密內容。

見下圖:

rsa handshake

證書(Digital certificate)

那么什么是證書呢?

certificate

證書中包含什么信息

  • 證書信息:過期時間和序列號

  • 所有者信息:姓名等

  • 所有者公鑰

為什么服務端要發送證書給客戶端

互聯網有太多的服務需要使用證書來驗證身份,以至于客戶端(操作系統或瀏覽器等)無法內置所有證書,需要通過服務端將證書發送給客戶端。

客戶端為什么要驗證接收到的證書

中間人攻擊

客戶端<------------攻擊者<------------服務端
        偽造證書            攔截請求

客戶端如何驗證接收到的證書

為了回答這個問題,需要引入數字簽名(Digital Signature)。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+              +--------+
| is a mathematical   |----哈希--->| 消息摘要  |---私鑰加密--->| 數字簽名 |
|technique used       |            +---------+              +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

將一段文本通過哈希(hash)和私鑰加密處理后生成數字簽名。

假設消息傳遞在Bob,Susan和Pat三人之間發生。Susan將消息連同數字簽名一起發送給Bob,Bob接收到消息后,可以這樣驗證接收到的消息就是Susan發送的

+---------------------+| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+| is a mathematical   |----哈希--->|  消息摘要 ||technique used       |            +---------+|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 對
|or digital document. |                 比
+---------------------+                 |
                                        |
                                        |
          +--------+               +---------+
          | 數字簽名 |---公鑰解密--->|  消息摘要 |
          +--------+               +---------+

當然,這個前提是Bob知道Susan的公鑰。更重要的是,和消息本身一樣,公鑰不能在不安全的網絡中直接發送給Bob。

此時就引入了證書頒發機構(Certificate Authority,簡稱CA),CA數量并不多,Bob客戶端內置了所有受信任CA的證書。CA對Susan的公鑰(和其他信息)數字簽名后生成證書。

Susan將證書發送給Bob后,Bob通過CA證書的公鑰驗證證書簽名。

Bob信任CA,CA信任Susan 使得 Bob信任Susan,信任鏈(Chain Of Trust)就是這樣形成的。

事實上,Bob客戶端內置的是CA的根證書(Root Certificate),HTTPS協議中服務器會發送證書鏈(Certificate Chain)給客戶端。

TLS協議

TLS協議包括TLS Record Protocol和TLS Handshake Protocol??傆[中的流程圖僅涉及到TLS Handshake Protocol。

TLS Record Protocol

在TLS協議中,有四種子協議運行于Record protocol之上

  • Handshake protocol

  • Alert protocol

  • Change cipher spec protocol

  • Application data protocol

Record protocol起到了這樣的作用

  • 在發送端:將數據(Record)分段,壓縮,增加MAC(Message Authentication Code)和加密

  • 在接收端:將數據(Record)解密,驗證MAC,解壓并重組

值得一提的是,Record protocol提供了數據完整性和隱私性保證,但Record類型(type)和長度(length)是公開傳輸的

Record Protocol有三個連接狀態(Connection State),連接狀態定義了壓縮,加密和MAC算法。所有的Record都是被當前狀態(Current State)確定的算法處理的。

TLS Handshake Protocol和Change Ciper Spec Protocol會導致Record Protocol狀態切換。

empty state -------------------> pending state ------------------> current state
             Handshake Protocol                Change Cipher Spec

初始當前狀態(Current State)沒有指定加密,壓縮和MAC算法,因而在完成TLS Handshaking Protocols一系列動作之前,客戶端和服務端的數據都是明文傳輸的;當TLS完成握手過程后,客戶端和服務端確定了加密,壓縮和MAC算法及其參數,數據(Record)會通過指定算法處理。

其中,Record首先被加密,然后添加MAC(message authentication code)以保證數據完整性。

TLS Handshaking Protocols

Handshakeing protocols包括Alert Protocol,Change Ciper Spec Protocol和Handshake protocol。本文不會詳細介紹Alert Protocol和Change Ciper Spec Protocol。

使用RSA算法的握手過程是這樣的(已在總覽中提到)

rsa handshake

Source: Keyless SSL: The Nitty Gritty Technical Details

客戶端和服務端在握手hello消息中明文交換了client_randomserver_random ,使用RSA公鑰加密傳輸premaster secret ,最后通過算法,客戶端和服務端分別計算master secret。其中,不直接使用premaster secret 的原因是:保證secret的隨機性不受任意一方的影響。

除了使用RSA算法在公共信道交換密鑰,還可以通過Diffie–Hellman算法。Diffie–Hellman算法的原理是這樣的

Diffie-Hellman_Key_Exchange

By Original Schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons

使用Diffie–Hellman算法交換premaster secret 的流程

diffie hellman handshake

Source: Keyless SSL: The Nitty Gritty Technical Details

小結

TLS Handshaking Protocols協商了TLS Record Protocol使用的算法和所需參數,并驗證了服務端身份;TLS Record Protocol在協商后保證應用層數據的完整性和隱私性。

TLS Handshaking Protocol的核心是在公開信道上傳遞premaster secret。

Q&A

為什么傳輸內容不直接使用非對稱加密?

性能

HTTPS能保證正常連接?

no

There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.

攻擊者甚至可以直接丟棄雙方的數據包

服務端如何驗證客戶端身份?

通過Client Certificate

This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating the premaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.

Alert protocol有什么作用?

Closure Alerts:防止Truncation Attack

In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.

Error Alerts:錯誤處理

master secret是如何計算的

  master_secret = PRF(pre_master_secret, "master secret",
                      ClientHello.random + ServerHello.random)
                      [0..47];

加密,壓縮和MAC算法參數是如何計算的

Handshaking Protocols使得客戶端和服務端交換了三個參數:client_random,server_random 和master_secret,通過以下算法生成算法所需要的參數

To generate the key material, compute

  key_block = PRF(SecurityParameters.master_secret,                  "key expansion",
                  SecurityParameters.`server_random ` +
                  SecurityParameters.`client_random`);until enough output has been generated.  Then, the key_block ispartitioned as follows:

  client_write_MAC_key[SecurityParameters.mac_key_length]
  server_write_MAC_key[SecurityParameters.mac_key_length]
  client_write_key[SecurityParameters.enc_key_length]
  server_write_key[SecurityParameters.enc_key_length]
  client_write_IV[SecurityParameters.fixed_iv_length]
  server_write_IV[SecurityParameters.fixed_iv_length]

The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key

使用Diffie-Hellman算法的TLS握手細節

dh-detail

Source: https://cipherstuff.wordpress.com/




如對本文有疑問,請提交到交流論壇,廣大熱心網友會為你解答??! 點擊進入論壇


發表評論 (183人查看,0條評論)
請自覺遵守互聯網相關的政策法規,嚴禁發布色情、暴力、反動的言論。
用戶名: 驗證碼: 點擊我更換圖片
最新評論
------分隔線----------------------------
自拍偷拍福力视频,偷拍国际精品,麻豆一区福利电影,国产网红视频午夜福利,se视频大全,久久国产AV影院 色就色 综合偷拍区| 国产在线一区二区三区在线视频| 三级国产三级在线| 宝贝堵着不许流出来二哥| 好看的电影网站| old woman| 亚洲女人天堂网av在线| 亚洲超清无码制服丝袜| 小棒堵住前面不让流出来| 欧美自拍另类欧美综合图片区| 妈妈让你弄的够| 2018国产天天弄| 69久久夜色精品国产| 男女后进式激烈嘿咻动态图| 全班女同学吸我的精子| 普通话熟女高潮对白出浆视频| 情侣作爱视频实拍| 亚洲五月六月丁香缴情| 欧美卡通另类偷拍| chinese熟女熟妇2乱| 丝袜亚洲精品中文字幕一区| 白袜自慰gay体育生网站| 高清videosgratis欧美| 男人把女人强吻扒衣服| 日本免费一本天堂在线| 久久精品国产亚洲av麻豆| tude8| cl2019地址更新| 国产色诱视频在线播放网站| 伊人久久大香线蕉综合bd高清| 岛国av无码免费无禁网站下载| http://www.caichantong.com