Secure HyperText Transfer Protocol

この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。（このテンプレートの使い方） 出典検索?: "Secure HyperText Transfer Protocol" – ニュース · 書籍 · スカラー · CiNii · J-STAGE · NDL · dlib.jp · ジャパンサーチ · TWL (2025年12月)

HTTP
主要項目
持続的接続 圧縮（英語版） HTTPS HTTP/2 HTTP/3
リクエストメソッド
OPTIONS GET HEAD POST PUT DELETE TRACE CONNECT PATCH（英語版）
ヘッダーフィールド（英語版）
Cookie ETag Location（英語版） リファラ DNT（英語版） X-Forwarded-For
ステータスコード
301 Moved Permanently（英語版） 302 Found 303 See Other（英語版） 403 Forbidden 404 Not Found 503 Service Unavailable
認証方式
Basic認証 Digest認証
セキュリティホール
HTTPヘッダ・インジェクション HTTPリクエストスマグリング HTTPレスポンス分割 HTTPパラメータ汚染
表 話 編 歴

Secure Hypertext Transfer Protocol (S-HTTP) は、HTTPで行われるウェブ通信を暗号化するHTTPSプロトコルの廃れた代替プロトコルである。Eric RescorlaとAllan M. Schiffmanにより開発され、1999年にRFC 2660として発表された。

ウェブブラウザは通常、ウェブサーバとの通信にHTTPを使用し、情報を暗号化せずに送受信する。インターネットでの電子商取引や金融機関の口座へのオンラインアクセスなど機密性の高い取引を行う場合は、ブラウザとサーバがこの情報を暗号化する必要がある。HTTPSとS-HTTPは1990年代半ばにこの需要に応えるために定義された。S-HTTPはSpyglassのウェブサーバにより使用されたが^[1]、ネットスケープやマイクロソフトはS-HTTPではなくHTTPSを支持したため、HTTPSはウェブ通信のセキュリティを確保するためのデファクトスタンダードとなった。

S-HTTPは、提供されたページデータとPOSTフィールドのような送信データのみを暗号化し、プロトコルの開始は変更されない。このため、S-HTTPは暗号化されていないヘッダにより残りの通信が暗号化されているかどうかが判断されるため、同じポートでHTTPと同時に使用することができた。

その一方、HTTP over TLSでは通信全体をTransport Layer Security (TLS; 旧SSL) で包むため、プロトコルデータが送信される前に暗号化が開始される。このため、名前ベースバーチャルホストではどのDNS名が要求を意図したものかを判断する際に「ニワトリと卵」のような問題が生じる。

つまり、Server Name Indication (SNI)サポートのないHTTPS実装では、DNS名ごとに個別のIPアドレスが必要であり、全てのHTTPS実装では、暗号化を明確に使用するために個別のポート（通常は443とHTTPの標準80）が必要である（ほとんどのブラウザでは個別のURIスキーム https:// として使用される）^[2]。

RFC 2817にあるように、HTTP/1.1 Upgradeヘッダーを実装しTLSにアップグレードすることでHTTPを保護することもできる。この方法で協定されたHTTP over TLSの実行は、名前ベースの仮想ホスティング（追加のIPアドレス、ポート、またはURIスペースなし）に関してHTTPSの影響を持たない。しかし、この方法をサポートする実装はほとんどない。

S-HTTPにおいて、所望のURLは平文のヘッダーで送信されず、空白のままになる。暗号化されたペイロード内に別のヘッダーのセットが存在する。HTTP over TLSにおいては、すべてのヘッダーが暗号化されたペイロード内にあり、サーバーアプリケーションは通常、TLSの致命的なエラー（「クライアント証明書が信頼されていない」や「クライアント証明書の有効期限が切れている」など）から正常に回復する機会がない^[要出典]。

• RFC 2660 The Secure HyperText Transfer Protocol