テクノロジー · 実用ガイド
curl error 35「wrong version number」？TLS を変える前に平文を返した区間を証明する
多くは古い TLS ではなくプロトコルの不一致です。プロキシと接続先を区間ごとに追跡し、検証を保ったまま該当契約だけ直します。
多くは古い TLS ではなくプロトコルの不一致です。プロキシと接続先を区間ごとに追跡し、検証を保ったまま該当契約だけ直します。
この文言は誤解を招きます。ある境界で握手の想定と異なるプロトコルのバイトを受けたことを示しますが、TLS バージョン自体が古い証明ではありません。
1. 失敗した経路を固定する
再試行前に curl の完全なコマンド、URL、curl -V、終了値、機密を除いた curl -v または --trace-time を保存します。プロキシ変数と .curlrc は環境依存なのでホストと shell も記録します。
http_proxy、HTTPS_PROXY、ALL_PROXY、NO_PROXY を資格情報なしで列挙します。--noproxy "*" は方針と経路が直結を許す場合だけ有効な対照です。
2. 全ネットワーク区間を名付ける
経路を client→proxy、CONNECT、tunnel、origin と書きます。http:// proxy はプロキシまで平文、https:// proxy は最初にプロキシと TLS を行います。
対象の scheme とポートも確認します。平文 HTTP のポートに HTTPS を送ると、双方が新しい TLS をサポートしていても wrong version number になり得ます。
3. 詳細ログの境界を読む
詳細ログで最後に成功したソケットと最初の TLS レコード失敗を探し、CONNECT 前、CONNECT 応答、またはトンネル後の接続先握手のどこかを決めます。
ServerHello の代わりにプロキシのバナー、HTTP ステータス行、可読な平文が見えれば経路の証拠です。認証ヘッダー、Cookie、クエリ秘密は削除します。
4. 一つの契約だけ直す
証明した不一致だけを直します。対象はプロキシ URL の scheme、プロキシポート、接続先 scheme、リスナー、古い環境変数です。最初から -k や TLS バージョン固定を使いません。
承認済み TLS 検査なら経路証明後に正しい信頼鎖を限定導入します。想定外なら不明なプロキシや証明書をセキュリティと設定の事故として扱います。
5. 修復結果を証明する
意図した経路で詳細リクエストを一度実行し、正しいプロキシ/トンネル順序、TLS 完了、ホスト名検証、接続先からの HTTP 状態を要求します。
修正コマンド、脱秘した追跡、設定差分を保存し、元のアプリやインストーラでも再確認します。実行環境が shell と異なる場合があるためです。
