在 ASP.NET Core 中強制執行 HTTPS

作者 David Galvan 與 Rick Anderson

為了強制要求 ASP.NET Core 應用程式使用 HTTPS/TLS，你可以：

• 針對所有要求都要求 HTTPS。
• 將所有 HTTP 要求都重新導向至 HTTPS。

任何 API 都無法防止用戶端在第一個要求時傳送敏感性資料。

本文說明如何設定您的 ASP.NET Core 應用程式要求 HTTPS/TLS 或將 HTTP 請求重新導向至 HTTPS/TLS 以確保安全互動。 為各種平台提供了故障排除步驟，以解決不受信任的憑證問題。

API 專案

使用 Web API 的專案應以下其中之一：

• 不監聽 HTTP。
• 關閉連線並回傳狀態碼 400（不當的請求），不處理該請求。

若要停用 API 中的 HTTP 重新導向，請設定 ASPNETCORE_URLS 環境變數或使用 --urls 命令列旗標。 如需詳細資訊，請參閱 Andrew Lock 所 ASP.NET Core 執行 階段環境 和 8 種設定 ASP.NET Core 應用程式 URL 的方法 。

Warning

請勿在接收敏感性資訊的 Web API 上使用 RequireHttpsAttribute。 RequireHttpsAttribute 會使用 HTTP 狀態碼，將瀏覽器從 HTTP 重新導向至 HTTPS。 API 用戶端可能無法理解或遵守從 HTTP 轉為 HTTPS 的重定向，且可能透過 HTTP 傳送資訊。

HSTS 和 API 專案

HTTP 嚴格傳輸安全協定（HSTS） 的安全方法是將 API 專案設定為僅透過 HTTPS 監聽與回應。

Warning

預設的 API 專案不包含 HSTS ，因為它通常是瀏覽器專用指令。 其他呼叫者，例如電話或桌面應用程式，不遵循指示。 即使在瀏覽器內，透過 HTTP 對 API 的單一驗證呼叫也會對不安全的網路造成風險。

HTTP 重新導向至 HTTPS（CORS 預檢要求上發生 ERR_INVALID_REDIRECT）

當使用 HTTP 對端點提出的要求以 UseHttpsRedirection 方法重新導向至 HTTPS 時，重新導向會因 CORS 預檢要求上的 ERR_INVALID_REDIRECT 錯誤而失敗。

API 專案可以拒絕 HTTP 請求，而非使用 UseHttpsRedirection 該方法將請求重新導向至 HTTPS。

需要 HTTPS

對於生產型 ASP.NET Core 網頁應用程式，建議採用以下方法：

• 若要將 HTTP 請求重定向至 HTTPS，請使用 HTTPS Redirect Middleware（UseHttpsRedirection）。

• 若要將 HSTS 標頭傳送給用戶端，請使用 HSTS 中介軟體的 UseHsts 方法。

Note

部署在反向 Proxy 設定中的應用程式可讓 Proxy 處理連線安全性 (HTTPS)。 如果 Proxy 也處理 HTTPS 重新導向，則不需要使用 HTTPS 重新導向中介軟體。 如果代理伺服器同時負責撰寫 HSTS 標頭（例如，Internet Information Services （IIS） 10.0 版本 1709 或更新版本中的 native HSTS 支援），則該應用程式不需要 HSTS 中介軟體。 如需詳細資訊，請參閱在專案建立時選擇退出 HTTPS/HSTS。

UseHttpsRedirection

以下程式碼 UseHttpsRedirection 呼叫 Program.cs 檔案中的該方法：

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

上述醒目提示的程式碼：

• 使用預設 HttpsRedirectionOptions.RedirectStatusCode 屬性搭配 Status307TemporaryRedirect 程式碼。
• 使用預設的 HttpsRedirectionOptions.HttpsPort 屬性（傳遞 null），除非被 ASPNETCORE_HTTPS_PORT 環境變數或 IServerAddressesFeature 覆寫。

建議的做法是使用暫時性重定向，而非永久重定向。 連結快取可能會導致開發環境中不穩定的現象。 如果你偏好在應用程式處於非環境Development 時傳送永久重定向狀態碼，請參考 「在生產環境中配置永久重定向 」部分。 使用 HSTS 向用戶端發出訊號，表示只有安全資源請求應該傳送給應用程式（僅限生產環境）。

連接埠設定

中介軟體必須可使用連接埠，才能將不安全的要求重新導向至 HTTPS。 如果沒有可用的連接埠：

• 不會重新導向至 HTTPS。
• 中介軟體會記錄警告： 無法確定重定向的 https 埠。

請透過以下任一方法指定 HTTPS 埠：

• 設定 HttpsRedirectionOptions.HttpsPort。

• 設定 https_port主機設定：

  • 在主機設定中。

  • 藉由設定 ASPNETCORE_HTTPS_PORT 環境變數。

  • 透過在 appsettings.json 檔案中加入頂層條目：

    {
      "https_port": 443,
      "Logging": {
        "LogLevel": {
          "Default": "Information",
          "Microsoft.AspNetCore": "Warning"
        }
      },
      "AllowedHosts": "*"
    }
    

• 使用 ASPNETCORE_URLS環境變數標示安全方案的埠。 環境變數會設定伺服器。 中介軟體會透過 IServerAddressesFeature 間接探索 HTTPS 連接埠。 此方法不適用於反向 Proxy 部署。

• ASP.NET Core 網頁範本會在 Properties/launchsettings.json 檔案中為 Kestrel 和 IIS Express 設定 HTTPS URL。 launchsettings.json 檔案僅在本地機器上使用。

• 為 Kestrel 伺服器或 HTTP.sys 伺服器的公開邊緣部署設定 HTTPS URL 端點。 應用程式只會使用一個 HTTPS 連接埠。 中介軟體會透過 IServerAddressesFeature 探索連接埠。

Note

當應用程式以反向代理設定執行時， IServerAddressesFeature 無法使用。 請使用本節所述的其他方法來設定埠。

Edge 部署

當 Kestrel 或 HTTP.sys 作為公開邊緣伺服器使用時，Kestrel 或 HTTP.sys 必須設定為接聽兩者：

• 重新導向用戶端所在的安全連接埠 (通常在生產環境中為 443，在開發環境中為 5001)。
• 不安全的連接埠 (通常為在生產環境中為 80，在開發環境中為 5000)。

用戶端必須能存取該不安全埠，應用程式才能接收不安全請求並重新導向該安全埠。

如需詳細資訊，請參閱 Kestrel 端點設定或 ASP.NET Core 中的 HTTP.sys Web 伺服器實作。

部署案例

用戶端與伺服器之間的任何防火牆也必須針對流量開啟通訊連接埠。

如果在反向 Proxy 設定中轉送要求，請在呼叫 HTTPS 重新導向中介軟體之前，先使用轉送標頭中介軟體。 轉送標頭中介軟體會使用 X-Forwarded-Proto 標頭來更新 Request.Scheme。 中介軟體允許重新導向 URI 和其他安全性原則以正常運作。 當未使用轉發標頭中介軟體時，後端應用程式可能無法收到正確的方案，陷入重定向迴圈。 常見的終端使用者錯誤訊息是重定向過多。

部署至 Azure App 服務 時，請依照 在 Azure App 服務 中為自訂網域啟用 HTTPS 中的指引。

選項

下列醒目提示的程式碼會呼叫 AddHttpsRedirection 方法來設定中介軟體選項：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

變更 AddHttpsRedirection 或 HttpsPort 的值時才需要呼叫 RedirectStatusCode。

上述醒目提示的程式碼：

• 將 HttpsRedirectionOptions.RedirectStatusCode 屬性設為 Status307TemporaryRedirect 代碼，此為預設值。 使用 StatusCodes 類別的欄位來指派至 RedirectStatusCode。
• 將 HTTPS 連接埠設定為 5001。

在生產環境中設定永久重新導向

中介軟體預設會傳送 Status307TemporaryRedirect 包含所有重定向的程式碼。 當應用程式處於非Development 環境時，若您偏好傳送永久的重定向狀態碼，可以在條件檢查非Development 環境時包裹中介軟體選項設定。

以下程式碼顯示 Program.cs 檔案中服務的配置：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

if (!builder.Environment.IsDevelopment())
{
    builder.Services.AddHttpsRedirection(options =>
    {
        options.RedirectStatusCode = Status308PermanentRedirect;
        options.HttpsPort = 443;
    });
}

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");

    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

HTTPS 重新導向中介軟體替代方法

使用 HTTPS Redirection Middleware（搭配該 UseHttpsRedirection 方法）的替代方案是使用 URL Rewriting Middleware（透過該 AddRedirectToHttps 方法）。 AddRedirectToHttps 也可以在執行重新導向時設定狀態碼和連接埠。 如需詳細資訊，請參閱 URL 重寫中介軟體。

當應用程式在不需其他重定向規則的情況下直接導向到 HTTPS，建議使用本文所述的 HTTPS Redirect MiddlewareUseHttpsRedirection（）。

HTTP 嚴格傳輸安全性通訊協定 (HSTS)

根據 OWASP，HSTS 是網站應用程式透過回應標頭宣告的自願採用安全性增強機制。 支援 HSTS 的瀏覽器收到此標頭時：

• 瀏覽器會儲存網域的設定，以防止透過 HTTP 傳送任何通訊。 瀏覽器會強制透過 HTTPS 進行所有通訊。
• 瀏覽器可防止使用者使用不受信任或不正確憑證。 瀏覽器會停用提示，讓使用者暫時信任此類憑證。

由於用戶端強制執行 HSTS，因此有一些限制：

• 用戶端必須支援 HSTS。
• HSTS 至少需要一個成功的 HTTPS 要求，才能建立 HSTS 原則。
• 應用程式必須檢查每個 HTTP 要求，並重新導向或拒絕 HTTP 要求。

ASP.NET Core 會使用 UseHsts 擴充方法實作 HSTS。 當應用程式不在開發模式時，下列程式碼會呼叫 UseHsts：

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

UseHsts 不建議用於開發環境，因為 HSTS 設定可能會被瀏覽器大量快取。 根據預設，UseHsts 會排除本機回送位址。

對於首次實作 HTTPS 的生產環境，請使用其中一種HstsOptions.MaxAge方法將初始TimeSpan屬性值設定為小值。 將數值設定從小時到不超過一天，以防你需要將 HTTPS 基礎架構還原到 HTTP。 當你對 HTTPS 配置的可持續性有信心後，提高 HSTS max-age 值（通常為一年）。

下列醒目提示的程式碼：

using static Microsoft.AspNetCore.Http.StatusCodes;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddHsts(options =>
{
    options.Preload = true;
    options.IncludeSubDomains = true;
    options.MaxAge = TimeSpan.FromDays(60);
    options.ExcludedHosts.Add("example.com");
    options.ExcludedHosts.Add("www.example.com");
});

builder.Services.AddHttpsRedirection(options =>
{
    options.RedirectStatusCode = Status307TemporaryRedirect;
    options.HttpsPort = 5001;
});

var app = builder.Build();

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

• 設定 Strict-Transport-Security 標頭的預先載入參數。 預載並非 RFC 6797 HSTS 規範的一部分。 網頁瀏覽器支援全新安裝時預載 HSTS 網站。 如需詳細資訊，請參閱https://hstspreload.org/。
• 啟用 includeSubDomain 指令，將 HSTS 政策套用於主機子網域。 欲了解更多資訊，請參閱 RFC 6797 HSTS 規範（第 6.1.2 節）。
• 將 max-age 標頭的 Strict-Transport-Security 參數明確設定為 60 天。 如果沒有設定，預設是 30 天。 欲了解更多資訊，請參閱 max-ageRFC 6797 HSTS 規範中的指令（第 6.1.1 節）。
• 將 example.com 新增至要排除的主機清單。

UseHsts 會排除下列回送主機：

• localhost：IPv4 迴路回溯位址。
• 127.0.0.1：IPv4 迴路回溯位址。
• [::1]： IPv6 迴路回送位址。

專案建立時選擇退出 HTTPS/HSTS

在某些後端服務情境中，連線安全由公開邊緣處理，則不需要在每個節點設定連線安全。 從 Visual Studio 中的範本或 dotnet new 命令產生的 Web 應用程式會啟用 HTTPS 重新導向和 HSTS。 對於不需要這些情境的部署，你可以在從範本建立應用程式時選擇不使用 HTTPS/HSTS。

若要退出 HTTPS/HSTS：

Visual Studio

當你建立新的 ASP.NET Core 網頁應用程式時，請取消選取 Configure for HTTPS 選項：

.NET CLI

例如：搭配 dotnet new webapp 指令使用 --no-https 選項

dotnet new webapp --no-https

信任 ASP.NET Core HTTPS 開發憑證

.NET SDK 包含 HTTPS 開發憑證。 憑證會安裝為初次執行體驗的一部分。 例如，指令 dotnet --info 會產生以下輸出的變化：

ASP.NET Core
------------
Successfully installed the ASP.NET Core HTTPS Development Certificate.
To trust the certificate run 'dotnet dev-certs https --trust' (Windows and macOS only).
For establishing trust on other platforms refer to the platform specific documentation.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.

安裝 .NET SDK 會將 ASP.NET Core HTTPS 開發憑證安裝到本機使用者證書存儲。 憑證已安裝，但不被信任。 若要信任憑證，請執行一次性步驟以執行 dotnet dev-certs 工具：

dotnet dev-certs https --trust

下列命令會提供 dotnet dev-certs 工具的說明：

dotnet dev-certs https --help

Warning

不要在規劃重新分發的環境中建立開發憑證，例如容器映像或虛擬機。 這種情況可能導致偽裝和特權提升。 為避免這種情況，第一次呼叫 .NET CLI 前，請將 DOTNET_GENERATE_ASPNET_CERTIFICATE 環境變數設為 false。 此方法跳過 CLI 首次執行時自動產生 ASP.NET Core 開發憑證的過程。

設定 Docker 的開發者憑證

要設定 Docker 的開發者憑證，請參考 GitHub dotnet/aspnetcore.docs issue #6199 - 如何在開發中使用 Docker 時設定開發憑證。

Linux 特定考量

Linux 發行版在標記憑證為可信的方式上有很大差異。

dotnet dev-certs該工具預計將廣泛適用，但官方支援僅支援 Ubuntu 與 Fedora。 此支援特別旨在確保對 Firefox 及基於 Chromium 的瀏覽器（Microsoft Edge、Chrome 和 Chromium）的信任。

Dependencies

• 若要建立 OpenSSL 信任，工具 openssl 必須位於路徑上。
• 要建立瀏覽器信任（例如在 Microsoft Edge 或 Firefox），certutil 工具必須在路徑上。

OpenSSL 信任

當 ASP.NET Core 開發憑證被信任時，該憑證會匯出到目前使用者的主目錄資料夾。 若要讓 OpenSSL （以及使用它的用戶端）選擇此資料夾，您需要設定 SSL_CERT_DIR 環境變數。 你可以透過執行類似 export SSL_CERT_DIR=$HOME/.aspnet/dev-certs/trust:/usr/lib/ssl/certs 的命令，在單一工作階段中設定該變數（傳入 --verbose 時，輸出中會顯示確切的值）；或者將它加入你的設定檔（依發行版和 shell 而定，例如 .profile）。

必須採用這種方法，才能讓像 curl 這樣的工具信任開發憑證。 或者，你也可以在每次個別的 curl 呼叫中傳入 -CAfile 或 -CApath。

Note

需要 1.1.1h 或更新版本，或是 3.0.0 或更新版本，視你使用的主版本而定。

如果 OpenSSL 信任進入不良狀態（例如 dotnet dev-certs https --clean 無法移除），你通常可以透過使用 c_rehash 工具來解決這個問題。

Overrides

如果你使用另一款擁有自己網路安全服務（NSS）儲存庫的瀏覽器，可以使用 DOTNET_DEV_CERTS_NSSDB_PATHS 環境變數指定一個以冒號分隔的 NSS 目錄清單（例如包含 cert9.db的目錄）。 接著你可以將開發證書的位置加入變數的清單中。

如果你把想讓 OpenSSL 信任的憑證存放在特定目錄中，你可以用 DOTNET_DEV_CERTS_OPENSSL_CERTIFICATE_DIRECTORY 環境變數來指示憑證的位置。

Warning

如果你設定任一變數，記得每次更新信任時都設定相同的數值。 如果數值改變，工具就無法知道先前位置的憑證（例如憑證清理時）。

使用 sudo

如同其他平台一樣，開發憑證會為每個使用者分別儲存並單獨信任。

如果你以不同使用者身份執行 dotnet dev-certs （例如使用 sudo），那麼 該 特定使用者（例如 root）會信任開發憑證。

使用 linux-dev-certs 信任 Linux 上的 HTTPS 憑證

linux-dev-certs 是開放原始碼、社群支援的 .NET 全域工具，可提供在 Linux 上建立及信任開發人員憑證的便利方式。 Microsoft 並不維護或支援這個工具。

下列命令會安裝工具，並建立受信任的開發人員憑證：

dotnet tool update -g linux-dev-certs
dotnet linux-dev-certs install

如需詳細資訊或回報問題，請參閱 linux-dev-certs GitHub 存放庫。

SUSE Linux 企業伺服器（SLES Linux）

如果您的組態包含 SUSE Linux Enterprise Server，請參閱 GitHub dotnet/aspnetcore.docs issue #28292 - 在 SLES 上信任 HTTPS 憑證。

疑難排解憑證問題（憑證不受信任）

有時當 ASP.NET Core HTTPS 開發憑證已安裝並受信任時，瀏覽器仍會警告該憑證不受信任。 以下章節將協助排除此問題。

ASP.NET Core HTTPS 開發憑證是由 Kestrel 所使用的。

要修復 IIS Express 憑證，請參見 Stack Overflow 問題 #20036984 / 答案 #20048613 - 我該如何還原遺失的 IIS Express SSL 憑證？

所有平台 - 憑證不受信任

對於所有平台，請嘗試透過以下步驟解決不受信任憑證的問題：

1. 執行下列命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

2. 關閉所有開啟的瀏覽器實例，並在新的瀏覽器視窗中開啟應用程式。

   瀏覽器快取會儲存憑證是否被信任。 關閉/開啟的過程有助於刷新憑證的瀏覽器快取設定。

這些 dotnet dev-certs https 指令通常能解決大多數瀏覽器的信任問題。 如果 dotnet dev-certs https --clean 指令失敗且瀏覽器仍不信任憑證，請嘗試以下章節中針對特定平台的建議。

Docker - 憑證不受信任

如果你正在使用 Docker，請嘗試以下步驟來解決這個問題：

1. 刪除 C:\Users{USER}\AppData\Roaming\ASP.NET\Https 資料夾。

2. 清潔溶液。 刪除 [bin] 和 [obj] 資料夾。

3. 重新啟動開發工具。 例如，Visual Studio 或 Visual Studio Code。

Windows - 憑證不受信任

如果你是在 Windows 上工作，請完成以下故障排除步驟：

1. 檢查憑證存放區中的憑證。 找一個帶有 localhost 友善名稱的 ASP.NET Core HTTPS development certificate 證書，放在兩個資料夾裡：

   • 目前使用者 > 個人 > 憑證
   • 目前的使用者 > 受信任的根憑證授權單位 > 憑證

2. 將所有憑證從個人及受信任根認證機構移除。

   Important

   請勿移除 IIS Express localhost 憑證。

3. 執行下列命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

4. 關閉所有開啟的瀏覽器實例，並在新的瀏覽器視窗中開啟應用程式。

OS X - 憑證不受信任

如果你使用的是 OS X，請嘗試以下步驟來解決這個問題：

1. 打開鑰匙圈存取，然後選擇系統鑰匙圈。

2. 檢查 localhost 憑證是否存在。

3. 確認憑證圖示上有加號（+）符號，表示該憑證對所有使用者皆有信任。

4. 從系統金鑰鏈移除憑證。

5. 執行下列命令：

   dotnet dev-certs https --clean
   dotnet dev-certs https --trust
   

6. 關閉所有開啟的瀏覽器實例，並在新的瀏覽器視窗中開啟應用程式。

欲了解更多關於 Visual Studio 憑證問題故障排除的資訊，請參見 GitHub dotnet/aspnetcore issue #16892） - HTTPS 錯誤使用 IIS Express。

Linux - 憑證不被信任

如果你使用的是 Linux，請依照以下步驟排除不受信任的憑證：

1. 確認你調查的憑證是否為伺服器規劃使用的 Kestrel 使用者 HTTPS 開發者憑證。

2. 在下列位置檢查目前的使用者預設 HTTPS 開發人員 Kestrel 憑證：

   ls -la ~/.dotnet/corefx/cryptography/x509stores/my
   

   HTTPS 開發人員 Kestrel 憑證檔案是 SHA1 指紋。 當使用 dotnet dev-certs https --clean 指令刪除該檔案時，系統會在需要時以不同的指紋重新產生該檔案。

3. 請執行以下指令驗證匯出憑證的指紋是否相符：

   openssl x509 -noout -fingerprint -sha1 -inform pem -in /usr/local/share/ca-certificates/aspnet/https.crt
   

   如果證書指紋不符，請調查以下條件：

   • 檢查證書是否過時。

   • 確認該憑證是否為根用戶匯出的開發者憑證。

     • 如果是，請匯出證明。

4. 請檢查以下資料夾中的根使用者憑證：

   ls -la /root/.dotnet/corefx/cryptography/x509stores/my
   

搭配 Visual Studio 使用的 IIS Express SSL 憑證

要解決 IIS Express 憑證的問題，請在Visual Studio安裝程式中選擇 Repair。 更多資訊請參見 GitHub dotnet/aspnetcore issue #16892） - HTTPS 錯誤，使用 IIS Express。

群組政策防止信任自簽憑證

在某些情況下，群組政策會阻止自簽憑證被信任。 欲了解更多資訊，請參閱 GitHub dotnet/aspnetcore issue #21173 - 信任 HTTPS 開發人員憑證時發生錯誤。

相關內容

• 設定 ASP.NET Core 以處理 Proxy 伺服器和負載平衡器
• 在 Linux 上使用 Nginx 裝載 ASP.NET Core：HTTPS 設定
• 在 IIS 7 或更新版本上設定 SSL
• 設定網頁伺服器端點 Kestrel
• OWASP HSTS 瀏覽器支援