仕様書

[16] Fetch Standard (2016-03-11 02:17:17 +09:00 版) https://fetch.spec.whatwg.org/#port-blocking

悪いポートの判定

[23] 要求要求について should be blocked due to a bad port は、次のようにします >>16。

[24] URL を、要求の現在URLに設定します。
[25] scheme を、URLのschemeに設定します。
[26] ポートを、 URLのportに設定します。
[27] scheme が ftp の場合、
1. [29] ポートが 20 か 21 なら、「認められる (allowed) 」を返し、ここで停止します。
[30] scheme がネットワークスキームの場合、
1. [28] ポートが悪いポートなら、「妨害される (blocked) 」を返し、ここで停止します。
[31] 「認められる (allowed) 」を返し、ここで停止します。

[32] WebSocket (scheme が ws や wss) は、この判定の時点で http や https に書き換えられているので、 HTTP の制約が適用されます。

[33] FTP から 80 にアクセスすることは認められますが、 HTTP から 20 や 21 にアクセスすることは禁じられます。

[34] 悪いポート (bad port) は、次のポートです >>16。

1 7 9 11 13 15 17 19 20 21 22 23 25 37 42 43 53 77 79 87 95 101 102 103 104 109 110 111 113 115 117 119 123 135 139 143 179 389 427 465 512 513 514 515 526 530 531 532 540 548 556 563 587 601 636 993 995 2049 3659 4045 6000 6665 6666 6667 6668 6669 6697

[37] このリストは次の JSON 形式のデータファイルにも含まれています。

[35] data-web-defs/url-schemes.json at master · manakai/data-web-defs (2016-03-11 21:04:32 +09:00 版) https://github.com/manakai/data-web-defs/blob/master/data/url-schemes.json
- [36] ドキュメント data-web-defs/url-schemes.txt at master · manakai/data-web-defs (2016-03-11 21:04:53 +09:00 版) https://github.com/manakai/data-web-defs/blob/master/doc/url-schemes.txt

[48] 悪いポートを既定のポートとするプロトコルの多くは、プロトコル横断攻撃の危険性が知られる前に作られていて何の対策もしていなかったり、多くのサーバーや Unix 系システムで標準状態で動作していたりして、ポート制限がなければ危険であると考えられています。そうしたポートで HTTP を使うことは無いでしょうから、制限に実害もありません。

[49] 新しいプロトコルの設計者は、おそらくこれら以外のポート番号を使うこととなるでしょうから、プロトコル横断攻撃への対策を考える必要があります。

といっても今後新たに設計される TCP 上のほとんどのプロトコルは TLS を使うことになるでしょうから、 ALPN で十分です。

OS 以遠の制限

[11] Webブラウザー独自の制限に加えて、 OS のネットワークスタックレベルでの (利用者や管理者の設定による) 制限があるかもしれません。

[12] 所属ネットワークなどの (ルーター等の) 制限で、接続できないポートがあるかもしれません。

[43] 残念なことに、こんにちの多くの ISP は OP25B を実施しています。

[45] 組織のネットワークでは、 80 と 443 とその他少数のポート以外の利用を禁止していることがあります。

[46] このような制限はWeb互換ではありませんが、現にそうしたネットワークが少なからず存在している以上、著者は 80 と 443 以外使うべきではありません。

[13] こうした制限は、実際に接続を試みないとWebブラウザーからは検知できませんから、 OS に接続の開始を指示した後、拒まれたとのエラーになったり、接続を開始した後にタイムアウトでネットワークエラーとなったりします。

[47] 制限の実装方法にもよりますが、タイムアウトまでに非常に時間がかかり、しかも利用者にはエラーの正確な原因が通知されず、非常に悪い利用者体験となることがあります。ネットワーク管理者は、安易にポートを制限して利用者を混乱させるべきではありません。

歴史

00年代の実装

[39] 2001年8月に報告されたフォームを使ったプロトコル横断攻撃に対処するため、 Mozilla は特定の特権ポートへのアクセスを遮断することにしました。他の Webブラウザーも追随しました。

[8] HTTP/HTTPS Port-Blocking in WinINET - IEInternals - Site Home - MSDN Blogs (2015-03-31 16:25:26 +09:00 版) http://blogs.msdn.com/b/ieinternals/archive/2009/06/17/9769913.aspx

IE8's current port-block list contains:

19 (chargen), 21 (ftp), 25 (smtp), 110 (pop3), 119 (nntp), 143 (imap2), 220 (imap3), 993 (secure imap)

Blocking ports 220 and 993 is new to IE8.

[10] Part2 - browsersec - Browser Security Handbook, part 2 - Browser Security Handbook - Google Project Hosting (2015-03-31 16:41:34 +09:00 版) https://code.google.com/p/browsersec/wiki/Part2#Port_access_restrictions

[15] IRC の 6667 番は Chrome や Firefox ではブロックされますが、 IE ではされません。 IRC サーバーの実装によっては、 GET や HEAD や POST のような命令 (大文字や小文字) に対して

ERROR :"Oops, HTTP request received? This is IRC!"

... のように返答して接続を閉じるようです。

命令として実装されているようなので、接続の先頭でなくてもそう動作します。

WebSocket

[40] HTML5 により規定される WebSocket は、プロトコル横断攻撃を防ぐため、 port blocking を適用することを明文化しました。ただしどのポートを遮断するべきかは実装に委ねていました。

[2] HTML Standard (2015-05-06 10:42:35 +09:00 版) https://html.spec.whatwg.org/#dom-websocket

[7] HTML Standard (2015-03-15 01:40:28 +09:00 版) https://html.spec.whatwg.org/#dom-websocket

If port is a port to which the user agent is configured to block access, then throw a SecurityError exception and abort these steps. (User agents typically block access to well-known ports like SMTP.)
Access to ports 80 and 443 should not be blocked, including the unlikely cases when secure is false but port is 443 or secure is true but port is 80.

[3] 利用者エージェントが接続しないように設定されているポートが指定されたら、 SecurityError 例外を投げなければなりません >>2。

[4] ただし 80 と 443 は、制限するべきではありません >>2。

[6] 80 への wss: や 443 への ws: であっても、制限するべきではありません >>2。

[14] WebSocket handshake は異なるプロトコルを偽装して接続する攻撃を防ぐように設計されていますから、他のプロトコルが動作するポートに接続できたとしても HTTP ほど問題にはならないかもしれません。

Fetch

[18] 2016年3月に、 Fetch Standard で port blocking が規定されました。 HTML Standard の WebSocket に関する規定もこれに統合されました。これによって誕生から15年を経て初めてWebプラットフォーム全体の port blocking が明文化されました。