Https的加密機制

對稱加密就是有乙個金鑰，他可以對一段內容進行加密，加密後只能用它才能解密看到內容

那麼最大的問題是這個金鑰怎麼傳輸只讓雙方知曉，同時不被別人知道。如果瀏覽器生成乙個金鑰並傳送給瀏覽器，這個傳輸過程種金鑰被別人劫持到手了怎麼辦？之後他就可以用金鑰解開雙方傳輸的任何內容了，這樣當然是不行的。

有兩把金鑰，一把公鑰，一把私鑰，用公鑰加密的內容必須用私鑰才能夠解密；同樣，用私鑰加密的過程必須用私鑰才能解密

瀏覽器向**伺服器請求，伺服器把公鑰a傳給瀏覽器

之後瀏覽器向伺服器傳輸的所有東西都採用公鑰a加密，伺服器收到後用私鑰a-解密。由於只有伺服器才有這個私鑰a-，可以解密，所以能保證這條資料的安全

伺服器向瀏覽器傳輸的所有東西都用公鑰b加密，瀏覽器收到後用私鑰b-解密，也可以保證這條資料的安全性

採用這樣的方法確實可以。那麼https為什麼不採用這種加密的當時方式。最主要的原因是非對稱加密演算法非常耗時，特別是加密一些比較大的資料的時候力不從心，所以必須要用對成加密。那我們是否可以採用對稱加密+非對稱加密的方式解決加密問題呢？

非對稱加密+對稱加密

https請求：使用者在瀏覽器輸入乙個https**，然後連線到服務端的443埠

服務端的配置：採用https的伺服器必須要有一套數字證書。這套證書其實就是一對公鑰和私鑰。

傳送證書：傳送的證書是公鑰，只是包含了很多資訊。例如：證書頒發的機構，過期時間等

客戶端解析證書：這部分工作由客戶端的ssl/tls來完成的，首先會驗證公鑰是否有效。如果發現異常，則會彈出乙個警示框，指示證書出現問題。如果證書沒有問題，就生成乙個對稱加密的隨機值val，然後用公鑰對這個隨機值進行加密

傳送加密資訊：此時傳送的是用證書加密後的加密值，目的是為了能夠讓服務端得到這個加密值。以後服務端就可以通過這個隨機值進行加密解密了。

服務端解密資訊：服務端用私鑰解密後，得到了客戶端傳過來的隨機值val。此時客戶端與服務端都擁有金鑰隨機值val，之後雙方的所有資料都用金鑰隨機值val加密解密

傳輸加密後的資訊：此時的資訊就是被隨機值val加密後的資訊，可以在客戶端進行解密

客戶端解密：客戶端使用金鑰隨機值val進行解密

這裡我們假設公鑰a，私鑰a-，瀏覽器生成的金鑰b(隨機值val)

中間人無法直接拿到金鑰b，因為金鑰b本身被公鑰a加密了，只有伺服器的私鑰a-揭開才能拿到他。那麼中間人完全不需要拿到私鑰a-就能夠幹壞事

數字證書

**在使用https前，需要向ca機構申請頒發乙份數字證書，數字證書裡有證書持有者，證書持有者的公鑰等資訊，伺服器把證書傳給瀏覽器，瀏覽器從證書裡取出公鑰就行了。那麼數字證書在傳輸的過程中如何防止被篡改？

如何防止數字證書被篡改

我們把證書內容生成乙份「簽名」，比對證書內容與簽名是否一致就能察覺到是否被篡改。這種技術叫做數字簽名

數字簽名

ca擁有非對稱加密的私鑰和公鑰

ca對證書明文資訊進行hash

對hash後的值用私鑰加密，得到數字簽名

瀏覽器驗證過程

拿到證書，得到明文t，數字簽名s

用ca機構的公鑰對s進行解密，得到s-

用證書內的hash演算法對明文t進行hash得到t-

比較s-與t-是否相等，相等則表示證書可信

簡述HTTPS（二） 混合加密機制

加密和解密同用乙個金鑰的方式就叫對稱加密，也稱為共享金鑰加密 例如 a和b是進行通訊的雙方 假設a手握一把金鑰 key1，那麼a需要轉殖一把相同的金鑰 key1 在第一次通訊中，a將報文連同 key1 一起傳送給b 此後 a和b則分別使用 key1 key1 分別對接收 傳送的報文進行解密 加密 對...

https 的加密原理

1.http 協議 hypertext transfer protocol，超文字傳輸協議 是客戶端瀏覽器或其他程式與web伺服器之間的應用層通訊協議 https 協議 hypertext transfer protocol over secure socket layer 可以理解為 http s...

https的加密處理

一 http資料傳輸的不安全 使用http協議進行網路資料傳輸的最大不足是 資料沒有安全性可言，所有的資料都是明文傳輸的，所以一旦被第三方截獲就造成了資料洩漏。二 https資料傳輸的安全性 https協議可以看成是http協議的公升級版，https http ssl，下面以漸進的方式來說明http...