SSL

一直沒有真正研究過SSL，不知道下面的理解是否正確。

SSL是Secure Sockets Layer的縮寫，它用來保護(hù)服務(wù)器和客戶端之前的通信。它是基于信任+加密的概念。

在介紹SSL的原理之前，首先介紹一下加密（Encryption）的概念。

?

在很多的應(yīng)用/API里，最常見的一種加密的方式是對稱加密（Symmetric Encryption）。

對稱加密的原理是這樣的：比如說甲方想要發(fā)送一些數(shù)據(jù)給某個(gè)調(diào)用者（乙方），乙方可能在某個(gè)進(jìn)程或客戶端服務(wù)器里，或者是跨越網(wǎng)絡(luò)的。總之是兩方通信。而甲方發(fā)送加密的數(shù)據(jù)需要一些加密的方法，這個(gè)加密方法雙方必須都知道（例如AES），此外還需要一個(gè)secret，它是一個(gè)任意的字符串，加密方法需要使用secret來進(jìn)行加密。使用這樣的加密方法把數(shù)據(jù)加密，然后加密的數(shù)據(jù)就會(huì)被發(fā)給乙方。乙方在接受這個(gè)加密后的數(shù)據(jù)之后，需要同樣的加密方法和同樣的secret來進(jìn)行解密。所以對稱加密的弱點(diǎn)也就在這，這個(gè)secret需要在雙方共享。

?

而對于SSL來說，它還可以使用第二種加密方式：非對稱加密（Asymetric Encryption）。

非對稱加密的原理是這樣的，它也需要加密方法來對數(shù)據(jù)進(jìn)行加密，但加密的時(shí)候使用的是public key

，這個(gè)public key是從乙方那里獲得的；它實(shí)際就是一個(gè)secret，但是這個(gè)secret并沒有被保護(hù)，所以乙方并不擔(dān)心甲方或其他方使用它來進(jìn)行解密，因?yàn)閜ublic key不可以用來解密，它只能用來進(jìn)行加密。而當(dāng)乙方接收到加密數(shù)據(jù)之后，它使用private key來進(jìn)行解密，這個(gè)private key是保密的，別人不知道的，這樣乙方就可以得到解密后的數(shù)據(jù)。

所以非對稱加密的優(yōu)勢還是很明顯的。

?

SSL使用這兩種加密方式。

當(dāng)客戶端和（Web）服務(wù)器使用SSL進(jìn)行通信前會(huì)有一個(gè)SSL握手的操作，用戶是不會(huì)察覺這個(gè)動(dòng)作的，它發(fā)生在真正調(diào)用API之前。

當(dāng)客戶端開始請求（https）后，服務(wù)器首先返回的是證書。

證書里面包含了很多的信息，這些信息首先就可以用來對證書本身進(jìn)行信任確認(rèn)。證書里包含了一些承諾：包括這個(gè)證書來自受信任的源。例如你使用SSL請求Microsoft.com，那么返回的證書就會(huì)對你承諾：“這個(gè)服務(wù)器是被微軟所擁有的”等。證書還會(huì)包含著“誰可以保證這些信息的真實(shí)性”的信息。這里還有一個(gè)證書頒發(fā)機(jī)構(gòu)（Certificate Authority，CA）的列表，這些機(jī)構(gòu)是我不得不信任的，證書頒發(fā)機(jī)構(gòu)可以保證這些信息等真實(shí)性。這里的證書就是由這些機(jī)構(gòu)來簽發(fā)的。通常瀏覽器都會(huì)加載這些知名證書頒發(fā)機(jī)構(gòu)的根證書。這些機(jī)構(gòu)維護(hù)著一個(gè)所有已簽名證書的列表和已經(jīng)被吊銷的證書的列表。未簽名的證書是不安全的，已簽名的證書是不可以被修改的。自己簽名的證書叫自簽名證書。所有的根證書頒發(fā)機(jī)構(gòu)的證書都是自簽名的。

服務(wù)器返回證書的同時(shí)還返回了一個(gè)public key，瀏覽器根據(jù)信任的CA來檢查證書是否仍然有效并且和該網(wǎng)站仍然關(guān)聯(lián)。

如果瀏覽器最終信任了這個(gè)證書，那么它會(huì)使用這個(gè)public key來生成加密一個(gè)隨機(jī)的對稱加密key并把它使用加密的URL和HTTP數(shù)據(jù)一同送回到服務(wù)器。

服務(wù)器通過它的private key來對這個(gè)對稱的加密key進(jìn)行解密，隨后用解密出來的對稱key來解密URL和HTTP數(shù)據(jù)。然后服務(wù)器會(huì)使用這個(gè)對稱加密key發(fā)出一個(gè)加密確認(rèn)，接下來加密的對話就可以開始了，后續(xù)的通信都是使用這個(gè)對稱key。

那么為什么整個(gè)通信不都使用非對稱加密呢？因?yàn)樗容^消耗資源。所以非對稱加密只用在SSL握手階段來創(chuàng)建一個(gè)后續(xù)對話的對稱加密key，后續(xù)的通信都是使用這個(gè)對稱key來加密傳輸?shù)臄?shù)據(jù)。

?

在ASP.NET Core中啟用HTTPS?

HTTPS (也叫做 HTTP over TLS, HTTP over SSL, and HTTP Secure)，它的傳輸協(xié)議使用TLS（SSL）加密。

下面都是官方文檔的內(nèi)容。

官方建議ASP.NET Core應(yīng)用使用HTTPS重定向中間件來把所有的HTTP請求都重定向到HTTPS上。

而實(shí)際上，ASP.NET Core 2.1的webapi模版里已經(jīng)這樣做了：

此外還可以在ConfigureServices方法里配置該中間件：

這里把返回到狀態(tài)碼設(shè)為307，這其實(shí)是默認(rèn)值。而生產(chǎn)環(huán)境應(yīng)該調(diào)用 UseHsts方法。

然后把Https的端口設(shè)置為5001，默認(rèn)值是443。

?

注意：需要同時(shí)監(jiān)聽http和https的端口。

?

運(yùn)行程序，使用POSTMAN發(fā)出一個(gè)GET請求到ValuesController：

沒有返回任何響應(yīng)，這是因?yàn)镻OSTMAN到設(shè)置問題。請按照下圖修改POSTMAN到配置：

把SSL certificate verification一項(xiàng)設(shè)置成 OFF。

然后再發(fā)送GET請求就OK了：

?

這里面有一個(gè)重定向到過程，我們改一下POSTMAN到設(shè)置來看一下這個(gè)過程：

把Automatically follow redirects改為OFF。

然后發(fā)送HTTP的請求：

它返回的body是空的，Header里面有重定向的地址，狀態(tài)碼是307，也就是我之前配置的。

然后我再發(fā)送請求到Header里L(fēng)ocation到這個(gè)地址就會(huì)得到想要到結(jié)果，我就不貼圖了。

?

下面是我的關(guān)于ASP.NET Core Web API相關(guān)技術(shù)的公眾號--草根專欄:

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Core Web API 与 SSL的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。