SSL

一直沒(méi)有真正研究過(guò)SSL，不知道下面的理解是否正確。

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

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

?

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

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

?

而對(duì)于SSL來(lái)說(shuō)，它還可以使用第二種加密方式：非對(duì)稱加密（Asymetric Encryption）。

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

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

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

?

SSL使用這兩種加密方式。

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

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

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

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

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

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

那么為什么整個(gè)通信不都使用非對(duì)稱加密呢？因?yàn)樗容^消耗資源。所以非對(duì)稱加密只用在SSL握手階段來(lái)創(chuàng)建一個(gè)后續(xù)對(duì)話的對(duì)稱加密key，后續(xù)的通信都是使用這個(gè)對(duì)稱key來(lái)加密傳輸?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重定向中間件來(lái)把所有的HTTP請(qǐng)求都重定向到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)聽(tīng)http和https的端口。

?

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

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

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

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

?

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

把Automatically follow redirects改為OFF。

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

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

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

?

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

總結(jié)

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

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