大津です。 もう一つ SSL が推奨されている可能性としては、歴史的な経緯もあるのもしれません。
これ書かれたのが commit ログの日付を見ると 2011-03-15 です。 2010年の11月末に WebSocket draft76 の脆弱性が報告され、当時 FirefoxやOperaなどが default で WebSocket を無効化し、Chromeなどはそのまま使えるような状況だったと思います。 SSLを利用すればキャッシュ汚染の脆弱性は回避できるので、当時 draft76 のWebSocket が利用されることが念頭にあって推奨と書かれてたのかもしれません。（あくまで可能性ですけど） その後 2011の7月にデータをマスクして脆弱性対応したWebSocket仕様が出て、今の RFC6455 に なっているので現在は問題ないのですが、koichik さんの返事にあるよう Upgrade の問題 もあり、特に修正されずそのままになっているのではないかと思います。 （単に気づかず放置されているだけかも） > "otherwise, all further communicatio for the connection (including the > server's handshake) MUST run > through the encrypted tunnel [RFC5246]." だと何か困るのか？だから HTTPS 推奨なのか、 この部分は、 「TLSハンドシェイクに失敗したら接続を切りなさい、そうでなければ引き続き暗号化通信上で WebSocketのハンドシェイク を含む全ての通信を継続しなさい。」 ということを書いてあります。「otherwise:そうでなければ」は、TLSのハンドシェイクに 成功して暗号化通信が行える状況を指しているので、それに続くWebSocketが非暗号化であ ると困るでしょう、だから（先のTLSハンドシェイクで確立した）暗号化通信を継続して使 いなさい(MUST)というこです。 WebSocketのHTTPS利用を推奨しているわけではないです。 (2013/12/08 10:57), mori dev wrote: > 小林 (koichik) さん、 > 森(mori_dev) です。 > > HTTPだと、途中のProxyなどによってはUpgrade: が通らない可能性があるため、 > HTTPを推奨しているのかもしれない。だから、xhr-polling で使う場合、WebSocket への > Upgrade: 処理は行わないのだし、HTTP でよさそうだとのこと。 > > わかりました。ありがとうございました。 > > 私の方でさらに調べたところ、 RFC6455 WebSocket ( http://tools.ietf.org/html/rfc6455 ) > に、ハンドシェイク時の仕様で、以下のような関係がありそうな記述をみつけたのですが、 > > 4.2.2. Sending the Server's Opening Handshake > > > When a client establishes a WebSocket connection to a server, the > server MUST complete the following steps to accept the connection and > send the server's opening handshake. > > 1. If the connection is happening on an HTTPS (HTTP-over-TLS) port, > perform a TLS handshake over the connection. If this fails > (e.g., the client indicated a host name in the extended client > hello "server_name" extension that the server does not host), > then close the connection; otherwise, all further communication > for the connection (including the server's handshake) MUST run > through the encrypted tunnel [RFC5246]. > > "otherwise, all further communicatio for the connection (including the > server's handshake) MUST run > through the encrypted tunnel [RFC5246]." だと何か困るのか？だから HTTPS 推奨なのか、 > といったところまではたどり着きませんでした。 > > socket-spec を書いた人が HTTPS を推奨する理由を説明している資料を見つけたら、 > この ML で報告しようと思います。 > > ありがとうございました。 > > > > 2013年12月8日 1:00 Koichi Kobayashi <koic...@improvement.jp > <mailto:koic...@improvement.jp>>: > > 小林 (koichik) です。 > > トランスポートの一つであるWebSocketは、最初HTTP(S)で > 接続してからUpgrade:によってプロトコルを変更します。 > しかしHTTPだと、途中のProxyなどによってはUpgrade: が > 通らなかったりするかもしれません。 > > HTTPSにすれば、途中のProxyなどでは通信の中身が > 見えないため、トラブルが少なくなると期待して > 推奨しているのかなと推測してみました。 > > もっとも、AWSのELBのようにSSLターミネータな > ところで弾かれるケースもあるわけですが。。。 > > この理由はトランスポートにXHR等を使う場合は > 関係なさげですね。 > > Socket.IOの中の人の意図はわかりませんが、 > 可能性の一つということで。 > > > On Sat, 7 Dec 2013 23:48:44 +0900, mori dev <mori.dev.a...@gmail.com > <mailto:mori.dev.a...@gmail.com>> wrote: > > > はじめまして。 > > ハンドルネーム mori-dev と申します。Node 歴は 3週間ほどです。 > > > > Socket.IO の HTTP リクエストで、URI スキーマとして HTTPS が socket.io-spec > > で推奨されている理由はなんでしょうか。 > > > > socket.io-spec ( > https://github.com/LearnBoost/socket.io-spec#uri-scheme ) > > というページで、Socket.IO の HTTP リクエストで、URI スキーマとして HTTPS が socket.io-spec > > で推奨されています。 > > > > URI scheme > > The URI scheme is decided based on whether the client requires a > > secure > > connection or not. Defaults to http, but https is the > recommended > > one. > > > > この根拠は何でしょうか。とくにふかよみするようなところではなく、本文から読み取れるとおり、通信が暗号化されていて HTTP > > よりセキュアだから、ということでしょうか。 > > publich key の 「SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference > 2013 ( > > > http://www.publickey1.jp/blog/13/spdyquicwebtcphtml5_conference_2013.html)」という記事には「HTTPSではTCPコネクションを複数張っているの > で、1つが欠損してもほかのTCPコネクションは関係なくデータを送れます。」とあります。これも推奨する根拠と関係があるのでしょうか。 > > > > Socket.IO の v0.9.16 を、xhr-polling, jsonp-polling > > で利用する予定で、調査していて、疑問に思い、質問しました。 > > たとえば、以下のような http リクエストではなく > > > > > > > http://localhost:8081/socket.io/1/xhr-polling/sIp1vNChR6RLWu74equ1?t=1386426845697 > > > > https モジュールを使った結果に対し、socket モジュールを使い、 > > > > > > > https://localhost:8081/socket.io/1/xhr-polling/sIp1vNChR6RLWu74equ1?t=1386426845697 > > > > といったふうにするのが推奨されているようだ、という認識です。 > > > > > > 関連リンク > > > > * https://github.com/LearnBoost/socket.io-spec#uri-scheme > > * > > > https://github.com/Jxck/socket.io-spec#uri-%E3%82%B9%E3%82%AD%E3%83%BC%E3%83%9E > > > > -- > > > > --- > > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com > <mailto:nodejs_jp%2bunsubscr...@googlegroups.com> にメールを送信します。 > > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 > > > -- > { > name: "Koichi Kobayashi", > mail: "koic...@improvement.jp <mailto:koic...@improvement.jp>", > blog: "http://d.hatena.ne.jp/koichik/";, > twitter: "@koichik" > } > > -- > > --- > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com > <mailto:nodejs_jp%2bunsubscr...@googlegroups.com> > にメールを送信します。 > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 > > > -- > > --- > このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 > このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com にメールを送信します。 > その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。 -- --- このメールは Google グループのグループ「Node.js 日本ユーザグループ」の登録者に送られています。 このグループから退会し、メールの受信を停止するには、nodejs_jp+unsubscr...@googlegroups.com にメールを送信します。 その他のオプションについては、https://groups.google.com/groups/opt_out にアクセスしてください。
