經過講故事的方式讓你理解,對稱密鑰加密,非對稱稱密鑰加密和HTTPS等

在講HTTPS以前咱們先聊一下密碼學的簡單知識,由於密碼學仍是比較複雜的學科,這裏就簡單的介紹一些概念,可是這些概念對理解HTTPS有很大的幫助。算法

在密碼學中,經常使用Alice和Bob這兩個名字進行舉例,咱們也尊重一下密碼學的文化,通常還有個大壞蛋,截獲網絡的消息,這我的叫作Eve。安全

基礎概念

咱們舉一個小例子,Bob喜歡同班的一個女孩Alice,Bob想給Alice子傳一張紙條,寫了上了LOVE,傳給Alice,在傳送過程當中紙條被老師(Eve)截獲了,Eve打開一看,寫着LOVE,Bob被找家長了(居然早戀)。服務器

Bob總結了經驗,想出了一個策略,即便紙條被Eve截獲也看不懂其中的內容,那麼怎麼作才能讓Eve看不懂,而讓Alice能看懂呢?markdown

Bob想出一個辦法,把當前的字母變成字母表的上一個字母,也就是是把B變成A,把C變成B,把D變成C。Bob想要寫的LOVE就變成了KNUD,當Eve截獲你的小紙條,看到的就是KNUD,而Alice會把KNUD的每個字母變成字母表的下一個字母,也就是解析出了LOVE,Bob追到了心儀的女孩,也沒有被找過家長。網絡

這個這樣的密碼方式叫作***凱撒密碼***。dom

  • 密碼post

    在密碼學中密碼是一種加密方式,好比上個例子中把當前的字母變成字母表的上一個字母,這是密碼。這個須要注意一下和咱們平常生活中的密碼概念不一樣,生活中的密碼一般是指是通行碼,通行碼和祕鑰還不是同一個概念,後面咱們會講祕鑰。學習

  • 明文ui

    沒有加密以前的內容,就是LOVE編碼

  • 密文

    使用加密以後的內容,也就是KNUD

  • 編碼

    把明文變成密文的過程,也就是把LOVE經過密碼變成KNUD,加密工做Bob完成的。

  • 解碼

    把密文變成明文的過程,Alice把KNUD變成了LOVE

  • 密鑰

    密鑰是一個用於加解密算法的祕密參數,一般只有通訊者擁有,也就是上一個字母或者上兩個字母。

你們發現了,在傳送小字條的過程當中,密文是能夠被Eve隨便截獲的,Eve也能夠知道你的編碼和解碼方式(向前移動字母),可是老師不知道密鑰,也就是不知道移動幾個字母,這樣老師仍是看不懂小紙條。

咱們再繼續上一個例子,過了一個月,Bob發現Eve可能要破解你的小字條,Bob同Alice商量,咱們換一下編碼方式吧,咱們把當前字母變成字母表的上一個字母的方式變成當前字母變成字母表的上兩個字母的方式吧,這樣Eve就會更難破解。

對稱密鑰加密

對稱密鑰加密是密碼學中的一類加密算法。這類算法在加密和解密時使用相同的密鑰。這個很容易理解,就是上面的例子,Bob和Alice使用的相同的祕鑰,都是變成字母表的上一個字母

再來個例子,Bob是一個特工,想把一個很是機密的事情告訴Alice,Bob把很是機密的事情寫好後,放在一個箱子中(假設這箱子很是結實,只能用鑰匙打開),Bob用鑰匙鎖好以後,把箱子郵寄了出去,只有Bob和Alice有開這個箱子的鑰匙。當Alice收到箱子後,她用鑰匙打開箱子看到其中的內容,這個就是對稱密鑰加密

非對稱稱密鑰加密

非對稱稱密鑰加密是密碼學的一種算法,它須要兩個密鑰,一個是公開密鑰,另外一個是私有密鑰;一個用做加密,另外一個則用做解密。

如今咱們先討論一個問題,也就是對稱密鑰加密有什麼大的缺點,特別是在互聯網中。

經過上面的圖很好理解,Alice想和Bob進行通信,Alice經過密鑰進行了編碼,Bob經過密鑰進行了解碼,這樣互聯網中有人截獲了密文,也不知道Alice和Bob在說什麼。可是你們想過沒有,密鑰怎麼辦傳輸。

也就是在Alice和Bob第一次通信的時候,Alice生成了一個密鑰,怎麼傳輸給B呢?經過網絡傳輸嗎,這樣一定會被戶聯網中的壞人(Eve)給截獲,若是截獲了密鑰,Eve就能經過密鑰解碼密文,這可怎麼辦?

咱們就把密鑰再加密傳輸,這樣應該能夠了。答案是這樣不行,若是密鑰能在互聯網中安全傳輸,那麼密文也能夠啊!就不須要加密了(這個論證方法很牛),看來對稱密鑰加密有一些問題。

這個時候非對稱稱密鑰加密出馬了,他是怎麼作到,不在互聯網中傳輸密鑰,並且在傳輸過程當中一直是密文的牛逼程度。

  1. Alice和Bob分別在本地生成了一個公鑰和一個私鑰。
  2. Alice想和Bob通信,Alice先拿到Bob的公鑰,由於公鑰是公開的,任何人均可以拿到。
  3. Alice用Bob的公鑰進行編碼,變成了密文,進程傳輸。
  4. Bob收到密文後,用本身的私鑰進行解碼,獲得明文。

非對稱密碼加密中傳輸的過程是密文,並且Bob的私鑰沒有在互聯網中傳輸,一切都很美好(看起來很美好)。

你們有沒有發現一個問題,由於Bob的公鑰是公開的,Eve能夠拿到Bob的公鑰進行加密,僞裝Alice,發送一個消息,在xxx地點見面,這個時候Bob沒辦法驗證對方是否是Alice,這個問題怎解決?下面爲你們揭曉。

數字簽名

數字簽名是作什麼事情的呢,看傳輸內容是否被修改過驗證是否是做者發出的內容 ,那怎麼作的的呢。

Bob想驗證內容是不是Alice發送,或者內容是否被Eve修改過。

  1. Alice對內容進行了一次MD5處理,生成了一個摘要。
  2. Alice用本身的私鑰對內容的摘要進行了一次編碼操做,獲得了一個簽名。
  3. Alice把內容和簽名放在一塊兒發送出去。
  4. 當Bob接到這個請求的時候,先把簽名的部分拿出來,用Alice的公鑰進行解碼,獲得一個內容摘要。
  5. 把內容用MD5進行一次摘要處理,獲得一個摘要內容,兩個摘要內容相同,證實內容沒被Eve修改過。

上面傳輸的整個過程,可是你們可能仍是會有一點點不理解,他們是怎麼驗證傳輸內容是否被修改過驗證是否是做者發出的內容,下面講解一下。

驗證是否是做者發出的內容:你們看上面第2步,Alice用本身的私鑰對摘要進行了一次編碼,而只有Alice有本身的私鑰,這樣Eve沒有辦法冒充Alice。

傳輸內容是否被修改過:這個比較容易理解,由於內容經過MD5生成了內容摘要,若是修改了內容,Alice生成的內容摘要和Bob的必定不同。

有了數字簽名Bob就能夠驗證這文字內容是否是Alice發的,可是有一天Eve偷走了Bob的電腦,把Alice的公鑰換成了本身的公鑰,這樣Eve就能夠假裝成Alice和Bob通信了。那咱們怎麼避免這樣的問題發生呢?

證書

這個時候出現了一個機構,證書受權中心(CA),這組織是幹啥的呢,這組織對Alice進行嚴格的身份驗證(CA 有不少的驗證手段,能驗證這我的是有信譽的人或者公司),發現Alice是一個有信譽的人,給Alice受權了一個證書。由於Eve信譽很差,他拿不到這個證書。

總結起來證書的做用是驗證公鑰的合法性,也就是Eve換成本身的公鑰也沒有用。

那麼證書怎麼生成的呢。

  1. Bob把本身公鑰給認證機構,認證機構經過不少辦法驗證這個公鑰是Bob的。
  2. 認證機構用本身的私鑰對對Bob的公鑰進行簽名,生成一個證書,證書的內容主要有兩部分,一個是Bob的公鑰和認證機構的簽名。

HTTPS介紹

當初人們在設計網絡協議的時候,沒有考慮網絡協議的安全性,HTTP是典型的不安全的協議,只能依靠人們的誠信過活。人們爲了更安全的互聯網通信,採用了HTTPS這樣通信方式。

超文本傳輸安全協議(Hypertext Transfer Protocol Secure,常稱爲HTTP over TLSHTTP over SSL)是一種透過計算機網絡進行安全通訊的傳輸協議。

其實就是在HTTP和TCP協議上加了一層,叫作SSL或者TLS的協議。

那麼如今的問題就明確了,咱們只有掌握了SSL或者TLS協議就能夠,那麼他們之間有什麼區別呢,能夠這樣的簡單的理解,TLS只不過是SSL的一個最新的版本。接下來咱們將以TLS 1.2的版本做爲主要的學習內容。TLS協議主要有4個很是主要的協議分別是握手協議、密鑰規格變動協議、應用數據協議和警報協議。

握手協議

根據當前的通信的不一樣場景,主要把握手協議分紅三種狀況。

完整的握手

在客戶端和服務器端想進行通信的時候,要進行握手,咱們先來講一下STL握手中最完整的握手機制,也就是完整的握手。完整的握手大概分紅四部分,

  1. Client Hello

    這是握手的第一條消息,這消息內容是告訴服務端的一些基本狀況。

  • Version

    當前客戶端的TLS的版本。

  • Random

    隨機數,也就是流程圖中的客戶端隨機數。包含32字節的數據,其中28字節是隨機生成的(Random Bytes)。剩下的4字節包含額外的信息(GMT Unix Time)。

  • Session ID

    第一條通信中握手是空的。

  • Cipher Suites

    加密套件,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

  • Compression

    採用的壓縮算法,由於HTTP會對數據進行壓縮,這裏面就沒有進行壓縮。

  1. Server Hello

    這個是服務端回覆客戶端的第一條消息,是告訴客戶端的一些基本信息,而且肯定加密套件。

這個字段的意思和ClinetHello的意思相同,這個Session ID 不是空的了

  1. Certificate

典型的Certificate消息用於攜帶的證書鏈,葉子證書必須是第一個發送,中間證書按照正確的順序跟在葉子證書以後。

  1. Server Key Exchange

當證書驗證不足的時候,須要補充一些信息。消息內容對於不一樣的協商算法套 件都會存在差別。

  1. Certificate Request

    服務器要求客戶端上傳證書,這個步驟是能夠省略的。

  1. Server Hello Done

    服務端發送完成了。

  2. Certificate

    客戶端把證書發送到服務端。

  3. Client Key Exchange

    這是通過加密的預備主密碼。預備主密碼是當作主密碼的一個種子。

    RSA密鑰交換的過程當中。客戶端生成預主密鑰(46字節隨機數),使用服務器公鑰對其加密,將其包含在這個消息中,最後發送出去。

  4. CertificateVerify

    證實本身擁有對應的私鑰,這個消息只有服務端發送Certificate Request,客戶端纔會發送這個消息。

  5. Change Clipher Spec

    咱們切換到了主密碼,在這以前他們通信都是明文進行通信的。

  6. Finished

    客戶端說握手結束。

  7. Change Clipher Spec

    切換到主密碼通信。

  8. Finished

    服務端說握手結束。

其它推薦

相關文章
相關標籤/搜索