前言

前不久我發(fā)表了一篇關(guān)于TLS協(xié)議配置被我鉆了空子，經(jīng)過(guò)第三方合作伙伴驗(yàn)證，針對(duì)此TLS協(xié)議存在不安全套件，急催速速解決，那么我們本篇開始繼續(xù)整活！第三方合作伙伴對(duì)平臺(tái)安全嚴(yán)苛要求，我們已連續(xù)發(fā)版十幾次進(jìn)行處理，在此過(guò)程中使得我對(duì)安全有了進(jìn)一步認(rèn)識(shí)，具體認(rèn)識(shí)則是在技術(shù)解決方案和密碼學(xué)盲點(diǎn)兩方面。下面我們來(lái)了解兩個(gè)方面，可能沒有完全深入，至少對(duì)作為開發(fā)者的我們而言，應(yīng)已基本足夠

.NET Core Cipher(套件)配置

如果沒有項(xiàng)目上的苛刻要求，我斷然也就無(wú)法在此方面展開研究和實(shí)踐。本文具以.NET 5為例，只不過(guò)針對(duì).NET Core 3或3.1通過(guò)工具掃描出的協(xié)議套件結(jié)果略有所差異，但不影響我們對(duì)安全套件的配置，我們使用OpenSSL生成自簽名證書，后續(xù)我會(huì)發(fā)表文章講解OpenSSL自簽名證書等等

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

HTTPS結(jié)合TLS 協(xié)議1.0或1.1不安全，所以TLS協(xié)議需使用1.2+，這里我們?nèi)缟鲜龃a使用版本1.2，接下來(lái)我們將其部署在Linux上，然后安裝nmap，通過(guò)nmap工具掃描（至于nmap是什么，可自行了解）

通過(guò)nmap掃描指定端口號(hào)并枚舉其支持TLS 套件需要注意一點(diǎn)，我們可能搜羅出來(lái)大多數(shù)文章的命令結(jié)果一掃，壓根沒有結(jié)果，其實(shí)nmap只對(duì)指定端口掃描才有效(比如443等等)，比如使用如下命令無(wú)效果

nmap --script ssl-enum-ciphers localhost -p 8000

若是其他端口，可使用如下命令進(jìn)行掃描

nmap --script +ssl-enum-ciphers localhost -p 8000

最終我們掃描出來(lái)的結(jié)果如下：

AES-CBC模式在中SSL或者TLS中存在一些已知的安全漏洞，如BEAST攻擊、Lucky 13攻擊等，雖然TLS1.1、TLS1.2未受到BEAST攻擊的影響、Lucky 13（影響涉及到TLS1.1/1.2）攻擊也在Openssl等知名加密算法庫(kù)得到了修復(fù)，但這些漏洞均暴漏出CBC模式在SSL/TLS協(xié)議實(shí)現(xiàn)時(shí)容易引入安全漏洞，HTTP/2中也明確將CBC模式加密套件列為黑名單

上述是在.NET 5 TLS 1.2默認(rèn)行為，但第三方規(guī)定禁止使用AES-CBC即使掃描出來(lái)的套件強(qiáng)度為A，并給定了其支持的安全套件

在上述配置通過(guò)路徑讀取文件和使用密碼啟用HTTPS重載方法中，如下

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

最后可針對(duì)連接做配置，在該類中有如下屬性

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

該輸入第二個(gè)類參數(shù)里面，有針對(duì)套件的配置，如下(我也是結(jié)合github找了老半天才翻到)

所以最終我們配置支持的安全套件如下（諸多套件，聞所未聞，不打緊，下面會(huì)歸納總結(jié)）：

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);
      };
    });
  });
});

咳咳，到這里為止，我們滿心歡喜，是不是就這樣愉快結(jié)束了？接觸到一個(gè)新的點(diǎn)時(shí)，一定一定要先看下解釋，別一頓操作后不好使，耗費(fèi)時(shí)間和勞力而全是無(wú)用功，最終才發(fā)現(xiàn)問(wèn)題癥結(jié)點(diǎn)所在，這也是我最近才有深刻體會(huì)

據(jù)我初步的了解應(yīng)該是在.NET Core 3.0+才開始支持配置OpenSSL的套件，且版本必須是1.1.1+，但不支持Windows，僅支持Linux或OSX！同時(shí)在.NET Core 3.1以下版本默認(rèn)協(xié)議是1.1或1.2，但在.NET 5默認(rèn)協(xié)議變更為了1.3，其支持套件配置也與OpenSSL配置也有了一定關(guān)聯(lián)。見鏈接《https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotnet-core-3-0》

當(dāng)接觸到某一知識(shí)點(diǎn)時(shí)(比如TLS)，我認(rèn)為稍微看下更高版本對(duì)此方面是否有變更很有必要，假設(shè)我們不知道.NET 5+默認(rèn)變更為了1.3，當(dāng)進(jìn)行版本升級(jí)過(guò)后，如果第三方對(duì)接此前使用的是TLS 1.2，那么數(shù)據(jù)對(duì)接就會(huì)斷層，業(yè)務(wù)必將受影響。僅我個(gè)人建議，至于其他我就管不到了~~~基于上述所述，若是在Windows開發(fā)環(huán)境，勢(shì)必要在對(duì)應(yīng)基礎(chǔ)上判斷操作系統(tǒng)

if (RuntimeInformation.IsOSPlatform(OSPlatform.OSX) || RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
{
  ......
}

最終我們掃描結(jié)果如下，已將AES-CBC不安全套件給去除，完全滿足安全要求

密碼學(xué)基礎(chǔ)

密碼套件所用到的算法大致有四種：對(duì)稱加密算法、非對(duì)稱密鑰交換算法、數(shù)字簽名算法(DSA)、可選的基于散列的消息身份驗(yàn)證代碼（HMAC）

說(shuō)白了，密碼學(xué)套件就是一組算法，開啟HTTPS和TLS并協(xié)同使用密碼學(xué)套件，才能使得傳輸更加安全

我們知道算法都是公開的，唯一不同的是算法依賴于密鑰，只有對(duì)接雙方知道，從而保護(hù)加密過(guò)后的密文而不能被窺探，那么接下來(lái)我們拆分講解上述幾種算法

非對(duì)稱加密算法，說(shuō)白了就是一方擁有公鑰，另一方擁有私鑰，它是瀏覽器和服務(wù)器開始時(shí)通過(guò)TLS握手時(shí)協(xié)商作為加密套件使用，至于HTTPS的其余部分可使用商定的密碼套件進(jìn)行使用

最初通過(guò)TLS握手時(shí)所使用的最主要的三種算法是：

DHE：Diffie-Hellman Ephemeral （密鑰交換算法）

RSA：以其發(fā)明者Rivest-Shamir-Adleman的名字而命名

ECDHE：Elliptic-curve Diffie–Hellman（橢圓曲線交換:翻譯而來(lái)）

對(duì)稱算法，說(shuō)白了就是雙方都知道的單一密鑰，相比較非對(duì)稱加密算法而言，它的計(jì)算速度更快，但并不適用于作為Web證書，因?yàn)闉g覽器和服務(wù)器不知道也完全不信任彼此，因此無(wú)法共享密鑰，然而，在進(jìn)行初始握手協(xié)議之后，再使用對(duì)稱加密算法非常合適即創(chuàng)建一個(gè)共享的密鑰以在HTTPS通信的其他期間使用

最常見的四種對(duì)稱加密算法是：

AES：Advanced Encryption Standard

AES-GCM：AES Galois/Counter

AES-CCM：AES Counter with CBC-MAC（密碼塊鏈接消息認(rèn)證碼）

ChaCha20：又名Salsa20

密碼強(qiáng)度是一種安全度量，加密文本在遭受攻擊時(shí)有多安全？算法的強(qiáng)度與密鑰的長(zhǎng)度相關(guān)，所以更長(zhǎng)的密鑰更強(qiáng)大，密鑰長(zhǎng)度表示為位數(shù)，常用的值為128 和 256，對(duì)稱算法由它們的首字母縮略詞和它們的密鑰長(zhǎng)度來(lái)標(biāo)識(shí)，比如像 AES128 或 AES256。

說(shuō)了這么一大堆，好像就了解到幾個(gè)算法名稱，要是脫離本文的內(nèi)容確實(shí)僅在腦后留下些許印象，那么接下來(lái)我們結(jié)合配置的密碼套件來(lái)進(jìn)行實(shí)踐理解，我們拿上述配置的第一個(gè)密碼套件來(lái)進(jìn)行闡述，其余同理，如下

TlsCipherSuite.TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

上述TlsCipherSuite是一個(gè)枚舉，我們僅看枚舉內(nèi)容，將TLS去掉剩余則是DHE_RSA_WITH_AES_128_GCM_SHA256

我們?cè)俳Y(jié)合上述闡述的非對(duì)稱和對(duì)稱加密算法將其拆分，則是DHE、RSA、AES-128-GCM

從最終拆分的結(jié)果來(lái)看，實(shí)際上HTTPS使用了一對(duì)算法而非單一算法，其中一種非對(duì)稱加密DHE和RSA用于初始期間TLS握手，而另一種對(duì)稱加密算法AES-128-GCM用于數(shù)據(jù)傳輸期間的加密和解密！如此一來(lái)對(duì)于HTTPS使用對(duì)稱和非對(duì)稱加密算法則形成多種組合

但簡(jiǎn)單地選擇一對(duì)非對(duì)稱/對(duì)稱算法不足以完全識(shí)別密碼套件，所以還需要指定用于確保身份驗(yàn)證和完整性的規(guī)則。比如通過(guò)LetsEncrypt證書機(jī)構(gòu)來(lái)頒發(fā)證書。更深層次的密碼學(xué)東東這里就不再展開了，我也就探究于此

.NET Core中配置的密碼套件與OpenSSL所支持套件吻合，如下截圖一部分：

那么問(wèn)題來(lái)了，上述我們配置了多種套件，結(jié)果通過(guò)工具掃描時(shí)有三種被支持的套件被掃描出，瀏覽器和服務(wù)器初次進(jìn)行TLS握手時(shí)，到底選擇哪一種呢？那么我們接下來(lái)通過(guò)訪問(wèn)并查看Web證書能否找到蛛絲馬跡，事先聲明：以下部分內(nèi)容為我個(gè)人推測(cè)，至于理論上是否如真如我所言未可知

通過(guò)查看證書反推，我們通過(guò)OpenSSL創(chuàng)建自簽名證書所使用的是RSA加sha256算法，然后再看如下圖可知所使用最終套件

結(jié)合這二者是不是就可以說(shuō)明所使用的密碼套件對(duì)應(yīng)OpenSSL配置則是：ECDHE-RSA-AES128-GCM-SHA256，也就是對(duì)應(yīng)通過(guò)nmap工具掃描出來(lái)支持的三種套件中的第一個(gè)

ECDHE-RSA-AES128-GCM-SHA256結(jié)論由上述證書和安全查看而言，因?yàn)槭莝ha256RSA所以密碼套件最后則是SHA256，果真是如此，我能否自圓其說(shuō)？要是我們將SHA256套件刪除，是不是頁(yè)面就不支持，Web頁(yè)面無(wú)法訪問(wèn)呢？

經(jīng)過(guò)上述修改和通過(guò)nmap掃描出結(jié)果如下：

看來(lái)與證書上所言算法無(wú)關(guān)，最終回到我通過(guò)自創(chuàng)建證書命令

openssl genrsa -out ca-key.key 3072

只能匹配到所使用RSA非對(duì)稱加密算法，OpenSSL可指定加密方式

但當(dāng)我指定aes128或其他位時(shí)，其模式其實(shí)是CBC而非GCM

最終查看是否支持GCM

openssl aes-256-gcm

其實(shí)OpenSSL支持GCM，只不過(guò)不能用過(guò)命令行來(lái)進(jìn)行操作，具體原因官方有解釋。分析了這么多，貌似沒啥用，目前大致能確定的是：密碼套件的支持還是需要瀏覽器和服務(wù)器來(lái)進(jìn)行握手協(xié)商

比如在谷歌瀏覽器中就可設(shè)置是否啟用TLS 1.3

到目前為止，我們大致知道了HTTPS所使用的是一組算法，握手期間用非對(duì)稱加密算法，數(shù)據(jù)傳輸期間用對(duì)稱加密算法！那么整個(gè)期間，猜測(cè)是結(jié)合生成的證書，然后遍歷配置套件進(jìn)行握手，握手成功后再進(jìn)行數(shù)據(jù)傳輸

大致握手和數(shù)據(jù)傳輸過(guò)程，簡(jiǎn)單描述如下：

客戶端向服務(wù)端發(fā)送消息，我使用TLS 1.2中的ECDHE-RSA-AES128-GCM-SHA256以及還有其他套件，你能處理嗎？服務(wù)端向客戶端回復(fù)消息，ECDHE-RSA-AES128-GCM-SHA256能處理，然后向客戶端發(fā)出公鑰證書?？蛻舳讼蚍?wù)端回復(fù)消息，證書是合法的，客戶端生成密鑰6p7vUjFz緊接著使用服務(wù)端的公鑰證書進(jìn)行加密，通知服務(wù)端以后數(shù)據(jù)傳輸用指定的密鑰即共享密鑰

當(dāng)自定義配置所支持套件時(shí)，需要額外注意一點(diǎn)的是，千萬(wàn)別同時(shí)指定TLS 1.2和TLS1.3

到此這篇關(guān)于.NET Core配置TLS Cipher(套件)的詳細(xì)過(guò)程的文章就介紹到這了,更多相關(guān).NET Core配置TLS Cipher內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！