目录
前言.NET Core Cipher(套件)配置密码学基础前言
前不久我发表了一篇关于TLS协议配置被我钻了空子，经过第三方合作伙伴验证，针对此TLS协议存在不安全套件，急催速速解决，那么我们本篇开始继续整活！第三方合作伙伴对平台安全严苛要求，我们已连续发版十几次进行处理，在此过程中使得我对安全有了进一步认识，具体认识则是在技术解决方案和密码学盲点两方面。下面我们来了解两个方面，可能没有完全深入，至少对作为开发者的我们而言，应已基本足够
.NET Core Cipher(套件)配置
如果没有项目上的苛刻要求，我断然也就无法在此方面展开研究和实践。本文具以.NET 5为例，只不过针对.NET Core 3或3.1通过工具扫描出的协议套件结果略有所差异，但不影响我们对安全套件的配置，我们使用OpenSSL生成自签名证书，后续我会发表文章讲解OpenSSL自签名证书等等
webBuilder.ConfigureKestrel(serverOptions =>{ serverOptions.Listen(IPAddress.Any, 8000, listenOptions => { listenOptions.UseHttps("ssl.pfx", "123456", adapterOptions => { adapterOptions.SslProtocols = SslProtocols.Tls12; }); });});HTTPS结合TLS 协议1.0或1.1不安全，所以TLS协议需使用1.2+，这里我们如上述代码使用版本1.2，接下来我们将其部署在linux上，然后安装nmap，通过nmap工具扫描（至于nmap是什么，可自行了解）
通过nmap扫描指定端口号并枚举其支持TLS 套件需要注意一点，我们可能搜罗出来大多数文章的命令结果一扫，压根没有结果，其实nmap只对指定端口扫描才有效(比如443等等)，比如使用如下命令无效果
nmap --script ssl-enum-ciphers localhost -p 8000
若是其他端口，可使用如下命令进行扫描
nmap --script +ssl-enum-ciphers localhost -p 8000
最终我们扫描出来的结果如下：
2，但在.NET 5默认协议变更为了1.3，其支持套件配置也与OpenSSL配置也有了一定关联。见链接《https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0》
当接触到某一知识点时(比如TLS)，我认为稍微看下更高版本对此方面是否有变更很有必要，假设我们不知道.NET 5+默认变更为了1.3，当进行版本升级过后，如果第三方对接此前使用的是TLS 1.2，那么数据对接就会断层，业务必将受影响。仅我个人建议，至于其他我就管不到了~~~基于上述所述，若是在Windows开发环境，势必要在对应基础上判断操作系统
if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX) || RuntimeInformation.IsOSPlatform(OSPlatform.Linux)){ ......}最终我们扫描结果如下，已将AES-CBC不安全套件给去除，完全满足安全要求
密码学基础
所使用RSA非对称加密算法，OpenSSL可指定加密方式
但当我指定aes128或其他位时，其模式其实是CBC而非GCM
最终查看是否支持GCM
openssl aes-256-gcm
其实OpenSSL支持GCM，只不过不能用过命令行来进行操作，具体原因官方有解释。分析了这么多，貌似没啥用，目前大致能确定的是：密码套件的支持还是需要浏览器和服务器来进行握手协商
比如在谷歌浏览器中就可设置是否启用TLS 1.3
到目前为止，我们大致知道了HTTPS所使用的是一组算法，握手期间用非对称加密算法，数据传输期间用对称加密算法！那么整个期间，猜测是结合生成的证书，然后遍历配置套件进行握手，握手成功后再进行数据传输
大致握手和数据传输过程，简单描述如下：
客户端向服务端发送消息，我使用TLS 1.2中的ECDHE-RSA-AES128-GCM-SHA256以及还有其他套件，你能处理吗？服务端向客户端回复消息，ECDHE-RSA-AES128-GCM-SHA256能处理，然后向客户端发出公钥证书。客户端向服务端回复消息，证书是合法的，客户端生成密钥6p7vUjFz紧接着使用服务端的公钥证书进行加密，通知服务端以后数据传输用指定的密钥即共享密钥
当自定义配置所支持套件时，需要额外注意一点的是，千万别同时指定TLS 1.2和TLS1.3
