.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和TLS1.3

到此這篇關於.NET Core配置TLS Cipher(套件)的詳細過程的文章就介紹到這瞭,更多相關.NET Core配置TLS Cipher內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: