巨群資訊

HTTPS協議的工作原理是什麼？”這是我在數天前工作專案中需要解決的問題。

作為一名 網頁設計 開發人員，我當然知道 HTTPS 協定是保障用戶敏感資料的好辦法，但並不知道這種協議的內在工作機制。

它怎麼保護資料？有人監聽線路的情況下，伺服器與用戶端之間如何建立安全的連接？安全證書又是什麼，為什麼還要花錢買呢？

一系列通道

在深入講解原理細節之前，讓我們首先簡單瞭解下HTTPS所防範的的問題，以及安全連接為何如此重要吧。

在你訪問自己喜歡的站點時，從你的電腦發送的請求會在各個不同的網路之間傳遞——這些網路很有可能是用來偷聽，甚至篡改你的資訊。

區域網中，資訊從你的電腦傳輸到其他電腦，傳輸到接入點，到ISP的路由器、交換機，最後到達骨幹網線路。這樣的一個過程中，有許多不同的組織在傳送著你的請求。這時，如果不懷好意的用戶侵入這條線路之中的任何一個系統中時，他們將很有可能看到線路中傳送的內容。

而一般情況下，Web請求和相應都經由普通的HTTP協定明文傳送。HTTP協定默認不使用加密協定，都是由於這些原因：

加密消耗了很多計算資源。

加密佔用了更多的傳輸帶寬。

加密後緩存機制會失效。

不過，網頁設計開發人員會時不時遇到在連接中傳送密碼、信用卡號等敏感資訊的情況。所以，有必要為這些頁面做好防嗅探的準備措施。

傳輸層安全協議（TLS）

雖然下面講解的內容和密碼學有關，但是這裏只是一個簡單的介紹，不熟悉相關知識也應該看得懂。在實踐中，是密碼學演算法確保了通信過程的安全，同時也抵禦了潛在的資訊黑手——干擾通信和監聽的人。

SSL協定的繼任者——TLS協定，常被用來實現安全HTTP連接（HTTPS）協議。在OSI網路模型中，TLS協定比HTTP協定的工作更加底層。確切來說，就是TLS的那部分連接發生在HTTP的連接之前。

TLS是一種混合的加密機制。它具有多種範式，接下來所看到的是對於這兩種範式（用於共用秘密資訊和身份認證（確保聲稱的身份和實際身份一致）的公鑰演算法和用於加密請求與回應機密資訊的對稱式演算法）的說明：

公鑰加密機制

使用公鑰加密機制，雙方各自擁有一份公鑰和一份私鑰，公鑰和私鑰通過數學演算聯繫在一起。公鑰用於將明文轉化為密文（變成了一堆亂碼），私鑰用來解密這一堆亂碼般的資訊。

一旦資訊被公鑰加密，它將只能由相應的私鑰解密。兩者缺一不可，而且也不能反過來使用。公鑰可以自由傳播，無需擔心系統安全性降低；但私鑰應妥善保管，不可將其洩露給未經授權解密的資訊的用戶，這就是公鑰和私鑰這兩個名稱的由來。

公鑰機制相當酷的地方在於，通信雙方可以在最初不安全的通道上建立起安全可靠的通信連接。

用戶端和伺服器都可以使用各自的私鑰，只要共用了一部分公開信息，也就是共用了同一個公鑰的情況下，就可以建立起相應的會話。

這意味著即使有人坐在用戶端或者伺服器前查看連接過程，他們也不會知道用戶端或者服務的的私鑰，也不會知道會話所共用的密碼。

這得靠什麼實現？靠數學！

Diffie-Hellman

這種密鑰交換最常使用是Diffie-Hellman的密鑰交換法。這項過程允許伺服器和用戶端雙方商定共同的保密資訊，而不需要在傳輸過程中交換這個資訊。這樣一來，即使嗅探者查看每個資料包，也不能確定連接上傳輸的共用密碼是什麼。

在最初的DH式密鑰交換發生之後所生成的共用資訊，可以在會話接下來的通信中使用更簡潔的對稱式加密法，我們之後就會看到對稱式加密法的說明。

一點點數學

公鑰演算法的特點就是很容易由運算元計算出結果，而基本上不可能作逆向運算。這也就是使用了兩個質數的所要達到的目的。

現在假設Alice和Bob分別是參與DH式密鑰交換過程的兩方，他們一開始會商議確定一個小質數（一般是2,3,5這樣的小數字）和一個大質數（有300位以上）作為加密的原始資訊。小質數和大質數都可以直接傳輸，不必擔心交換過程中的不安全。

需要明白的是，Alice和Bob各自都持有著自己的私鑰（100多位的數），而且也永遠不應該共用自己的私鑰。不光是兩人之間，也包括其他不相關的人都不應該擁有這兩組私鑰。網路中傳輸的是他們的私鑰、小質數和大質數混合運算得到的結果。更確切來說，就是：

Alice的結果 = （小質數Alice的密碼）% 大質數

Bob的結果 = （小質數Bob的密碼）% 大質數

（“%” 符號表示取模運算，即取得除法運算的餘數）

所以Alice使用大質數和小質數加上自己的私鑰運算，就會得出結果，而Bob做同樣的計算，也能得到相同的結果。當他們接收到對方的運算結果時，他們可以由數學計算導出會話中所要傳輸的資訊，也就是說：

Alice計算的是

（Bob的結果Alice的密碼）% 大質數

而Bob則計算

（Alice的結果Bob的密碼）% 大質數

Alice和Bob得出來的數位相同，這個數位也就是會話中所要共用的密碼。請注意，雙方都沒有向對方傳輸各自的私鑰，而連接過程中也沒有明文傳遞保密資訊。這一點真是太棒了！

對數學不好的人而言，維琪百科上有一張混合顏料的圖可以用來說明情況：

請注意一開始的顏色（黃色）最後都會有Alice和Bob的顏色參與計算。這就是雙方會得到同樣結果的原因。對於觀看中間過程的人來說，唯一在連接中發送的半合成資訊是毫無意義的。

對稱式加密機制

每次會話中只需要產生一次公鑰交換的過程。在接受了同一個共用保密資訊以後，伺服器和用戶端之間會使用更為高效的對稱式加密機制進行通信，省去了來回交換的額外花銷。

在接受了之前的共用保密資訊之後，還會使用一套密碼機制（一般是一組加密演算法），使用共用的密碼安全地通信，加密解密各自的資訊。而竊聽者只會看到一堆亂碼在傳來傳去。

身份認證

DH式密鑰交換允許雙方創建私有的，共有的密碼，但通信雙方怎麼確保是真正想要對話的人呢？這裏就涉及到了身份認證的問題。

假設我拿起電話，跟我的朋友進行DH式密鑰交換，在電話已經被干擾的情況，實際上是在跟其他人交換資訊。在使用共用密碼了以後，我仍然可以安全地與“朋友”交換資訊，沒有人可以解密我們的通信資訊，但是“朋友”並不真的是我的朋友，這可是十分不安全的！

要解決身份認證問題，需要有配套的公鑰基本設施，來核實用戶的真實身份。這些設施用來創建，管理，發佈，收回數字證書。而數位證書正是你需要為站點使用HTTPS協定付費的惱人事項。

但是，什麼是數位證書，數位證書又是如何保證資訊更加安全的呢？

證書

從更高的層次來講，數位證書是將機器上的公鑰和身份資訊綁在一起的數位簽名。數字簽名擔保某份公鑰屬於某個特定的組織和機構。

證書將功能變數名稱（身份資訊）和特定公鑰關聯起來。這就避免了竊聽者將自己的伺服器偽裝成用戶將要連接的伺服器，並進行攻擊的行為。

在上面打電話的例子中，攻擊者可以嘗試展示自己的公鑰，裝作是你的“朋友”，但是證書上面的簽名資訊便顯示出：這份證書不是來自我信任的人的。

要受到一般瀏覽器的信任，證書本身還應當受到CA的信任。CA公司對認證會進行人工核查，確定申請主體滿足以下兩個條件：

1. 在公共記錄中存在著這個人/這家公司。

2.需要簽名的證書上標明的功能變數名稱的確由申請主體實際控制。

當CA查證，得出申請人屬實，並且的確擁有這個功能變數名稱的結果，CA便會為證書頒發簽證，蓋上“已核准”的戳記，表明網站的公鑰屬於這個網站，而且可以信任。

你的瀏覽器中會內置一系列受信任的CA列表。如果伺服器返回的是未經過受信任CA簽證的證書，瀏覽器會彈出大大的警告，這就在系統中多了一層安全措施，如果不然，任何人都可以四處簽售偽造的證書。

這樣一來，即使攻擊者將自己的公鑰拿出來，生成這份密鑰，聲稱自己的偽造伺服器就是“facebook.com”，瀏覽器也會因為檢查到“未經受信任CA簽名的證書”而彈出提示。

一些關於證書的其他事項

增強式認證

在常規的X.509 證書之外，增強式認證證書提供了更強力的認證。

要授予增強式認證證書，CA會對功能變數名稱持有著做更加深入的查驗（通常需要提供護照和水電費帳單等資訊）。

這種類型的證書，瀏覽器中大鎖圖示的顯示位置背景也會變成綠色。

在同一台伺服器上運行的多個網站

在HTTP協定連接開始之前進行的TLS協定握手流程，很有可能存在著多個網站存放在同一個伺服器，使用相同IP位址的情況。

虛擬主機 的Web路由是由Web伺服器分發，但是TCP握手的過程，卻是發生在連接之前。整個系統的單張證書會被發送到伺服器的所有請求之中，這種流程會在共用主機的環境中發生問題。

如果你正在使用Web主機上提供的服務，他們會在你使用HTTPS協議之前要求使用獨立的IP位址。不然主體提供商就需要每次在伺服器上有新站點的時候，取得新證書（並且向CA重新申請認證）。

轉貼來源：Web前端

http://www.piece2ec.com.tw/news.asp?ID=1834

參考文獻：

1.吳政隆，2002，以XML 為資料擷取介面之審計系統實作，私立中原大學會計系碩士班未出版論文。

2.陳柏任，2001，網際網路財務報告揭露之系統架構研究，私立中原大學會計系碩士班未出版論文。

3.梁定彭，1997，資訊管理研究方法總論，中華民國資訊管理學報，第一期第四卷：1-6。