在互聯(lián)網(wǎng)上, 明文傳輸是比較危險的事情!!!

HTTPS 就是在 HTTP 的基礎(chǔ)上進行了加密, 進一步的來保證用戶的信息安全。

二、HTTPS加密方法

加密就是把 明文 (要傳輸?shù)男畔?進行一系列變換，生成 密文 。

解密就是把 密文 再進行一系列變換，還原成 明文 。

在這個加密和解密的過程中，往往需要 一個或者多個中間的數(shù)據(jù) ，輔助進行這個過程，這樣的數(shù)據(jù)稱為 密鑰 。

HTTPS的加密方法：
發(fā)送方通過密鑰將明文轉(zhuǎn)換成密文，進行發(fā)送，
接收方收到數(shù)據(jù)再通過密鑰將密文轉(zhuǎn)換成明文。

看似簡單的過程，而這其中HTTPS為了保證信息的安全又與竊取篡改者進行了多次博弈,下面的加密流程揭示其中的博弈過程。

三、HTTPS加密流程

既然要保證數(shù)據(jù)安全, 就需要對數(shù)據(jù)進行 “加密”。

網(wǎng)絡傳輸中不再直接傳輸明文了，而是加密之后的 “密文”。

你以為進行加密后，就能萬事無憂了？ 不正所謂道高一尺魔高一丈，黑客也在想盡辦法破解。
世界上沒有絕對的安全，只有當破解成本超過了數(shù)據(jù)本身的價值，那這些數(shù)據(jù)就安全了。正所謂虧本的買賣沒人做。

加密的方式有很多, 但是整體可以分成兩大類: 對稱加密 和 非對稱加密 。

對稱加密

對稱加密其實就是通過同一個 “密鑰” , 把明文加密成密文, 并且也能把密文解密成明文。

此時就算黑客入侵路由器，截獲了密文，他沒有密鑰解密，因此數(shù)據(jù)仍是安全的。

但是實際情況可不是這樣的。

一個服務器會同時給N個客戶端提供服務。 那么所有客戶端都用同一個密鑰進行加密嗎？
如果這樣，黑客直接注冊一個客戶端，就能拿到密鑰，就可以竊取篡改所有客戶端的信息。
所以是每個客戶端都會自己生成一個密鑰，然后再將密鑰與通過這個密鑰加密好的密文一起發(fā)送給服務器，服務器拿到密鑰和密文，再通過這把密鑰解密密文。

如果密鑰進行明文傳輸?shù)脑?，那前面的加密操作就沒有意義了，因此密鑰也需要加密。
且密鑰的加密不能再使用對稱加密了，因為這個密鑰就是為了解決對稱加密的安全問題。這里就使用非對稱加密解決。

非對稱加密

非對稱加密要用到兩個密鑰, 一個叫做 “公鑰”, 一個叫做 “私鑰”。
有以下兩種方法：

公鑰進行加密操作，私鑰進行解密操作。
私鑰進行加密操作，公鑰進行解密操作。

須知

1??公鑰與私鑰一個用來加密，另一個用來解密，可以公鑰加密，私鑰解密；也可以私鑰加密，公鑰解密。
2??一個鑰匙進行加密，那么這個鑰匙就無法將密文解密成明文舉例：我用公鑰對數(shù)據(jù)進行加密，此時這個密文使用公鑰就解不出來，只有私鑰可以正確解密。
形象來說就是，公鑰與私鑰，一個充當鎖的角色，一個充當鑰匙的角色。所以無法同時做到又能加密又能解密。
3??公鑰私鑰就是兩把 “鑰匙” ， 公布出去的叫做公鑰，自己留下不告訴別人的叫做私鑰。
4??公鑰和私鑰是配對的，最大的缺點就是運算速度非常慢，比對稱加密要慢很多。

圖解

共涉及到兩個個密鑰：
服務器的：公鑰：pubKey;私鑰：priKey

前提：服務器將公鑰告訴所有客戶端，自己保留私鑰。
用來加密的鑰匙：key
私鑰：priKey(privateKey)；公鑰pubKey(publicKey)。

你以為這就安全了嗎？？
魔高一丈的攻擊要來了?。?！

中間人攻擊

攻擊來啦！

圖解

共涉及到四個密鑰：
服務器的：公鑰：pubKey;私鑰：priKey
黑客的：公鑰：pubKey1;私鑰：priKey1

1??客戶端先向服務器申請公鑰，服務器發(fā)送(明文傳輸)公鑰pubKey給客戶端
2??黑客截取到公鑰，黑客記錄這個pubKey，并自己生成了一對非對稱密鑰，pubKey1與priKey1。
3??然后將pubKey1發(fā)送給客戶端。

4?? 客戶端拿到公鑰，但是他并不知道這個公鑰被篡改了，因此仍然使用pubKey1對key進行加密，并發(fā)送。
5??此時黑客再次截取客戶端發(fā)送的數(shù)據(jù)，使用priKey1將key解密出來，然后再用key將密文解密得到數(shù)據(jù)。
6??然后再將數(shù)據(jù)篡改后，用key加密，再用之前記錄的pubKey對key加密，然后再發(fā)送給服務器。

上述的中間人攻擊，就對數(shù)據(jù)神不知鬼不覺的完成了截取篡改。

那么HTTPS為了應對中間人攻擊，就實施了 “證書” 這一方案

證書

如何破解 “中間人攻擊” 呢？

"中間人攻擊"的原理
中間人攻擊主要就是通過截獲服務器發(fā)送給客戶端的公鑰，然后將自己生成的公鑰以相同的數(shù)據(jù)格式發(fā)送給客戶端，讓客戶端以為自己拿到了服務器的公鑰。

所以破解"中間人攻擊"的關(guān)鍵就是服務器的公鑰可以安全送達。
而 “證書” 就可以讓客戶端驗證服務器傳輸過來的公鑰有沒有被篡改。

證書是什么

證書可以理解成是一個Java中的對象，這個對象中包含許多信息(成員變量)以字符串的形式呈現(xiàn)。

證書包含的信息：

• 證書發(fā)布機構(gòu)
• 證書有效期
• 公鑰
• 證書所有者
• 簽名：簽名就是通過算法將整個證書計算出的一個哈希值?？梢园押灻斫鉃橐粋€校驗和
• …等等信息

搭建一個 HTTPS 網(wǎng)站要在相關(guān)權(quán)威機構(gòu)先申請一個證書，要向權(quán)威機構(gòu)提供一些資料(包括服務器要發(fā)送給客戶端的公鑰)，申請下來的 證書的信息中就包括公鑰 ，證書中有一個最關(guān)鍵的核心信息： 簽名 ！

這個 簽名由權(quán)威機構(gòu)先針對證書計算出一個值，然后權(quán)威機構(gòu)再用自己的私鑰對這個簽名進行加密 。
電腦操作系統(tǒng)內(nèi)置了 與權(quán)威機構(gòu)私鑰成對的公鑰 。

此時服務器就不會向客戶端發(fā)送公鑰，而是將整個證書發(fā)送給客戶端。
而證書仍然采用明文傳輸，其中只有簽名這個屬性進行了加密！

圖解

共涉及到四個密鑰：
服務器的：公鑰：pubKey;私鑰：priKey
黑客的：公鑰：pubKey1;私鑰：priKey1


如果黑客自己 偽造一個證書發(fā)給客戶端 或者 用系統(tǒng)內(nèi)置的公鑰解密并篡改了簽名 ，但是黑客沒有權(quán)威機構(gòu)的私鑰，無法對簽名進行加密，那么系統(tǒng)內(nèi)置的公鑰就無法正確解密簽名，就更不會信任這個證書了。

當然，客戶端拿到證書后不止是會對簽名進行校驗。
當客戶端獲取到這個證書之后, 會對證書進行校驗(防止證書是偽造的，或被篡改過)

• 判定證書的有效期是否過期
• 判定證書的發(fā)布機構(gòu)是否受信任(操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機構(gòu))
• 驗證證書是否被篡改: 從系統(tǒng)中拿到該證書發(fā)布機構(gòu)的公鑰, 對簽名解密, 得到一個 hash 值(稱為數(shù)據(jù)摘要), 設為 hash1，然后計算整個證書的 hash 值，設為 hash2， 對比 hash1 和 hash2 是否相等，如果相等，則說明證書是沒有被篡改過的 。

此時就保證了數(shù)據(jù)的安全！
黑客將證書中的公鑰替換成自己的，客戶端可以識別，直接報錯，就不會再向外發(fā)送數(shù)據(jù)。
如果黑客不替換，那么他也無法解密出數(shù)據(jù)，更別說篡改數(shù)據(jù)了。

證書的目的就是為了保護服務器的公鑰可以安全送達客戶端，而不被篡改。

以上的 “對稱加密”，“非對稱加密”，“證書”，都是SSL協(xié)議中的內(nèi)容。
而HTTPS協(xié)議 = HTTP協(xié)議 + SSL協(xié)議。

總結(jié)

以上就是今天要講的內(nèi)容，本文介紹了HTTPS的是如何保證數(shù)據(jù)安全傳輸，以及如何應對中間人攻擊！

路漫漫不止修身，也養(yǎng)性。文章來源地址http://www.zghlxwxcb.cn/news/detail-607029.html

到了這里，關(guān)于HTTPS——HTTPS如何加密數(shù)據(jù)，“證書“為什么可以應對 “中間人攻擊“的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！