Amazon Corretto 27加入PQC混合交換：Java TLS升級先看相容性

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-09-30

Amazon Corretto 27已正式推出。iThome 報道指出，這個免費的 OpenJDK 發行版本納入 JEP 527，讓 TLS 1.3 可使用後量子混合金鑰交換；同時加入 JEP 536，為 Java Flight Recorder（JFR）帶來程序內資料遮蔽。對維護面向互聯網 Java 服務的團隊來說，前者關乎加密連線的長期遷移準備，後者則直接影響生產環境收集除錯資料時，如何減少敏感內容外流。

不過，這不代表安裝新 JDK 後，所有 Java 流量便即時獲得完整的量子防護。混合金鑰交換能否用上，仍取決於連線兩端及中間網絡設備對 TLS 1.3 協商的支援情況。企業若有舊版客戶端、TLS 終止代理、負載平衡器或第三方 API 連線，升級前尤其要檢查協商結果及相容性回復機制；否則，即使 JDK 提供相關功能，實際服務亦未必會採用。

混合金鑰交換把遷移工作帶進TLS層

iThome 指出，JEP 527 將傳統與後量子金鑰交換演算法結合到 TLS 1.3 連線之中。這個設計的實際意義，是讓現有公鑰密碼學的保護與面向未來量子運算威脅的機制同時參與金鑰建立，而非要求企業一次過押注單一新演算法。從系統管理角度看，它較像為現有 TLS 架構提供一條可逐步採用的遷移路徑。

這種安排回應的是「先截取、後解密」的長期風險：若某些通訊內容需要多年保密，攻擊者理論上可先保存今日加密流量，等待日後能力改變再嘗試破解。因此，處理長保存期限客戶資料、商業文件或內部系統通訊的 Java 服務，應開始分辨哪些連線值得優先評估。這是基於功能用途作出的部署分析，並非指 Corretto 27 已替所有資料種類解決保密年期問題。

Java團隊要驗證的是整條連線，而非JDK版本

對香港金融、電商及企業雲端環境的 Java 團隊而言，較務實的第一步是建立 TLS 依賴清單：哪些服務由 JVM 直接提供 HTTPS，哪些經 CDN、API gateway 或反向代理終止 TLS，哪些需要與合作夥伴或舊有流動應用程式溝通。只有把這些環節串起來，團隊才可判斷混合金鑰交換在何處可被協商，以及在哪些位置可能因相容性而不適合立即啟用。

測試亦不宜只看服務能否啟動。部署團隊可在非生產環境比較不同客戶端、代理與 server 組合下的握手成功率、協商出的 TLS 參數及連線錯誤紀錄，並預備可回退的發布安排。由於加密套件協商會跨越應用程式、JDK 和網絡邊界，單靠開發部門更新 runtime 不足以完成遷移；資安、平台與網絡營運人員需要共同確認影響範圍。

iThome 報道亦提到，Oracle 在 9 月 15 日發布 Java 27，兩日後開放下載的 Corretto 27定位為功能發行版本，兩者均包含相關 JEP。對使用 Corretto 的企業，這提供了把評估納入正常 JDK 升級周期的切入點；但是否採用仍須配合自身的支援政策、相關框架測試及變更時段。將「可用功能」與「可安全大規模啟用」分開處理，會較穩陣。

JFR遮蔽讓生產除錯少一個資料出口

另一項較貼近日常營運的更新是 JEP 536。據 iThome 報道，JFR 可在記錄資料離開 JVM 前，於程序內遮蔽敏感資訊。JFR 原本用於蒐集 Java 應用程式及 JVM 的執行資料，以協助效能分析和問題診斷；然而，診斷檔案一旦包含客戶、員工、營運或受監管資料，分享給開發、支援或外部分析流程時，便可能形成額外的資料處理風險。

把遮蔽放在 JVM 內部處理，價值在於縮短原始敏感資料可出現在記錄檔中的路徑。團隊毋須因此假設 JFR 檔案可任意流轉：資料遮蔽規則是否覆蓋實際欄位、誰可啟動錄製、檔案存放多久、可由誰下載，仍然需要內部權限與保留政策配合。尤其在事故壓力下，工程人員往往傾向收集更多資料；預先設計好遮蔽與存取流程，才較容易兼顧除錯速度和資料保護。

升級評估應把加密與可觀測性一併處理

PQC 混合交換和 JFR 資料遮蔽看似分屬傳輸加密與可觀測性，實際上都反映 Java 生產環境的一個共同課題：安全控制必須嵌入既有營運流程。前者要求盤點跨系統 TLS 相容性，後者要求重新檢視診斷資料的生命週期。若企業只把 Corretto 27 視為例行 runtime 更新，便容易忽略這兩項功能背後涉及的架構和管治工作。

下一步值得留意的，是各企業是否會將 JEP 527 的 TLS 協商測試納入 Java 27 升級驗證，以及把 JEP 536 的遮蔽規則接入既有事故應變與合規程序。對擁有大量對外 Java API 或需要在生產環境頻繁分析 JVM 問題的團隊，這兩項工作會比單純確認版本號更具實際影響。