Loading article…
セキュアハイパーテキスト転送プロトコル（S-HTTP）は、インターネット上で行われるウェブ通信を暗号化するためのHTTPSプロトコルの旧式な代替手段です。これは、1994年にエンタープライズインテグレーションテクノロジーズのエリック・レスコーラとアラン・M・シフマンによって開発され[ 1 ] 、1999年にRFC 2660 として公開されました。Netscapeがブラウザ市場を支配したことで、HTTPSがウェブ通信を保護する事実上の方法となりました。
S-HTTPは、配信されるページデータとPOSTフィールドなどの送信データのみを暗号化し、プロトコルの開始部分は変更しません。そのため、暗号化されていないヘッダーによって送信の残りの部分が暗号化されるかどうかが決まるという点で、S-HTTPは同じポートでHTTP（非暗号化）と同時に使用できます。
一方、TLS 上の HTTP は通信全体をトランスポート層セキュリティ(TLS、旧称 SSL) でラップするため、プロトコルデータが送信される前に暗号化が開始されます。これにより、リクエストの宛先となるDNS名を特定するという、名前ベースの仮想ホスティングにおける「鶏と卵」のような問題が生じます。
これは、Server Name Indication (SNI) をサポートしない HTTPS 実装では、DNS 名ごとに別のIP アドレスが必要であり、すべての HTTPS 実装では、暗号化を明確に使用するために別のポート (通常は HTTP の標準 80 ではなく 443) [ 2 ]が必要であることを意味します(ほとんどのブラウザでは、別のURI スキーム、https://として扱われます)。
RFC 2817に記載されているように、HTTPはHTTP/1.1 Upgradeヘッダーを実装し、TLSにアップグレードすることでもセキュリティを強化できます。このようにネゴシエートされたTLS上でHTTPを実行する場合、名前ベースの仮想ホスティングに関してHTTPSのような影響はありません（追加のIPアドレス、ポート、URI空間は不要です）。ただし、この方法をサポートする実装はほとんどありません。
S-HTTPでは、目的のURLは平文ヘッダーには送信されず、空白のままになります。別のヘッダーセットが暗号化されたペイロード内に存在します。TLS上のHTTPでは、すべてのヘッダーが暗号化されたペイロード内にあり、サーバーアプリケーションは通常、TLSの致命的なエラー（「クライアント証明書が信頼されていません」や「クライアント証明書の有効期限が切れています」など）から適切に回復する機会がありません。[ 2 ]