中間人攻擊(MITM)與SSL-Pinning

隨著資安議題逐漸受到重視，許多相關技術及規定相繼出現。
從HTTP未使用加密協定，至HTTPS加入了SSL、TLS等等憑證規則。然而，上有對策下有對策，仍然有許多攻擊的方式存在，其中一種就是「中間人攻擊」(Man-In-The-Middle attack)。

首先說說密碼學基礎中的基礎。（實際上資料都是以二進制紀錄，但為了方便理解，用十進制說明吧。）
資料產生時，都是轉換成數字記錄下來。換句話說，這些數字其實都代表著資料。例如十進制Unicode中「66」代表「a」，「67」代表「b」，「68」代表「c」，以此類推。
附上對照表：

十進制Unicode對照表

假設我今天表示：我的加密規則是「f(x)=x+1」。而我的原始訊息如果是「ab cd」，那麼加密後則會變成「bc de」。
反之，如果對方收到我已加密的訊息為「xy z」，那麼就能猜出原始訊息為「wx y」。

舉個例子：我想向我喜歡的人 — 甄甄表白，但我怕被別人發現我的告白信，於是我先告訴甄甄「我的加密規則是「f(x)=x+1」」。然後再寄告白信給她，信中寫下「j mpwf zpv」。乍看之下跟沒人看得懂，但只要她只要依照規則來反向計算（解密），就可以得到「i love you」了。

再來看看中間人攻擊。

附上幾篇講解較簡單明瞭的：

有关ssl-pinning的总结

wiki舉例也蠻有趣的：

中间人攻击

主要就是偽造憑證來騙取信任，取得稍後通信的非對稱加密技術的金鑰，成功後就可以竊取看到通信資料，甚至竄改。

好啦，反正就是一種攻擊方式。
那麼為了防範這種中間人攻擊，SSL Pinning是可以有效地達到目的（但不是完全解決，一樣那句，上有政策下有對策，第一篇參考資料也有提到）。

SSL Pinning，在client端存放server端的憑證，一模一樣的。如此一來，當server回覆憑證時，就可以詳細一一比對，防止接收到的憑證是被偽造的。

但是未來憑證可能會更新，若要更新，client存放的憑證也必須要更換，才能保持之後的通信成功。

在iOS App內，當我們使用WKWebView來開啟網頁時，勢必會向server發請求，並進行後續互動。這時若要避免中間人攻擊，即可使用SSL Pinning。

以google為例：

先到google取得憑證。

這裡可以直接拖拉下來，並直接拉入專案中。而專案中可以使用：

func webView(_ webView: WKWebView, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void)

當web view需要回應server的驗證時會觸發。

此時，只要造訪www.google.com，就會進入func內的流程進行驗證。若專案內沒有他的憑證，就無法進行後續的互動了。

註：這樣的寫法是，造訪www.google.com時需要憑證，但造訪其他網頁時都不需要，可以直接連線成功。

這就是SSL Pinning。

即便不是使用web view，單純使用URLSession時，也可以用SSL Pinning方式驗證，方法極為相似，附上參考資料：

SSL Pinning in Swift(iOS)

最後再附上官方相關講解：

Performing Manual Server Trust Authentication

Handling an Authentication Challenge

我不是資安高手，只是這幾天稍有收穫就分享出來，如有錯誤還請不吝指正我，謝謝。

如果你喜歡我的文章，請幫我clap幾下，我會很感謝的，謝謝。