CA證書掃盲,https講解

1.什麼是CA證書。

 

看過一些博客,寫的比較形象具體。

 ◇ 普通的介紹信

  想必大夥兒都聽說過介紹信的例子吧?假設 A 公司的張三先生要到 B 公司去拜訪,但是 B 公司的所有人都不認識他,他咋辦捏?常用的辦法是帶公司開的一張介紹信,在信中說:茲有張三先生前往貴公司辦理業務,請給予接洽......云云。然後在信上敲上A公司的公章。

  張三先生到了 B 公司後,把介紹信遞給 B 公司的前臺李四小姐。李小姐一看介紹信上有 A 公司的公章,而且 A 公司是經常和 B 公司有業務往來的,這位李小姐就相信張先生不是歹人了。

這裏,A公司就是CA證書

◇ 引入中介機構的介紹信

  好,回到剛纔的話題。如果和 B 公司有業務往來的公司很多,每個公司的公章都不同,那前臺就要懂得分辨各種公章,非常滴麻煩。所以,有某個中介公司 C,發現了這個商機。C公司專門開設了一項“代理公章”的業務。

  今後,A 公司的業務員去 B 公司,需要帶2個介紹信:

  介紹信1

  含有 C 公司的公章及 A 公司的公章。並且特地註明:C 公司信任 A 公司。

  介紹信2

  僅含有 A 公司的公章,然後寫上:茲有張三先生前往貴公司辦理業務,請給予接洽......云云。

  某些不開竅的同學會問了,這樣不是增加麻煩了嗎?有啥好處捏?

  主要的好處在於,對於接待公司的前臺,就不需要記住各個公司的公章分別是啥樣子的;他/她只要記住中介公司 C 的公章即可。當他/她拿到兩份介紹信之後,先對介紹信1的 C 公章,驗明正身;確認無誤之後,再比對介紹信1和介紹信2的兩個 A 公章是否一致。如果是一樣的,那就可以證明介紹信2是可以信任的了。

 

◇ 什麼是證書?

  “證書”洋文也叫“digital certificate”或“public key certificate”(專業的解釋看“這裏”)。

  它是用來證明某某東西確實是某某東西的東西(是不是像繞口令?)。通俗地說,證書就好比例子裏面的公章。通過公章,可以證明該介紹信確實是對應的公司發出的。

  理論上,人人都可以找個證書工具,自己做一個證書。那如何防止壞人自己製作證書出來騙人捏?請看後續 CA 的介紹。

  ◇ 什麼是CA?

  CA是Certificate Authority的縮寫,也叫“證書授權中心”。(專業的解釋看“這裏”)

  它是負責管理和簽發證書的第三方機構,就好比例子裏面的中介——C 公司。一般來說,CA必須是所有行業和所有公衆都信任的、認可的。因此它必須具有足夠的權威性。就好比A、B兩公司都必須信任C公司,纔會找 C 公司作爲公章的中介。

 ◇ 什麼是CA證書?

  CA 證書,顧名思義,就是CA頒發的證書。

  前面已經說了,人人都可以找工具製作證書。但是你一個小破孩製作出來的證書是沒啥用處的。因爲你不是權威的CA機關,你自己搞的證書不具有權威性。

  這就好比上述的例子裏,某個壞人自己刻了一個公章,蓋到介紹信上。但是別人一看,不是受信任的中介公司的公章,就不予理睬。壞蛋的陰謀就不能得逞啦。

  文本後續提及的證書,若無特殊說明,均指 CA 證書。

 

2.證書的簽發過程:

 

a.服務方 S 向第三方機構CA提交公鑰、組織信息、個人信息(域名)等信息並申請認證;

b.CA 通過線上、線下等多種手段驗證申請者提供信息的真實性,如組織是否存在、企業是否合法,是否擁有域名的所有權等;

c.如信息審覈通過,CA 會向申請者簽發認證文件-證書。

證書包含以下信息:申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文,同時包含一個簽名;

簽名的產生算法:首先,使用散列函數計算公開的明文信息的信息摘要,然後,採用 CA 的私鑰對信息摘要進行加密,密文即簽名;

d.客戶端 C 向服務器 S 發出請求時,S 返回證書文件;

e.客戶端 C 讀取證書中的相關的明文信息,採用相同的散列函數計算得到信息摘要,然後,利用對應 CA 的公鑰解密簽名數據,對比證書的信息摘要,如果一致,則可以確認證書的合法性,即公鑰合法;

f.客戶端然後驗證證書相關的域名信息、有效時間等信息;

g.客戶端會內置信任 CA 的證書信息(包含公鑰),如果CA不被信任,則找不到對應 CA 的證書,證書也會被判定非法。

在這個過程注意幾點:

1.申請證書不需要提供私鑰,確保私鑰永遠只能服務器掌握;

2.證書的合法性仍然依賴於非對稱加密算法,證書主要是增加了服務器信息以及簽名;

3.內置 CA 對應的證書稱爲根證書,頒發者和使用者相同,自己爲自己簽名,即自簽名證書;

4.證書=公鑰+申請者與頒發者信息+簽名;

 

 3.http存在的問題(引用:http://blog.csdn.net/wangjun5159/article/details/51510594)

http通信存在的問題

  • 容易被監聽 
    • http通信都是明文,數據在客戶端與服務器通信過程中,任何一點都可能被劫持。比如,發送了銀行卡號和密碼,hacker劫取到數據,就能看到卡號和密碼,這是很危險的
  • 被僞裝 
    • http通信時,無法保證通行雙方是合法的,通信方可能是僞裝的。比如你請求www.taobao.com,你怎麼知道返回的數據就是來自淘寶,中間人可能返回數據僞裝成淘寶。
  • 被篡改 
    • hacker中間篡改數據後,接收方並不知道數據已經被更改

共享密鑰加密和公開密鑰加密

後續內容的需要,這裏插播一段共享密鑰加密和公開密鑰加密

  • 共享密鑰加密 
    • 共享密鑰的加密密鑰和解密密鑰是相同的,所以又稱爲對稱密鑰
  • 公開密鑰加密 
    • 加密算法是公開的,密鑰是保密的。公開密鑰分爲私有密鑰和公有密鑰,公有密鑰是公開的,任何人(客戶端)都可以獲取,客戶端使用公有密鑰加密數據,服務端用私有密鑰解密數據。
  • 異同 
    • 共享密鑰加密與公開密鑰加密相比,加解密處理速度快,但公開密鑰更適應互聯網下使用

https解決的問題

https很好的解決了http的三個缺點(被監聽、被篡改、被僞裝),https不是一種新的協議,它是http+SSL(TLS)的結合體,SSL是一種獨立協議,所以其它協議比如smtp等也可以跟ssl結合。https改變了通信方式,它由以前的http—–>tcp,改爲http——>SSL—–>tcp;https採用了共享密鑰加密+公開密鑰加密的方式

  • 防監聽 
    • 數據是加密的,所以監聽得到的數據是密文,hacker看不懂。
  • 防僞裝 
    • 僞裝分爲客戶端僞裝和服務器僞裝,通信雙方攜帶證書,證書相當於身份證,有證書就認爲合法,沒有證書就認爲非法,證書由第三方頒佈,很難僞造
  • 防篡改 
    • https對數據做了摘要,篡改數據會被感知到。hacker即使從中改了數據也白搭。

https連接過程

  • 客戶端發送請求到服務器端
  • 服務器端返回證書和公開密鑰,公開密鑰作爲證書的一部分而存在
  • 客戶端驗證證書和公開密鑰的有效性,如果有效,則生成共享密鑰並使用公開密鑰加密發送到服務器端
  • 服務器端使用私有密鑰解密數據,並使用收到的共享密鑰加密數據,發送到客戶端
  • 客戶端使用共享密鑰解密數據
  • SSL加密建立………

 

客戶端認證的通信的過程

  • 客戶端需要認證的過程跟服務器端需要認證的過程基本相同,並且少了最開始的兩步。這種情況都是證書存儲在客戶端,並且應用場景比較少,一般金融才使用,比如支付寶、銀行客戶端都需要安裝證書

後續的問題

    • 怎樣保證公開密鑰的有效性 
      • 你也許會想到,怎麼保證客戶端收到的公開密鑰是合法的,不是僞造的,證書很好的完成了這個任務。證書由權威的第三方機構頒發,並且對公開密鑰做了簽名。
    • https的缺點 
      • https保證了通信的安全,但帶來了加密解密消耗計算機cpu資源的問題 ,不過,有專門的https加解密硬件服務器
    • 各大互聯網公司,百度、淘寶、支付寶、知乎都使用https協議,爲什麼? 
      • 支付寶涉及到金融,所以出於安全考慮採用https這個,可以理解,爲什麼百度、知乎等也採用這種方式?爲了防止運營商劫持!http通信時,運營商在數據中插入各種廣告,用戶看到後,怒火發到互聯網公司,其實這些壞事都是運營商(移動、聯通、電信)乾的,用了https,運營商就沒法插播廣告篡改數據了。
          •  

4.比較完整的過程:

1. 客戶端發起HTTPS請求

  這個沒什麼好說的,就是用戶在瀏覽器裏輸入一個https網址,然後連接到server的443端口。

  2. 服務端的配置

  採用HTTPS協議的服務器必須要有一套數字證書,可以自己製作,也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過,纔可以繼續訪問,而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇,有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解,可以想象成一把鑰匙和一個鎖頭,只是全世界只有你一個人有這把鑰匙,你可以把鎖頭給別人,別人可以用這個鎖把重要的東西鎖起來,然後發給你,因爲只有你一個人有這把鑰匙,所以只有你才能看到被這把鎖鎖起來的東西。

  3. 傳送證書

  這個證書其實就是公鑰,只是包含了很多信息,如證書的頒發機構,過期時間等等。

  4. 客戶端解析證書

  這部分工作是有客戶端的TLS來完成的,首先會驗證公鑰是否有效,比如頒發機構,過期時間等等,如果發現異常,則會彈出一個警告框,提示證書存在問題。如果證書沒有問題,那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的,把隨機值用鎖頭鎖起來,這樣除非有鑰匙,不然看不到被鎖住的內容。

  5. 傳送加密信息

  這部分傳送的是用證書加密後的隨機值,目的就是讓服務端得到這個隨機值,以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

  6. 服務段解密信息

  服務端用私鑰解密後,得到了客戶端傳過來的隨機值(私鑰),然後把內容通過該值進行對稱加密。所謂對稱加密就是,將信息和私鑰通過某種算法混合在一起,這樣除非知道私鑰,不然無法獲取內容,而正好客戶端和服務端都知道這個私鑰,所以只要加密算法夠彪悍,私鑰夠複雜,數據就夠安全。

  7. 傳輸加密後的信息

  這部分信息是服務段用私鑰加密後的信息,可以在客戶端被還原。

  8. 客戶端解密信息

  客戶端用之前生成的私鑰解密服務段傳過來的信息,於是獲取瞭解密後的內容。整個過程第三方即使監聽到了數據,也束手無策。

 

5.總結整個過程:

1.服務器向CA機構獲取證書(假設這個證書僞造不了),當瀏覽器首次請求服務器的時候,服務器返回證書給瀏覽器。(證書包含:公鑰+申請者與頒發者的相關信息+簽名)

2.瀏覽器得到證書後,開始驗證證書的相關信息,證書有效(沒過期等)。(驗證過程,比較複雜,詳見上文)。

3.驗證完證書後,如果證書有效,客戶端是生成一個隨機數,然後用證書中的公鑰進行加密,加密後,發送給服務器,服務器用私鑰進行解密,得到隨機數。之後雙方便開始用該隨機數作爲鑰匙,對要傳遞的數據進行加密、解密。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章