【導讀】此前，測試小伙伴通過工具掃描，平臺TLS SSL協議支持TLS v1.1，這不安全，TLS SSL協議至少是v1.2以上才行，想到我們早已將其協議僅支持v1.3，那應該非我們平臺問題。

近日，第三方合作伙伴再次提到該高危安全問題，我依然自信的解釋，與我們平臺無關，應與openssl自身配置支持v1.1有關，但此問題必須得到解決，抱著半信半疑的態度，難道是代碼問題？于是乎，開始探索之路，本文以ASP.NET Core 3.1.20作為示例

驗證TLS SSL協議問題

由于平臺相關配置啟用太多，以排除帶來的影響，我單獨寫了一個干凈的web api，代碼如下。

webBuilder.UseStartup<Startup>(); webBuilder.UseKestrel(options?=>? {var?sslCertPath?=?Path.Combine(AppContext.BaseDirectory,?"ssl.pfx");options.Listen(IPAddress.Any,?5000,listenOption?=>{listenOption.UseHttps(sslCertPath,?"KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");});options.ConfigureHttpsDefaults(co?=>{co.SslProtocols?=?SslProtocols.Tls13;});});

然后我們將其發布到linux上并運行起來，如下：

接下來我們借助nmap工具掃描該端口，如下：

耐心等待一會，最終掃描輸出結果如下，我驚呆了

.NET Core TLS SSL協議默認啟用的是支持v1.1和v1.2，明明設置的是僅支持v1.3，這不是和沒設置一樣嗎？

webBuilder.UseStartup<Startup>(); webBuilder.UseKestrel(options?=>? {var?sslCertPath?=?Path.Combine(AppContext.BaseDirectory,?"ssl.pfx");options.ConfigureHttpsDefaults(co?=>{co.SslProtocols?=?SslProtocols.Tls12;});options.Listen(IPAddress.Any,?5000,listenOption?=>{listenOption.UseHttps(sslCertPath,?"KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");});});

那只能說明代碼有問題，既然已經設置了，但是未生效，so，那說明放的順序有問題，那我將上述設置協議放在監聽HTTPS之前又會如何呢？如上，首先我們配置僅支持v1.2，會不會掃描出v1.1呢？

看來猜測的不錯，和配置順序有關系，v1.1協議已不支持，同理，對于配置v1.3輸出結果如下

至此，TLS SSL協議指定已經得到了解決，稍加思索，想想也正常，監聽端口之前，必須建立連接，所以協議配置肯定在監聽端口之前指定

講到這里，我們進一步稍加了解原理，對于協議和端口監聽整個過程大概是怎樣的

我們首先看看通過指定SSL證書路徑和密碼監聽HTTPS內置的大致實現

監聽HTTPS存在多個重載，看來都是通過X509Certificate2來加載證書、驗證證書等等操作

內置賦值上述類加載證書，然后在如下擴展方法中應用各個選項，如下標注即為引用進行連接的選項

由于我們在開始時將SSL v1.3協議配置在監聽HTTPS下面，所以執行到這里時，使用的默認協議1.1和1.2

同時需要注意一點的是：在.NET Core 3.x版本中，證書密碼必須提供，但此種情況我通過查看源碼，若沒記錯的話，應該是5.x中，證書密碼可以為空

?????????其實在監聽HTTPS擴展方法中提供了所使用連接TLS SSL協議的重載，當時配置時沒想那么多，因為此前配置已經寫好，平臺根據實際情況可開啟HTTP或HTTPS，所以直接調用默認HTTPS選項配置，結果大意了?????????

當然若明確必須是HTTPS協議，我們也可以基于默認配置去修改，如下：

webBuilder.UseStartup<Startup>(); webBuilder.UseKestrel(options?=> {var?sslCertPath?=?Path.Combine(AppContext.BaseDirectory,?"ssl.pfx");options.ConfigureHttpsDefaults(co?=>{co.SslProtocols?=?SslProtocols.Tls13;co.ServerCertificate?=?new?X509Certificate2(sslCertPath,?"KSnRJkGPf@OVA8uDsY*D5EP4kd!AagLS84uNS~5@@u#dKrNxHC");});options.Listen(IPAddress.Any,?5000);});

沒啥可總結的，大意失荊州，一度懷疑配置了v1.3，但工具掃描卻支持1.1和1.2，認為問題出在openssl配置支持的問題，未曾想一時疏忽，一頓操作，沒考慮建立連接過程，則對應配置順序也應一致，.NET Core提供多種配置，然鵝我卻剛好卡在中間，自己鉆了自己的空子

????后面多學習，開始多寫寫.NET Core在Linux上的部署、操作等等之類的，好了，我們下次再見????

總結

以上是生活随笔為你收集整理的.NET Core TLS 协议指定被我钻了空子~~~的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。