Google Cloud 的流動資料加密機制

這是說明 Google 如何使用加密技術保護資料的第三份白皮書,這份白皮書會進一步說明 Google Cloud (包含 Google Cloud Platform 和 Google Workspace) 採取的流動資料加密機制。

對於所有 Google 產品,我們都努力保護客戶資料,並盡可能完整公開我們確保資料安全無虞的方法。

本文撰寫於 2017 年 12 月,所有資訊皆以當時情況為依據。另外,我們會持續改善客戶資料的保護機制,因此 Google Cloud 的安全性政策和系統未來可能會調整。

「播放」按鈕

Google Cloud 的流動資料加密機制

資訊長層級摘要

  • Google 採用多種安全防護措施,協助確保傳輸中資料的真實性、完整性和隱私性。
  • 針對這份白皮書提及的用途,在資料移至非 Google 或 Google 代理單位控管的實體界限之外時,Google 會在一或多個網路層級對傳輸中的資料進行加密與驗證。虛擬私有雲網路和對等互連虛擬私有雲網路中的所有 VM 對 VM 流量都會經過加密。
  • 視連線情況而定,Google 可能會對傳輸中的資料套用預設的安全防護措施。舉例來說,我們會使用傳輸層安全標準 (TLS) 來保護使用者與 Google Front End (GFE) 之間的通訊內容。
  • 如果 Google Cloud 客戶需要對 WAN 中的資料額外加密,可以選擇採用進階資料保護機制,在使用者的資料移至應用程式或在不同虛擬機器之間移動資料時提供妥善的防護措施。這類安全防護機制包括 IPSec 通道、Gmail S/MIME、代管的安全資料傳輸層 (SSL) 憑證和 Istio。
  • Google 積極與業界合作,致力於推廣流動資料加密機制,讓所有人隨時隨地都能使用這項技術。我們已建立多項開放原始碼專案,藉此推行網際網路流動資料加密與資料安全防護機制,包括憑證透明化、Chrome API 和安全 SMTP。
  • Google 已擬定計畫,期望在流動資料加密技術上繼續引領業界。為達成這個目標,我們將許多資源投注於開發及改善加密技術。我們在這方面的成果包含金鑰透明化和後量子密碼編譯領域中的創新。

簡介

選擇公用雲端服務供應商時,安全性往往是一項決定性因素。對 Google 而言,安全性是我們的優先要務。無論您的資料是在網際網路中傳輸、在 Google 的基礎架構內移動,還是儲存於我們的伺服器,我們都會努力不懈地保護。

Google 安全性策略的重點在於靜態資料和流動資料的驗證作業、完整性和加密機制。本頁面說明 Google Cloud 的流動資料加密機制。

如需靜態資料的相關資訊,請參閱 Google Cloud Platform 靜態資料加密一文。如想瞭解 Google 安全防護措施的基本資訊,請參閱 Google 基礎架構安全性設計總覽一文。

目標對象:本文的目標對象為正在使用或考慮使用 Google Cloud 的資訊安全長與安全性作業團隊。

前提說明:我們假定您在閱讀本文以前,對加密機制密碼編譯基元已有基本認識。

資料驗證、完整性及加密

Google 採用多種安全防護措施,協助確保傳輸中資料的真實性、完整性和隱私性。

  • 驗證:無論資料是由真人或程序提供,我們都會驗證資料的來源與目的地。
  • 完整性:我們會確保您所傳送的資料保持未受變更的狀態,平安傳輸至目的地。
  • 加密:我們會確保他人無法解讀傳輸中的資料,維護資料隱私。加密程序的作用是將可以輕易解讀的資料 (明文) 轉換為無法理解的文字 (密文),目標在於確保只有資料擁有者授權的實體才能存取資料明文。雖然加密程序採用的是公開演算法,但解開密文所需的金鑰為私密金鑰。流動資料的加密作業通常會使用非對稱式金鑰交換機制 (例如橢圓曲線型的 Diffie-Hellman 金鑰),藉此建立用來加密資料的共用對稱式金鑰。如要進一步瞭解加密機制,請參閱《Introduction to Modern Cryptography》(現代密碼學)。

資料加密可用來在以下三個階段保護資料:

  • 靜態資料加密:對儲存的資料套用加密保護,確保資料不會因為系統遭駭或他人竊取受到影響。進階加密標準 (AES) 通常用於靜態資料的加密。
  • 流動資料加密:當資料在您的網站與雲端供應商之間,或是兩種服務之間傳輸時,流動資料加密機制可在有人攔截通訊時,確保資料安全無虞。這種保護機制會將傳輸前的資料加密,然後驗證端點,並在資料抵達目的地時解密並驗證資料,透過這種方式來達到目標。舉例來說,傳輸層安全標準 (TLS) 通常是為了達到傳輸安全性,而用於流動資料加密上,而安全/多用途網際網路郵件延伸標準 (S/MIME) 則通常用於保護電子郵件的安全。
  • 使用時加密:可在處理過程中加密資料 (例如機密運算),藉此保護記憶體中的資料,避免遭到外洩或竊取。

加密機制是廣義安全性策略中的一環。在系統建立並驗證連線之後,流動資料的加密機制會透過下列方式保護您的資料不受潛在攻擊的影響:

  • 停止信任第三方常用的較低層網路
  • 減少潛在的受攻擊面
  • 若通訊遭到攔截,可阻擋攻擊者存取資料

在驗證程序、加密機制與完整性均完備的情況下,即便處於惡劣的環境中,在使用者、裝置或程序之間傳輸的資料仍能受到妥善保護。本文後續章節將說明 Google 的流動資料加密機制和應用情況。

Google 網路基礎架構

實體邊界

當資料傳輸至由 Google 控制或第三方代表 Google 控制的實體界限之外時,Google 會採取各種不同的保護機制。實體界限是 Google 或 Google 代理單位控管的實體空間屏障,我們可以確定此處設下了嚴謹的安全防護措施。我們會嚴加限制並監控這類位置的實體權限,只有少部分的 Google 員工具備相關硬體的存取權。在這些實體界限之內所傳輸的資料一般皆經過驗證,不過可能並未預設為加密,您可以依據您的威脅模型,選擇要套用哪些額外的安全措施。

由於全球網路的規模龐大,對於 WAN 的光纖連結,以及 Google 或第三方代表 Google 控制的實體界限之外的任何位置,我們都無法採取相同的實體安全控管機制。因此,在實體信任界限之外,我們會自動施加額外的保護機制,流動資料加密也是保護機制之一。

流量轉送方式

為了讓您徹底瞭解 Google 的流動資料加密機制如何運作,在此有必要說明流量在網際網路上的轉送方式。本節會說明要求如何從使用者端傳送至正確的 Google Cloud 服務或客戶應用程式,並介紹流量在不同服務之間的轉送方式。

Google Cloud 服務是 Google 提供給客戶的模組型雲端服務,包含運算、資料儲存、資料分析和機器學習等服務。舉例來說,Google Cloud Storage 和 Gmail 皆為 Google Cloud 服務。客戶應用程式是託管於 Google Cloud 的應用程式,Google 客戶可以使用各項 Google Cloud 服務來建構及部署這類應用程式。託管於 Google Cloud 的客戶應用程式或合作夥伴解決方案不屬於 Google Cloud 服務1。舉例來說,您透過 Google App Engine、Google Kubernetes Engine 或 Google Compute Engine 中 VM 建構的應用程式即為客戶應用程式。

圖 1 呈現了下文提及的五種轉送要求。本圖呈現了不同網路元件之間的互動關係,以及每個連線設有的安全防護措施。

使用者 (網際網路) 至 Google Cloud 服務

Google Cloud 服務採用遍及全球的系統來接收世界各地傳出的要求,這個系統稱為「Google Front End」(GFE)。GFE 會終止傳入的 HTTP(S)、TCP 和傳輸層安全標準 (TLS) Proxy 流量,提供分散式阻斷服務攻擊的因應措施,將流量轉送至 Google Cloud 服務,並進行負載平衡。世界各地都有透過單點傳播或 Anycast 伺服器通告路徑的 GFE 服務據點。

GFE 會將流量以 Proxy 的方式轉送至 Google Cloud 服務。GFE 會將使用者的要求從中樞網路轉送至 Google Cloud 服務。一旦這類通訊離開了由 Google 或第三方代表 Google 控制的實體界限,GFE 即會針對 Google Cloud 服務或客戶應用程式的前端進行連線驗證與加密。圖 1 顯示了這項互動 (標為 A 連線)。

使用者 (網際網路) 至託管在 Google Could 上的客戶應用程式

有數種方法可以將流量從網際網路轉送至您託管在 Google Cloud 之上的客戶應用程式。流量的轉送方式取決於設定選項,說明如下。圖 1 顯示了這項互動 (標為 B 連線)。

使用 Google Cloud HTTP(S) 或 TCP/安全資料傳輸層 (SSL) Proxy 外部負載平衡器

所有 Google Cloud 區域的加密方式

虛擬私有雲網路和對等互連虛擬私有雲網路中的所有 VM 對 VM 流量都會經過加密。其中包括在實體界限內 (即叢集內流量) 的 VM 對 VM 流量。

以 Proxy 為基礎的負載平衡器與後端之間的加密

對於部分負載平衡器類型,Google 會自動將流量轉送至 Google Cloud 虛擬私有雲網路中的後端,也就是所謂的自動網路層級加密

另外,Google Cloud 也提供加密機制適用的後端服務加密通訊協定

某些 Google Cloud 負載平衡器類型會使用 Google Front End (GFE) 來當做後端的用戶端,有些則是使用 Envoy Proxy。 無論在何種情況下,負載平衡器均支援 RFC 8446 第 9.1 節中列出的加密套件。

下表提供摘要資訊。

以 Proxy 為基礎的產品類型 後端用戶端 自動網路層級加密 後端服務安全通訊協定選項
全域外部 HTTP(S) 負載平衡器 GFE (搭配 Envoy 軟體的進階轉送功能) HTTPS 和 HTTP/2
全域外部 HTTP(S) 負載平衡器 (傳統版) GFE HTTPS 和 HTTP/2
區域型外部 HTTP(S) 負載平衡器 Envoy Proxy HTTPS 和 HTTP/2
TCP Proxy 負載平衡器 GFE 無。如要使用安全通訊協定,請使用安全資料傳輸層 (SSL) Proxy 負載平衡器。
安全資料傳輸層 (SSL) Proxy 負載平衡器 GFE SSL
內部 HTTP(S) 負載平衡器 Envoy Proxy HTTPS 和 HTTP/2
Traffic Director 用戶端 Proxy HTTPS 和 HTTP/2

安全後端通訊協定用途

在下列情況下,建議使用安全通訊協定連線至後端執行個體:

  • 當您需要從負載平衡器 (或 Traffic Director) 連到後端執行個體的可稽核加密連線。

  • 當負載平衡器透過網際網路 NEG 連線至 Google Cloud 外部的後端執行個體。與網際網路 NEG 後端之間的通訊可能會透過公開網際網路傳送。當負載平衡器連線至網際網路 NEG 時,公開 CA 簽署的憑證必須符合驗證要求

安全後端通訊協定注意事項

當使用安全後端服務通訊協定時,請注意下列事項:

  • 負載平衡器的後端執行個體或端點必須使用與後端服務相同的通訊協定來提供。舉例來說,如果後端服務通訊協定是 HTTPS,則後端必須是 HTTPS 伺服器。

  • 如果後端服務通訊協定是 HTTP/2,則後端必須使用傳輸層安全標準 (TLS)。如需設定操作說明,請參閱在後端執行個體或端點上執行的軟體說明文件。

  • 後端執行個體或端點上必須安裝私密金鑰和憑證,才能做為 HTTPS 或 SSL 伺服器使用。這些憑證不需要與負載平衡器的前端 SSL 憑證相符。如需安裝操作說明,請參閱在後端執行個體或端點中運作的軟體相關說明文件。

  • 除了採用網際網路 NEG 後端的 HTTPS 負載平衡器以外,GFE 不會使用伺服器名稱指示 (SNI) 擴充功能連線至後端。

  • 連線至 Google Cloud 中的後端時,GFE 會接受您的後端提供的任何憑證。GFE 不會執行憑證驗證。舉例來說,憑證在以下情況中視為有效:

    • 憑證為自行簽署。
    • 憑證由未知的憑證授權單位 (CA) 簽署。
    • 憑證已過期或尚未生效。
    • CNsubjectAlternativeName 屬性與 Host 標頭或 DNS PTR 記錄不符。

安全前端通訊協定

如果您在設定中使用目標 HTTPS 或目標 SSL Proxy,Google Cloud 會使用安全前端通訊協定。

HTTP(S) 負載平衡和 SSL Proxy 負載平衡會使用 Google 的 BoringCrypto 程式庫。如需 FIPS 140-2 的詳細資料,請參閱 NIST 密碼編譯模組驗證計畫憑證 #3678 相關說明。

內部 HTTP(S) 負載平衡會使用 Google 的 BoringSSL 程式庫。如需 FIPS 140-2 的詳細資料,請參閱 Envoy 說明文件。Google 會在符合 FIPS 規範的模式下建構適用於內部 HTTP(S) 負載平衡的 Envoy Proxy。

Traffic Director 支援在符合 FIPS 規範的模式下建構的 Envoy Proxy。

使用外部 IP 或網路負載平衡器 IP 直接連線至 VM

如果您正透過 VM 的外部 IP 或網路負載平衡 IP 連線,則連線不會經過 GFE。根據預設,這類連線不會經過加密,且其安全性由使用者自行負責。

使用 Cloud VPN

如果您是透過內部部署主機以 Cloud VPN 連線至 Google Cloud VM,則連入/連出地端部署主機的連線會依序傳送至地端部署 VPN、Cloud VPN 和 Google Cloud VM。地端部署 VPN 至 Cloud VPN 的連線是以 IPSec 保護。從 Cloud VPN 傳輸至 Google Cloud VM 的連線會經過 Google 驗證及加密。

使用 Cloud 專屬互連網路

如果您是透過專屬互連網路建立連線,該連線會直接連入/連出內部部署主機,而不會通過 GFE。根據預設,這類連線不會經過加密,且其安全性由使用者自行負責。您可以使用傳輸層安全標準 (TLS) 第 7 層的密碼編譯通訊協定,加密透過專屬互連網路傳輸的應用程式流量。

虛擬機器至虛擬機器

位於 Google 的實際工作環境網路中的虛擬私有雲網路,以及對等互連虛擬私有雲網路中的所有 VM 對 VM 連線都會經過驗證和加密。其中包括客戶 VM 之間,以及客戶與 Google 代管的 VM (例如 Cloud SQL) 之間的連線。圖 1 顯示了這項互動 (標為 C 連線)。

連線到 Google API 和服務

流量處理方式會根據 Google Cloud 服務的位置而有所不同:

  • 大部分的 Google API 和服務都在 Google Front Ends (GFE) 中託管;但部分服務則會在 Google 代管的執行個體中託管。舉例來說,私人服務存取權私人叢集的 GKE 主要執行個體會在 Google 代管的執行個體中託管。

    使用私人 Google 存取權時,沒有外部 IP 位址的 VM 可以存取支援的 Google API 和服務,包括託管在 App Engine 上的客戶應用程式。如要進一步瞭解 Google API 和服務的存取權,請參閱各項服務的私人存取權選項

  • 如果 Compute Engine VM 執行個體連線至另一個 Compute Engine VM 執行個體的外部 IP 位址,流量會在 Google 的實際工作環境網路中流通。而位於 Google 的實際工作環境網路以外的系統連線至 Compute Engine VM 執行個體的外部 IP 位址時,則可經由網際網路轉送流量。

    圖 1 顯示了外部路徑 (標為 D 連線)。這類轉送要求的典型案例如下:

    • 從 Compute Engine VM 到 Google Cloud Storage
    • 從 Compute Engine VM 到 Machine Learning API

根據預設,從 VM 到 GFE,Google Cloud 服務支援以傳輸層安全標準 (TLS) 保護這類連線2。從 GFE 傳送至服務的連線會經過驗證,連線離開實體界限時則會經過加密。

Google Cloud 服務之間的連線

產品服務之間的轉送作業發生在中樞網路上,且流量可能必須轉送至由 Google 控制或第三方代表 Google 控制的實體界限外部。圖 1 顯示了這項互動 (標為 E 連線)。Google Cloud Storage 事件觸發 Google Cloud Functions 的情況就屬於此類流量。如果產品服務之間的連線離開實體界限,就會受到加密,並且在實體界限之內進行驗證。

透過應用程式層傳輸安全性 (ALTS) 加密將使用者跨實體界限轉送至 Google Cloud 服務。

圖 1:虛擬私人雲端網路中的預設保護機制與重疊選項

預設的流動資料加密機制

Google 使用多種不同的流動資料加密機制,包括預設或是由使用者設定的加密方式。使用的加密方式會視 OSI 層級、服務種類以及基礎架構的實體元件而有所不同。下方的圖 2 和圖 3 說明了 Google Cloud 針對第 3、4、7 層設定的選用和預設保護措施。

第 3 與第 4 層的加密選項包括傳向 VM 及跨越界限的資料流量。

圖 2:Google Cloud 在第 3 與第 4 層設定的各項預設保護機制和選項

第 7 層的加密選項包括在 VM 之間傳輸及傳向 Google Front End 的資料。

圖 3:Google Cloud 在第 7 層設定的各項預設保護機制和選項3

下文會說明 Google 用來保護傳輸資料的預設保護機制。

使用者至 Google Front End 資料加密

目前有許多系統在網際網路中使用 HTTPS 來進行通訊。HTTPS 會使用傳輸層安全標準 (TLS) 連線來確保安全性,藉此保障要求和回應的真實性、完整性和隱私性。為接收 HTTPS 要求,接收者必須取得公開/私密金鑰組和 X.509 憑證,以便用於憑證授權單位 (CA) 規定的伺服器驗證程序。金鑰組和憑證可用來證明接收者擁有要求傳送目標的網域名稱,這樣即可在應用程式層 (第 7 層) 保護使用者的要求。以下小節會說明使用者到 GFE 的加密作業元件,包括傳輸層安全標準 (TLS)、BoringSSL 和 Google 的憑證授權單位。請注意,並非所有客戶路徑都是透過 GFE 轉送。GFE 主要用來將流量從使用者端傳送至 Google Cloud 服務,以及從使用者端傳送至託管於 Google Cloud (必須採用 Google Cloud Load Balancing) 的客戶應用程式。

傳輸層安全標準 (TLS)

使用者將要求傳送至 Google Cloud 服務時,我們會以 HTTPS 和公開網路憑證授權單位提供的憑證來證明完整性,並執行驗證和加密作業,藉此保護傳輸中的資料。在傳輸期間,使用者傳送至 GFE 的所有資料都會以傳輸層安全標準 (TLS) 或 QUIC 加密。GFE 會依據用戶端可以支援的通訊協定,與用戶端交涉特定的加密通訊協定,並盡可能選擇採用最現代化的加密通訊協定。

GFE 的擴充型 TLS 加密機制,不僅會套用於使用者和 Google 的互動,也有助於 API 在 TLS 上與 Google 互動,包括 Google Cloud。另外,我們的傳輸層安全標準 (TLS) 加密機制也應用於 Gmail,以便利用外部郵件伺服器交換電子郵件。詳情請參閱在 Gmail 中使用傳輸層安全標準 (TLS) 一節。

Google 是採用傳輸層安全標準 (TLS) 及強化傳輸層安全標準 (TLS) 實作項目的業界先鋒。因此,我們預設啟用了多項傳輸層安全標準 (TLS) 安全防護功能。舉例來說,自 2011 年起,我們就在傳輸層安全標準 (TLS) 實作項目中使用了正向密碼。正向密碼可以確保系統不會留存保護連線的金鑰。這樣一來,即便攻擊者能夠攔截及讀取某則訊息,也無法讀取先前的其他訊息。

BoringSSL

BoringSSL 是由 Google 負責維護的傳輸層安全標準 (TLS) 通訊協定開放原始碼實作項目。這個項目是 OpenSSL 的分支版本,因此與 OpenSSL 的介面大多相容。Google 將 BoringSSL 從 OpenSSL 中獨立出來是為了簡化 OpenSSL。這麼做不僅可以方便內部使用,也能更充分支援 Chromium 和 Android 開放原始碼計畫。BoringSSL 的核心「BoringCrypto」已通過 FIPS 140-2 第 1 級驗證。

我們同時在 GFE 中採用傳輸層安全標準 (TLS) 和 BoringSSL,表 1 列出了 GFE 與用戶端進行通訊時可支援的加密通訊協定。

通訊協定 驗證 金鑰交換 加密 雜湊函式
傳輸層安全標準 (TLS) 1.34 RSA 2048 Curve25519 AES-128-GCM SHA384
TLS 1.2 ECDSA P-256 P-256 (NIST secp256r1) AES-256-GCM SHA256
TLS 1.1     AES-128-CBC SHA18
傳輸層安全標準 (TLS) 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

表 1:Google Front End 中採用的加密機制 (適用於 Google Cloud 服務),以及在 BoringSSL 密碼編譯資料庫中實作的加密機制

Google 的憑證授權單位

伺服器隸屬於傳輸層安全標準 (TLS),因此伺服器收到連線要求時,必須向使用者證明其身分。為了在傳輸層安全標準 (TLS) 通訊協定中驗證伺服器的身分,伺服器必須提出含有其宣稱身分的憑證。這組憑證中包含伺服器的 DNS 主機名稱與公開金鑰。伺服器提出憑證之後,該組憑證就會由核發的憑證授權單位 (CA) 簽署,不過該憑證授權單位 (CA) 必須是提出連線要求的使用者信任的單位10。因此,向伺服器提出連線要求的使用者只需要信任根 CA。如果使用者希望能隨時隨地存取該伺服器,則全球的用戶端裝置都必須取得其根 CA。以大多數瀏覽器和其他傳輸層安全標準 (TLS) 用戶端現今的實作方式來說,使用者各自具備一組專屬的根 CA,並在其「根儲存庫」中設為受信任的根 CA。

Google 先前曾設有自己的憑證授權單位,以便為 Google 網域簽署憑證,不過並沒有自己的根 CA。我們的 CA 憑證目前是由遍布各地的多個根 CA 交叉簽署,包括 Symantec (「GeoTrust」) 和先前由 GlobalSign 負責管理的根 CA (「GS Root R2」和「GS Root R4」)。

我們在 2017 年 6 月宣布改為使用 Google 自己的根 CA。隨著時間累積,我們希望能經營一個廣泛分布的根 CA,為 Google 網域和我們的客戶核發憑證。

根金鑰遷移和金鑰輪替

根 CA 金鑰不會經常變更,因為如要遷移到新的根 CA,所有瀏覽器和裝置都必須嵌入對該憑證的信任,而這項作業相當費時。因此,雖然目前 Google 有在經營自己的根 CA,我們仍會在過渡期間繼續使用多個第三方的根 CA,以在遷移到我們自己的 CA 時仍能顧及舊版裝置。

建立新的根 CA 需要進行一項金鑰儀式。對 Google 來說,6 位獲得授權的人選中,至少需有 3 位實際到場,才能使用儲存於保險箱內的硬碟鑰匙。授權人員會在專用房間內建立一組金鑰和憑證,該房間除了能夠防止電磁波干擾,還設有氣隙隔離的硬體安全性模組 (HSM)。該專用房間位於 Google 資料中心內的安全位置。除了實體安全措施、攝影監視器等額外控管之外,還會有其他人員負責監看,以確保程序按計畫進行。如果流程順利執行完畢,產生的憑證除了核發者名稱、公開金鑰和簽名不同之外,其他部分會與樣本憑證完全相同。接著,系統會將流程產生的根 CA 憑證提交給瀏覽器和裝置的根計畫,以便納入憑證。這項流程可以確保系統妥善解讀關聯私密金鑰的隱私性和安全性,這樣金鑰才能沿用十年以上。

如先前所述,CA 會使用自身的私密金鑰來簽署憑證,而這些憑證會在系統啟動傳輸層安全標準 (TLS) 握手程序時驗證身分,做為使用者工作階段的一環。伺服器憑證是以中繼 CA 簽署,這類 CA 的建立方式與根 CA 相仿。中繼 CA 的憑證會在傳輸層安全標準 (TLS) 工作階段中發布,因此可以更輕鬆地遷移至新的中繼 CA。另外,這個發布方法也讓 CA 營運商得以在離線狀態下保留根 CA 金鑰內容。

傳輸層安全標準 (TLS) 工作階段的安全性取決於伺服器的金鑰保護程度。為進一步降低金鑰遭駭的風險,Google 的傳輸層安全標準 (TLS) 憑證生命週期上限約為三個月,而且憑證通常每兩週輪替一次。

先前曾連線至伺服器的用戶端可以使用私密票證金鑰11,透過簡略的傳輸層安全標準 (TLS) 握手程序接續先前的工作階段,因此這類票證對攻擊者來說極具價值。Google 每天至少會輪替票證金鑰一次,且每 3 天所有資源上的金鑰就會到期。如要進一步瞭解工作階段金鑰票證的輪替機制,請參閱 Measuring the Security Harm of TLS Crypto Shortcuts (評估傳輸層安全標準 (TLS) 密碼編譯捷徑的安全性傷害)。

Google Front End 至應用程式前端

流量轉送方式一節中曾經提到,使用者在某些情況下會連線至不同實體界限內的 GFE,而非所需的服務和關聯應用程式前端。當這種情況發生時,使用者的要求以及其他第 7 層通訊協定 (如 HTTP),若非受 TLS 保護,就是壓縮在遠端程序呼叫 (RPC) 機制中,而 RPC 是以應用程式層傳輸安全性 (ALTS) 保護,如同服務對服務的驗證、完整性和加密機制所述。這些遠端程序呼叫 (RPC) 會經過驗證及加密。

對於 Google Cloud 服務而言,RPC 預設是以 ALTS 保護。至於託管在 Google Cloud 上的客戶應用程式,如果流量是透過 Google Front End 轉送,例如正在使用 Google Cloud 負載平衡器的情況,轉送至 VM 的流量就會受到 Google Cloud 虛擬網路加密機制的保護,下節會詳加說明。

Google Cloud 的虛擬網路加密和驗證

在相同的虛擬私有雲,或位於 Google Cloud 虛擬網路內的對等互連虛擬私有雲網路之間的私人 IP 流量,加密機制會在網路層執行。

我們會在 Galois/計數器模式 (GCM) 下使用進階加密標準 (AES),以 128 位元金鑰 (AES-128-GCM) 在網路層部署加密程序。每一對通訊主機都會透過控制頻道建立一組工作階段金鑰,並以 ALTS 提供防護機制,以便用於經過驗證及加密的通訊內容。該組工作階段金鑰可用來加密主機之間所有的 VM 對 VM 通訊內容,工作階段金鑰也會定期輪替。

在網路層 (即第 3 層) 中,Google Cloud 虛擬網路會驗證 VM 之間的所有流量。這項驗證作業是以安全性符記執行,可避免遭到入侵的主機在網路中以假冒的身分傳送封包。

在這項驗證程序中,安全性符記會封裝於通道標頭,當中包含傳送者與接收者的相關驗證資訊。傳送端的控制層12 會設定符記,接收端的主機則會驗證該組符記。每次流程都會預先產生安全性符記,由含有傳送者資訊和主機密鑰的符記金鑰所組成。每組由 Google 控制或第三方代表 Google 控制的實體界限與所有來源接收方的配對,都會存在一個密鑰。

圖 4 呈現了符記金鑰、主機密鑰和安全性符記的建立過程。

安全性符記的元件部分可能包含憑證金鑰、主機密鑰,以及其依附元件。

圖 4:安全性符記

實體界限密鑰是 128 位元的偽隨機數,其中主機密鑰是採用 HMAC-SHA1 衍生而來。實體界限密鑰由一組實體界限網路控制層之間的握手交涉而得,且每隔幾小時就會重新交涉一次。個別 VM 對 VM 驗證所用的安全性符記為 HMAC,是由這類和其他輸入內容衍生而來,是為了指定的發送方和接收方配對而交涉。

服務對服務的驗證、完整性和加密機制

在 Google 的基礎架構中,我們在應用程式層 (即第 7 層) 使用了自己的應用程式層傳輸安全性 (ALTS),藉此確保 Google 遠端程序呼叫 (RPC) 從 GFE 傳送至服務的呼叫,以及服務對服務的呼叫均能經過驗證及加密,並保障其完整性。

ALTS 會使用服務帳戶進行驗證,每項在 Google 基礎架構內執行的服務,均會以含有相關加密編譯憑證的服務帳戶身分來執行。當以其他服務產生或接收 RPC 時,服務會使用自己的憑證進行驗證。ALTS 使用內部憑證授權單位來驗證這些憑證。

在 Google 或 Google 代理單位控管的實體界限內,ALTS 會在「資料驗證和完整性」模式下提供 RPC 的驗證和完整性。至於在 Google 或 Google 代理單位控管的實體界限 WAN 之外的流量,ALTS 會在「資料驗證、完整性和隱私性」模式下自動強制加密基礎架構的 RPC 流量。目前所有送往 Google 服務的流量,包括 Google Cloud 服務在內,均可受惠於這些相同的保護機制。

用以從 Google Front End 轉送流量到應用程式前端的基礎架構 RPC 機制中,也會使用 ALTS 壓縮其他第 7 層的通訊協定 (如 HTTP)。這項保護機制會隔離應用程式層,並移除用於維持網路路徑安全性的所有依附元件。

就算資料在 Google 控制或第三方代表 Google 控制的實體界限內,還是可以將服務設定為只在「資料驗證、完整性和隱私性」模式下接受和傳送 ALTS 通訊。舉例來說,Google 的內部金鑰管理服務 (存於 Google 基礎架構中的靜態資料所用的加密保護金鑰,是由這項服務來儲存、管理) 就是依照前述的模式運作。

ALTS 通訊協定

ALTS 具備近似於雙向傳輸層安全標準 (TLS) 的安全握手通訊協定,想要透過 ALTS 進行通訊的兩項服務會採用這個握手通訊協定,以便在傳送任何機密資訊前進行驗證及交涉通訊參數。這個通訊協定中包含兩個步驟:

  • 步驟 1:握手 用戶端透過使用 Curve25519 的伺服器啟動橢圓曲線 Diffie Hellman (ECDH) 握手程序。用戶端和伺服器各有認證的 ECDH 公開參數,這是屬於其各自的憑證;這個憑證也會在 Diffie Hellman 金鑰交換期間使用。這類握手會產生可供用戶端及伺服器使用的共用流量金鑰。來自憑證的對等身分會出現在應用程式層內,以便在授權決策中使用。
  • 步驟 2:記錄加密 使用來自步驟 1 的共用流量金鑰,將資料從用戶端安全地傳輸到伺服器。ALTS 加密實作則是使用 BoringSSL 及其他加密程式庫來進行。加密機制是最常見的 AES-128-GCM,AES-GCM 的 GMAC 則能確保完整性。

下圖顯示了 ALTS 握手的詳細資訊。在較新的實作方式中,會由程序輔助程式執行握手,但是在某些情況下,仍會由應用程式直接執行握手。

用戶端應用程式會透過程序輔助程式與握手服務互動,並透過金鑰交換與伺服器應用程式進行互動。

圖 5:ALTS 握手程序

服務對服務的驗證、完整性和加密機制一節開頭所述,ALTS 會使用服務帳戶進行驗證,每項在 Google 基礎架構內執行的服務,均會以含有相關加密編譯憑證的服務帳戶身分來執行。在這類 ALTS 握手作業中,這類程序輔助程式可存取私密金鑰和相對應的憑證,而該憑證也會用於每組用戶端和伺服器配對的通訊之中。系統會佈建該組私密金鑰和相對應的憑證 (已簽署的通訊協定緩衝程序),以便該項服務的服務帳戶身分使用。

ALTS 憑證 ALTS 憑證分為以下種類:

  • 機器憑證:提供身分識別憑證給特定機器上的核心服務。這類憑證大約每 6 小時輪替一次。
  • 使用者憑證:提供使用者身分供開發程式碼的 Google 工程師使用。這類憑證大約每 20 個小時輪替一次。
  • Borg 工作憑證:提供身分識別憑證給在 Google 基礎架構中執行的工作。這類憑證大約每 48 個小時輪替一次。

根憑證簽署金鑰會儲存在 Google 的內部憑證授權單位 (CA) 中,這代表該組憑證與我們的外部 CA 無關,而是獨立的憑證。

ALTS 加密

視所用的機器而定,ALTS 中的加密作業可以透過不同演算法實作。舉例來說,大多數服務使用的是 AES-128-GCM13。表 2 提供了 ALTS 加密作業的相關詳細資料。

機器 使用的訊息加密機制  
最常見 AES-128-GCM  
Sandy Bridge 或更早的版本 AES-128-VCM 使用 VMAC 而非 GMAC,在這些舊版機器中的實作效率會略為升高。

表 2:ALTS 加密機制

大多數 Google 服務都是使用 ALTS,或是採用 ALTS 的遠端程序呼叫 (RPC) 封裝內容。在未採用 ALTS 的情況下,系統會使用其他保護機制。例如:

  • 部分低階機器管理和引導服務使用 SSH
  • 部分低階基礎架構記錄服務會使用傳輸層安全標準 (TLS) 或 Datagram TLS (DTLS)14
  • 在 Google 或 Google 代理單位控管的實體界限內,部分使用非 TCP 傳輸協定的服務會使用其他密碼編譯通訊協定或網路層保護機制

VM 和 Google Cloud Platform 服務之間的通訊內容是以傳輸層安全標準 (TLS) 傳送至 Google Front End,而不是使用 ALTS。在虛擬機器對 Google Front End 加密一節中,我們會另行說明這類通訊作業。

虛擬機器對 Google Front End 加密

從 VM 傳送至 GFE 的流量會透過外部 IP 傳輸至 Google 服務,但您也可以將私人 Google 存取權功能設為以僅適用於 Google 的 IP 位址來處理要求。

根據預設,針對外部使用者向 Google 提出的要求,我們支援從 VM 傳送至 GFE 的傳輸層安全標準 (TLS) 流量。這類連線的產生方式與其他外部連線相同。如要進一步瞭解傳輸層安全標準 (TLS),請參閱傳輸層安全標準 (TLS)

可由使用者設定的流動資料加密選項

傳輸加密一文說明了 Google 對傳輸資料設置的預設保護機制。本節則會說明使用者可對這些預設保護機制進行的自訂設定。

內部部署資料中心至 Google Cloud

使用 GCLB 外部負載平衡器的 TLS

如果您的雲端服務使用的是 Google HTTPS 或安全資料傳輸層 (SSL) Proxy 外部負載平衡器,則在採用您佈建及控管的安全資料傳輸層 (SSL) 憑證的使用者建立傳輸層安全標準 (TLS) 連線之後,GFE 就會將該連線終止。如要進一步瞭解如何自訂憑證,請參閱安全資料傳輸層 (SSL) 憑證說明文件

使用 Cloud VPN 的 IPSec 通道

Google Cloud 客戶可以使用 Google Cloud VPN,透過 IPsec VPN 連線 (第 3 層) 安全地從地端部署網路連線至 Google Cloud 虛擬私有雲網路。在這兩個網路之間傳輸的流量會經由其中一個 VPN 閘道加密,然後由另一個 VPN 閘道解密,這樣即可確保您的資料在網際網路中安全無虞。另外,您也可以透過多個 VPN 閘道設定多個已平衡負載的通道。Google Cloud VPN 會透過下列方式保護您的資料:

  • 從您的 VM 傳送至 Cloud VPN 閘道的封包還是位在虛擬私人雲端網路中。這些封包會透過 Google Cloud 的虛擬網路驗證及加密。
  • 從 Cloud VPN 傳送至您的地端部署 VPN 的封包會以 IPSec 通道驗證及加密。
  • 自您的內部部署 VPN 至內部部署主機的封包則由您網路本身所有的控管機制保護。

如要設定 VPN,請在託管服務的虛擬私有雲網路中建立 Cloud VPN 閘道和通道,然後允許這兩個網路之間的往來流量。您也可以選擇設定兩個虛擬私有雲網路之間的 VPN。

您可以指定 VPN 通道的網際網路金鑰交換15 (IKE) 版本,進一步自訂網路。有 IKEv1 和 IKEv2 兩種版本的 IKE 可供選擇,各自支援不同的加密。如果您指定的版本為 IKEv1,Google 會使用 AES-128-CBC 來加密封包,並透過 SHA-1 HMAC16 確保資料的完整性。如果您指定的版本為 IKEv2,Google 則會提供並支援多種加密機制。不論在任何情況下,Google Cloud VPN 會以對等裝置所支援的最安全的共用通訊協定進行交涉。如需設定 VPN 的詳細操作說明,請參閱選擇 VPN 轉送選項一文。

除了 Cloud VPN (IPSec) 通道之外,您也可以使用 Google Cloud 專屬互連網路。在地端部署網路和虛擬私有雲網路之間,專屬互連網路可以提供直接的實體連線和私人 IP 通訊程序。根據預設,採用專屬或合作夥伴互連網路的資料傳輸作業「不會」經過加密,因此資料必須在應用程式層受到保護,例如使用傳輸層安全標準 (TLS) 提供安全防護。目前系統不支援 MACsec (第 2 層保護機制)。

使用者至 Google Front End

代管 SSL 憑證:免費且自動化的憑證

在 Google Cloud 上建構應用程式時,可以設定您所使用的 SSL 憑證,藉此善加利用 GFE 支援的 TLS。舉例來說,您可以在應用程式內終止 TLS 工作階段。這項終止作業與 使用 GCLB 外部負載平衡器的傳輸層安全標準 (TLS) 中所述的傳輸層安全標準 (TLS) 終止作業不同。

Firebase 代管Google App Engine 的自訂網域中,Google 也提供自動化的免費安全資料傳輸層 (SSL) 憑證。這些憑證僅供託管於 Google 的資源使用。使用 Google App Engine 自訂網域時,您也可以提供自己的安全資料傳輸層 (SSL) 憑證,並使用 HTTP 嚴格傳輸安全性 (HSTS) 標頭。

您的網域指向 Google 的基礎架構後,我們會要求並取得該網域的憑證,以執行安全的通訊。我們會管理 TLS 伺服器的私密金鑰 (若非 2048 位元 RSA 即為 secp256r1 ECC),並代客戶更新憑證。

在 Gmail 中使用傳輸層安全標準 (TLS)

如同傳輸層安全標準 (TLS) 中所述,Gmail 預設使用傳輸層安全標準 (TLS)。Gmail 會記錄及顯示電子郵件是否在傳輸層安全標準 (TLS) 工作階段中建立了最後一個躍點17。Gmail 使用者與另一位 Gmail 使用者交換電子郵件時,郵件會受到傳輸層安全標準 (TLS) 的保護。不過在某些情況下,這些郵件會直接在應用程式中傳送。此時,Gmail 應用程式使用的遠端程序呼叫 (RPC) 會受到 ALTS 的保護,如服務對服務的驗證、完整性和加密機制一節中所述。如果傳入的郵件來自其他電子郵件服務供應商,Gmail 就不會強制執行傳輸層安全標準 (TLS)。Gmail 管理員可以將 Gmail 設為所有傳入和傳出電子郵件均須使用安全的傳輸層安全標準 (TLS) 連線。

Gmail S/MIME

安全/多用途網際網路郵件延伸標準 (S/MIME) 是一種電子郵件安全性標準,可提供資料驗證、完整性和加密。S/MIME 標準的實作方式規定,與使用者傳送電子郵件相關的憑證需託管在公開 CA 中。

管理員可以調整 Gmail 設定,藉此對傳出的電子郵件啟用 S/MIME、設定內容和附件的規範政策,並為傳入和傳出的電子郵件建立轉送規則。完成設定之後,您必須使用 Gmail API 將使用者的公開憑證上傳至 Gmail。非 Gmail 使用者必須先交換以 S/MIME 簽署的初始電子郵件,接著才能將 S/MIME 設為預設選項。

服務至服務和 VM 至 VM 的加密

Istio 是 Google、IBM、Lyft 及其他供應商所開發的開放原始碼服務網格,用意在於簡化服務探索和連線。Istio 驗證程序提供了服務之間的自動化傳輸資料加密,同時可管理相關金鑰和憑證。Istio 可用於 Google Kubernetes Engine 和 Google Compute Engine。

如要執行雙向驗證和工作負載加密作業,您可以使用 Istio 驗證 (特別是在 Kubernetes 中的工作負載)。Istio 驗證允許叢集層級的 CA 產生及發布憑證,該組憑證接著會用於 pod 對 pod 雙向傳輸層安全標準 (mTLS)。

Google 如何協助推廣網際網路流動資料加密機制

預設流動資料加密可由使用者自行設定的流動資料加密選項段落中,我們說明了 Google Cloud 針對流動客戶資料提供的自訂和預設保護機制。此外,Google 有數個開放原始碼的專案和其服務,鼓勵大家在網際網路上廣為使用流動資料加密和資料安全機制。

憑證透明化

使用者至 Google Front End 資料加密中所述,網站必須先申請受信任公開網路憑證授權單位 (CA) 核發的憑證,才能提供 HTTPS。憑證授權單位負責驗證申請者是否已獲得網域擁有者的授權,並確保憑證中包含的任何其他資訊均正確無誤。接著,系統會將這組憑證提交給瀏覽器,藉此驗證使用者想要存取的網站。為確保 HTTPS 經過妥善驗證,您必須確認 CA 只核發該名網域擁有者已授權的憑證。

憑證透明化 (CT) 是 Google 在 2013 年 3 月推出的服務,可讓網站營運商和網域擁有者偵測 CA 是否核發任何未經授權或不正確的憑證。這項服務的運作方式為向網域擁有者、CA 和大眾提供一種機制,方便他們記錄自己看見的受信任憑證 (對 CA 來說則是自己核發的憑證),其形式為可公開驗證、僅供附加且可預防破壞的記錄檔。任何人都能檢查這些記錄檔中的憑證,確保資訊正確無誤且經過授權。

IETF 實驗性的 RFC (RFC 6962) 中載明了初版的憑證透明化。在憑證透明化的開發作業期間,Google 也開放了多項工具的原始碼,當中包含可記錄憑證的開放原始碼記錄檔伺服器,以及可建立憑證透明化記錄檔的工具。另外,Google Chrome 要求某些憑證必須對外公開,例如延伸驗證 (EV) 憑證,或是過去曾誤發憑證的 CA 核發的憑證。2018 年起,Chrome 要求揭露所有新的公開信任憑證。

有了憑證透明化,網站營運商就能偵測自己的網站是否收到未經授權的憑證。您可以透過幾項免費工具輕鬆進行檢查,例如 Google 的憑證透明化報告憑證搜尋Facebook 提供的工具。即使未使用憑證透明化服務,現在仍有數個瀏覽器會定期檢查憑證透明化,以確保使用者所信任而存取您網站的 CA 確實遵循業界規定和最佳做法,減少詐欺性憑證核發的風險。

提高 HTTPS 的使用率

使用者至 Google Front End 資料加密中所述,我們致力於確保 Google 的網站和服務可以預設提供新世代 HTTPS。我們的目標是在所有產品和服務上達成百分之百的加密機制。為達成這個目標,我們每年都會發布 HTTPS 資訊公開報告,藉此追蹤所有資源實踐目標的進度,當中也包含 Google Cloud。我們會持續克服技術障礙,突破某些產品無法支援加密機制的困境,例如適用於瀏覽器的解決方案,或是不支援 HTTP 嚴格傳輸安全性 (HSTS)18 的其他用戶端。我們在 google.com 首頁等幾個網站中採用 HTTP 嚴格傳輸安全性,讓使用者只能透過 HTTPS 連線至伺服器。

我們瞭解網際網路中的其他網站同樣致力於改用 HTTPS,以下是我們嘗試推動這項變革的幾個方法:

2016 年起,我們便開始針對網際網路中前 100 名的非 Google 網站發布「網際網路中的 HTTPS 使用率」指標。這些指標旨在提高此議題的關注,讓網際網路使用者能更安全的使用網路。2017 年 10 月,Chrome 正式承諾繼續向「Let’s Encrypt」計畫提供經濟支援,並成為白金級贊助者。

提高安全 SMTP 的使用量:Gmail 指標

大多數的郵件在交換時會使用簡易郵件傳輸通訊協定 (SMTP),預設中電子郵件的傳送並不會使用加密機制。如果要加密郵件,電子郵件供應商必須使用如 TLS 的安全控管規範。

使用者至 Google Front End 資料加密中所述,Gmail 會依預設使用傳輸層安全標準 (TLS)。另外,在 Gmail 中使用傳輸層安全標準 (TLS) 一節說明了 Gmail 管理員如何對傳入和傳出的電子郵件強制執行傳輸層安全標準 (TLS) 保護機制。如同 Google 致力於推動 HTTPS 透明化一樣,Gmail 對傳入 Gmail 的郵件也提供使用 TLS 上的資料。在更安全的電子郵件資訊公開報告中,您可以找到這項資料。

Google 與 IETF 和其他業界龍頭合作夥伴一起帶領開發 SMTP STS。SMTP STS 和 HTTPS 的 HSTS 相似,可在只有加密過的管道上強制使用 SMTP。

Chrome API

2015 年 2 月時,Chrome 宣布只有安全的來源才能使用強大的新功能19,包括處理私人資訊和存取至使用者裝置上的感應器等功能。自 Chrome 50 版中的地理位置起,我們便開始針對不安全的來源淘汰這些功能。

流動資料加密機制的持續革新

Chrome 安全性使用者體驗

Google Chrome 率先運用使用者介面顯示安全性資訊,讓使用者得以迅速瞭解自己與網站的連線是否安全。透過這項資訊,使用者可以對共享資料的時機和方式做出明智決定。Chrome 也進行廣博的使用者研究,研究成果分享於同儕評論報告之中。

為進一步保護 Chrome 使用者,Chrome 宣布會在 2017 年年底前將所有 HTTP 連線標示為不安全。自 Chrome 56 版起,如果 HTTP 頁面中的表單含有密碼或信用卡欄位,系統會依預設向使用者顯示警告訊息。在 Chrome 62 版中,如果使用者在 HTTP 頁面中輸入資料,或是以無痕模式造訪任何 HTTP 頁面,系統都會顯示警告訊息。最後,Chrome 將在所有透過 HTTP 供應的頁面上顯示警告訊息。

如果要瞭解 Chrome 中如何對使用者顯示特定設定,您可以使用 BadSSL 工具

金鑰透明化

無法廣泛採用郵件加密機制的最大癥結點在於難以交換公開金鑰:針對正在與我通訊的新使用者,我該如何以可靠的方式找出其公開金鑰?為協助解決這個問題,Google 在 2017 年 1 月宣布金鑰透明化。這個開放式架構提供的一般性方法可供稽核,讓您以安全的方式發布公開金鑰,而使用者也不需要手動執行金鑰驗證程序。金鑰透明化的主要目標為發布使用者在通訊時的公開金鑰,例如 E2E 和 OpenPGP 電子郵件加密。金鑰透明化的設計是一種復原及發布金鑰的新方法,並以透過憑證透明化CONIKS 獲得的深入分析結果為基礎。

金鑰透明化屬於開放原始碼開發項目,實作時使用了大規模的默克爾樹 (Merkle tree)。金鑰透明化驗證可讓帳戶擁有者看見自己的帳戶中與哪些金鑰相關聯,以及帳戶的使用時間多久,以及帳戶穩定的時間長短。Google 的金鑰透明化工作的長期目標就是讓所有人執行金鑰透明化伺服器,並使之易於和不限數量的應用程式整合。

後量子密碼編譯

Google 計劃在傳輸加密技術上繼續引領業界。為了達成此目標,我們開始研究後量子密碼編譯的領域。透過這種密碼編譯方式,能夠以後量子候選選項取代易遭受高效率量子攻擊的現有密碼編譯基本功能;一般認為後量子候選項目應具有更強固的防禦能力。2016 年 7 月,我們宣布已在 Chrome 開發人員版本中使用 New Hope 後量子密碼編譯演算法,對部署這類演算法的可行性進行實驗。除了這項成果以外,Google 的研究人員也發布了其他可行後量子金鑰交換通訊協定的相關報告

附錄

進一步瞭解 Google Cloud 安全性 (包括基礎架構安全性設計總覽) 和 Google Cloud 的法規遵循情況 (包括公開的 SOC 3 稽核報告)。

註釋

1 合作夥伴解決方案包含 Cloud Launcher 中提供的解決方案,以及 Google 與合作夥伴攜手打造的產品 (例如 Cloud Dataprep)。
2 您還是可以停用這項加密機制,例如透過 HTTP 存取 Google Cloud Storage 值區時。
3 在第 7 層未受到保護的 VM 對服務通訊內容在第 3 層和第 4 層中仍會受到保護。
4 傳輸層安全標準 (TLS) 1.3 尚未完成,我們目前僅在特定 Google 網域中部署草稿版本來進行測試,例如 Gmail。
5 針對仍在使用這個通訊協定版本的瀏覽器,Google 支援傳輸層安全標準 (TLS) 1.0。提醒您,在付款卡產業 (PCI) 相關法規要求淘汰傳輸層安全標準 (TLS) 1.0 之後,所有會處理信用卡資訊的 Google 網站已自 2018 年 7 月起停止支援傳輸層安全標準 (TLS) 1.0。
6 如要進一步瞭解 QUIC,請參閱 https://www.chromium.org/quic
7、8、9 為維持某些舊版作業系統的回溯相容性,我們目前仍支援三重數據加密算法、SHA1 和 MD5。
10 以鏈結憑證來說,CA 會連帶受到信任。
11 可能是工作階段案件 RFC 5077 或工作階段 ID RFC 5246
12 負責轉送流量的控制層是網路的一部分,當中含有可發送訊號的流量。
13 先前曾使用其他通訊協定,但現已淘汰。目前只有不到 1% 的工作使用這些舊版通訊協定。
14 Datagram TLS (DTLS) 允許應用程式透過可防範資料竊取與竄改的方式進行通訊,藉此保護資料包類型的應用程式。
15 網際網路金鑰交換 (IKE) 是用來在 IPSec 通訊協定組合中設定安全性關聯的通訊協定。
16 HMAC-SHA-1 不會因 SHA-1 碰撞而遭到破壞,例如 Google 研究人員發現的 SHAttered 碰撞。
17 以 Enterprise Plus 來說,這項資料不會顯示在使用者介面中。網域管理員可以使用電子郵件記錄檔搜尋來檢查自有網域的資料。
18 HTTP 嚴格傳輸安全性 (HSTS) 這項機制會讓網站宣告本身只能透過安全的連線加以存取,並/或允許使用者限定使用者代理程式只能透過安全的連線與指定的網站互動。
19 「安全來源」是指與特定架構、主機或通訊埠 模式相符的連線。