什麼導致來自WinHttpSendRequest的間歇性SEC_E_BUFFER_TOO_SMALL錯誤？

我有一個工具，它執行HTTP S POST命令針對具有相同標題，相同帖子主體等的相同URL進行多次迭代。什麼導致來自WinHttpSendRequest的間歇性SEC_E_BUFFER_TOO_SMALL錯誤？

我碰到的是，對於某些測試人員來說，WinHttpSendRequest（）函數經常失敗，隨後對GetLastError（）的調用返回記錄在這裏的SEC_E_BUFFER_TOO_SMALL（0x80090321）：COM Error Codes (Security and Setup)。

這不是WinHttpSendRequest（）記錄的錯誤代碼，相當廣泛的谷歌搜索沒有發現任何東西。

我有四重檢查，我提供的輸入WinHttpSendRequest（）是正確和有效的，這些輸入連續工作數萬次......直到它沒有。

我無法提供MVCE，但根據此處提供的假設，我正在尋找返回錯誤代碼的任何可能的原因。

2016-08-03 qexyn

請發表編碼。 –

「我無法提供MVCE」（最小可驗證代碼示例）。 – qexyn

由於您正在進行**安全** HTTP請求，並且正在收到**安全**錯誤，所以很可能「WinHttpSendRequest（）」本身在內部向其使用的安全API內部提供的數據緩衝區不足加密HTTP流量。這可能不是你的錯。雖然很難說肯定，因爲你還沒有顯示任何代碼.. –

我被某人離線提供了一個答案，並且發現它很有趣。

在使用RSA + ECDHE的TLS 1.2中發生的密鑰交換期間，ECDHE的256字節（2048位）公共模數整數隨機生成，因此偶爾會有高位字節爲零。在這種情況下，正在使用的服務器（某些帶有OpenSSL的Linux機箱，不知道發行版或任何版本的任何內容）將使用256字節發送整數。

WinHTTP代碼接收公共模數整數在其稍短的形式顯然不能正確處理。值得注意的是，我還沒有看到這個問題在所有軟件更新的Windows 7上重現，但在Windows 8上經常看到它（Windows 10尚未測試）。

在微軟邊緣此錯誤的報告證實了相同的行爲，只需用1024位模數，而不是2048，但可能是同一個問題：

但是，它確實讓我懷疑如果OpenSSL應該填充整數。我沒有找到實際的規格，看看在這種情況下允許的行爲是什麼。

2016-08-30 00:24:44 qexyn

回答