書きましたが深追いはせずの精神 "AWS ALB+ACMの意外な落とし穴 | 外道父の匠"

この辺を軸に見直していくと良さげかな……あんま楽しくない系だし、どーせ忘れるけど、も少しマシにしとかんとな

長くHTTP(S)に関わってるけど、進化もしてるわけだし、知らん仕様はまだまだ存在するんだろうな……やらざるを得ない時以外で、プロトコルにダイブするの嫌いな方なんだよなｗ

せっかくかまってもらったので、ブログにも追記しておきました

サーバーが提示した証明書を検証した上で通信していいかを決めるのはクライアントの責務なので(curlでも-kをつけると検証エラーでも通信できます)、そういうものだと思います

なるほどーと思ってシーケンス図とか見直してみることにしましたけど、クライアント側があえて暗号化通信を使わない、という選択というかフローは頭になかったですね…まだまだ甘ちゃんですわ

httpsなので通信路の暗号化はされているんですが、通信相手がまともな証明書を持っているか検証していない(ので偽物相手に通信している可能性がある)、という状態ですね。でもChromeはcurl同様デフォルトだと証明書のエラーでブロックすると思うので、なにか設定されてたり?

いや、特に何も特殊な設定はしていないですね。クライアントの送信内容が平文なのか暗号化されてるのか、の確認をしたら何かはわかりそうですが…Chrome開発者ツールじゃそれっぽい項目なかったし、Wireshark引っ張り出すの面倒だなｗ でスンッってなりました

クライアントやその設定によっては、直IPアドレスでアクセスしても、HTTPSサーバー側（=ALB）がそれを受け付けられる場合がある（というか仕様）ってのがわかれば、悪意の有無とか関係なく、想定通りの挙動になるよう設定しましょうってオチではあります

(サーバー側でクライアント証明書の検証をしていれば別ですが)普通のhttpsサーバーの場合それが仕様ですね。cloudflare.com/ja-jp/learning… 例えばここのフローだと「認証：クライアントはサーバーのSSL証明書を発行元の認証局に確認します」のところをクライアントが意図的にskipする状態ですね

証明書による認証と、鍵での暗号化／復号は別の話で、HTTPSサーバーはどちらもやりとりするけど、クライアントが認証を無視しても暗号化通信はできるぜってことですな。で、暗号化通信に実はドメインは不要だから直IPアドレスでも通れましたよ、って結果だったという感じか

そんな感じです！

整理してみると、確かに「そーゆーもの」だってのがわかる。なんでかサーバー側でも強力にチェックしてる、すべきと思いこんでたけど、基本はクライアントを守る仕組みってことなんやろなー