CA證書掃盲,https講解。

不少關於CA證書的講解。html

1.什麼是CA證書。git

 

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

 ◇ 普通的介紹信瀏覽器

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

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

這裏,A公司就是CA證書tcp

◇ 引入中介機構的介紹信函數

  好,回到剛纔的話題。若是和 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.驗證完證書後,若是證書有效,客戶端是生成一個隨機數,而後用證書中的公鑰進行加密,加密後,發送給服務器,服務器用私鑰進行解密,獲得隨機數。以後雙方便開始用該隨機數做爲鑰匙,對要傳遞的數據進行加密、解密。

 

 

 

 

關於https:http://blog.csdn.net/wangjun5159/article/details/51510594

 

 

 

 

 

 

 

 

 

 

 

引用參考博客:http://kb.cnblogs.com/page/194742/

關於https的誤解:http://www.admin5.com/article/20150523/600106.shtml

相關文章
相關標籤/搜索