Secure HyperText Transfer Protocol

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

ウェブブラウザは通常、ウェブサーバーとの通信にHTTPを使用しますが、このプロトコルでは情報が暗号化されずに送受信されます。そのため、インターネット上での電子商取引や金融機関の口座へのオンラインアクセスなど、機密性の高い情報のやり取りにはセキュリティ上の問題がありました。この問題を解決するために、1990年代半ばにHTTPSとS-HTTPが定義されました。

S-HTTPは当初、Spyglassのウェブサーバーで使用されましたが、ネットスケープやマイクロソフトはHTTPSを支持したため、HTTPSがウェブ通信のセキュリティを確保するためのデファクトスタンダードとなりました。

HTTP over TLSとの比較

S-HTTPとHTTP over TLS（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://` として使用されます）。

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

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

まとめ

S-HTTPは、HTTP通信を暗号化する初期の試みでしたが、HTTPSに取って代わられました。HTTPSは、通信全体を暗号化することでより高いセキュリティを提供し、現在ではウェブ通信の標準となっています。S-HTTPは、その技術的なアプローチとHTTPSとの違いを理解する上で、歴史的な観点から興味深いプロトコルと言えるでしょう。

出典

* RFC 2660 The Secure HyperText Transfer Protocol

もう一度検索