HTTPS 是如何工作的？這篇文章來自于我在團隊的內(nèi)部分享。很多人可能不能很好的理解HTTPS，不能理解為什么HTTPS的代碼要那樣寫。因此我寫了這片博客，希望能讓更多人了解HTTPS。 密碼（Cipher）Java 1.2內(nèi)置了一個叫做"JCE"(Java Crytography Extension)的系統(tǒng)。它主要負責(zé)Java內(nèi)部的密鑰和證書的管理。 眾所周知，我們要給一段信息加密或者解密，就必須要有密鑰。這就好比開門或者鎖門，你得有一把鑰匙。 這個密鑰可以用Java帶的KeyGenerator 或者 KeyPairGenerator生成。前者用于生成對稱密鑰，后者用于生成分對稱密鑰。
公鑰也許分布廣泛，但是私鑰只有它的服務(wù)器知道。 在一個安全的非對稱加密方案中，當使用公鑰加密一段信息后，只有配對的私鑰可以解密這一段信息。因此，即使黑客拿到了公鑰加密信息，他也不能解密這一段信息。因為他沒有配對的私鑰。所以說，使用非對稱加密傳輸?shù)男畔⑹前踩摹?/p> 證書（Certificate）生活中，假設(shè)你要買鉆石然后進入了一家鉆石店。你怎么能夠知道鉆石是真的。對于多數(shù)人來說，他們沒有鉆石相關(guān)的知識，是很難分辨鉆石的真假的。但是，如果這家店有美國政府發(fā)布的的鉆石營業(yè)執(zhí)照，你就能確定這家店賣的是真的鉆石。 證書在計算機世界好比上面說的營業(yè)執(zhí)照，它可能有另一些密鑰——另一個證書（假設(shè)是“B”）。這個密鑰正是我需要的，而“B”則是證明這個證書是可信賴的憑證。 你可能會問:我怎么知道“B”是可信的。這是一個好問題。 Android在手機里內(nèi)置了將近150份CA（certificate agent 代理證明機構(gòu)）根證書。他們就好像美國的首席法官(like the chief justice in u.s)，在整個世界都是被認可的。 “B”內(nèi)置了內(nèi)另一個證書（C），因此我們會檢查“C”是否是可信的。。。查詢整條證書鏈，如果在這條證書鏈的末端或者根證書，正是我們在手機中內(nèi)置的150份預(yù)設(shè)的證書之一，我們就確信原證書是合法的。 P.S. : 證書有很多格式。
：PKCS12證書同時包含私鑰和公鑰。因此，PKCS12證書需要密碼開啟。 Https最后，講講“https”部分。之所以前面介紹“密碼”和“證書”兩部分，是因為HTTPs包含它們。 HTTPs（HTTP over SSL）被設(shè)計用于在互聯(lián)網(wǎng)中安全通信。 1. 何如安全通信？怎么才能建立安全的通信呢？首先想到的是加密。我給需要傳輸?shù)臄?shù)據(jù)加密，然后將數(shù)據(jù)和“加密用的密鑰”傳給服務(wù)器，服務(wù)器就能使用這個k密鑰解密傳輸?shù)臄?shù)據(jù)了。
?
讓我們想象這樣一個場景：黑客攔截了這次通信，這意味著加密用的密鑰和加密的數(shù)據(jù)都被盜取了。如果黑客有密鑰，解密這段加密的數(shù)據(jù)就不是什么難事了。好了，你的數(shù)據(jù)泄露了。 2. 非對稱加密（Asymmetric Cryptography）如何呢？上一個方法一點也不安全，我們考慮下一個，非對稱加密有怎么樣呢？ 這是一個很棒的想法。你使用服務(wù)器提供的公鑰加密信息。因為服務(wù)器是唯一知道這個與公鑰配對的私鑰的，這意味著只有服務(wù)器能夠解密這段加密的信息。這樣，即使是黑客攔截了這段消息，它沒有配對的私鑰，也無法解密這段信息。因此，數(shù)據(jù)是安全的。 不足之處就是，非對稱加密較對稱加密來說，需要花費更長的時間來完成加解密的工作。出于用戶體驗的考慮，給一大串數(shù)據(jù)執(zhí)行非對稱加解密，并不是一個理想的方案。 3. 最終的方案先前兩個方案都失敗了。有沒有綜合兩個方案優(yōu)勢的方案呢？下面這個方案就是你需要的。 HTTPS :
上圖很清楚的展示了HTTPS的執(zhí)行加解密的過程
結(jié)論因為對稱加密比非對稱加密快，因此HTTPS使用對稱加密給數(shù)據(jù)加密，使用非對稱加密加密對稱加密生成的密鑰，從而確保數(shù)據(jù)傳輸?shù)陌踩浴Ｊ褂眠@種方法，加密就變的即快速又安全了。 總之，理解HTTPS的工作原理是非常重要。這樣在現(xiàn)實工作生活中就可以使用這種思想保證你的數(shù)據(jù)安全。 |
|
|
