アカウント名:
パスワード:
大丈夫？
証明書の検証まではしてないだろうから無理かな。
proxyでssl通信の中身を見るにはssl通信の復号化が必要で、その際には証明書のドメイン不一致による警告が表示されるから、httpsなら中間者攻撃対策に気付くことができるはず。
×復号化
鍵を使って復号器を作るのだから、復号器化が正しい．．．のかもしらない。
今回の件はユーザーとサーバーの間に割り込むわけではなく、クライアントからリクエストを受けたサーバー側が更にどこかにHTTPリクエストを投げるケースで、「更にどこかにHTTPリクエストを投げる」の部分に中間者攻撃が成立しうるというものであって、これが「更にどこかにHTTPSリクエストを投げる」であればターゲットになる環境変数は「HTTPS_PROXY」とかになるんだろうけど、今回のキモはリクエストヘッダの頭に「HTTP_」を付け加えるってところなので成立しない#よね？
https_proxyが無いときはhttp_proxyを読むようになってたりするかも
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
それでもhttpsなら・・・ (スコア:0)
大丈夫？
証明書の検証まではしてないだろうから無理かな。
Re: (スコア:0)
proxyでssl通信の中身を見るにはssl通信の復号化が必要で、その際には証明書のドメイン不一致による警告が
表示されるから、httpsなら中間者攻撃対策に気付くことができるはず。
Re: (スコア:0)
×復号化
Re:それでもhttpsなら・・・ (スコア:2)
鍵を使って復号器を作るのだから、復号器化が正しい．．．のかもしらない。
Re: (スコア:0)
今回の件はユーザーとサーバーの間に割り込むわけではなく、クライアントからリクエストを受けたサーバー側が更にどこかにHTTPリクエストを投げるケースで、「更にどこかにHTTPリクエストを投げる」の部分に中間者攻撃が成立しうるというものであって、
これが「更にどこかにHTTPSリクエストを投げる」であればターゲットになる環境変数は「HTTPS_PROXY」とかになるんだろうけど、今回のキモはリクエストヘッダの頭に「HTTP_」を付け加えるってところなので成立しない
#よね？
Re: (スコア:0)
https_proxyが無いときはhttp_proxyを読むようになってたりするかも