Zenn
🚦

httpとhttpsの違い

2023/04/22に公開2件
Web
http
tech

TLSの有無

言うまでもないことですが、httpsでは通信路をTLSを使って保護することが想定されています。[1][2]

デフォルポート

httpは80、httpsは443です。[3][4]

権威性

以降の説明に入る前に前提を確認します。本稿は「httpとhttpsの違い」と題されていますが、これはURLのスキーム部分のことを指しています。URLはリソースの所在を指すものであり、通信方法はそこから二次的に決まるものです。このことを前提に置きつつ権威性について説明します。

Webにおいて、所望のリソースにアクセスする方法はひとつではありません。このような方法のうち、リソースの所有者の制御下にある(第三者による加工などが行われていないと期待される)方法で取得することを権威的アクセスと呼びます。[5]

どのようなアクセス方法が権威的とみなせるかについて100%客観的で統一的な指標があるわけではなく、最終的には各々のクライアントの置かれた状況にあわせて判断する必要があります。その一方で、HTTPは代表的な権威的アクセス方法についての規定を与えています。

この規定によれば、http URLの権威性はTCP通信に依存しています。つまり、URLに記載されたドメイン名をDNSで解決し、解決されたIPアドレスにURLのポート番号を使って確立したTCP通信は、権威的なアクセス方法であるとみなされます。[6] この権威性はDNSの信頼性とTCP通信の信頼性に依存しています。

一方、https URLの権威性はPKIを通じてオリジンに紐付けられた秘密鍵の所有確認 (デジタル署名の検証) で担保されます。TCP通信は代表的なアクセス方法にすぎず、この方法をとらなくても署名さえ確認できれば権威的とみなせることになります。たとえば、過去の通信等を通じて別の通信路 (たとえばQUICなど) の存在を知っており、その方法を試した結果期待した通りの署名が得られたのであれば、TCP通信を行わなくても権威的な結果であると信用してよいことになります。この権威性はPKI、特にCAの信頼性に依存しています。

HTTP/2

HTTP/2では平文通信とTLS通信でプロトコル交渉の方法が異なります。

httpsリソースのためのHTTP/2接続を確立するには、TLSのレイヤでプロトコル交渉を行います。[7]

平文通信によるHTTP/2接続の確立方法に標準的なものは存在しません。

  • サーバーがHTTP/2をサポートしていることが何らかの方法でわかっている場合は、通信路にHTTP/2のconnection prefaceを送信することでHTTP/2通信を開始することができます。この方法はhttpsでは禁止されています。[8]
  • 古いHTTP/2の規定では、HTTP/1.1リクエストに Upgrade: h2c ヘッダーを含めることでHTTP/2へのアップグレードを交渉することができました。これは実用的に普及しなかったことから現行規格では廃止されています。[9]

HTTP/3

HTTP/3ではhttpとhttpsでプロトコル交渉に使える方法が異なります。HTTP/3ではTCPを使わない点に注意が必要です。

httpsリソースのためのHTTP/3接続の確立には2つの方法が提供されています。

  • URLのポートをUDPポート番号とみなして、URLのホストに対してQUIC接続を試みる。[10]
  • 先行して他のバージョンでHTTP接続を行い、HTTP/1.1のAlt-SvcヘッダーやHTTP/2のALTSVCフレームによる広告をもとに、指定された接続先に対してQUIC接続を試みる。 [11]

いずれの場合も、TLSで署名の検証を行うことでリソースの権威性を担保できます。

一方、httpリソースでは権威性がTCP接続性に依存しているため、QUIC単独で権威性を検証することができません。そのため、もしHTTP/3を利用したければ、基本的にはTCPを使ったHTTP通信 (HTTP/1.1, HTTP/2) を使ってAlt-Svcによる広告を受けることで接続することになります。[12]

まとめ

httpとhttpsのURLスキームとしての違いは:

  • TLSの有無
  • デフォルトポート
  • 権威性の依拠
  • HTTP/2, HTTP/3の交渉手順
脚注

  1. <q>The "http" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential HTTP origin server listening for TCP ([TCP]) connections on a given port.</q> IETF RFC 9110 - HTTP Semantics, §4.2.1 http URI Scheme ↩︎

  2. <q>The "https" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS ([TLS13]) connection that has been secured for HTTP communication.</q> IETF RFC 9110 - HTTP Semantics, §4.2.2 https URI Scheme ↩︎

  3. <q>If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default.</q> IETF RFC 9110 - HTTP Semantics, §4.2.1 http URI Scheme ↩︎

  4. <q>If the port subcomponent is empty or not given, TCP port 443 (the reserved port for HTTP over TLS) is the default.</q> IETF RFC 9110 - HTTP Semantics, §4.2.2 https URI Scheme ↩︎

  5. <q>Authoritative access refers to dereferencing a given identifier, for the sake of access to the identified resource, in a way that the client believes is authoritative (controlled by the resource owner).</q> IETF RFC 9110 - HTTP Semantics, §4.3 Authoritative Access ↩︎

  6. <q>Although HTTP is independent of the transport protocol, the "http" scheme (Section 4.2.1) is specific to associating authority with whomever controls the origin server listening for TCP connections on the indicated port of whatever host is identified within the authority component.</q> IETF RFC 9110 - HTTP Semantics, §4.3.2 http Origins ↩︎

  7. <q>A client that makes a request to an "https" URI uses TLS [TLS13] with the ALPN extension [TLS-ALPN].</q> IETF RFC 9113 - HTTP/2, §3.2 Starting HTTP/2 for "https" URIs ↩︎

  8. <q>A client that knows that a server supports HTTP/2 can establish a TCP connection and send the connection preface (Section 3.4) followed by HTTP/2 frames.</q> IETF RFC 9113 - HTTP/2, §3.3 Starting HTTP/2 with Prior Knowledge ↩︎

  9. <q>A client that knows that a server supports HTTP/2 can establish a TCP connection and send the connection preface (Section 3.4) followed by HTTP/2 frames.</q> IETF RFC 7540 - Hypertext Transfer Protocol Version 2 (obsolete), §3.2 Starting HTTP/2 for "http" URIs ↩︎

  10. <q>A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port (including validation of the server certificate as described above), and sending an HTTP/3 request message targeting the URI to the server over that secured connection.</q> IETF RFC 9114 - HTTP/3, §3.1 Discovering an HTTP/3 Endpoint ↩︎

  11. <q>On receipt of an Alt-Svc record indicating HTTP/3 support, a client MAY attempt to establish a QUIC connection to the indicated host and port; if this connection is successful, the client can send HTTP requests using the mapping described in this document.</q> IETF RFC 9114 - HTTP/3, §3.1.1 HTTP Alternative Services ↩︎

  12. <q>However, protocol extensions such as [ALTSVC] permit the authoritative server to identify other services that are also authoritative and that might be reachable over HTTP/3.</q> IETF RFC 9114 - HTTP/3, §3.1.2 Other Schemes ↩︎

Discussion