保护非公开服务：使用HTTPS的前提下，私密路径和密码具有相同的安全性？

背景

この三代目サイトを立てた時に、いくつかのサービスを隠して使おうと検討してました．

このように，ネットワークの上には大量なサービスがあります． その中には隠れていて，特定な人しか使えないサービスもあります．

特定な人しか使えないのを保証するためにはいろんな手法があります． VPNを利用して仮想的なネットワークを作るのもあり，IPアドレスを制限するのもあります． しかし，HTTP¹の上で稼働しているサービスならやはりHTTPプロトコルを利用して認証を行うのが一番自然でしょう．

HTTPを利用した認証手法も色々あります． よくつかわれている例として，HTTP Basic AuthやPOSTフォームによる認証情報交換があります．

このサイトを立てるときに，このような手法を色々調査しましたが，一つの疑問が浮かんできました．

このような認証はたいていHTTPプロトコルでちょっとだけ情報を挟むことで実現しています． パスもHTTPプロトコルによる伝送している情報の一種であり，認証に使えるのでしょうか？

当我们建立这个第三代网站时，我们考虑以一种隐蔽的方式使用其中的一些服务。

如你所见，网络上有大量的服务。 其中有些服务是隐藏的，只有特定的人才能使用。

有各种方法可以保证只有特定的人才能使用这些服务。 有的使用 VPN 创建虚拟网络，有的则限制 IP 地址。 不过，如果服务是通过 HTTP ¹运行的，那么使用 HTTP 协议进行身份验证是最自然不过的了。

使用 HTTP 有多种身份验证方法。 常用的例子包括 HTTP Basic Auth 和使用 POST 表单交换身份验证信息。

在建立本网站时，我对这些方法进行了研究，并想到了一个问题。

这种身份验证通常是通过在 HTTP 协议中插入一点信息来实现的。 路径也是 HTTP 协议传输的一种信息吗？

当建立这个第三代网站时，其实还有一个在网站中运行一些隐藏服务的想法。

实际上，在网络中存在

HTTPに基づいた認証

この問題を解明するためには，まずどんな認証手法があるかを知る必要があります． ここでよく使われている認証手法をいくつか挙げてみます．

Basic認証

Basic認証（ベーシックにんしょう、Basic Authentication）はHTTPで定義される認証方式（HTTP認証）の一つです． 1996年にHTTP1.0²と同時に提案されました． 三年後，HTTP1.1³と同時に，RFC2617⁴としてより詳細な仕様が定義されました． HTTP標準の一部なので，ほぼ全てのWebサーバおよびブラウザで対応していて，広く使われています⁵.

HTTP認証仕様書により，ユーザ名とパスワードを利用して認証を行うときには， ユーザ名とパスワードの組をコロン:でつなぎ，Base64⁶でエンコードして送信します． ユーザ名 “root”，パスワード “password”の場合は以下のようになります

GET /private_resource HTTP/1.1
Host: example.com
Authorization: Basic cm9vdDpwYXNzd29yZA==

ここで補足説明で，HTTP1.1はプレーンテキストで通信するプロトコルなので，リクエスト行とヘッダーはとくに処理ず，ほぼ書いた通りに送信しています．上の例では

00000000: 4745 5420 2f70 7269 7661 7465 5f72 6573  GET /private_res
00000010: 6f75 7263 6520 4854 5450 2f31 2e31 0d0a  ource HTTP/1.1..
00000020: 486f 7374 3a20 6578 616d 706c 652e 636f  Host: example.co
00000030: 6d0d 0a41 7574 686f 7269 7a61 7469 6f6e  m..Authorization
00000040: 3a20 4261 7369 6320 636d 3976 6444 7077  : Basic cm9vdDpw
00000050: 5958 4e7a 6432 3979 5a41 3d3d 0d0a 0d0a  YXNzd29yZA==....

のままで送信されます.

RFC1738ではさらにユーザ名とパスワードをURLに埋め込むフォーマットを定義しました⁷．この定義によると，IPネットワークを利用してリソースを取得する場合は以下のURLを利用します．

//<user>:<password>@<host>:<port>/<url-path>

しかしこの標準はまだHTTP認証情報をURLに埋め込む手法を定義しませんでした． RFC1808⁸により，HTTP認証情報をURLに埋め込む手法が定義されました． HTTP仕様にはなっていませんが，多くのブラウザが対応しているようです．

HTTP認証を利用するときには，ブラウザが認証情報入力フォームをユーザーに見せるのは一般的ですが，もちろん，ユーザ名とパスワードのほかに，トークンを利用することもできます． トークンを利用する場合は，ユーザ名の代わりにトークンをAuthorizationヘッダーに入れて送信します． ただし，トークンを利用する場合，ブラウザが提供した認証フォームとは違うフォーマットになるので，JavaScriptにより認証情報を送信したり，ブラウザ以外のHTTPクライアントを利用する場合が多いです．

フォームによる認証

ユーザ名とパスワードの組み合わせで認証を行うのは，必ずしもBasic認証で指定したAuthorizationヘッダーを利用する必要はありません． クェリー文字列⁹⁸や，POSTフォーム¹⁰によってユーザ名とパスワードを送信することもできます．

HTTPはいくつかのメソッドを定義しています．POSTメソッドは，サーバがクライアントからの情報を受信するメソッドとして定義しました．

The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:

• Annotation of existing resources;
• Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
• Providing a block of data, such as the result of submitting a form, to a data-handling process;
• Extending a database through an append operation.

この三つ目の機能を利用して，ユーザ名とパスワードを送信することができます． そしてPOSTメソッドによってフォームを送信する手法もRFC1867によって定義されました¹⁰．

これはPOSTメソッドによってユーザ名とパスワードが含まれてるフォームを送信する例です．

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 31

username=root&password=password

Basic認証と同じ，すべての情報はテキストとして送信されます．実際に伝送したデータは以下のようになります．

00000000: 504f 5354 202f 6c6f 6769 6e20 4854 5450  POST /login HTTP
00000010: 2f31 2e31 0d0a 486f 7374 3a20 6578 616d  /1.1..Host: exam
00000020: 706c 652e 636f 6d0d 0a43 6f6e 7465 6e74  ple.com..Content
00000030: 2d54 7970 653a 2061 7070 6c69 6361 7469  -Type: applicati
00000040: 6f6e 2f78 2d77 7777 2d66 6f72 6d2d 7572  on/x-www-form-ur
00000050: 6c65 6e63 6f64 6564 0d0a 436f 6e74 656e  lencoded..Conten
00000060: 742d 4c65 6e67 7468 3a20 3331 0d0a 0d0a  t-Length: 31....
00000070: 7573 6572 6e61 6d65 3d72 6f6f 7426 7061  username=root&pa
00000080: 7373 776f 7264 3d70 6173 7377 6f72 64    ssword=password

このようなフォームは標準化されたので，ほぼすべてのブラウザが対応しています． この手法を利用したアプリケーションも多く存在します． 例としてWordPress¹¹などを挙げられます．

POSTメソッドではない場合，クエーリー文字列により情報を送信する手法もあります． クエーリー文字列はHTTPリクエスト行の中で情報を挟む手法です．RFC1808によると，URIのフォーマットは以下のようになっています．

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

クエーリー文字列は<query>の部分です．

クエーリー文字列は任意の文字列を含むことができます⁹． よく知られているaaa=bbb&ccc=dddのような形式は，最初にHTML+のフォーム提出フォーマットとしてドラフトが出されました¹²． このドラフトは正式仕様書にならないまま，HTML自体は2.0まで進化しました．ただし，この提案もHTML2.0フォームの標準として採用されました¹³．

クエーリー文字列を利用してユーザ名とパスワードを送信すると以下のようになります．

GET /login?username=root&password=password HTTP/1.1
Host: example.com

実際に伝送したデータは以下のようになります．

00000000: 4745 5420 2f6c 6f67 696e 3f75 7365 726e  GET /login?usern
00000010: 616d 653d 726f 6f74 2670 6173 7377 6f72  ame=root&passwor
00000020: 643d 7061 7373 776f 7264 2048 5454 502f  d=password HTTP/
00000030: 312e 310d 0a48 6f73 743a 2065 7861 6d70  1.1..Host: examp
00000040: 6c65 2e63 6f6d 0d0a 0d0a                 le.com....

ユーザ名とパスワードが現れるところに微妙な違いがありますが，どちらのメソッドも，ユーザ名とパスワードを送信することで認証しています．

ステートフルな認証

たしかにユーザ名とパスワードを毎回送信することでも認証できますが，サーバー側がログイン状態などを把握できなくなる問題があります．

この問題を解決するためには，また別の手法を考える必要があります． RFC2109では，Cookieというヘッダーを提案し，ステートフルな認証を実現しました¹⁴． サーバー側はこのCookieを利用して，ログインしているユーザーを識別することができます． 本文章はステートについては触れませんが，Cookieを認証手法の一種として軽く議論します．

HTTP cookieは，HTTPにおけるウェブサーバとウェブブラウザ間で状態を管理する通信プロトコル，またそこで用いられるウェブブラウザに保存された情報のことを指します． ユーザ識別やセッション管理などを実現するために利用されます¹⁵¹⁴．

Cookieを利用した例としては：

1. ユーザーが前節で議論した手法でユーザ名とパスワードなどの認証情報を用いてログインし，サーバー側はCookieを発行する．
2. ユーザーがサーバーに対してリクエストを送信する際，Cookieヘッダーに含め，サーバー側が発行したCookieを送信する．
3. サーバー側はCookieを用いてユーザーとセッションなどを識別する．

という手順で認証を行います．

実際にCookieを利用するときのリクエストは以下のようになります．

GET / HTTP/1.1
Host: example.com
Cookie: session=1234567890abcdef

バイナリーでは以下のようになります．

00000000: 4745 5420 2f20 4854 5450 2f31 2e31 0d0a  GET / HTTP/1.1..
00000010: 486f 7374 3a20 6578 616d 706c 652e 636f  Host: example.co
00000020: 6d0d 0a43 6f6f 6b69 653a 2073 6573 7369  m..Cookie: sessi
00000030: 6f6e 3d31 3233 3435 3637 3839 3061 6263  on=1234567890abc
00000040: 6465 660d 0a0d 0a                        def....

もちろんほかの認証手法もありますが，ここでは最も一般的な認証手法だけを議論します．

実際は同じなのでは？

認証はいろんな手法がありそうですが，実際にはたいてい3種類の手法があります¹⁶¹⁷．それは

1. 所持物による認証（What you have）
2. 先験的な知識による認証（What you know）
3. 固有特徴による認証（What you are）

です． 例を挙げると，携帯電話やスマートカードなどは所持物，パスワードやPINコードは先験的な知識，指紋や虹彩などは固有特徴による認証です¹⁸． 前節で上げた例は，すべて知識による認証に分類できます．そしてこのような認証は大まかに三種類の脅威を受けます．

1. 盗聴などにより先験的な知識を盗まれます． ショルダーハックのように覗き込んだり(Shoulder surfing¹⁹)，キー入力を記録したり(Keylogging¹⁶)，画面を録画したり(Screen capturing¹⁷)してその知識を盗むことができます．
2. パスワードなどの先験的な知識を推測される． 人間はパスワードを覚えるのが苦手です．そのため，推測されやすいパスワードを使いがちです． 例えば，生年月日や名前，住所などは推測されやすいです． ソーシャルハッキングでこのようなパスワードを推測できます²⁰． もちろん，辞書を利用したり，すべての組み合わせを試したりすることでパスワードを推測することもできます．
3. 伝送する途中で先験的な知識が盗まれます． ユーザエージェントが勝手に情報を記憶したり，ネットワーク上にあるデバイスが勝手にパケットを覗いたりして，その知識が盗まれます． その後者は中間者攻撃(MITM)とも呼ばれています．

先験的な知識で認証を行う限り，このような種類の脅威にさらされます． そのため，前節に議論した手法も例外なくこのような脅威にさらされます．

このような脅威の中でも，特に中間者攻撃は深刻です． 信頼できるデバイスを使ったり，より推測しにくいパスワードを使うことで，先験的な知識を盗まれることをある程度で防ぐことはできます． しかし，中間者攻撃はもう自らの手では防ぐことができません．

特に，前節で挙げた例ではすべての情報が平文で送信されます． ネットワークパケットを覗くだけで，パスワードなどの情報が簡単に盗まれてしまいます．

HTTPSは世界を救う

アプリケーションは中間者攻撃を防ぐためにはいろんな手法を試してきました． 例としては，パスワードを伝送するときには暗号を利用したりして，中間者攻撃を防ぐ手法などがあります． しかしセッションを導入した時点ですべての努力は泡になります．

そこで登場するのがHTTPS²¹です．

HTTPの下レイヤーをTCPからTLSに変更して，HTTPSになりました． 伝送した内容が平文だから中間者に盗まれるのであって，その内容をTLSで暗号化してしまえばもう大丈夫ですよね．

たしかHTTPSを利用しても中間者攻撃を受ける可能性はありますが²²，HTTPよりはだいぶ安全になってきました． そしてHTTPSのおかげで前々節に議論した手法もある程度は安全が確保できました．

パスを利用してサービスを隠せるのはあり？

ここから本題に入りたいと思います．

サイト管理員さん（実はYeonji本人です）が言うた「サービスを隠す」は，実は「サービスを限定的なユーザに公開する」と捉えてもいいと考えられます． そしてこの話は，このサービスを限定的なユーザに公開するための認証に関する話になります． 前文に議論したように，認証は所持物による認証，先験的な知識による認証と固有特徴による認証の三種類があります． 所有物と固有特徴による認証はなかなか複雑で，個人サイトとしては実用ではありません． そして残ってるのは先験的な知識による認証です．

先験的な知識による認証でもいろんな手法がありますが，パスワードを使うのが一般的です． しかし，セッションやフォームなどの認証手法はアプリケーション側の対応が望ましいです． すでに対応したアプリケーションなら利用できますが，対応していないアプリケーションで利用したいなら難所があります． HTTP認証も一つの手法ですが，実際に利用するクライアントによっては対応していない場合があります．

ここでサイト管理員さんは，パスを利用してサービスを隠すことを考案し始めました．

先験的な知識による認証はたいてい情報交換と伴っています． もちろんゼロ知識証明なども認証に使ってますが²³，さすがに個人サイトでは実用ではありません．

HTTPプロトコルに挟まれる情報を分析するため，まずプロトコル自身を観察しましょう． HTTPプロトコルは平文で以下のような形式で情報をサーバーに送信します．

METHOD /path/to/resource?query_string HTTP_VERSION
HEADER1: value1
HEADER2: value2
...

前文には，ヘッダーとクエリー文字列を利用した情報交換を議論しましたが，パスでも情報の一種ではありませんか？

ただし，リバースプロキシやユーザエージェントなどにおけるパスとヘッダーとクエリー文字列の処理はちょっと違いがあります． 基本的に，パスはリソースを特定する部分として考えられているため，キャッシュなどが稼働する可能性があります． それと，アプリケーションが利用するパスが変わったとき，アプリケーションの挙動が変わる可能性もあります． そのため，パスを利用してサービスを特定なユーザーに公開するのは基本非推奨です．

ただし，選択肢としてはあります．

強さは大丈夫？

もしパスをパスワードとして使ったら，セキュリティ上の問題も考えなくちゃいけません． もちろんCDNなどでキャッシされたりしてしまうセキュリティ上の問題はありますが，そこは利用しているCDNなどを信頼するしかありません．

そしてサイト管理員として最も関心があるのは，パスを利用した認証の強度です．

結論として，複雑性が高いパスを利用すれば，特に心配しなくていいです．

認証の強さはこのような式で計算できます．

$$T_{ハッキングする時間} \approx n_{試す回数} \times t_{一回試す所要時間}$$

そこで，試す回数は情報量で計算できます．

$$n_{試す回数} = 2^{I_{情報量}}$$

情報量は以下の式で計算できます．

$$I_{情報量} = \log_2 N_{情報の種類}$$

情報の種類は，文字列の長さと文字種類で計算できます．

$$N_{情報の種類} = N_{文字種類}^{n_{文字列の長さ}}$$

以上の式をまとめると

$$T_{ハッキングする時間} \approx N_{文字種類}^{n_{文字列の長さ}} \times t_{一回試す所要時間}$$

となります．

実際にBase64が指定した64文字を利用して，文字列の長さを16にして ネットワーク遅延を60msとして，一回試す所要時間も60msとすると，以下のような結果になります．

$$T_{ハッキングする時間} \approx 64^{16} \times 60 ms = 4.75 \times 10^{30} ms \approx 1.5 \times 10^{20} 年$$

たとえ並列十万スレッドで試しても，そのパスを見つけるためには億年以上かかるので，セキュリティ上では問題ないと考えられます．

まとめ

本サイトはいくつか隠れサービスを利用してます（明らかにしても心配ないほど自信があります）． これらのサービスはBase64が指定した64文字で合計16文字のパスを利用しています． これらのHTTPSを利用しているので，中間者攻撃でパスが盗まれる心配はありません． 信頼できる環境だけで利用するため，ショルダーハックなどの心配もありません． 乱数で生成したパスを利用するため，十分推測しにくいです． このような前提ではパスとHTTP認証は同じほどの安全性だと考えられます．

参考文献