戲說https

       最近在看一些關於https的東西，其餘人寫的博文啊什麼，有寫的比較通俗的，有寫的比較晦澀的，引起了兩點思考：

       一、其實任何一種技術的產生都是服務於現實需求的,也就是爲解決實際問題或者對已有版本的存在的問題進行改進。https也不列外，那若是以解決問題的思路去理解它，即爲何要有它？那我想是相對比看一堆名詞和理論要容易理解的多。這是否是就是傳說中的上帝視角呢？

       二、 另外我在想其實不少事務都有共通性，即雖然看似不是一個領域的事，可是解決問題的思路和方法，細細想來，其實很類似，因此咱們在理解一種技術的時候，若是能以現實生活的例子作類比，那對咱們對事物的理解又會更上一層樓。因此這篇文章不會沒有各類圖，沒有各類協議的實現細節，沒有各類指標，僅僅只對https這個東西的一點初略理解。

         廢話很少說（其實已經說了不少），下面來驗證個人思考，就以我https爲例吧：

        1、首先什麼是HTTP?

        按照我思考的第一點，說到HTTP，他首先就是千萬種技術中的一種，那咱們首先就要思考這種技術爲何會產生。咱們都知道當今互聯網使用最普遍的服務應當就是web服務，就是平常咱們用瀏覽器打開各類網頁這種，普通用戶其實只是作了一個簡單的打開操做，那實際上這個操做背後有許多技術在支撐，HTTP協議就是其中一個。

        首先http就是一種協議，協議是什麼呢，就是一種流程，一種規範，好比咱們實際生活中買東西也罷，吃東西也罷，都是在按着必定的流程和規矩在辦事的，那放到網絡上也同樣，咱們在瀏覽器中打開一個網頁，實際上就是想看到咱們想看的東西，那這個東西是放在你打開的這個網頁背後對應的公司的服務器上的，因爲不是面對面的交流，這種交流的方式是經過網絡來實現的，就像咱們跟遠方的朋友交流用電話實現同樣，那麼問題來了，這麼多用戶和服務器交互，若是沒有一個規矩，那根本不能實現有序良好的交流，想一想若是沒有交通規則，馬路上的車該如何通行吧。因此http這種協議產生的目的就是爲規範瀏覽服務。好比瀏覽器跟網站（服務器）如何請求數據，如何返回數據，如何控制交互過程當中的一些細節等等。

          2、爲何會有HTTPS?

         咱們知道了http是什麼，那其實任何一種事物或者技術的產生都是基於當時的環境，即便能作長遠考慮，也未必能徹底適應將來的發展，畢竟生活環境的變遷及技術的演進有時的確難以預料，因此纔有了技術的不斷更新。http跟其餘任何技術同樣，剛出現時只考慮解決了功能需求，對安全性卻沒有過多考慮：http協議下的數據傳輸都是明文方式進行的，就像現實生活中的白話交流同樣，旁人若是願意聽，實際上是很容易聽到的，網絡世界裏的交流也是同樣，因此能夠說http解決了web瀏覽這種需求，可是卻很不安全，這就是https產生的緣由：須要對http進行安全加固。

         3、什麼是HTTPS?

         https比http從名字上簡單來看就是多了一個S,這個多出的S表明什麼呢？其實就是指SSL/TLS,說的直白點就是在http這種協議上又套了一個殼子，爲何要套這個殼子呢，前面說過，爲的就是解決上一代http協議的安全問題。那爲何又是SSL,又是TSL呢，他們有什麼區別呢？其實就是一套東西。剛開始誕生的時候就叫SSL（安全套接字層），一開始是由一個叫網景的公司開發出來的，後來這個公司倒閉，IETF（一個管理互聯網技術規範的組織）接手了這個協議，從新起了個名字叫TLS(傳輸層安全)，就是這麼回事，哈哈。明白了https爲何產生，以及多出那個S是個啥玩意，下面開始正經說下這個「S」究竟是如何實現http協議安全性的？

          4、HTTPS如何實現安全？

         相信若是你本身研究過https相關的東西，必定據說過如下這些概念：對稱加密，非對稱加密、證書、數字簽名，公鑰、私鑰。。。等等。網上有很是多關於這方面的理論解釋，相信每個概念若是深刻研究下去都會是一個課題，咱們的重點只放在對HTTPS實現輪廓的理解上。

          咱們知道了http不安全，那到底如何不安全呢？我不打算像大多數博文同樣上圖+解釋了。我用一個例子來講明一下。前面說過用戶和網站的交互就像平常生活中人跟人之間的交流同樣。正常人的交流內容若是沒有什麼要緊的須要保密的，那被別人聽到也就聽到了，那若是咱們須要交流的內容是有隱私的或者須要保密的，那若是被別人聽到可能就會有很大問題。電視上諜戰劇你們都看過吧，地下接頭都是暗號先對一下，沒有暗號那對不起，再見。這個暗號就至關於一個密碼啊，對接頭行動進行安全保障。考慮到安全，這個暗號應該只有接頭的雙方知道。放到網絡通訊裏，這其實也是https要解決的核心問題，讓http通訊安全的進行。暗號其實就是對http過程的加密，這種加密的方法就是對稱加密方法（用同一個暗號）。

          看到這裏，不少人會以爲，那這多簡單啊，弄一個暗號，你們就用這個暗號來接頭唄。這樣想的童鞋實際上是沒有考慮到不少現實的問題：

           一、暗號怎麼產生呢？

           二、有了暗號後怎麼安全的讓雙方都知道這個暗號？

           其實安全都是創建在最初階段的基礎上，是一種底層設計的東西，底層不安全，後續的都不會安全，就像大樓的地基會影響整棟樓同樣。  回到接頭這個例子，初次接頭其實你們是不知道暗號的， 難的就是這第一次的暗號怎麼安全的讓彼此知曉。一但成功安全的交換了暗號，那後續的接頭就會變得簡單。

         問題來了，咱們解決問題：

        第1、暗號怎麼產生？ 這個其實沒有太多規矩，只要保證暗號能用且不可預期就好。https協議是客戶端隨機產生一個KEY

        第2、如何保證這個暗號的安全？直接傳遞暗號確定風險太大，萬一暗號被偷聽泄露了，那以後全部的接頭都是不安全的了。

         回到諜戰場景，爲了保證暗號安全，上線能夠提供一個預先準備好的箱子給下線用於盛放暗號---這就是公鑰   鑰匙只有上線那裏有---這就是私鑰 ，==》這種用公鑰加密，私鑰解密的加密方法就是非對稱加密

         同時也給出一些能證實上線身份的東西 ，好比屬於哪一個組織啊什麼的，-----這就是數字證書（公鑰+身份證實）    

         下線拿到這個箱子後，把暗號放到箱子裏，鎖好，再還給上線。這個過程即便有人中間獲得這個箱子也沒用，由於只有上線那裏有鑰匙啊。至於有人會說能夠撬開箱子啊什麼的，那這個就牽涉到箱子的牢固度，放在網絡通訊裏就是算法的強度，說的白點，這個箱子堅固到除了用配套的鑰匙打開外別無他法。

          那麼問題又來了，數字證書這個方法只解決了通訊過程當中的安全問題，那通訊雙方的身份怎麼驗證真假呢？下線的的身份驗證只要雙方都安全的知道了暗號還好說，關鍵是一開始的放暗號的箱子是上線給的，上線若是是假的，或者被敵方抓住策反了，天然以後全部的接頭（通訊）都是不安全的了。

           回到驗證上線身份的問題，這個上線的真假對於下線來講基本沒法判斷，惟一的方法就是去一個權威的地方覈實一下，這個權威確定是全部人都承認的。----這就是CA頒發機構   有人可能會說，這個權威萬一也淪陷了呢？ 好吧，實際上是存在這個可能的。這個其實就是信任鏈的問題，跟安全鏈是一個道理，若是信任鏈頂端都有問題，那下面全部的信任都沒有基礎了，因此數字證書的頒發機構自己的安全至關重要啊！從以上非對稱加密的原理能夠知道，對於根證書機構來講，私鑰是最重要的，因此私鑰一但泄露，整個信任鏈都會崩潰。

            上線的身份也驗證了，暗號也經過安全的方式進行傳輸了，看似無懈可擊了，那有沒有什麼問題了呢？細想一下，還有一個地方存在薄弱環節，那就是那個放暗號的箱子，這個箱子其實你們均可以獲取到（因此叫公鑰），若是這個箱子被掉包，那暗號天然也就泄露了。因此須要對這個箱子進行加固呢。諜戰劇裏有一個方法，就是對物品作標記，這個標記是很難被仿製或模仿的，即一但有人對這個箱子作了手腳，上線拿回這個箱子一看就知道了。-------這就是數字簽名

         梳理一下以上提到的，https其實解決了如下幾個問題

            一、數據的保密性                              對稱加密

            二、對稱加密密碼傳輸的安全           非對稱加密

            三、服務器身份驗證                          數字證書

            四、數字證書的安全                          數字簽名

 

        發現沒有，安全的問題都是一環一環的，也許爲了解決某個安全問題想了一個辦法，可是這個辦法自己又有漏洞，因而又要想辦法修補這個漏洞，循環往復，直到沒有明顯漏洞（至少當下看起來是），這其實就是開頭所說的技術服務於實際需求和問題。你絕對不會看到一個技術毫無用處而被髮明出來，若是有，也會迅速被淘汰。

       不知道這樣講https能讓你聽懂麼？ 反正我是這麼理解的哈，畢竟事物類似而不一樣，類比之處不免有疏漏，若有發現，還請指正。

       最後來張數字證書的圖鎮樓：