一直沒有真正研究過SSL,不知道下面的理解是否正確。web
SSL是Secure Sockets Layer的縮寫,它用來保護服務器和客戶端以前的通訊。它是基於信任+加密的概念。api
在介紹SSL的原理以前,首先介紹一下加密(Encryption)的概念。瀏覽器
在不少的應用/API裏,最多見的一種加密的方式是對稱加密(Symmetric Encryption)。安全
對稱加密的原理是這樣的:好比說甲方想要發送一些數據給某個調用者(乙方),乙方可能在某個進程或客戶端服務器裏,或者是跨越網絡的。總之是兩方通訊。而甲方發送加密的數據須要一些加密的方法,這個加密方法雙方必須都知道(例如AES),此外還須要一個secret,它是一個任意的字符串,加密方法須要使用secret來進行加密。使用這樣的加密方法把數據加密,而後加密的數據就會被髮給乙方。乙方在接受這個加密後的數據以後,須要一樣的加密方法和一樣的secret來進行解密。因此對稱加密的弱點也就在這,這個secret須要在雙方共享。服務器
而對於SSL來講,它還可使用第二種加密方式:非對稱加密(Asymetric Encryption)。網絡
非對稱加密的原理是這樣的,它也須要加密方法來對數據進行加密,但加密的時候使用的是public key網站
,這個public key是從乙方那裏得到的;它實際就是一個secret,可是這個secret並無被保護,因此乙方並不擔憂甲方或其餘方使用它來進行解密,由於public key不能夠用來解密,它只能用來進行加密。而當乙方接收到加密數據以後,它使用private key來進行解密,這個private key是保密的,別人不知道的,這樣乙方就能夠獲得解密後的數據。加密
因此非對稱加密的優點仍是很明顯的。spa
SSL使用這兩種加密方式。3d
當客戶端和(Web)服務器使用SSL進行通訊前會有一個SSL握手的操做,用戶是不會察覺這個動做的,它發生在真正調用API以前。
當客戶端開始請求(https)後,服務器首先返回的是證書。
證書裏面包含了不少的信息,這些信息首先就能夠用來對證書自己進行信任確認。證書裏包含了一些承諾:包括這個證書來自受信任的源。例如你使用SSL請求Microsoft.com,那麼返回的證書就會對你承諾:「這個服務器是被微軟所擁有的」等。證書還會包含着「誰能夠保證這些信息的真實性」的信息。這裏還有一個證書頒發機構(Certificate Authority,CA)的列表,這些機構是我不得不信任的,證書頒發機構能夠保證這些信息等真實性。這裏的證書就是由這些機構來簽發的。一般瀏覽器都會加載這些知名證書頒發機構的根證書。這些機構維護着一個全部已簽名證書的列表和已經被吊銷的證書的列表。未簽名的證書是不安全的,已簽名的證書是不能夠被修改的。本身簽名的證書叫自簽名證書。全部的根證書頒發機構的證書都是自簽名的。
服務器返回證書的同時還返回了一個public key,瀏覽器根據信任的CA來檢查證書是否仍然有效而且和該網站仍然關聯。
若是瀏覽器最終信任了這個證書,那麼它會使用這個public key來生成加密一個隨機的對稱加密key並把它使用加密的URL和HTTP數據一同送回到服務器。
服務器經過它的private key來對這個對稱的加密key進行解密,隨後用解密出來的對稱key來解密URL和HTTP數據。而後服務器會使用這個對稱加密key發出一個加密確認,接下來加密的對話就能夠開始了,後續的通訊都是使用這個對稱key。
那麼爲何整個通訊不都使用非對稱加密呢?由於它比較消耗資源。因此非對稱加密只用在SSL握手階段來建立一個後續對話的對稱加密key,後續的通訊都是使用這個對稱key來加密傳輸的數據。
HTTPS (也叫作 HTTP over TLS, HTTP over SSL, and HTTP Secure),它的傳輸協議使用TLS(SSL)加密。
下面都是官方文檔的內容。
官方建議ASP.NET Core應用使用HTTPS重定向中間件來把全部的HTTP請求都重定向到HTTPS上。
而實際上,ASP.NET Core 2.1的webapi模版裏已經這樣作了:
此外還能夠在ConfigureServices方法裏配置該中間件:
這裏把返回到狀態碼設爲307,這實際上是默認值。而生產環境應該調用 UseHsts方法。
而後把Https的端口設置爲5001,默認值是443。
注意:須要同時監聽http和https的端口。
運行程序,使用POSTMAN發出一個GET請求到ValuesController:
沒有返回任何響應,這是由於POSTMAN到設置問題。請按照下圖修改POSTMAN到配置:
把SSL certificate verification一項設置成 OFF。
而後再發送GET請求就OK了:
這裏面有一個重定向到過程,咱們改一下POSTMAN到設置來看一下這個過程:
把Automatically follow redirects改成OFF。
而後發送HTTP的請求:
它返回的body是空的,Header裏面有重定向的地址,狀態碼是307,也就是我以前配置的。
而後我再發送請求到Header裏Location到這個地址就會獲得想要到結果,我就不貼圖了。