codesこの広告は、90日以上更新していないブログに表示しています。指摘頂いたタイポや誤訳などを更新しました。構成を一部修正しました。セキュリティブログに下記のようなエントリが投稿されました。Blogエントリはそこまで長くないので、ここに翻訳の全文を記載します。徐々に廃止していくという方針についてアナウンスします。前進させる手段であるという点は、広く同意が得られています。インターネットのアプリケーションでは、暗号化通信を広く使おうという声明が出ています。機能を取り除き始めていくという合意にいたりました。この計画は、大きく二つの要素から成ります。サイトでしか、すべての新しい機能が使えなくします。アクセスできないようにしていきます。最初のステップとしては、この期限をコミュニティで決める必要があります。どれが「新しい」機能なのかを定義する必要があります。できない機能」と定義するなどが考えられます。ハードウェアの機能にアクセスするようなものは、制限されます。このプランの二つ目の要素は、セキュリティと互換性のトレードオフを踏まえて進む必要があります。機能を削れば、壊れるサイトも出るかもしれません。そのため、私たちはその破損具合をモニタし、セキュリティ的なメリットとのバランスを取る必要があります。同様に私たちは既に、セキュアではないサイトから使われる機能のより緩い制限についても考えています。スコープについても制限する提案がなされています。古いコンテンツでも使えなくなるという意味ではないことです。解釈され、セキュアになります。コミュニティと強調して進めることで最も成果が得られます。Groupに対して何らかの提案を作成するつもりです。議論に参加してくれた多くの人に感謝します。中心としたセキュアな世界にしていこう」という提案です。含め多くの人が多くの場所で行ってきました。公開されたサービスが多く有り、これは徐々にしか移行していくことができません。移行を促すということです。そのための作業として、まず以下があります。それをいつからやるか?新しい機能ってどれのことか?より詳細なプランはここに書かれています。一般化し、その使われ方も多岐にわたるようになりました。メールや金融取引まであらゆることを行います。人がそこに依存すれば、同時に攻撃するメリットもどんどん増えていきます。使えば、そのパケットはだれかに盗み見られているかもしれません。どこかから送られて来たメール内のリンクは、罠サイトに通じているかもしれません。いう米国機関までもが、大規模な盗聴を実施していた可能性がでてきました。ユーザの多くは、プロトコルや暗号の知識など無いでしょう。した人にも安全に使えるように、安全側に倒されていくのは必然かと思います。実際そういったサービスは増え始めています。無いと使用できないものもあります。公開されるコンテンツはまだまだあります。移行するように呼びかけてきました。移行を促すものと解釈できるでしょう。なっていくのか?端的に言えば「暗号化すべきかどうか」ではなく、「暗号化しない理由があるか」を考えることになっていくんだと思います。化っていうのは結構前から始まっていました。本格的にそういう時代になっていくんだなという気がします。携わっている人なら思うところはあるでしょう。いう事を言ってられる局面ではないのかもしれません。言わざるをえないところまで来たということか。HTTPS」になっている実感はありました。化に踏み切るサービスはでてくるかもなぁ。ないと新しいことができない」のニュアンスを強めるということでしょう。選ばない理由はあまり無いと思っています。別にビジネスだけの基盤ではありません。どんな使い方もできて、何をしてもいい。窮屈にするのかどうか」です。確かに、デバッグしにくいなどの気持ちもわかります。円くらい払っています。悪用されて誰かに迷惑をかけた場合どうでしょう。俺にはまだその答えはわかりません。考える上で重要な問題だと思います。単純に是非だけで割り切れる問題ではないし、個々の立場やコンテキストによって結論は変わっていくでしょう。必要があれば声を上げる必要が有るし、必要に応じて準備をしていく必要が有ります。今回は、そうした議論をする上で知っておくべき動きについて知っている範囲で紹介します。要求される流れやその理由を紹介します。そのパケットを正しく通過させる必要があります。意図的に落とされてしまい接続が確立できない場合が報告されています。そのポートを空ける必要もあります。このパターンに対処する一番簡単かつ確実な方法の一つが、経路を暗号化してしまう事です。ヘッダはもとより、自分を経由したパケットを一切見る事ができないため、基本的には丸っと通すしかなくなります。通してしまえば、新たな穴を空ける必要も有りません。いう組み合わせに載ってくる可能性が予想されます。したものは、仕様自体が最初から暗号化前提で作られているものがあります。暗号化が必須になっています。ないと登録することすらできません。場合は毎回求められます。整備されつつ有ります。した仕様の策定は、セキュリティサンドボックス化が非常に重要になり、慎重に設計されています。そもそも使えない、もしくは制限がかかるものは増えていくと予想されます。移行を助ける仕様など全てを暗号化前提にするといっても、現実的に難しい場面があることは既知の問題です。した問題に対する解決策や、それに準ずる回避策として、最近ある話題について紹介しておきます。Proxyすべての通信が暗号化されると逆に困る場面も考えられます。通信が暗号化されていては、中身が見えないのでフィルタリングできません。同じように、平文だったから提供できたサービスは実は色々あります。途中で通信をほどいて、そうしたサービスが提供できるようにするための仕様が考えられています。明示的に許すというイメージです。呼ばれ、議論されています。持つ証明書検証の仕組みなどを使います。問い合わせて検証し、相手を確認する必要があります。「とりあえず通信経路を暗号化」できるとうれしいという考え方もできます。いうヘッダを用いてクライアントを暗号化通信に誘導します。そもそも検証が行われないことが前提なため、証明書はいわゆる「オレオレ証明書」でサーブできます、ただしエラー画面は出ません。仕組みから見て「安全な通信」とは言い切れません。し、そうできない場面への対応というとこになるでしょう。コンテンツも攻撃される可能性があります。呼ばれ、現状ブラウザはコンテンツに応じて以下のようなアフォーダンスを提供します。コンテンツをブロックする特にコンテンツがブロックされる場合、正しい表示にならなくなります。移行を妨げる原因になる場合があります。膨大なレガシーコンテンツを例に出しています。書き換えてリクエストを発行してくれるというものです。オンリーに移行できるということです。upgrade-insecure-requestsしかし、ここまで単純な例ばかりではないため、実際はより細かい設定が可能になっています。タグで指定されています。証明書取得には、種類などあれどそれなりの費用がかかります。個人で趣味でやっているサイトなどで証明書を入れるのは、手軽とは言えない現実もあります。これは誰でも無料で手軽に証明書を取得できるというものです。ビジネス用途で使うものではありませんが、個人が趣味で使うドメインなどに使うことができます。加えていくつかのやり取りが両者間で発生します。外部とのやり取りも発生します。比して暗号/複合の計算コストも追加されます。した問題は既知であり、最適化の手段も整備されつつある印象です。以下のようなものがあります。よるハードウェアサポートによる高速化この辺は、そのうちまた別途まとめて書きたいと思います。さんにレビュー頂きました。公開後以下の方々にフィードバックを頂きました。内容については一切保証しません。マニュアル翻訳を開始しました。タイトルの通り、翻訳を開始しました。#nextwebconf月別アーカイブリンクhttps://jxck.iohttps://github.com/jxckhttps://twitter.com/jxck_http://mozaic.fmはてなブログをはじめよう!Jxckさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。