HTTPS-透徹學習匯總

標籤：代理   授權   完整   介紹   社交網站   升級   使用者   偽造   也有   

SSL和SSH和OpenSSH，OpenSSL有什麼區別

 

一、SSL的作用

　　不使用SSL/TLS的HTTP通訊，就是不加密的通訊。所有資訊明文傳播，帶來了三大風險。

竊聽風險（eavesdropping）：第三方可以獲知通訊內容。篡改風險（tampering）：第三方可以修改通訊內容。冒充風險（pretending）：第三方可以冒充他人身份參與通訊。

　　SSL/TLS協議是為瞭解決這三大風險而設計的，希望達到：

所有資訊都是加密傳播，第三方無法竊聽。具有校正機制，一旦被篡改，通訊雙方會立刻發現。配備身份認證，防止身份被冒充。

　　具體解決原理請繼續往下閱讀。

二、SSL的曆史

1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，但是未發布。1995年，NetScape公司發布SSL 2.0版，很快發現有嚴重漏洞。1996年，SSL 3.0版問世，得到大規模應用。1999年，互連網標準化組織ISOC接替NetScape公司，發布了SSL的升級版TLS 1.0版。2006年和2008年，TLS進行了兩次升級，分別為TLS 1.1版和TLS 1.2版。最新的變動是2011年TLS 1.2的修訂版。目前，應用最廣泛的是TLS 1.0，接下來是SSL 3.0。但是，主流瀏覽器都已經實現了TLS 1.2的支援。TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。

　　通俗的講，TLS、SSL是個加密套件，負責對HTTP(或其他協議)的資料進行加密。TLS是SSL的升級版。現在提到HTTPS，加密套件基本指的是TLS。

　　傳輸加密的流程

　　原先是應用程式層將資料直接給到TCP進行傳輸，現在改成應用程式層將資料給到TLS/SSL，將資料加密後，再給到TCP進行傳輸。

三、HTTP缺陷

　　HTTP在網路上都是以明文傳輸的，很容易遭受中間人攻擊。也就意味著，監聽發送端、接收端中間的任意節點都可以知道你們傳輸的內容是什麼。這些節點可能是路由器、代理等。

　　在發送端對密碼進行加密？沒用的，雖然別人不知道你原始密碼是多少，但能夠拿到加密後的帳號密碼，照樣能登陸。

四、HTTPS是如何保障安全的

　　HTTP是應用程式層協議，位於HTTP協議之下是傳輸協議TCP。TCP負責傳輸，HTTP則定義了資料如何進行封裝。

HTTP –> TCP （明文傳輸)　　

　　HTTPS相對於HTTP有哪些不同呢？其實就是在HTTP跟TCP中間加多了一層加密層TLS/SSL。

　　傳輸加密的流程

　　原先是應用程式層將資料直接給到TCP進行傳輸，現在改成應用程式層將資料給到TLS/SSL，將資料加密後，再給到TCP進行傳輸。:

　　在原來的五層模型中嵌入了SSL/TSL層，用來為傳輸中的資料進行加密的服務，從這張圖上可以看出，當資料從HTTP層往下流的時候經過SSL層的Data Encryption Service，然後再把資料群組合到TCP層進而傳輸，而當資料從另一端的TCP層向上流的時候，將加密後的資料往上交付，SSL層會為其解密，然後再交付給HTTP層。

　　概括的講，就是一個端到端的加、解密流程而已

　　就是這麼回事。將資料加密後再傳輸，而不是任由資料在複雜而又充滿危險的網路上明文裸奔，在很大程度上確保了資料的安全。這樣的話，即使資料被中間節點截獲，壞人也看不懂。

五、非對稱式加密與認證

　　SSL/TLS協議的基本思路是採用公開金鑰加密法，也就是說，用戶端先向伺服器端索要公開金鑰，然後用公開金鑰加密資訊，伺服器收到密文後，用自己的私密金鑰解密。這就存在了兩個問題：

　　1.公開金鑰如何擷取？

　　　　瀏覽器是怎麼獲得XX的公開金鑰的？當然，使用者可以自己去網上查，XX也可以將公開金鑰貼在自己的首頁。然而，對於一個動不動就成敗上千萬的社交網站來說，會給使用者造成極大的不便利，畢竟大部分使用者都不知道“公開金鑰”是什麼東西。

　　2.資料轉送僅單向安全

　　　　公開金鑰加密的資料，只有私密金鑰能解開，於是使用者發給伺服器的帳號、密碼是安全了，半路不怕被攔截。但是有個很大的問題：伺服器用私密金鑰加密的資料，公開金鑰也能解開。加上公開金鑰是公開的，伺服器發給使用者的隱私資料相當於在網上換了種方式裸奔。（中間Proxy 伺服器拿到了公開金鑰後，毫不猶豫的就可以解密使用者的資料）

 　　解決問題1:

　　　　這裡要涉及兩個非常重要的概念：認證、CA（憑證授權單位）。

　　　　認證，可以暫時把它理解為網站的身份證。這個身份證裡包含了很多資訊，其中就包含了上面提到的公開金鑰。

　　　　也就是說，當小明、小王、小光等使用者訪問XX的時候，再也不用滿世界的找某個伺服器的公開金鑰了。當他們訪問某伺服器的時候，這台伺服器就會把認證發給瀏覽器，告訴他們說，乖，用這個裡面的公開金鑰加密資料。

　　　　這裡有個問題，所謂的“認證”是哪來的？這就是下面要提到的CA負責的活了。

　　　　CA（憑證授權單位），可以頒發認證的CA有很多（國內外都有），但是只有少數CA被認為是權威、公正的，這些CA頒發的認證，瀏覽器才認為是信得過的，我們的作業系統中會預先安裝好一些認證發布機構的認證。比如VeriSign。（CA自己偽造認證的事情也不是沒發生過。。。）憑證發行的細節這裡先不展開，可以先簡單理解為，網站向CA提交了申請，CA審核通過後，將憑證發行給網站，使用者訪問網站的時候，網站將認證給到使用者。

　　解決問題2:

　　　　上面提到，通過私密金鑰加密的資料，可以用公開金鑰解密還原。那麼，這是不是就意味著，網站傳給使用者的資料是不安全的？

　　　　　　答案是：是！！！（三個歎號表示強調的三次方）

　　　　看到這裡，可能你心裡會有這樣想：用了HTTPS，資料還是裸奔，這麼不靠譜，還不如直接用HTTP來的省事。但是，為什麼業界對網站HTTPS化的呼聲越來越高呢？這明顯跟我們的感性認識相違背啊。因為：HTTPS雖然用到了公開祕密金鑰加密，但同時也結合了其他手段，如對稱式加密，來確保授權、加密傳輸的效率、安全性。

　　　　概括來說，整個簡化的加密通訊的流程就是：

1.小明訪問XX，XX將自己的認證給到小明（其實是給到瀏覽器，小明不會有感知）2.瀏覽器從認證中拿到XX的公開金鑰A2.瀏覽器產生一個只有自己自己的對稱金鑰B，用公開金鑰A加密，並傳給XX（其實是有協商的過程，這裡為了便於理解先簡化）4.XX通過私密金鑰解密，拿到對稱金鑰B5.瀏覽器、XX 之後的資料通訊，都用密鑰B進行加密注意：對於每個訪問XX的使用者，產生的對稱金鑰B理論上來說都是不一樣的。比如小明、小王、小光，可能產生的就是B1、B2、B3.

六、認證可能存在的問題

　　認證非法可能有兩種情況：

　　　　認證是偽造的：壓根不是CA頒發的
　　　　認證被篡改過：比如將XX網站的公開金鑰給替換了

　　舉個例子：這個世界上存在一種東西叫做代理，於是，上面小明登陸XX網站有可能是這樣的，小明的登陸請求先到了Proxy 伺服器，Proxy 伺服器再將請求轉寄到的授權伺服器。

小明 –> 邪惡的Proxy 伺服器 –> 登陸授權伺服器

　　然後，這個世界壞人太多了，某一天，Proxy 伺服器動了壞心思（也有可能是被入侵），將小明的請求攔截了。同時，返回了一個非法的認證。如果善良的小明相信了這個認證，那他就再次裸奔了。因為這個認證中有邪惡伺服器的公開金鑰，而不是授權伺服器的公開金鑰，小明會使用邪惡伺服器的公開金鑰加密，此時邪惡伺服器就可以使用自己的私密金鑰擷取資料包中內容。當然不能這樣，那麼，是通過什麼機制來防止這種事情的發生的呢。

　　下面，我們先來看看”認證”有哪些內容，然後就可以大致猜到是如何進行預防的了。

七、認證內容

　　在正式介紹認證的格式前，先插播個小廣告，科普下數位簽章和摘要，然後再對認證進行非深入的介紹。為什麼呢？因為數位簽章、摘要是認證防偽非常關鍵的武器。

　　數位簽章與摘要

　　　　“摘要”就是對傳輸的內容，通過hash演算法計算出一段固定長度的串（是不是聯想到了文章摘要），供下載者驗證下載後的檔案是否完整，或者說是否和伺服器上的檔案”一模一樣“，而且不同的明文摘要成密文，其結果總是不同的，而同樣的明文其摘要必定一致，“數字摘要“是https能確保資料完整性和防篡改的根本原因。

　　　　“簽名”，通過CA的私密金鑰對這段摘要進行加密，加密後得到的結果就是“數位簽章”。數位簽章只能驗證資料的完整性，資料本身是否加密不屬於數位簽章的控制範圍。

明文 –> hash運算 –> 摘要 –> CA的私密金鑰加密 –> 數位簽章

　　結合上面內容，我們知道，這段數位簽章只有CA的公開金鑰才能夠解密。

　　接下來，我們再來看看神秘的“認證”究竟包含了什麼內容，然後就大致猜到是如何對非法認證進行預防的了。內容非常多，這裡我們需要關注的有幾個點：

　　　　認證包含了頒發認證的機構的名字 — CA

　　　　認證內容本身的數位簽章（用CA私密金鑰加密）

　　　　認證持有人的公開金鑰（對應伺服器的私密金鑰）

　　　　認證簽名用到的hash演算法（使用同一個hash演算法來驗證簽名）

參考:

　　SSL/TLS協議運行機制的概述

　　HTTPS科普掃盲貼

　　安全科普:HTTPS初探

　　

 

HTTPS-透徹學習匯總