「ERR_SSL_PROTOCOL_ERROR 」はHTTPSで公開しているWebサーバーにHTTP(TCP80番ポート)したときにも表示されるプロトコルエラーのメッセージの一つです。
私の運用中のWebサイトにアクセスして試しました。
Edge
このサイトへの接続はセキュリティで保護されていません
navitoku.jp が無効な応答を送信しました。
ERR_SSL_PROTOCOL_ERROR
Chrome
このサイトは安全に接続できません
navitoku.jp から無効な応答が送信されました。
Windows ネットワーク診断ツールを実行してみてください。
ERR_SSL_PROTOCOL_ERROR
アドレスバーを見てわかるようにURLはhttps:から始まるHTTPSのアクセスなのにTCP 443番ポートではなくTCP 80番ポートを指定してアクセスしています。
プロトコルエラーに関してはWebサーバー側のログに制御コードの以下のようなログが記録されることがあります。
\x16\x03\x01\x01+\x01
プロトコルシーケンスのハンドシェイクの際のものですが、最近のEdgeやChromeのブラウザで「https://www.exsample.com:80」のようにHTTPSでTCP80番ポートにアクセスしてもこのようなアクセスログは記録されません。 一般ユーザーのプロバイダー利用のアクセスではクライアントOSやブラウザが古いTLSバージョンを無効にしているのでほぼアクセスはないです。あったらちょっと不審です。
つまり、脆弱性診断ツールあるいは攻撃ツールでアクセスしていることが推測されます。TLSのバージョンを特定することでSSLがらみのWebサーバの脆弱性を突こうとしていることが考えられます。
アクセス元のIPアドレスを調べると大抵はサーバーホスティングや仮想プライベートサーバー(VPS)です。AWSなども頻繁につかわれています。 こうしたアクセスをしてくる通信元のIPアドレスは自らサイバー攻撃を行っているか、攻撃されて乗っ取られている(攻撃や探索行為に加担)していると考えてよいと思います。
ちなみにアクセスブロックすると別のIPアドレスから別の攻撃も仕掛けてくることさえあります。ログ監視の次のステップとしてブロックすべきか判断に迷うことがありますが、一般向けWebサーバーの場合、ユーザーのアクセス元がサーバーホスティングや仮想プライベートサーバー(VPS)からになることはまずないのでブロックしています。もちろん例外はあります。具体的にはレガシー系のサーバーやVPSを紹介をしている場合には設定などを試行錯誤しているサーバーからアクセスすることもあるでしょう。そういうコンテンツを提供している場合はユースケース考慮してブロックルールを定義します。
■参考情報
Apache - strange requests in logs [Stack Exchange Inc;]
https://security.stackexchange.com/questions/162782/apache-strange-requests-in-logs
1 Answer
Q : I'm concerned especially about first request from this host - what may this be, some function coded in hex or dec?
A : What you see in \x16\x03\x01\x01... is just the start of a TLS 1.0 handshake, i.e. content type (0x16 = handshake) followed by TLS version (0x0301 = TLS 1.0). Looks like somebody tried to speak HTTPS on port 80 instead of 443.
1回答
私は特にこのホストからの最初のリクエストについて心配しています。これは一体何なのでしょうか、16 進数または 10 進数でコード化された何らかの関数なのでしょうか?
表示されているのは、\x16\x03\x01\x01...TLS 1.0 ハンドシェイクの開始部分、つまりコンテンツ タイプ (0x16 = ハンドシェイク) の後に TLS バージョン (0x0301 = TLS 1.0) が続く部分です。誰かがポート 443 ではなくポート 80 で HTTPS を話そうとしたようです。
■関連リンク
・Windows での TLS 1.0 と TLS 1.1 の非推奨化 [Microsoft Windows開発]
https://learn.microsoft.com/ja-jp/windows/win32/secauthn/tls-10-11-deprecation-in-windows
・SSL・PKI・電子証明書ガイドTLSとは? SSLとの違い [GMOグローバルサインカレッジ]
https://college.globalsign.com/ssl-pki-info/tls_ssl_brittle/
・Microsoft、「TLS 1.0」「TLS 1.1」対応を終了 ~2024年10月31日以降、利用不可「TLS 1.2」またはそれ以降の利用を義務付け [Impress 窓の杜]
https://forest.watch.impress.co.jp/docs/news/1605556.html
・ついにWindowsのOSレベルで「TLS 1.0/1.1」が既定で無効化へ、その影響を調査するには [@IT]
https://atmarkit.itmedia.co.jp/ait/articles/2309/05/news010.html
・2024 年 10 月 31 日までに終了する TLS 1.0 と TLS 1.1 のサポート [マイクロソフト ライフサイクル]
https://learn.microsoft.com/ja-jp/lifecycle/announcements/tls-support-ending-10-31-2024
・Update: Azure support for TLS 1.0 and TLS 1.1 extended to August 31, 2025 [Microsoft Lifecycle]
https://learn.microsoft.com/en-us/lifecycle/announcements/tls-support-ending-10-31-2024
更新: Azure の TLS 1.0 および TLS 1.1 のサポートが 2025 年 8 月 31 日まで延長されました
2023 年 11 月 10 日の発表に続き、Azure サービスへのすべての接続に TLS 1.2 以降を要求する移行を継続しています。多くのサービスでは既に従来の TLS が廃止されていますが、いくつかのサービスでは TLS 1.0 および TLS 1.1 バージョンのサポートを継続し、2025 年 8 月 31 日までにその移行を完了します。その時点で、Azure サービスへのすべての接続に TLS 1.2 以降が必要になります (サービス ドキュメントに明示的に記載されていない限り)。
・TLS 1.0および1.1の廃止について [digicert]
https://www.digicert.com/jp/blog/depreciating-tls-1-0-and-1-1
TLS 1.0は1999年にリリースされた、約20年前のプロトコルです。BEASTやPOODLEなどの攻撃に脆弱であることが、何年も前から知られており、また脆弱な暗号しかサポートしていないため、現在の通信を十分に安全に保つことができません。
ナビ得