SSL

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

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

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

?

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

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

?

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

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

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

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

?

SSL使用這兩種加密方式。

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

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

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

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

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

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

那么為什么整個通信不都使用非對稱加密呢？因為它比較消耗資源。所以非對稱加密只用在SSL握手階段來創(chuàng)建一個后續(xù)對話的對稱加密key，后續(xù)的通信都是使用這個對稱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上。

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

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

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

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

?

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

?

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

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

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

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

?

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

把Automatically follow redirects改為OFF。

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

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

然后我再發(fā)送請求到Header里Location到這個地址就會得到想要到結(jié)果，我就不貼圖了。

?

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

總結(jié)

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

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