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