HTTPSおよびセマンティックWeb/リンクされたデータ

W3Cブログに、HTTP/HTTPS/HSTS/UIRに関連するセキュリティーについてのトピックが掲載されましたので、日本語で速報します。訳文は翻訳速度優先ですので、間違いなどありましたら指摘いただけると嬉しいです。

原文:https://www.w3.org/blog/2016/05/https-and-the-semantic-weblinked-data/

HTTPSおよびセマンティックWeb/リンクされたデータ

20 May 2016 by Phil Archer | Posted in: Data, Semantic Web

もうお気付きであるとよいですが、W3Cは自Webサイトのセキュリティを向上させていて、他の皆にも同じことを強く奨励しています。我々のシステムチームからのいくつかの情報を、以下に書き出しました。もし興味があるなら、キー技術の参照先としてHttp Strict Transport Security (HSTS)やUpgrade-Insecure-Requests (UIR)がよいでしょう。

結論:みんながHTTPSを使用するのがよいです。また、我々のサーバーには適切な場所に賢い仕組みがあり、多くのブラウザにもあり、自動アップグレードの世話をしてくれるようになっています。

そこで、セマンティックWeb URIのどの部分の話しでしょうか?特にこのような名前空間では?:http://www.w3.org/1999/02/22-rdf-syntax-ns#

URI近代的な、安全なブラウザでは、あなたはここにリダイレクトされます:https ://www.w3.org/1999/02/22-rdf-syntax-ns# 。古いブラウザや、もっと重要な意味ではHSTSを認識しなかったり、UIRを認識しなかったりする他のユーザエージェントでは、リダイレクトされません。このため、http://www.w3.orgの名前空間を使用すると、中断せずに、行くことができます。

ここで複数の質問が発生します。

最初に、「コミュニティーの合意では、スキームのみの違いの2つのURL (http://とhttps://だが、将来は追加があるかもしれない)が同一リソースを指すことになっているのか?」です。私たちは、これはドメイン所有者によってのみ、そう仮定することができると信じています。具体的なケースとして http://www.w3.org/* では、そのように仮定しています。これは必ずしもw3.orgの現在または将来のサブドメインには適用されないことに注意してください。

第二に、セマンティックWebコミュニティの一部のメンバーが、既にHTTPSに移動したとします (それは w3id.org の重要な動機でした)。私たちがいまいるパスから、より安全なセマンティックWebへの移行は、どれほど急なのでしょうか。つまり、習慣的にHTTPではなくHTTPSを使用する場合。あなたは自分で使用しているソフトウェアのアップグレードを検討していますか?

セマンティックWebが、よりセキュアな接続上で動作するまでは、http URIのあたりを渡す操作では注意する必要があります。使っているブラウザからURIを貼り付けるときに、sを外すことを覚えておくなどです。

それはすごく苦痛ですが、我々が見てきた様々な回避策のほうがひどかったのです。例えば、私たちは意図的に、w3.orgサイトから、意図的に安全性の低くなっているサブドメインに、セキュアから離れた語彙の名前空間にリクエストを意図的にリダイレクトすることができます。こういうのは要りません。

第三に、HSTS/UIRの世界のキー機能は、古いリソースを編集する必要がないということです。通信がさらなる介入なしに、HTTPSを使用して行われます。これは、セマンティックWeb/リンクされたデータでもそうでしょうか?あるいは、より思い切った行動を考慮すべきでしょうか?例えば、以下の場所にあるturtleファイルの定義を編集する場合はどうでしょう。 http://www.w3.org/ns/dcat# が明確に http://www.w3.org/ns/dcat#Dataset が https://www.w3.org/ns/dcat#Dataset に対する owl:equivalentClass であることを示す場合。 (またはさらに悪いことに、実際には異なる件名を見ていって、定義をすべて複製する必要がある場合)。

私は第3の点が不要であることを望みます。が、それを確認したいと思います。

背景

W3CのシステムチームのJose Kahanが追記

HSTSは、指定されたドメインについて、HTTPからHTTPSへのクライアント側アップグレードを行います。しかし、そのヘッダーは、HTTPS接続を行うときにのみ送信されます。UIRは、ヘッダを定義します。それは、もしブラウザによって送信された場合は、サーバーにHTTPSを好むことを教えてくれますし、サーバーのほうでもHTTPSにリダイレクトし、その後 (レスポンスのヘッダを介して) HSTSを開始します。HSTSは、混合コンテンツの場合は処理しません。これが、UIRがHSTSを補完するために行う、その他の部分です。HTTPSへのリソースに関連付けられているすべてのコンテンツのURLを更新するようにブラウザに伝え、リスエストの前にこれを行います。

ブラウザのUAについては、もしHSTSがドメインで有効になっていて、ナビゲーションバーにそのURLを入力して文書を閲覧したり、新しいドキュメントへのリンクをたどる場合には、URLがHTTPかどうかに関係なく、リクエストはHTTPSで送信されます。文書にCSSファイルやJavaScript、または画像などが含まれる場合、そのURLがHTTPの場合、UAがUIRをサポートしている場合に限り、それらのリソースに対する要求がHTTPSとして送信されます。

Ruby on RailsによるWEBシステム開発、Android/iPhoneアプリ開発、電子書籍配信のことならお任せください この記事を書いた人と働こう! Ruby on Rails の開発なら実績豊富なBPS

週刊Railsウォッチ

インフラ

Rubyスタイルガイドを読む

BigBinary記事より

ActiveSupport探訪シリーズ