ポート 443: 安全な Web トラフィック用の HTTPS ポート

HTTPS は、Web セッションを保護する標準的な方法になりました。プレーンな HTTP では、ネットワーク パスを監視できるすべてのユーザーにリクエスト、応答、Cookie、およびフォーム データが公開されるためです。ポート 443 は、クライアントとサーバーに、暗号化された会話を開始するための予測可能な場所を提供します。ブラウザではユーザーがポート番号を入力する必要がなく、インフラストラクチャ チームは既知のデフォルトに基づいてファイアウォール、プロキシ、監視ルールを作成できます。

番号自体は、IANA が管理する既知のポート レジストリから取得されます。初期の安全な Web トラフィックでは SSL が使用され、その後、SSL が最新のセキュリティ プロトコルとして TLS に置き換えられました。アプリケーション プロトコルは依然として HTTP であるため、HTTPS という名前が残りましたが、TLS で保護されたチャネル内で伝送されます。現在、SSL 証明書というと、通常はポート 443 で HTTPS によって使用される TLS 証明書を意味します。

ポート 80 は HTTP のデフォルトのポートです。これは、初期リダイレクト、証明書の自動化の課題、内部ヘルス チェック、レガシー クライアントとの互換性にとって依然として役立ちます。ポート 443 は、ブラウザが通常の HTTP トラフィックが開始される前に TLS ハンドシェイクを予期しているため、異なります。このハンドシェイクにより、サーバーは証明書を使用して身元を証明し、プライベート データが交換される前に双方が暗号化キーに同意することができます。

現在の運用サイトでは、通常、リダイレクトまたは証明書の自動化のためにのみポート 80 を開いたままにしています。実際のアプリケーション トラフィックは 443 に到達する必要があり、多くの場合、ブラウザーが HTTPS の使用を忘れないように HSTS が有効になっています。

インターネット ユーザー、顧客アプリケーション、Webhook プロバイダー、CDN、モバイル アプリ、またはパートナー システムが HTTPS 経由でサービスにアクセスする必要がある場合は、ポート 443 を開きます。典型的な例には、パブリック Web サイト、REST API、GraphQL エンドポイント、OAuth コールバック、支払い Webhook、リバース プロキシ フロント ドア、コンテナーイングレス コントローラー、認証によって保護されたセルフホスト ダッシュボードなどがあります。

安全そうだからといって 443 を開かないでください。 HTTPS は転送中のトラフィックを暗号化しますが、脆弱な認証、古いソフトウェア、公開された管理ルート、または危険なデフォルトの認証情報は修正されません。 443 を、パッチ適用、ロギング、およびアクセス制御に値するパブリック エントリ ポイントとして扱います。

HTTPS エンドポイントが動作するには、4 つの要素を揃える必要があります。 DNS はホスト名が正しいパブリック アドレスを指す必要があります。サービスは 443 でリッスンする必要があります。ホスト ファイアウォール、クラウド セキュリティ グループ、ルーター ポート転送、ロード バランサー リスナーなどのネットワーク制御が接続を許可する必要があります。最後に、サーバーはホスト名と一致する証明書を提示する必要があります。

2 つの質問に分けてください: ポートは到達可能ですか? と HTTPS は正しく構成されていますか?ポート チェッカーは TCP パスを確認します。 curl、ブラウザ devtools、openssl s_client などのツールは、リダイレクト、証明書、TLS バージョン、HTTP 応答の検査に役立ちます。

Windows Server に、IIS、Nginx、Caddy、または別の Web サーバーをインストールし、証明書をサイトにバインドし、Windows Defender ファイアウォールで受信 TCP 443 を許可します。クラウド サーバーには、クラウド セキュリティ グループまたはファイアウォール ポリシーで許可された 443 も必要です。

Linux では、Nginx、Apache、または Caddy をインストールし、443 用の仮想ホストを構成し、Let's Encrypt などのプロバイダーからの証明書を使用します。次に、ホスト ファイアウォールでポートを許可します (たとえば、Ubuntu では ufwallow 443/tcp を使用します)。コンテナーには、ホストまたはロード バランサー上で公開された 443 も必要です。

macOS では、ポート 443 は主にローカル開発環境またはラボ環境用です。 443 でリッスンするプロセスが引き続き必要であり、特権ポートには昇格されたアクセス許可が必要な場合があります。

パブリック IP アドレスまたはホスト名に対する外部ポートのチェックから始めます。結果がオープンの場合、リモート クライアントは 443 への TCP 接続を確立できます。 次に、ブラウザまたはcurl -I https://example.com を使用して、HTTP ステータス、リダイレクト、およびヘッダーを確認します。

サーバー自体で、プロセスが ss -tlnp、netstat、または PowerShell を使用してリッスンしているかどうかを確認します。 TLS の詳細については、openssl s_client -connect example.com:443 -servername example.com に証明書チェーンとハンドシェイク情報が表示されます。

ポート 443 が閉じていると表示される場合は、サービスが実行中でないか、ローカルホストでのみリッスンしているか、または間違ったインターフェイスにバインドされている可能性があります。タイムアウトになる場合は、ファイアウォール、クラウド セキュリティ グループ、ルーター、ISP、または上流のプロバイダーがパケットをドロップしている可能性があります。ポートは開いているが HTTPS が失敗する場合は、証明書名、証明書チェーン、SNI 構成、リバース プロキシ アップストリーム、およびアプリケーション ログを検査します。

よくある間違いとしては、クラウド ファイアウォールを忘れてホスト ファイアウォールを開く、Docker ポート 443 をホストに公開せずにコンテナ内にマッピングする、CGNAT の背後にある住宅ネットワークからテストするなどがあります。そのような場合、トンネル、ビジネス接続、またはパブリック クラウド エンドポイントが必要になる場合があります。

TLS をシンプルかつモダンに保ちます。 TLS 1.3 と TLS 1.2 を優先し、古いプロトコルを無効にし、証明書を自動的に更新し、HTTP を HTTPS にリダイレクトし、証明書の有効期限を監視します。暗号化のみに依存しないでください。認証をプライベート ツールの前に置き、管理パスを制限し、アプリケーション スタックにパッチを適用し、失敗した認証試行をログに記録します。

高価値サービスの場合は、疑わしいトラフィックをレート制限して可観測性を向上させることができるリバース プロキシ、WAF、CDN、またはロード バランサーの背後に 443 を配置します。サービスがスタッフのみを対象としている場合は、広範囲にアクセス可能な状態にするのではなく、VPN、アイデンティティ認識プロキシ、ホワイトリスト、または mTLS を使用してください。