Lab Overview
公鑰加密是當今安全通信的基礎，但當通信的一方向另一方發送其公鑰時，它會受到中間人的攻擊。根本的問題是，沒有簡單的方法來驗證公鑰的所有權，即，給定公鑰及其聲明的所有者信息，如何確保該公鑰確實屬於聲明的所有者?公鑰基礎設施(PKI)是解決這一問題的一種切實可行的方法。
通過這個實驗，我們應該能夠更好地了解PKI是如何工作的，PKI是如何用來保護網絡，以及PKI如何打敗中間人攻擊。此外，我們將能夠了解在公鑰基礎設施中信任的根源，以及如果這種根源信任被破壞會出現什麼問題。本實驗所涵蓋的主題如下:
• Public-key encryption
• Public-Key Infrastructure (PKI)
• Certificate Authority (CA) and root CA
• X.509 certificate and self-signed certificate
• Apache, HTTP, and HTTPS
• Man-in-the-middle attacks
Lab Environment
這個實驗在我kali VM和Ubuntu 16.04 VM上進行了測試.在這個實驗中，我們將使用openssl命令和庫。
Lab Tasks
Task1: Becoming a Certificate Authority(CA)
證書頒發機構(CA)是發布数字證書的受信任實體。数字證書通過證書的命名主體來驗證公鑰的所有權。一些商業性的CAs被視為根類CAs;在撰寫本文時，VeriSign是最大的CA。想要獲得商業核證機關發出的数字證書的用戶需要向這些核證機關支付費用。
在這個實驗室，我們需要創建数字證書，但是我們不會支付任何商業CA，我們自己會成為一個根CA，然後用這個CA為其他人(比如服務器)頒發證書。在這個任務中，我們將使自己成為一個根CA，併為這個CA生成一個證書。RootCA的認證通常預裝在大多數操作系統、web瀏覽器和其他依賴於PKI的軟件中。根CA的證書是無條件信任的。
The Configuration File openssl.conf
為了使用OpenSSL創建證書，必須有一個配置文件。配置文件通常有一個extension.cnf。它由三個OpenSSL命令使用:ca、req和x509。可以使用谷歌搜索找到openssl.conf的手冊頁。還可以從/usr/lib/ssl/openssl.cnf獲得配置文件的副本。將此文件複製到當前目錄后，需要按照配置文件中指定的方式創建子目錄(查看[CA default]部分):
對於index.txt文件，只需創建一個空文件。對於serial文件，在文件中放入一個字符串格式的数字(例如1000)。設置好配置文件openssl.cnf之後，就可以創建和頒發證書了。
CertificateAuthority(CA).
如前所述，我們需要為我們的CA生成一個自簽名證書，這意味着這個CA是完全可信的，它的證書將作為根證書。運行以下命令為CA生成自簽名證書:
系統將提示您輸入信息和密碼。不要丟失此密碼，因為每次要使用此CA為其他人簽名證書時，都必須鍵入口令。您還將被要求填寫一些信息，如國家名稱、常用名稱等。該命令的輸出存儲在兩個文件中:ca.key和ca.crt。文件CA .key包含CA的私鑰，而CA .crt包含公鑰證書。
Task2: Creating a Certificate for SEEDPKILab2018.com
現在，我們成為一個根CA，我們準備為我們的客戶簽署数字證書。我們的第一個客戶是一家名為SEEDPKILab2018.com的公司。該公司要從CA獲得数字證書，需要經過三個步驟。
Step 1: Generate public/private key pair 。公司需要首先創建自己的公鑰/私鑰對。可以運行以下命令來生成RSA密鑰對(私有和公共密鑰)。您還需要提供一個密碼來加密私鑰(使用AES-128加密算法，在命令選項中指定)。密鑰將存儲在文件服務器中。
server.key是一個編碼的文本文件(也是加密的)，因此無法看到實際內容，例如模數、私有指數等。要查看這些，可以運行以下命令:
Step 2: Generate a Certificate Signing Request (CSR). 一旦公司擁有了密鑰文件，它應該生成一個證書籤名請求(CSR)，它基本上包括公司的公鑰。CSR將被發送到CA, CA將為密鑰生成證書(通常在確保CSR中的身份信息與服務器的真實身份匹配之後)。使用SEEDPKILab2018.com作為證書請求的通用名稱。
需要注意的是，上面的命令與我們為CA創建自簽名證書時使用的命令非常相似，唯一的區別是使用了-x509選項。沒有它，命令生成一個請求;使用它，該命令生成一個自簽名證書。
Step 3: Generating Certificates . CSR文件需要有CA的簽名才能形成證書。在現實世界中，CSR文件通常被發送到受信任的CA進行簽名。在這個實驗中，我們將使用我們自己的可信CA來生成證書。以下命令使用CA的CA .crt和CA .key將證書籤名請求(server.csr)轉換為X509證書(server.crt):
如果OpenSSL拒絕生成證書，您請求中的名稱很可能與ca的名稱不匹配。匹配規則在配置文件中指定(查看[policy match]部分)。您可以更改請求的名稱以符合策略，也可以更改策略。配置文件還包括另一個限制較少的策略(稱為任何策略)。您可以通過更改以下行來選擇該策略:
“policy = policy_match” change to “policy = policy_anything”.
Task3: Deploying Certificate in an HTTPS Web Server
在這個實驗中，我們將探索網站如何使用公鑰證書來保護web瀏覽。我們將使用openssl的內置web服務器建立一個HTTPS網站。
Step1: Configuring DNS .我們選擇SEEDPKILab2018.com作為我們的網站名稱。為了讓我們的計算機識別這個名稱，讓我們將下面的條目添加到/etc/hosts;這個條目基本上將主機名SEEDPKILab2018.com映射到本地主機(即127.0.0.1):
Step 2: Configuring the web server. 讓我們使用在上一個任務中生成的證書啟動一個簡單的web服務器。OpenSSL允許我們使用s_server命令啟動一個簡單的web服務器:
默認情況下，服務器將監聽端口4433。您可以使用-accept選項進行更改。現在，您可以使用以下URL訪問服務器:https://SEEDPKILab2018.com:4433/。最有可能的是，您將從瀏覽器中得到一條錯誤消息。在Firefox中，您將看到如下消息:“seedpkilab2018.com:4433使用了無效的安全證書。該證書不受信任，因為發布者證書未知”.
Step3: Getting the browser to accept our CA certificate. 如果我們的證書是由VeriSign分配的，就不會出現這樣的錯誤消息，因為VeriSign的證書很可能已經預加載到Firefox的證書存儲庫中了。很遺憾，SEEDPKILab2018.com的證書是由我們自己的CA，並且Firefox無法識別此CA。有兩種方法可以讓Firefox接受CA的自簽名證書。
- 我們可以請求Mozilla將我們的CA證書包含在Firefox軟件中，這樣每個使用Firefox的人都可以識別我們的CA。不幸的是，我們自己的CA沒有足夠大的市場讓Mozilla包含我們的證書，所以我們不會追求這個方向。
- 加載CA .crt到Firefox中:我們可以手動添加我們的CA證書到Firefox瀏覽器通過點擊下面的菜單序列:
Edit -> Preference -> Privacy & Security -> View Certificates
您將看到一個已經被Firefox接受的證書列表。從這裏，我們可以“導入”我們自己的證書。請導入CA .crt，並選擇以下選項:“信任此CA識別網站”。您將看到我們的CA證書現在位於Firefox接受的證書列表中。
Step4. Testing our HTTPS website . 現在，將瀏覽器指向https://SEEDPKILab2018.com: 4433，可以正常訪問
Task4: Deploying Certificate in an Apache-Based HTTPS Website
使用openssl的s_server命令設置HTTPS服務器主要用於調試和演示目的。在這個實驗中，我們基於Apache建立了一個真正的HTTPS web服務器。Apache服務器(已經安裝在我們的VM中)支持HTTPS協議。要創建一個HTTPS網站，我們只需要配置Apache服務器，這樣它就知道從哪裡獲得私鑰和證書。
一個Apache服務器可以同時託管多個網站。它需要知道網站文件存儲的目錄。這是通過它的VirtualHost文件完成的，該文件位於/etc/apache2/sites-available目錄中。要添加一個HTTP網站，我們需要在文件000-default.conf中添加一個虛擬主機條目。而要添加一個HTTPS網站，我們則需要在同一個文件夾的default-ssl.conf文件中添加一個VirtualHost條目。
ServerName條目指定網站的名稱，而DocumentRoot條目指定網站文件存儲的位置。在設置中，我們需要告訴Apache服務器證書和私鑰存儲在哪裡。
修改了default-ssl.conf文件之後，我們需要運行一系列命令來啟用SSL。Apache將要求我們輸入用於加密私鑰的密碼。一旦一切都設置好了，我們就可以瀏覽網站了，瀏覽器和服務器之間的所有流量都被加密了。
Task5: Launching a Man-In-The-Middle Attack
在這個任務中，我們將展示PKI如何擊敗中間人(MITM)攻擊。下圖描述了MITM攻擊的工作原理。假設Alice想通過HTTPS協議訪問example.com。她需要從example.com服務器獲取公鑰;Alice將生成一個密鑰，並使用服務器的公鑰對該密鑰進行加密，然後將其發送到服務器。如果攻擊者可以攔截Alice和服務器之間的通信，則攻擊者可以用自己的公鑰替換服務器的公鑰。因此，Alice的秘密實際上是用攻擊者的公鑰加密的，因此攻擊者將能夠讀取秘密。攻擊者可以使用服務器的公鑰將密鑰轉發給服務器。秘密用於加密Alice和服務器之間的通信，因此攻擊者可以解密加密的通信。
Step 1: Setting up the malicious website. 在Task 4中，我們已經為SEEDPKILab2018.com建立了一個HTTPS網站。我們將使用相同的Apache服務器模擬example.com 。為此，我們將按照任務4中的指令向Apache的SSL配置文件添加一個VirtualHost條目:ServerName應該是example.com，但配置的其餘部分可以與任務4中使用的相同。我們的目標如下:當用戶試圖訪問example.com時，我們將讓用戶登陸我們的服務器，其中為example.com託管一個假網站。如果這是一個社交網站，虛假網站可以显示一個登錄頁面類似於目標網站。如果用戶不能分辨出兩者的區別，他們可能會在假網頁中輸入他們的帳戶憑據，本質上就是向攻擊者披露憑據。
Step2: Becoming the man in the middle 。有幾種方法可以讓用戶的HTTPS請求到達我們的web服務器。一種方法是攻擊路由，將用戶的HTTPS請求路由到我們的web服務器。另一種方法是攻擊DNS，當受害者的機器試圖找到目標網絡服務器的IP地址時，它會得到我們的網絡服務器的IP地址。在此任務中，我們使用“攻擊”DNS。我們只需修改受害者機器的/etc/hosts文件，以模擬DNS緩存設置攻擊的結果，而不是啟動實際的DNS緩存中毒攻擊。
Step3: Browse the target website 。一切都設置好了，現在訪問目標真實的網站。
可以看到，我們訪問到的是kali攻擊機的默認目錄。
訪問https服務的時候，由於kali攻擊機的證書不被信任，所以會有安全警告
Task6: Launching a Man-In-The-Middle Attack with a Compromised CA
設計一個實驗來證明攻擊者可以在任何HTTPS網站上成功發起MITM攻擊。可以使用在Task 5中創建的相同設置，但是這一次，需要演示MITM攻擊是成功的。即，當受害者試圖訪問一個網站而進入MITM攻擊者的假網站時，瀏覽器不會引起任何懷疑。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益
※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面
※南投搬家公司費用需注意的眉眉角角，別等搬了再說!
※教你寫出一流的銷售文案?
