.NET Core如何配置TLS 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

最终我们扫描出来的结果如下:

AES-CBC模式在中SSL或者TLS中存在一些已知的安全漏洞,如BEAST攻击、Lucky 13攻击等,虽然TLS1.1、TLS1.2未受到BEAST攻击的影响、Lucky 13(影响涉及到TLS1.1/1.2)攻击也在Openssl等知名加密算法库得到了修复,但这些漏洞均暴漏出CBC模式在SSL/TLS协议实现时容易引入安全漏洞,HTTP/2中也明确将CBC模式加密套件列为黑名单

 

上述是在.NET 5 TLS 1.2默认行为,但第三方规定禁止使用AES-CBC即使扫描出来的套件强度为A,并给定了其支持的安全套件

 

在上述配置通过路径读取文件和使用密码启用HTTPS重载方法中,如下

public static ListenOptions UseHttps(this ListenOptions listenOptions, string fileName, string password, Action<HttpsConnectionAdapterOptions> configureOptions);

最后可针对连接做配置,在该类中有如下属性

public Action<ConnectionContext, SslServerAuthenticationOptions> OnAuthenticate { get; set; }

该输入第二个类参数里面,有针对套件的配置,如下(我也是结合github找了老半天才翻到)

所以最终我们配置支持的安全套件如下(诸多套件,闻所未闻,不打紧,下面会归纳总结):

webBuilder.ConfigureKestrel(serverOptions =>
{
  serverOptions.Listen(IPAddress.Any, 8000, listenOptions =>
  {
    listenOptions.UseHttps("ssl.pfx", "123456", adapterOptions =>
    {
      adapterOptions.SslProtocols = SslProtocols.Tls12;

      adapterOptions.OnAuthenticate = (connectionContext, authenticationOptions) =>
      {
        var ciphers = new List<TlsCipherSuite>()
        {
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_PSK_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_PSK_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_DHE_PSK_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
          TlsCipherSuite.TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256,
          TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256,
          TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384,
          TlsCipherSuite.TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256,
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_CCM,
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_CCM,
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_CCM_8,
          TlsCipherSuite.TLS_DHE_RSA_WITH_AES_256_CCM_8,
          TlsCipherSuite.TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256,
          TlsCipherSuite.TLS_PSK_WITH_AES_128_CCM,
          TlsCipherSuite.TLS_PSK_WITH_AES_256_CCM,
          TlsCipherSuite.TLS_DHE_PSK_WITH_AES_128_CCM,
          TlsCipherSuite.TLS_DHE_PSK_WITH_AES_256_CCM,
          TlsCipherSuite.TLS_PSK_WITH_AES_128_CCM_8,
          TlsCipherSuite.TLS_PSK_WITH_AES_256_CCM_8,
          TlsCipherSuite.TLS_PSK_DHE_WITH_AES_128_CCM_8,
          TlsCipherSuite.TLS_PSK_DHE_WITH_AES_256_CCM_8,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CCM,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_CCM,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8,
          TlsCipherSuite.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
        };

        authenticationOptions.EnabledSslProtocols = SslProtocols.Tls12;
        authenticationOptions.CipherSuitesPolicy = new CipherSuitesPolicy(ciphers);
      };
    });
  });
});

咳咳,到这里为止,我们满心欢喜,是不是就这样愉快结束了?接触到一个新的点时,一定一定要先看下解释,别一顿操作后不好使,耗费时间和劳力而全是无用功,最终才发现问题症结点所在,这也是我最近才有深刻体会

据我初步的了解应该是在.NET Core 3.0+才开始支持配置OpenSSL的套件,且版本必须是1.1.1+,但不支持Windows,仅支持Linux或OSX!同时在.NET Core 3.1以下版本默认协议是1.1或1.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不安全套件给去除,完全满足安全要求

 密码学基础

密码套件所用到的算法大致有四种:对称加密算法、非对称密钥交换算法、数字签名算法(DSA)、可选的基于散列的消息身份验证代码(HMAC)

说白了,密码学套件就是一组算法,开启HTTPS和TLS并协同使用密码学套件,才能使得传输更加安全

 

我们知道算法都是公开的,唯一不同的是算法依赖于密钥,只有对接双方知道,从而保护加密过后的密文而不能被窥探,那么接下来我们拆分讲解上述几种算法


非对称加密算法,说白了就是一方拥有公钥,另一方拥有私钥,它是浏览器和服务器开始时通过TLS握手时协商作为加密套件使用,至于HTTPS的其余部分可使用商定的密码套件进行使用

 

最初通过TLS握手时所使用的最主要的三种算法是:

 

DHE:Diffie-Hellman Ephemeral (密钥交换算法)

RSA:以其发明者Rivest-Shamir-Adleman的名字而命名

ECDHE:Elliptic-curve Diffie–Hellman(椭圆曲线交换:翻译而来)

 

对称算法,说白了就是双方都知道的单一密钥,相比较非对称加密算法而言,它的计算速度更快,但并不适用于作为Web证书,因为浏览器和服务器不知道也完全不信任彼此,因此无法共享密钥,然而,在进行初始握手协议之后,再使用对称加密算法非常合适即创建一个共享的密钥以在HTTPS通信的其他期间使用

 

最常见的四种对称加密算法是:

AES:Advanced Encryption Standard

AES-GCM:AES Galois/Counter

AES-CCM:AES Counter with CBC-MAC(密码块链接消息认证码)

ChaCha20:又名Salsa20

 

密码强度是一种安全度量,加密文本在遭受攻击时有多安全?算法的强度与密钥的长度相关,所以更长的密钥更强大,密钥长度表示为位数,常用的值为128 和 256,对称算法由它们的首字母缩略词和它们的密钥长度来标识,比如像 AES128 或 AES256。

 

说了这么一大堆,好像就了解到几个算法名称,要是脱离本文的内容确实仅在脑后留下些许印象,那么接下来我们结合配置的密码套件来进行实践理解,我们拿上述配置的第一个密码套件来进行阐述,其余同理,如下

 TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

上述TlsCipherSuite是一个枚举,我们仅看枚举内容,将TLS去掉剩余则是DHE_RSA_WITH_AES_128_GCM_SHA256

 

我们再结合上述阐述的非对称和对称加密算法将其拆分,则是DHE、RSA、AES-128-GCM

 

从最终拆分的结果来看,实际上HTTPS使用了一对算法而非单一算法,其中一种非对称加密DHE和RSA用于初始期间TLS握手,而另一种对称加密算法AES-128-GCM用于数据传输期间的加密和解密!如此一来对于HTTPS使用对称和非对称加密算法则形成多种组合

 

但简单地选择一对非对称/对称算法不足以完全识别密码套件,所以还需要指定用于确保身份验证和完整性的规则。比如通过LetsEncrypt证书机构来颁发证书。更深层次的密码学东东这里就不再展开了,我也就探究于此

 

.NET Core中配置的密码套件与OpenSSL所支持套件吻合,如下截图一部分:

那么问题来了,上述我们配置了多种套件,结果通过工具扫描时有三种被支持的套件被扫描出,浏览器和服务器初次进行TLS握手时,到底选择哪一种呢?那么我们接下来通过访问并查看Web证书能否找到蛛丝马迹,事先声明:以下部分内容为我个人推测,至于理论上是否如真如我所言未可知

通过查看证书反推,我们通过OpenSSL创建自签名证书所使用的是RSA加sha256算法,然后再看如下图可知所使用最终套件

结合这二者是不是就可以说明所使用的密码套件对应OpenSSL配置则是:ECDHE-RSA-AES128-GCM-SHA256,也就是对应通过nmap工具扫描出来支持的三种套件中的第一个

ECDHE-RSA-AES128-GCM-SHA256结论由上述证书和安全查看而言,因为是sha256RSA所以密码套件最后则是SHA256,果真是如此,我能否自圆其说?要是我们将SHA256套件删除,是不是页面就不支持,Web页面无法访问呢?

经过上述修改和通过nmap扫描出结果如下:

 

看来与证书上所言算法无关,最终回到我通过自创建证书命令

openssl genrsa -out ca-key.key 3072

只能匹配到所使用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和TLS 1.3

 

总结

啊,又到了总结的地方,貌似没啥可总结的,具体相关了解到的或体会到的已在文中有阐述,我们下节再会

posted @ 2021-12-05 00:27  Jeffcky  阅读(3699)  评论(9编辑  收藏  举报