[Burp Suite 完整教學] 不安全的連線？HTTPS與SSL憑證

介紹完了關於Proxy的部分之後，
讓我們先來解決上次提到的不安全的連線這個問題。

講完了Proxy，
大家應該都可以清楚明白Burp就是位於我們跟Server中間的服務。
不知道有沒有人發現我們似乎忽略了一個環節？就是HTTPS！

簡單的提一下，
目前網路上基本網站使用的協定都是HTTP或是HTTPS。
而HTTPS其實就是HTTP利用SSL/TLS加密過後的協定，
HTTPS的用途是利用加密來保護傳輸中數據的，
可以讓使用者與網站間傳遞的內容是透過SSL/TLS加密傳輸，
HTTP則是明文的傳輸協定，
如果利用譬如Wireshark的封包側錄工具來錄封包的話，
我們可以直接看到HTTP的內容都是明文，
而HTTPS(SSL/TLS)的內容則是經過加密，
如果沒有金鑰解密是沒辦法看出明文內容的。

為什麼要提到HTTPS呢?
開始繼續下面的內容之間，大家可以先想想一件事情，
當使用者與網站的內容是加密的時候 Burp是如何知道網站加密的內容的呢?

難不成是Burp天生神力，
已經精通破解各種加密演算法，
當然不是這樣的～

實際上的運作原理是這樣的，
使用者與Burp建立了一個加密的連線，
而Burp與網站建立了一個加密的連線。

所以實際過程並不是真的使用者跟網站間的通訊加密，
Burp不必從中間去想辦法去破解這個加密的訊息，
而是透過最一開始就對使用者假裝成server，
跟使用者之間建立了一道HTTPS加密的連線，
而既然是使用者與Burp建立的連線，Burp當然可以得到解密的請求內容。
取得使用者的明文請求之後呢，
再假裝成client與網站建立連線，將收到的請求送給server，
因為這個HTTPS的加密連線是Burp與網站建立的，
所以網站所傳回的回應，Burp當然也是可以得到解密的回應內容，
Burp再將這個得到的解密內容，回傳給使用者。

那我們使用Burp之後，可能會遇到下列的情形：

這個就稍微有點棘手了，
也就是我們今天要來談關於PKI(公開金鑰基礎建設)中的CA，
CA(憑證頒發機構)可以算是PKI的核心，
HTTPS也利用PKI的核心CA來完成連線中的信任機制。

談PKI之間我們先來簡單介紹對稱式加密與非對稱式加密，
首先我們來考慮一個情境分別描述兩種加密方法的差異，
假設今天Server丟給我們了一把鑰匙(也就是金鑰)，
然後要求我們把要傳給他的資料用這個金鑰給加密，
加密之後再傳給他，他那邊會想辦法解密開來看到我們傳的資料。

(1)對稱式加密
對稱式加密其實相當好理解，就是從頭到尾只有一把金鑰，
雙方利用這把金鑰來進行加密與解密。
所以Server會丟給我們一把金鑰，
我們利用這個金鑰去加密我們要傳給他的內容，
而Server收到我們的加密資料後，
就會用他手上的金鑰去解開這個加密資料，
看到裡面的明文內容。

(2)非對稱式加密(a.k.a.公開金鑰加密)
整個流程中會有兩把金鑰，
其中一個被稱為私鑰，只有server才會有的，
然後另一把被稱為公鑰，是所有人都可以知道的。
而非對稱式加密的重點就在於，
公鑰加密的內容，只有私鑰能作解密；
而同樣的，私鑰加密的內容，只有公鑰才可以解密。
所以server會丟給我們一把公鑰，
我們利用這個公鑰去加密我們要傳給他的內容，
而Server收到我們的加密資料後，
就會用他手上的公鑰去解開這個加密資料，
看到裡面的明文內容。

以上兩段話看起來很像對不對？
為什麼要搞得這麼大費周章呢，其實目的就在於防止中間人攻擊(MitM)，
因為我們對稱式加密只有一把金鑰，如果傳送這把金鑰的過程中被攻擊者給知道了，
然後攻擊者剛好在我們使用者與server之間攔截到加密的封包的話，
就可以利用這個金鑰去作解密，來進行竊聽或是竄改封包的惡意操作。
不過其實我們使用了非對稱式加密之後，
雖然私鑰不會被流傳在網路上，但是仍然有可能遭受到中間人攻擊，
為什麼呢？
假設今天server與使用者之間存在一個中間人攻擊者，
當server要傳公鑰A給使用者的時候，被中間人攔截了，
而中間人用自己產生的一對公私鑰B，把這個公鑰B傳給使用者，
而使用者拿到了這把公鑰B，其實也不知道這把公鑰其實並非server的，
當使用者把資料用公鑰B加密傳給了Server的時候，
中途又被攻擊者攔截了，並且將加密的內容用私鑰B解開，
看光光甚至是修改了裡面的內容之後呢，
再把這個內容用公鑰A給加密傳給Server，Server再用私鑰A解密。
以上的過程就是在非對稱式加密中發生的中間人攻擊。

所以為了避免這樣的事情發生！
又有了我們所謂的憑證，
我們來談談憑證中有甚麼東西吧，
憑證當中會有我們的公鑰、數位簽章、伺服器相關的資訊。

關於憑證與整個流程與相關內容，說起來有一匹布那麼長，
估計要再講個３０天都是完全沒有問題的，
為了不讓這個話題無限發散，讓我們來專注在數位簽章這個部分。
數位簽章就是公鑰密碼反過來使用的一種方法，
一般在非對稱密碼學中我們傳輸資料，都是利用公鑰加密，
然後利用私鑰解密，取得加密的機敏資訊，
因為公鑰是大家每個人都可以有的，但是私鑰是自己才會擁有的，
利用這樣的方式可以確保資料的機密性，
而何謂反過來使用呢？前面提到一點關於對稱式密碼學的重要事情，
公鑰加密的內容，只有私鑰能作解密；
而同樣的，私鑰加密的內容，只有公鑰才可以解密。

所以假設今天server傳了一個內容，
而這個內容是利用server自己的私鑰加密的，
內容是甚麼先不管不重要，
重要的是，這個內容只有server的公鑰才可以解開，
所以如果我們利用server的公鑰成功解開的話，
就可以確認這個內容是由server所發送的，
目的僅僅是在於確認內容是由這個server所發送的，
並沒有遭到其他人所偽裝。

如果大家以上都還聽得懂的話，
可能會懷疑，就算利用以上的數位簽章的方法，
也無法避免我們剛剛非對稱加密的中間人攻擊吧？
沒錯！因為剛剛過程中的使用者拿到的公鑰也是由中間人給的阿。
所以就有了CA(憑證頒發機構)，CA就是一個受到信任的第三方機構。
每一個瀏覽器的裡面都可以看到這些已經受到信任的CA，

這些都是已經預設就安裝好在你的電腦裡的CA。
那這些CA有甚麼用意呢?
假設今天一般的網站是希望他們自己伺服器是受到使用者所信任的話，
並且希望自己的網站能夠避免遭受到中間人攻擊的話呢，
網站就會將自己的公鑰、伺服器相關的資訊、
然後還有一串利用公鑰與伺服器相關資訊所產生的hash，
以上的內容交給第三方可信任的單位(CA)進行簽章，
CA會將那一串hash進行簽章(也就是利用私鑰將這段hash加密)，
這個簽章過後的內容也就被稱為數位簽章。

這樣當使用者與網站進行連線的時候，
網站就會把憑證傳給使用者，憑證裡面會包含甚麼呢？
憑證＝公鑰＋伺服器相關的資訊＋數位簽章
這時候瀏覽器會做一件事情，
會將公鑰＋伺服器相關的資訊進行hash，我們稱為hash A，
再利用CA來對數位簽章解密，得到hash B，
檢查hash A與hash B是否為一樣的，
如果是的話，就能確認這個憑證是我們所信任的憑證！

講到這邊我們就可以回頭來說我們為什麼使用Burp，
並且將瀏覽器Proxy設定掛到Burp之後，
瀏覽器會跳出紅色的驚嘆號了！
因為Burp攔截了server的內容之後，
是改用了自己的數位簽章，
但是我們瀏覽器並沒有信任Burp Suite的CA呀，
所以對瀏覽器來說，這張憑證是不受信任的，
也就是這個網站是不受信任的網站。

知道了整個來龍去脈，
我們也就知道了該怎麼解決這個問題！
解決的方法就是將PortSwigger CA這個憑證，
匯入到我們瀏覽器中受信任的根憑證就可以搞定了。
Burp也非常貼心的幫我們想得周到，
操作的流程相當簡單，
依照以下圖片的流程，
我們開啟Burp並且在chrome後，
輸入127.0.0.1:8080可以下載憑證，
開啟瀏覽器的設定，找到匯入根憑證的地方，
(這邊是以Chrome為例，但是其他的瀏覽器都差不多)
將剛剛下載的憑證給匯入到瀏覽器中。

完成之後呢，我們也可以再次確定PortSwigger憑證確實有在。

接著瀏覽網站(要更保險一點的作法，建議先關閉整個瀏覽器重開再試)，
可以發現網站都可以正常連線，不會出現您的連線不安全的紅色驚嘆號了，
我們的問題終於解決啦！
也可以點選左上角的鎖頭確認，
如果有經過Burp的話，其實簽發的單位會試PortSwigger CA，
同時這次因為我們有匯入CA的關係，所以成為了受信任的憑證。

這邊其實還有一個小小的坑，許多人可能不知道，
就是Burp的憑證，每次當你重新安裝的時候或是在不台電腦安裝時產生的憑證是不同的喔，
所以如果你重新安裝了burp，要記得將原本的CA憑證刪掉，重新匯入一個新的憑證。

今天關於憑證的部分就說到了這邊，
不過要小小跟大家說聲抱歉，
因為關於非對稱式加密，中間人攻擊，還有憑證、數位簽章這類型原理，
其實用圖來講解會比較清楚，但是實在是沒有時間好好畫圖(也是懶XD)，
關於更多公開金鑰密碼學(非對稱式加密)、中間人攻擊(MitM)、憑證與數位簽章的內容，
大家如果想知道得更詳細，也可以找找網路上有很多介紹很詳細的文章喔！

本系列的文章為作者參與第 12 屆 iT 邦幫忙鐵人賽的文章修改
原文連結 https://ithelp.ithome.com.tw/users/20114110/ironman/3806