2016-02-19 107 views
0

我正在使用GuzzleHttp\Client與API進行通信。 API的運營商正在禁用SSL和1.2之前的TLS,並告訴我我的應用程序仍在使用較早的協議。在拼圖中強制使用TLS 1.2

我該如何確保Guzzle只使用最新的?我不確定我的Guzzle版本是什麼(我沒有設置它),它沒有在源代碼中的任何地方顯示。

+0

您的客戶端可能支持TLS 1.2,如果這是唯一可用的協議,則可以。您無需強制Guzzle使用最新版本的TLS:無論如何,服務器都將舊版本帶走。您真正需要問的問題是「我的客戶*支持* TLS 1.2嗎?」您不必擔心*強制*您的客戶端使用它:服務器將執行此操作。 – TRiG

回答

1

直到最近,我還爲一家名爲WePay的公司工作,負責處理財務信息,並受到PCI-DSS更改的影響,該更改聲明早期版本的TLS不再被認爲是安全的,並且我們需要所有客戶推到TLS 1.2。直到2018年6月,這種PCI-DSS要求才放寬,但您仍應儘早確保兼容。

我的任務是研究客戶如何受到影響(例如,PHP,Java,Ruby,C#),並記錄我發現的所有內容。我在這裏寫的是來自內存,因爲我不再爲WePay工作或訪問其內部Confluence頁面。


Guzzle有多種傳輸方法,包括PHP流,以及PHP的cURL擴展。

  1. PHP流(如fsockopen())沒有關於TLS支持保障,所以真的,你應該確保你的PHP安裝已安裝PHP cURL擴展(包括底層libcurl.so庫, 假設你的Web服務器Linux的)。

  2. 您的底層捲曲/ libcurl必須是版本7.35.0或更新。面向消費者的Linux可能有更新的版本。我可以告訴你,比CentOS/RHEL/OracleLinux 6.8附帶cURL 7.19.0(太舊),7.3附帶7.29.0(也太舊)。我沒有花太多時間在Ubuntu/Debian/SLES上,所以您需要自行調查這些選項。對於CentOS/RHEL/OracleLinux,您可以自己編譯和打包cURL,或者您可以依賴Cityfan repo(取決於來自EPEL的軟件包)的cURL。

    與往常一樣,從不信任第三方依賴關係。要麼知道誰編譯/打包代碼並將其作爲資源信任,要麼自己編譯/打包代碼。

  3. 您還需要兼容的PHP版本。支持TLS 1.2的PHP的第一個版本是PHP 5.5.19和PHP 5.6.3。版本低於5.6.0的PHP是EOL,並且不再接收任何安全更新,因此從一個專業人員到另一個專業人員,我會強烈鼓勵您升級,如果您的版本超過5.6.0。

  4. 一些不是PHP本地人的開發人員可能會使用工作的代碼,但實際上對您不利。在一個大的,傳統的代碼庫,它並不少見:

    1. 老派流功能(例如,fsockopen()fopen($remote_url))。這些通常被認爲是針對HTTP(S)請求的Bad™,並且就TLS支持而言是不可靠的。

    2. 調用curl_*直接起作用。 cURL是一個非常複雜的野獸,有許多不錯的選擇和很多不好的選擇。作爲一般規則,如果您直接在PHP中使用cURL函數,幾乎可以確定您正在做錯誤™。

    3. 最好的方法是使用專門的,編寫良好,經過充分測試的HTTP庫,例如Guzzle(或Requests,或Buzz)來完成Web服務調用。這些庫是Good™。

如果你確信:

  • 底層服務器已捲曲/ libcurl的版本7.35.0或更新的版本安裝...
  • 您必須安裝新版本足夠的PHP(推薦至少 5.6.3)...
  • 並正在使用Guzzle 100%對HTTP(S)端點的呼叫...

然後你身體狀況良好。一旦服務將交換機翻轉爲需要TLS 1.2,您的應用程序將自動開始使用TLS 1.2。