2016/4/14

從原理解說到申請憑證 免錢搞定網站安全性

用Let's Encrypt免費憑證 實作OpenSSL安全網站

吳惠麟

轉載至 https://www.netadmin.com.tw/article_content.aspx?sn=1604060002&jump=1

本文將採用開源碼OpenSSL套件來實作一個安全的SSL網站，以便簽發符合資安政策的數位憑證，並說明如何透過Let's Encrypt服務來取得免費且合法的數位憑證。

密碼系統一直是確保資料傳輸安全的基石。而在電子商務的運作上，安全網站伺服器（使用HTTPS連線來連接的網站，以下簡稱SSL網站）也一直利用密碼系統來保護在網路上傳輸資料的安全性與完整性。

但隨著電腦硬體的進步，在過去被認為不可能利用暴力破解法破解的密碼演算法，也發現在強大的硬體運算能力之下，此類的密碼演算法似乎已經不是所想的那麼安全，常用的密碼演算法SHA1即被證明，只要利用適當的電腦運算即可破解。

為了因應此類潛在的威脅，知名的瀏覽器如Chrome、IE等同時宣示了相關的資安政策，如果使用相關瀏覽器去瀏覽利用SHA1演算法為加密基礎的SSL網站，就會出現如圖1所示的警告資訊，藉此提醒使用者，並督促網站管理員儘速更新SSL網站所使用的數位憑證（Certificate，利用密碼系統所產生的憑證來證明網站的身分），以提升網站的安全性。

▲圖1 當瀏覽以SHA1演算法為加密基礎的SSL網站時將會出現警告資訊。

因此，本文除了會說明數位憑證相關背景說明外，還將以開源碼中的OpenSSL套件為例，示範如何簽發符合相關資安政策的數位憑證來實作一個安全的SSL網站（以Apache網站伺服器為例）。

另一方面，在現實環境中若要申請一個數位憑證，不但手續繁雜，而且也需要相關的費用，所以這裡也將說明如何利用Let's Encrypt服務（官方網站為https://letsencrypt.org）來取得一個免費且合法的數位憑證。

什麼是SSL

隨著電子商務的興起，有越來越多的交易行為不再是透過傳統的面對面行為交易，而是隱藏在鍵盤的後面，透過電子下單的方式完成交易。在這種情況下，需要一套安全的交易機制來保障雙方的交易。

一般來說，在評估電子交易安全的機制時，通常會以C.I.A原則來評估其機制的安全性，原則說明如下：

·機密性（Confidential）：在資料傳輸過程中，資料內容不能被不相關的第三者所窺視，例如在網路上購買商品的訂單資料，在傳輸到店家系統的過程中，不能被其他人偷窺到相關的訂單內容資訊，通常會加密所要傳輸的資料（即使在傳輸的中途被攔截，也無法直接看到內容），等到店家系統接收到資料時，再加以解密來還原相關資訊。

·完整性（Integrity）：要保持資料在傳輸的過程中，均不能被無權限的使用者任意竄改。例如電子商務的下單，當消費者送出訂單後，此訂單的內容，除了消費者本人外，誰都不能修改此訂單的內容。如果其他人可以用某種方式，能在不經消費者本人同意的情況下竄改內容，就表示系統有完整性的安全問題。

·可用性（Available）：網路資訊服務的基礎是來自於服務主機（如網站伺服器），可用性即是評估服務主機能夠正常服務的程度。簡而言之，期待服務主機能夠7×24全年無休的服務。但受限於主機的硬體或人力因素，常無法達到全年無休的目標，可用性分析就是評估主機能夠達到正常服務的最大時限。

除了上述傳統的資安原則外，由於電子商務的特性，也須考慮下列面向的問題：

·商家的真實性：商業交易最重要的基礎在於「信任」，消費者因為信任商家，所以交付財物來取得相對的貨物，而網路的商業行為最大的一個特徵是並非面對面的交易，因此對消費者而言並不容易去辨別商家的真實性，所以在電子交易中，商家需要一個具有公信力的數位憑證來證明其身分的真實性。

·來源端不可否認性：對商家而言，最頭痛的莫過於消費者出爾反爾，否認自己曾下過訂單的事實，因此也需要經相關的機制來確保消費者不能否認曾下過單的事實，此為不可否認性。

為了解決上述的相關問題，網景公司（Netscape）提出SSL（Secure Socket Layer，安全套接層協議）的解決方案，利用密碼系統的方式來解決上述的問題。使用者如果利用HTTPS來連接網站伺服器，即表示該網站伺服器支援以SSL的方式來加密來往的資料。隨著時間的演進，SSL也推出不同的版本，如表1所示。

表1 SSL各個版本比較


由於SSL是建構於密碼系統之下，因此以下繼續說明何謂密碼系統。

何謂密碼系統 

密碼系統可說是人類最古老的運用之一，其主要目的在於確保互相約定的雙方能在安全的前提下傳輸完整的資訊。依照其型態，可分為對稱式密碼（Symmetric）及非對稱式密碼（Asymmetric），分別說明如下： 

對稱式密碼（Symmetric） 

雙方在傳輸資料之前，先行互相約定一個鑰匙（一般稱之為金鑰），而後雙方在傳輸資料時，就以此金鑰來加解密文件，如圖2所示，傳輸過程如下所述： 

▲圖2 對稱式密碼系統使用流程。

傳送端在傳輸資料之前，先以金鑰加密所要傳送的資料，而後接收端在接收到資料之後再以相同的金鑰來解開此資料。 

對照C.I.A資安原則來分析，對稱式密碼系統可解決下列幾項相關的問題： 

·機密性（Confidential）：由於傳送端所傳輸的資料已經過金鑰加密，所以在傳輸過程中，即使被無關的第三者所擷取（例如利用Sniffer技術），但由於資料已被加密，因此就算資料被擷取，沒有相對應的金鑰也無法解開此資料，而達到機密性的要求。 

·完整性（Integrity）：如果傳送端所傳送的資料，在傳輸的過程中遭到惡意更改其內容，那在接收端接收到資料時，就無法以原先所約定的金鑰來解密此資料。因此，同理可證，如果傳輸的加密資料能正常地以金鑰成功的解密，即表示資料在傳輸的過程中並未遭到不正當的更改。反之，如果無法成功解密，就可能是資料在傳輸的過程中遭到不正當的更改。在實務上，通常會利用雜湊函數來驗證資料的完整性。 

·不可否認性：因為金鑰僅為傳送雙方所持有，一旦使用金鑰加密資訊並傳送後可正常地加解密，就表示該份文件確為金鑰持有者所傳送。 

目前常用對稱式密碼系統的演算法包括DES（Data Encryption Standard）、IDEA（International Data Encryption Algorithm）、RC5（Ron,s Code）、AES（Advanced Encryption Standard）等。 

對稱式密碼系統最大優點在於其加解密的運算速度相當快，但此類密碼系統也有下列的缺點： 

1. 由於用來加解密的金鑰為共用，所以在傳輸資料 前，須將金鑰以安全的方法交付到傳輸的雙方。 

2. 隨著約定傳輸人數的增長，所需要的金鑰也會越來 越多，相關的管理問題也將越發複雜。 

有鑑於上述對稱式密碼的缺點，而有非對稱式密碼系統的產生。 

非對稱式密碼系統（Asymmetric） 

有別於對稱式密碼，非對稱式密碼利用兩把金鑰來加解密文件（兩者為相互對應），金鑰如下所述： 

·Public Key（公開金鑰）：顧名思義，此把金鑰均 會公開（即可避免對稱式密碼須傳送金鑰的問題），提供所有人下載，每把公共金鑰（Public Key），均會有一個相對應的私鑰來完成資料加解密的流程。 

·Private Key（私鑰）：不公開，為個人所保管的金鑰（就如同現實環境中的個人私章的角色）。 

非對稱式密碼系統常用的使用流程，如圖3所示。傳送者利用公開金鑰（Public Key）來加密欲傳送的文件。待接收者接收到加密後的文件，再以相對應的私鑰（Private Key）來解開文件。 

▲圖3 非對稱式密碼系統使用流程。

非對稱式密碼對於上述所說明的機密性、完整性以及不可否認性的要求，就如同對稱式密碼系統分析一樣，在此就不多加贅述。非對稱式密碼系統雖然可解決對稱式密碼系統所面臨的困境，但其最大的問題在於運算非常緩慢，所以在實務上通常會與對稱式密碼系統交互使用。目前最常用的非對稱式密碼系統演算法即為RSA。 

在簡單的說明密碼系統後，接下來繼續說明用來驗證傳輸資料完整性的單向雜湊函數。 

單向雜湊函數簡介 

單向雜湊函數（Hash Function）是一組數學函式，其特性為不同的輸入即會產生不同輸出。此輸出又稱為訊息摘要（Message Digest），有點類似指紋的用途，而且不能由輸出反推得到輸入的資訊。其用法如下：

1. 傳送者在傳送資訊之前，先以單向雜湊函數針對此 資訊產生訊息摘要，並將資訊及此訊息摘要傳給接收端。 

2. 接收端在取得資訊和訊息摘要後，以相同的單向雜 湊函數對資訊產生訊息摘要，並與所接收的訊息摘要做比對，如兩者的內容完全一致，就表示所傳送的資訊並未遭到更改，藉此來驗證資料的完整性。 

常用的單向雜湊函數演算法包括MD5（Message-Digest Algorithm 5）、SHA（Secure Hash Algorithm）、MAC（Message Authentication Code）、HMAC（Hash-based Message Authentication Code）等。 

在過去因受限於電腦硬體演算能力的限制，無法以暴力演算的方式來破解，但隨著硬體的進步，以SHA1演算法所加密的密碼已被證明有被破解的可能。於是，微軟率先宣佈將從2016年起停用採SHA1演算法的數位憑證，而接著Google也宣布跟進，如果連接到使用SHA1密碼演算法的SSL網站，除了會顯示警告訊息外，還會在瀏覽器（Chrome）的網址列上加上警示標誌。警示標誌的意義，可參考網址「https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1」的說明。 

簡單說明過密碼系統之後，接下來利用開源碼社群中的OpenSSL程式庫套件來實作密碼系統的運用。 

什麼是OpenSSL 

OpenSSL是一套開放原始碼的軟體安全程式庫，於1998年釋出第一版以來，經過多年的修正，至今已成為一套相當穩定的安全程式庫。

應用程式可以使用OpenSSL所提供的加解密函式進行安全通訊，避免相關資料被竊聽。一般來說，此套件可用在任何一種的網路服務，例如郵件伺服器、網站伺服器等等。而至今日，如果是使用開源碼的網站解決方案，其中的SSL安全網站伺服器絕大部分都是使用OpenSSL來實作完成。接著說明OpenSSL的使用（在此使用版本為1.0.1e），openssl語法如下： 




其中，[標準命令]用來設定密碼演算法，產生相關的金鑰。[參數]的部分，則依各個標準命令的不同，而有不同的參數，通常是用來設定金鑰的一些常用屬性。接下來，就以OpenSSL來實作其工作流程。 

對稱式密碼實作 

首先說明對稱式密碼實作，以DES加解密演算法為例，如圖4所示。 

▲圖4 對稱式密碼實作。

(1) 產生一個檔名為test.txt，內容為test的測試檔案。 

(2) 針對此檔以des演算法加密，其中參數-e為encrypt 加密，-in則指定要加密的檔案，並將加密後的密文儲存至檔名為crytest.txt檔案內。在過程中，要求使用者設定一組密碼用來解密，加密完成後，從「cat encrytest.txt」即可發現其內容已是加密過後的資訊。 

(3) 將以des演算法加密的檔案予以解密，並將解密後 的資料儲存至檔名為decrytest.txt的檔案內，同樣地，在解密過程中須輸入相同的密碼，才可解密。 

(4) 驗證解密之後的檔案內容，是否已經正常完整的 解密。 

非對稱式密碼實作 

再以OpenSSL實作非對稱式密碼，以RSA演算法為例，如圖5所示。 

▲圖5 非對稱式密碼實作。

(1) 以RSA演算法（參數為genrsa）產生一把長度為 2,048位元，檔名為private.pem的私鑰。 

(2) 利用此私鑰，產生一把相對應的公鑰（檔名為 public.pem），以「ls *.pem」查看，會產生兩個金鑰檔案。 

(3) 利用公鑰（-inkey public.pem）來對檔名為testrsa. txt的檔案加密（-encrypt）並將加密過後的檔案，儲存到檔名為encrytestrsa.txt。 

(4) 利用相對應的私鑰（-inkey public.pem）來對 encrytestrsa.txt加以解密（-decrypt），並將解密過後的檔案，放置於decrytestrsa.txt，最後再利用「cat decrytestrsa.txt」查看是否已正常的解密。 

介紹完以OpenSSL實作密碼系統後，可以知道運用密碼系統能夠保證資料傳輸時的機密性和完整性要求。但對於驗證商家身分卻無能為力，也因此而有PKI（Public Key Infrastructure，公開金鑰基礎建設）機制來解決驗證身分的問題。在PKI驗證成功後，就會發給伺服器一個證明身分的數位憑證來證明伺服器的身分。 

什麼是PKI（公開金鑰基礎建設） 

首先說明SSL網站的運作過程，如圖6所示，相關流程說明如下： 

▲圖6 SSL網站的運作流程。

(1) 使用者端送出Client Hello訊息，將瀏覽器所支援 的SSL版本、加密演算法等相關資訊發送給SSL網站伺服器。 

(2) SSL伺服器收到Client Hello訊息後，確定本次通 訊採用的SSL版本和加密套件後，利用Server Hello訊息將SSL伺服器上的數位憑證的資訊回覆給瀏覽器。在此階段中會驗證數位憑證上相關資訊，例如數位憑證的有效期限、是否為公正的第三方所簽署。此時瀏覽器會驗證數位憑證是否安全，一旦發現有疑慮，就會警示使用者，如圖7所示為連結到自行簽署數位憑證的網站所產生的警示畫面。 

▲圖7 連結到自行簽署數位憑證的網站所產生的警示畫面。

(3) 在確認數位憑證後，瀏覽器至公開地方取得SSL 網站伺服器公開公鑰（Public Key），並利用此公鑰加密本次連線所要使用的金鑰（稱為Session Key）。 

(4) 最後，SSL網站伺服器端取得加密過後的Session Key後，即以本身的網站伺服器私鑰（Private Key）來解密，並取得相關的Session Key後，接下來雙方的通訊即利用此Session Key進行加解密。 

而在上述流程中，僅是利用OpenSSL程式庫來實現資料傳輸的加解密功能以確保資料的安全。但在現實運用上，還會遇到下列的問題： 

1. 數位憑證是代表網站伺服器的身分，因此在申請時 需要一套機制來確認申請者的真實身分，並在確認完後再發給相關數位憑證。 

2. 數位憑證該如何管理？可能會有廢止、過期等相關 管理問題。 

PKI的出現就是為了解決上述的問題，簡而言之，PKI就是一套維護數位憑證的機制（這有點像是現實生活中的戶政單位），整體架構圖如圖8所示。 

▲圖8 公開金鑰基礎建設（PKI）運作流程。

其中，RA（Registration Authority，註冊中心）主要目的在於認證申請者的身分，就如同在現實生活中，有些銀行業務需要臨櫃申請（行員會審核是否為本人），在確認身分之後，即會產生該申請者所屬的公鑰和相對應的私鑰，私鑰須由申請者自行妥善保管。 

接著，RA會產生一組憑證請求檔（C.S.R）連同申請者的公鑰送往憑證管理中心（Certificate Authority，CA），在CA確認完成後，即會簽署數位憑證（憑證格式為X.509），並且將相關的憑證送往目錄服務（以下簡稱DS）系統管理。接下來，說明數位憑證所使用的格式X.509。


X.509簡介 

X.509最早起始於1998年，由國際電信聯盟（ITU-T）制定的一種數位憑證標準，如圖9所示，其架構分為三層。 

▲圖9 X.509架構示意圖。

由上述之授權中心負責憑證的簽發與驗證。基本上，目前的瀏覽器均會內建主要的憑證授權中心（CA），圖10所示為Chrome瀏覽器所內建憑證管理中心的資訊，一旦使用者需要相關驗證時（如HTTPS連線），就會利用所內建的憑證授權中心來驗證金鑰是否經過簽署。 

▲圖10 Chrome瀏覽器內建的憑證管理中心。

X.509憑證內容主要是說明簽章演算法、有效日期、簽署的CA等等資訊，常用欄位如圖11所示。 

▲圖11 X.509憑證常用欄位。

介紹過數位憑證相關的背景知識後，最後將以OpenSSL程式庫為例來實際簽發符合目前主流瀏覽器安全規範的數位憑證。 

安裝自行簽發數位憑證的SSL網站 

如果要為自己的伺服器申請一張數位憑證，在實際的運作中必須經下列步驟： 

1. 申請者必須先產生私鑰。 

2. 向RA申請。在審核相關資訊，確認身分後，就 會產生憑證需求檔（C.S.R）並向CA請求簽發數位憑證。 

3. CA在驗證過後即簽發數位憑證，並將相關資訊送 往DS管理。 

在本文中將以自行簽發的方式來取得數位憑證，因此執行如下指令（其中#部分為註解）： 




在產生數位憑證後，基本上只要更改httpd-ssl.conf即可，須更改下列選項，亦即指定憑證與金鑰的位置，然後重新啟動Apache即可： 




使用自行簽署的數位憑證，並未經過公正的第三方單位驗證，所以瀏覽器在瀏覽此類SSL網站時，將會觸發警告訊息，如果要避免此類訊息，可利用Let's Encrypt套件來免費取得有效的數位憑證。 

安裝Let's Encrypt 

Let's Encrypt是一個由ISRG（Internet Security Research Group）組織所維護管理的數位認證機構，其主要目的在於為網站伺服器提供免費的數位憑證。目前的政策是所簽發的證書一次有效期為3個月（可使用延期的方式持續使用）。 

▲圖12 安裝Let’s Encrypt。

Let's Encrypt安裝方式如圖12所示，首先執行「git clone https://github.com/letsencrypt/letsencrypt」命令取得套件。接著，使用「letsencrypt-auto」命令來更新letsencrypt相關套件。然後以「letsencrypt-auto certonly --webroot -w /usr/local/apache2/htdocs/ -d test.7995.tw」命令產生相關的數位憑證，相關參數說明如下： 

webroot：使用webroot的方式作驗證，可不須停止目 前運作中的網站伺服器服務。

-w：設定網站根目錄的位置

-d：欲申請憑證的網域名稱 

成功執行指令後，即產生如圖13所示的數位憑證。 

▲圖13 產生數位憑證。

以同樣的設定方式設定httpd-ssl.conf，指定相關憑證的所在位置即可，設定內容如下： 




重啟網站伺服器後，再以瀏覽器測試，就不會出現如自行簽署數位憑證的警告訊息。如果有興趣，可利用瀏覽器來查看數位憑證的內容，如圖14所示。 

▲圖14 查看數位憑證的內容。

實作至此，一個完整SSL網站就建構完成了！ 

＜本文作者：吳惠麟，多年資安經驗，喜好利用開源碼建構相關解決方案，著有「資訊安全原理與實驗」等書。＞