2/28/2019

「The OA」シーズン2の予告登場、配信は3月22日

Slashfilmより。カルト・ドラマ「The OA」が帰ってくる。

「The OA」が2016年に初めてNetflixで封切られた時、まったく別世界のように感じました。バラク・オバマはまだ大統領で、世界は(少し)こんなに滅茶苦茶ではなく、そしてブリット・マーリングの野心的なSFシリーズがカルト的ヒットになりました。そして、シリーズの第2シーズンが戻るまでに3年掛かりましたが、新しい「The OA」シーズン2の予告編の冒頭で述べたバラク・オバマの話だけではなく、さらに別世界から来たように感じます。第2部はオルタナティブな世界に関する全てです。「The OA Part II」で、もう1つの圧倒的なシーズンに備えましょう。

「The OA」は、コンテンポラリーダンスか何かを通じて世界を救う人々についてのブリット・マーリングとザル・バトマングリッジのシリーズの第2部に戻って来ます。マーリングは、7年間行方不明になった後に再び現れ、別の次元への入り口を通って他の行方不明者を救うために人々を集める女性プレーリー・ジョンソン/The OAとして戻って来ます。パートIIでは、OAは新しい次元を飛び越える事に成功し、そこで、彼女は私立探偵とチームを組んで数人のティーンエイジャーの失踪を調査しなければなりません。

これが「The OA」シーズン2の概要です。

「圧倒的な」物語が、「The OA Part II」と共に戻って来ます。このPart IIでは、彼女がロシアの遺産相続人とはまったく異なる人生を過ごし、そしてまたハップの囚われ人として再び自分自身を見いだすという新たな次元をナビゲートするOAに続くものです。Part IIでは、行方不明の10代のMichelle Vuを見つけることを目的とした私立探偵Karim Washingtonを引き合わせます。Michelleの居場所と、数人のティーンエイジャーの失踪に関連したNob Hillの家の謎を解決しようと試みるため、彼の進路はOAと交差します。一方、最初の次元に戻ると、BBA、Angie、そして男の子たちは、OAの物語の背後にある真実と彼女が説明した驚くべき現実を理解するために旅に出ます。

「The OA」は2019年3月22日金曜日にNetflixに戻って来ます。

2/27/2019

CloudflareのRPKIツールキット

Cloudflareのブログより

24 Feb 2019 by Louis Poinsignon

数ヵ月前、私たちは、CloudflareがResource Public Key Infrastructure(RPKI)に関与していることと、BGPインターネットルーティングをより安全にすることについての2度の発表を行いました。私たちの使命は、より安全なインターネットを構築することです。私たちはネットワークオペレータがRPKIをより簡単に導入できる事を望んでいます。

本日の投稿では、私たちの経験と使用しているツールについて説明します。ちなみに、RPKIは、ネットワークが暗号化検証済みの情報を使用して経路フィルタリングを展開できるようにするフレームワークです。IPアドレスと自律システム番号(ASN)のTLS証明書を思い浮かべて下さい。

あなたにとって何を意味するのか

私たちはIP経路を検証しています。これは、1.1.1.1 DNSリゾルバユーザーとして、あなたがキャッシュポイズニングの犠牲になる可能性が低いことを意味します。私たちは自分のIP経路に署名しました。つまり、Cloudflareのネットワーク上のWebサイトを閲覧しているユーザーが経路ハイジャックを経験する可能性は低いということです。

ルータプロトコルへのリソース公開鍵基盤(The Resource Public Key Infrastructure (RPKI) to Router Protocol)と互換性のあるルーターを持つ全てのPOP(Points of Presence)は、GoRTRと呼ばれるカスタムソフトウェアに接続され、無効な経路をフィルタリングしています。その配備は、当社のネットワークの約70%に相当します。

私たちは無効なトラフィック量に関して多くの質問を受けました。私たちの見積もりでは100Mbpsから2Gbpsです。無効な経路に向かうトラフィックを計算するのが難しいため、範囲は広いままです。私たちの規模では、それはパケットの大海の一滴に過ぎません。

RPKI環境の重要なリソースであるRoute Origin Attestation(ROA)が含まれていない小規模なサブネットとしてアナウンスされた多くの地域IPによって、1つのプロバイダがかなりのトラフィックシフトを経験したことは言及に値します。私たちは多くの重要なネットワークがインターネット・エクスチェンジ・ポイント上で不正経路をアナウンスしていることに気付きました。私たちはネットワーク運営センターにメールを送り、記録がほんの数日で修正されるのを見て喜びました。。

ツールについて話しましょう!

GoRTRとOctoRPKIの2つのコンポーネントがあります。私たちの設定の全体像。

Octorpki

OctoRPKIとGoRTRのエコシステム図

GoRTR

ネットワークが拡大し続けるにつれて、検証済みのROAリストをエッジに送信するための拡張性のあるソリューションが必要でした。リソースのキャッシュにCDNを使用するのが理想的です。RPKI Validatorによって使用されるフォーマットを使用してJSONファイルを取得する小さなGoアプリケーションGoRTRを作成しました。私たちは、それが様々なサーバーで使用できることを確認し、改ざんされていない事を保証するために暗号チェックを実装しました。デフォルトでは、rpki.cloudflare.com/rpki.jsonで利用可能なプレフィックスのリストを取得します。

独自の検証ソフトウェアを実行する必要はありません。RPKI対応ルータをGoRTRに接続してフィルタリングを開始するだけです。GoRTRはまた、WebサーバーとPrometheusタイプのメトリクスも公開します。それにも関わらず、あなた自身の検証ソフトウェアを実行したいならば、OctoRPKIはあなたの解決策であるかもしれないので読み続けて下さい。Dockerを使ってGoRTRを起動し、ルーターをポート8282に接続してRTRフィードを受け取ることができます。

$ docker run -ti -p 8282:8282 cloudflare/gortr

OctoRPKI

あなたが経路の検証を制御したいのであれば、私たちがあなたをカバーします!

Asset 1 0 25x

数ヵ月後に、OctoRPKIをリリースしました。タコのロゴの後ろには、Goで書かれたRPKI Relying Partyがあります。

なぜ、Validatorを作成したのですか?

現在のエコシステムは私たちに喜びをもたらしませんでした。私たちは、RPKI Repository Delta Protocol (RRDP)、本格的なモニターされたバリデーターサブシステム、そしてストレージクラスターに最終的な計算データだけをプッシュする能力を必要としました。私たちはGoでそれを構築することを複数の理由で決めました。わずかに増加したオーバーヘッドと引き換えに、私たちは柔軟性を得ました。Go言語用には、大量の暗号リソースとライブラリがあります。そして、私たちはこれが既に重要なコミュニティに利益をもたらすことを願っています。

リポジトリにはOctoRPKIに加えて証明書、ROA、マニフェストなどをデコードするためのライブラリが含まれています。コードはrsyncやRRDPとの同期を開始することができます。

GoRTRと同様に、最新の同期結果を取得するためのAPIと、アラートを展開するためのPrometheusメトリックス・エンドポイントが組み込まれています。内部的には、Prometheusを使って検証の状態を監視します。まもなくリリースされるGraphQL APIのデータも提供しています。

Dockerで始めることができます

dockerイメージはOctoRPKIを即座に実行する方法を提供し、操作に必要な5つのトラストアンカーロケーター(TAL)ファイル(AFRINIC、APNIC、LACNIC、およびRIPE)のうちの4つを完備しています。5番目はARIN TALです。従って、ARINからTALを追加することを忘れないで下さい。www.arin.net/resources/rpki/tal.htmlからダウンロードすることができます。

$ docker run -ti \
     -p 8080:8080 \
     -v $PWD/cache:/cache \
     -v path_to_arin_tal:/tals/arin.tal 
   cloudflare/octorpki

結果は、http://localhost:8080/output.jsonにあります。GoRTRをこのファイルに接続するには、-cache URL引数を使用します(JSONの一部のフィールドに署名する公開鍵をロードする必要があります)。

$ gortr -cache http://localhost:8080/output.json -verify.key path-to-key

結論として、これらのツールがRPKIを簡単に導入するのに役立つことを願っています。ルーティングセキュリティは避けてはいけない重要な問題です。このイニシアチブに参加し、インターネットをより安全にするネットワークの増加を楽しみにしています。5つのレジストリの経路に署名することから、数秒で暗号的に60000を超えるリソースを検証することまで、RPKIについて多くのことを学びました。OctoRPKIとGoRTRを常により安定した信頼性のあるものにするために努力を続けていきます。ご意見をお待ちしています!

2/26/2019

パスワードマネージャのセキュリティ

シュナイアーのブログより

パスワードマネージャ、特に1Password、Dashlane、KeePass、Lastpassのセキュリティに関する新しい研究があります。この研究は特にホストコンピュータ上のパスワード漏洩を調べます。つまり、パスワードマネージャが誤ってプレーンテキストのパスワードのコピーをメモリ上に置いているのでしょうか?

私たちが分析した全てのパスワードマネージャーは、「実行されていない」状態では、ユーザーの機密情報を十分に保護していました。つまり、パスワードデータベースがディスクから抽出され、強力なマスターパスワードが使用されている場合、パスワードマネージャのブルートフォースは計算上不可能です。

各パスワードマネージャは、メモリから機密情報をスクラブしようとしました。しかし、多分メモリリーク、メモリ参照の喪失、あるいは機密情報をサニタイズするための内部メモリ管理メカニズムを暴露しないようにする複雑なGUIフレームワークが原因で、機密情報を含む未処理のバッファが残っていました。

これは、1Password7で最も明白で、マスターパスワードやそれに関連する秘密鍵を含む機密情報がロック状態とロック解除状態の両方で存在していました。これは1Password4とは対照的で、1Password4では、エントリが「実行中のロック解除」状態でさらされ、マスターパスワードは難読化された形式でメモリに存在しますが、簡単に取り出せます。1Password4がロック解除に成功するとマスターパスワードメモリ領域をスクラブした場合、私たちが先に概説したすべての提案されたセキュリティ保証に従います。

この論文は、特定のパスワードマネージャの実装を批判することを意図していません。ともかく、すべてのパスワード管理者が従うべき合理的な最低基準を立証することです。全てのパスワードマネージャで機密メモリのスクラブを試みることは明らかです。しかし、各パスワードマネージャは様々な理由で適切な隠れサニタイズを実装していません。

例えば、

LastPassは、ユーザーがエントリにタイプしている間はマスターパスワードを難読化し、パスワードマネージャがロック解除状態になった時に、ユーザーの操作があった時にのみデータベースエントリがメモリに復号化されます。しかし、ISEは、ソフトウェアがロック状態になった後もこれらのエントリがメモリに保持されると報告しています。メモリリークのせいで、研究者がマスターパスワードと相互作用するパスワードエントリを抽出することも可能でした。

KeePassはマスターパスワードをメモリから削除し、回復することはできません。ただし、作業工程のエラーにより、研究者は相互作用した資格エントリを抽出することができました。Windows APIの場合、復号化されたエントリを含む様々なメモリバッファが正しくスクラブされないことがあります。

これが大事なことかどうかは、あなたのコンピュータが信頼できると考えるかどうかに掛かっています。

数人の人が私にEメールを送って、なぜ私のPasswordSafeが評価に含まれなかったのか、そしてそれが同じ脆弱性を持っているのかどうかを尋ねました。前者についての私の推測は、PasswordSafeが他のものほど普及していないということです。(これはに2つの理由があります: 1) あまり公表していません。2) デバイス間でパスワードを同期させる、またはパスワードデータをクラウドに保存する簡単な方法はありません。) 後者については、 プレーンテキストのパスワードをメモリに置いたままにしないようにPasswordSafeをコーディングしようとしました。

そんなわけで、Independent Security Evaluatorsへ: PasswordSafeをざっと見て下さい。

また、2014年に多くのクラウドベースのパスワードマネージャで見付かった脆弱性を覚えていますか?

ニュース記事、Slashdotスレッド

現実世界の不可能と思える数学

NAUTILUSより

ニアミス数学はほぼ正しい答えの正確な表現を提供します。

BY EVELYN LAMB
FEBRUARY 21, 2019

硬い紙と透明なテープを使用して、クレイグ・カプランはバックミンスター・フラーの創造や空想の新しい種類のサッカーボールのように見える美しい丸みを帯びた形状を組み立てます。4つの正12角形(すべての角度と辺が同じ12角形の多角形)と12角形(10面)で構成され、正三角形の形をした28個の小さな隙間があります。ただ1つ問題があります。 この図は不可能なはずです。この一連の多角形は頂点では交わりません。形は蓋をすることができません。

カプランの模型は、紙を使って組み立てたときに生じる余裕があるためにのみうまくいきます。側面は、ほとんど認識できないほど少し歪む可能性があります。カナダのウォータールー大学のコンピューター科学者カプランは、次のように述べています。

Impossibly real

アメリカの数学者ノーマン・ジョンソンが1960年代に偶然見付けたのは、予想外のクラスの数学的オブジェクトの新しい例です。ジョンソンは、2000年以上前にプラトンによって作られた幾何学的完成度のカタログをやり直して、プロジェクトを完成させるために取り組んでいました。無限の多様な3次元形状の中で、四角形、立方体、八面体、十二面体、二十面体の5つのみが同一の正多角形から構成され得られます。多角形を混ぜ合わせると、すべての頂点で同じ方法で出会う通常の多角形(アルキメデスの立体)と、プリズム(正方形で接続された2つの同一の多角形)およびアンチプリズム(正三角形で結ばれた2つの同一の多角形)からさらに13の形を作ることができます。

1966年、当時ミシガン州立大学にいたジョンソンは、現在はジョンソンの立体と呼ばれる正多角形のみで構成された別の92種類の立体を見つけました。そしてそれとともに、数年後にロシアの数学者ヴィクター・ザルガラー(当時はレニングラード州立大学)が証明したように、すべての可能性を使い果たしました。正多角形から他の閉じた形を作ることは不可能です。

それでも多面体の目録を完成させることにおいて、ジョンソンは何か変なことに気付きました。彼はボール紙と輪ゴムから模型を作ることによって形を発見しました。可能な多面体は比較的少ないので、彼はどんな新しい多面体もすぐにそれら自身を明らかにするであろうと予想しました。彼がいったん側面を配置し始めたら、形状は必要な事として一緒にクリックするべきです。しかし、それは起こりませんでした。「たくさんの多角形を組み立てたとき、組み立てられたものが正当な形であることはいつも明白ではありませんでした」とジョンソンは思い出します。

それらは解決できそうでできないように見えますが、最終的には不可能であることが証明されています。

モデルはしっくり来ているように見えるかもしれませんが、「もしあなたが計算をしたならば、それは全く説得力がないことが分かるでしょう。」と彼は言います。よく調べてみると、正方形のように見えたものはほとんど正方形ではないか、外観の1つは全く平らになっていませんでした。面をトリミングした場合、それらは正確に組み合わされますが、それらはもはや正確には規則正しくはありません。

ジョンソンは完璧な立体を列挙することを意図して、これらのニアミスに多くの注意を向けませんでした。「私はそれらを脇に置いて、有効なものに集中しました。」と彼は言います。しかし、この些細な完璧に近いことは、今日のカプランや他の数学愛好家の興味を引くだけではなく、ニアミス数学の大きなクラスの一部です。

ニアミスの正確な定義はありません。定義することはできません。不安定な現実の世界では、厳格で速い規則は意味がありません。今のところ、新しいニアミスのジョンソン立体を探す際、カプランは経験則に頼っています: 「立体に内在する本当の、数学的な誤りは、現実世界の材料とあなたの不完全な手を使って作業することから来る実用的な誤りに匹敵します。」言い換えれば、不可能な多面体を構築することに成功した場合 — それが可能な限りあなたがそれを欺くことができるように近い場合 — その多面体はニアミスです。数学的に他の部分で、ニアミスはあなたを驚かせたり騙したりするのに十分に近いもの、数学的な冗談やいたずらです。

円を二乗することや立方体を二倍にすることの古代の問題は、どちらもニアミスの傘下に入っています。彼らを焦らすように解決に開かれて見えますが、最終的には不可能であることを証明します。幾何学的図形はまるで閉じなければならないかのように見えますが、閉じることはできません。レオナルド・ダ・ヴィンチアルブレヒト・デューラーによるコンパスと真っ直ぐな構造のいくつかは、本物ではなくほぼ正五角形を生み出すように角度をごまかしました。

Shell game

それから消える正方形パズルです。この(上の)例では、直角三角形が4つに切り分けられています。ピースを並べ替えると、隙間ができます。それはどこから来たのですか? これはニアミスです。どちらの「三角形」も実際には三角形ではありません。斜辺は直線ではありませんが、傾きが青い三角形の0.4から赤い三角形の0.375に変わる小さな曲がりがあります。欠陥はほとんど感知できないので、錯覚がそれほど顕著な理由です。

数値の一致は、おそらく日常生活の中で最も有用なニアミスです: $2^{7/12}$はほぼ3/2に等しいです。このニアミスは、ピアノが1オクターブ内に12の鍵を持ち、西洋音楽における平均律システムの基礎となっている理由です。それは2つの最も重要な音程の間の妥協点を打ちます: オクターブ(2:1の周波数比)と5分の1(3:2の比)。5分の1がすべて完璧になるようにオクターブを細分化することは数値的に不可能です。 しかし、オクターブを12の等しい半音に分割することによって非常に近づくことができます。そのうち7つはあなたに1.498の周波数比を与えます。ほとんどの人にとってはこれで十分です。

数学がそれ自体でトリックを演じているかのように、数学の領域内でニアミスが発生することがあります。ザ・シンプソンズの「Treehouse of Horror VI (ハロウィーン・スペシャルVI〜3Dの衝撃〜)」のエピソードでは、数学的な才能のある視聴者が驚くべきことに気付いたかもしれません。方程式$1782^{12}+1841^{12}=1922^{12}$。とりあえず脚本家たちはフェルマーの最後の定理に反論しました。これは、nが2より大きい場合、$x^n + y^n = z^n$という形の方程式は整数解を持たないと述べています。あなたがポケット計算機にそれらの数を打ち込むならば、方程式は有効であるようです。しかし、ほとんどの計算機が管理できる以上の精度で計算を行えば、方程式の左辺の12乗根は1922.999999955867…であり、1922ではなく、フェルマーは安心することができます。これは、1000万分の1以下の驚異的なニアミスです。

しかし、ニアミスは単なる冗談以上のものです。カリフォルニア大学リバーサイド校の数学者ジョーン・バエズは、次のように述べています。ラマヌジャン定数と呼ばれるものがあります。この数は$e^{\pi\sqrt{163}}$で、約262,537,412,640,768,743.999999999999925に相当します。驚くほど整数に近くなっています。先験的に、これら3つの無理数$e$、$\pi$、および$\sqrt{163}$は、完全な整数はもちろんのこと、どういうわけか有理数を形成するために組み合わされるべきであると考えるべきではありません。これらがそんなに親しくなる理由があります。「われわれが理解できない偶然の一致ではありません。」とバエズは言います。「それはディープな数学のピースへの手がかりです。」正確な説明は複雑ですが、163がヒーグナー数と呼ばれるものであるという事実にかかっています。これらの数に関連する指数はほぼ整数です。

あるいは「モンストラス・ムーンシャイン」として知られている奇妙な数学的関係を取り上げす。1978年に数学者ジョン・マッカイが完全に自明で奇妙に具体的な所見196,884=196,883+1を説明したという話があります。最初の数196,884は、j-不変量と呼ばれる重要な多項式の係数として登場し、196,883はモンスター群と呼ばれる巨大な数学的オブジェクトに関連して登場しました。多くの人々はおそらく肩をすくめて一緒に動いていたでしょうが、所見は何人かの数学者を魅了しました。彼らは二つの一見無関係な主題: 数論とモンスター群の対称性との間の関係を明らかにしました。これらの関連性は、まだ把握されておらず、他のテーマにとってもより広い意味を持つかもしれません。物理学者エドワード・ウィッテンは、モンスター群は量子重力と時空の構造に深く関連しているかもしれないと主張しました。

数学的なニアミスは、数学における人間味の力と遊び心を示しています。ジョンソン、カプラン、その他は、生物学者が熱帯雨林を駆け巡って新しい種を探すような探求によって、試行錯誤によって発見をした。しかし数学では体系的に検索する方が簡単です。例えば、彼のウェブサイトでニアミスを集める数学的な趣味家であるジム・マクニールと、コンピュータプログラマーであるロバート・ウェッブは、多面体を作成し研究するためのソフトウェアを開発しました。

ニアミスは理想主義的でゆるぎない数学と私たちの贅沢で実用的な感覚の間の曖昧な境界に住んでいます。それらは近似の論理を逆にします。通常、現実の世界はプラトン哲学の不完全な影です。基礎となる数学の完成度は、実現可能な条件下では失われます。しかし、ニアミスがあると、現実の世界は不完全なレルムの完璧な影となります。近似は「正しい答えの正しくない見積もり」であり、「ニアミスはほぼ正しい答えの正確な表現です」とカプランは言います。

このように、ニアミスは数学者と数理物理学者の自然界との関係を変えます。「私は、現実世界の不完全性には本当に感謝しています。本質的に完璧ではないことが分かっているオブジェクトで一種の準完全性を達成できるからです。」とカプランは言います。「それは、私が現実の美しい壊れた感じのために数学の限界を克服することを可能にします。」

Hacker News

Google: ソフトウェアがSpectreタイプのバグを修正できるようになることは決してないだろう

ars technicaより

PETER BRIGHT - 2/24/2019, 2:30 AM

Googleの研究者たちは、Spectre攻撃の範囲と影響を調査し、Spectreライクな脆弱性はプロセッサの継続的な特徴となる可能性が高く、さらにソフトウェアベースの防御技術はパフォーマンス的に高コストを課すと主張する論文を発表しました。そして、コストがどうであれ、研究者たちは続け、ソフトウェアでは無力になるでしょう。一部のSpectreの欠陥は、効果的なソフトウェアベースの防御を持っていないようです。そのため、Spectreには、直接的な解決策はなく、コンピュータ環境の継続的な特徴となるでしょう。

MeltdownとSpectreの攻撃の発見と開発は間違いなく2018年の大きなセキュリティ上の話題でした。昨年1月に初めて明らかにされ、新しい亜種と関連する発見が年の残りを通して行われました。どちらの攻撃も、プロセッサの理論的なアーキテクチャ上の動作(プログラマが依存してプログラムを作成するという文書化された動作)と実装上の実際の動作との間の矛盾に依存しています。

具体的には、最近のプロセッサはすべて投機的実行を実行します。例えば、メモリから読み取られる値やif条件が真か偽かについての仮定を立て、これらの仮定に基づいて実行を進めることができます。仮定が正しい場合、推測された結果は保持されます。そうでなければ、推測された結果は破棄され、プロセッサは計算をやり直します。投機的実行はプロセッサのアーキテクチャ上の機能ではありません。これは実装の機能なので、プログラムを実行してもまったく見えないはずです。プロセッサが不適切な投機を捨てる際、それは投機が起こったことさえないようにするべきです。

後に残された足跡

研究者がMeltdownとSpectreを発見したのは、投機的な実行は完全に目に見えないわけではなく、プロセッサが投機的な結果を破棄した際に、不適切な投機の証拠がいくつか残るからです。例えば、推測によってプロセッサのキャッシュに保持されているデータが変わる可能性があります。プログラムは、メモリから値を読み取る時間を測定することによってこれらの変化を検出できます。

慎重に組み立てると、攻撃者は関心のある値に基づいてプロセッサを推測させ、キャッシュの変化を使用してその推測された値が実際に何であるかを明らかにすることができます。これは、Webブラウザなどのアプリケーションで特に危険になります。悪意のあるJavaScriptは、このようにして明らかにされたデータを使用して、実行中のプロセスのメモリレイアウトを調べ、次にこの情報を使用して任意のコードを実行します。ブラウザ開発者は、ブラウザプロセス内に安全なサンドボックスを構築できると想定しているため、スクリプトはそのプロセスを含むプロセスのメモリレイアウトを知ることができません。アーキテクチャ的には、これらの仮定は正しいです。しかし、現実にはSpectreがいます、そしてそれらの仮定を打ち負かします。

Intel、Apple、および特定の標準的なARM設計を構築している他のメーカーのチップが直面しているMeltdown攻撃は、この特に厄介な変種でした。 悪意のあるプログラムがオペレーティングシステムのカーネルからデータを抽出することを可能にしました。Meltdownの発見の直後に、そのような悪意のあるプログラムからデータの大部分を隠すため、オペレーティングシステムに変更が加えられました。IntelはMeltdownに対処するためにプロセッサに特別な変更を加えたため、最近のプロセッサはもはやこれらのオペレーティングシステムの変更を有効にする必要はありません。

ふさわしい名前

しかし、様々な変種や反復を伴う特定の攻撃スタイルとして最もよく考えられているSpectreは、更に狡猾だと示されています。プロセッサが機密コードを投機的に実行することを防ぐか、または投機的実行を通じて明らかになる可能性のある情報を制限するため、様々なソフトウェア技術が考案されてきました。

Googleの研究によると、これらのソフトウェア対策にはまだ直さなければならない点がたくさんあります。メモリから値をロードした後にすべての推測をブロックするなどのいくつかの対策は、多くの攻撃から守りますが、実際に使用するにはパフォーマンスを悪化させ過ぎます。研究者たちはChromeのV8 JavaScriptエンジンの修正版を試していましたが、この技術を無差別に使用すると、パフォーマンスが低下した場合に3分の1から5分の1になりました。他の緩和策はそれほど懲罰的ではありませんでした。例えば、ある種の開示から配列アクセスを保護するのに、10%のパフォーマンスコストでした。

しかし、どの場合でもトレードオフがありました。全てのSpectreの変種に対して緩和策が適用されないため、様々な手法を使用する必要があります。また、無差別に使用できない手法については、緩和策を適用する場所を特定することでも大きな課題があります。さらに、Googleは、既知のどのような緩和技術でも破ることができない汎用のSpectreファミリー攻撃を考案しました。

Spectre攻撃の重要な要素はそれらのキャッシュの変化を測定するためのタイミングシステムです。人々がSpectreに対抗する必要があるアイデアの1つは、アプリケーションで利用可能なクロックをそれほど正確でないものにすることです。実用的な理論は、長さが数ナノ秒のキャッシュの違いを測定する必要がある場合、例えばミリ秒の分解能を持つクロックは粗すぎるということです。研究者たちは小さなタイミング差を増幅するための技術を考案しました、そしてこの増幅はタイマーをより粗くするどんな試みも打ち負かすことができます。

終わりが見えない

そのため、同社は、Spectreを防御するためにソフトウェアの修正に頼ることはできないと結論付けました。ハードウェアの緩和は可能かもしれませんが、これは今のところ未解決の問題です。明確な解決策があったMeltdownとは異なり、Spectreは投機的実行に、はるかに多く内在しているようです。そして、投機的実行を捨てることもあまりいい選択肢ではありません。それはすべての高性能プロセッサの機能であり、そして、かなりの性能上の利点を提供すると言う正当な理由があります。

今のところ、安全な環境を構築しようとするアプリケーションは、ハードウェアによる保証、つまりプロセス間の保護に依存する必要があります。例えば、Chromeは、複数のドメインからのコンテンツが同じプロセス内で実行されないように変更されました。これはまだChromeサンドボックス自体をスクリプトによる攻撃から保護するものではありませんが、1つのスクリプトが他のドメインのコンテンツを攻撃することはできません。

全体から見て、この研究はSpectreが適切に命名されたことを示しています。ソフトウェアとハードウェアの両方の開発者が今後何年にも渡って悩まされることになるでしょうし、明確な終わりは見えていません。

Hacker News

2/25/2019

DNSの存在しない名前へのクエリについて (NO!)

ジェフ・ヒューストンのブログより。

February 2019
Geoff Huston

「No!」のどの部分がDNSに認識されていないのか?

ルートサーバーを含む権威DNSサーバーインフラへの攻撃の効果的な形式の1つは、いわゆるランダム名攻撃です。特定のドメイン名のオンライン可用性を目標としたい場合、ランダム名攻撃はそのドメイン内の名前を解決するクエリでドメイン名の正式なネームサーバを飽和させようと試みます。そのようなレベルの負荷では、「正当な」クエリはもはや答えられません。その結果、名前が消えて、サービス拒否攻撃が成功します。

この攻撃は、他の多くの形式の攻撃よりはるかに簡単に実行できます。高度な形式のクエリパケットの作成や、高度なレベルの攻撃ボットのコントロールを必要としません。選択した各ホストから必要なのは、ターゲットドメイン内でランダムな名前を生成し、そのランダムな名前を使用するURLを取得するだけです。これは通常、ホスト上で特権アクセスを必要としない単純なスクリプト内で実現されます。

DNSが「no such domain name」(NXDOMAIN)応答を処理する方法のため、この攻撃は信頼できるサーバーを標的にするのに効果的です。意図的に信頼できるサーバーにプレッシャーをかけることを目的としているため、攻撃者の目的はローカルのDNSリゾルバキャッシュを回避することです。分散攻撃でターゲットの名前空間内に存在する名前が使用されている場合、名前のクエリレベルが様々な組織的な攻撃者から増加するにつれて、解決応答は攻撃者のローカルの再帰リゾルバにキャッシュされます。信頼できるネームサーバを本質的に保護します。たとえ、攻撃は存在しないが一定のクエリ名を使用する場合でも、再帰リゾルバはDNS名が存在しないという事実をキャッシュし、このキャッシュされた情報を使用して同じ名前に対する後続のクエリに応答するので、リゾルバキャッシュは依然として有効です。攻撃がランダムに生成された名前を使用する場合、ローカルキャッシュは特定のクエリ名のみをキャッシュするため無効であり、新しいランダム名に対する各クエリは権限のあるサーバーに渡されて解決されます。

DNSが存在しない名前を解決するための要求をどのように処理するかを理解することは、この形式のランダム名攻撃に対してDNSをより強固にする方法を理解する上で重要な要素です。DNSのこの側面に焦点を当てるためにAPNICラボで、私たちが運営するドメインの一部である存在しないドメイン名へのクエリでDNSを取り除く実験をしていました。

方法は非常に簡単です。オンライン広告に埋め込まれたスクリプトを使用して測定実験を行い、サーバーインフラでクエリデータを収集します。このスクリプトは、存在しないランダムな名前に対するDNS解決クエリを生成します。その後、DNS再帰リゾルバがこれらの同じDNS名について権威あるネームサーバにクエリするのが分かります(図1)。

Nxd fig1

図1 – NXDOMAIN実験

1日あたり何百万ものエンドポイントに広告を表示するように指示することで、地理的な多様性とプラットフォームの多様性の両方に関して、インターネットの幅の大部分を網羅するビューを素早く得ることができます。

予測される結果

私たちはこの簡単な実験から何が期待できるかについての仮説を持っていました。

仮説を説明する前に、DNSリゾルバがどのように構成されているかについてのいくつかの背景を知る必要があります。クライアントには、1つ以上のDNSリゾルバのアドレスがロードされます。例えば、私のISPは2つのそのようなリゾルバアドレスを提供します。それらはDHCPベースの自動設定によって私のデバイスに渡されます。アプリケーションがDNSクエリを生成すると、アプリケーションホストのネームリゾルバ・ライブラリルーチンはこれらのリゾルバアドレスの1つにクエリを送信します。DNSはUDPプロトコルであるため、エンドホストが応答を受け取るという保証はありません。そのため、エンドホストはクエリを起動したときにタイマーを開始します。タイマーが期限切れになり、応答が受信されていない場合は、クエリが繰り返されます。エンドホストに複数のリゾルバが設定されている場合、繰り返しクエリは別のリゾルバに送信される可能性があります。連続してタイムアウトすると、クライアントは設定されたリゾルバ群に対してさらに繰り返しクエリを発行する可能性があります。連続した問い合わせ間の間隔は、総問い合わせ期間が経過するまで長くなることがあり、その時点で問い合わせは破棄されます。

クエリ間のタイムアウト期間、およびクエリがリゾルバ内でアクティブなままでいる時間の合計は、DNSリゾルバの実装とローカル構成設定によって異なります。そのようなアプローチの一例、Microsoftのクライアント・リゾルバライブラリにはクエリーリピート手順の説明があります。

再クエリを実行するのは、クライアントリゾルバライブラリだけではありません。再帰的リゾルバでも同様のタイムアウトメカニズムが使用されています。これらのリゾルバは、応答を受け取らないときにさらにクエリを発行することもあります。名前に対して 2つ以上の権威ネームサーバーが設定されている場合、繰り返しのクエリはネームサーバー群全体に送信されます。典型的には、エンドホストからよりも再帰的リゾルバから再問い合わせするためのはるかに保守的なアプローチを私たちは目にします。エンドホストとフォワーディングリゾルバの両方が非常に攻撃的な一連の再クエリタイマーを使用すると、ロードされたサーバー上で一つのクエリがクエリの嵐を引き起こす可能性があり、一時的な処理イベントが意図しないサービス拒否攻撃に変わる可能性があります!

一般的な振る舞いの原則は、応答しないサーバーはリゾルバからさらにクエリを引き出すことですが、これらの再クエリはサーバーに大きな負荷をかけてはいけません。

クエリと同様に、応答を見てみましょう。ゾーンに名前が存在しない場合は、DNS応答がクエリをした側に返送されます。DNS応答は応答コード3、NXDOMAINを使用します。この応答は、名前がゾーンに含まれていないことを示しています。リゾルバはこの応答を自分のクエリに対する終了応答として解釈する必要があります。これはローカルにキャッシュ可能な応答であるため、クエリの種類に関係なく、同じ名前に対して繰り返しクエリが行われた場合、キャッシュの有効期間中、キャッシュリゾルバはそのローカルキャッシュから回答できます。

私たちはこれで質問に答える事ができます。NXDOMAINでクエリに応答すると、何が期待されますか?

権威サーバーがすべてのクエリに応答しており、複合ネットワーク遅延とサーバー処理遅延の遅延がクライアントの再送信タイマー値の範囲内であると仮定して、各クライアントから1つのクエリが表示されると想定しました。

実験で使用したサーバーのパケットキャプチャを実行して全てのクエリに回答し、これらの名前に対する全てのクエリが一致する応答を生成したことを確認しました。

サーバへの遅延が長いクライアントの場合、繰り返しクエリが発生する可能性がありますが、未解決のクエリがまだクライアントに対して「オープン」であると仮定すると、最初の応答が2番目のクエリのタイムアウトの時間枠内にクライアントに届く可能性があります。

これらの理由で、私たちは例外的な遅延条件がいささかレアであると予想していたので、ドメインの権威サーバによって見られるようにそれぞれの存在しないユニークな名前のための平均クエリ数は2よりはるかに1の値に近いだろうと期待していました。

実際の結果

私たちは実験のランダムなサンプルからのデータを使用し、そして権威サーバーに提示されている名前の最初の30秒以内に存在しない名前のための質問だけを調べました。このデータセットには、6,269,472の測定値が含まれていました。

これらの存在しないドメインに対する権威サーバーで確認されたDNSクエリの数は14,003,675、またはクエリされた一意の名前あたり平均2.23クエリでした。特に上記の我々の期待を考えると、これは驚くほど高い価値です。

実験用に4台のサーバーを運用し、シンガポール、フランクフルト、ダラス、サンパウロにサーバーを配置し、エンドホストがクエリに与えられる名前がそれらの位置に最も近いサーバにDNSクエリを向けるように、実験エンドホストを地理的に配置します。私たちは、エンドホストへの往復時間はほとんどすべての測定エンドポイントで0.5秒以内であり、クライアントソフトウェアで1秒の再クエリータイマーを使用すると、クエリータイムアウトが発生して再クエリを実行して、パフォーマンスが低下するのは10%未満になると予想されます。一意の名前あたり2つを超えるクエリのこの平均は、予想される結果のかなり上回っています。

平均値は大量の情報を隠すため、個々の実験の分布を理解するのに役立ちます。大きすぎるクエリを使用した実験は少数しか見ていないのでしょうか? あるいは、よりノーマルな分布を見ているのでしょうか。

Nxd fig2

図2 – 存在しない一意の名前ごとのクエリ数の分布

図2は、各実験のクエリ数の分布を示しています。

驚くべきことに、名前が定義されていないことを証明するために一つのクエリを使用した実験は43%に過ぎませんでした。この数字は、実験の半数以上が最初のNXDOMAIN応答を受け入れなかったことを意味します。更に36%のリゾルバシステムが2つのクエリを使用してドメイン名が存在しないことを確認し、21%が3つ以上のクエリを使用しました。エンドホストでの実験の初期ロードから30秒にわたるクエリ数の範囲は、1クエリから297クエリまででした!

より低い範囲のクエリ(1〜100)をよく見ると、対数スケールのプロット(図3)がほぼ直線的に減少しています。これは、スケールのないデータの指数関数的な減少と相関しています。

Nxd fig3

図3 - ユニークな存在しない名前ごとのクエリ数のより低い分布範囲

連続するクエリ間の時間間隔はどうですか? 識別できるな時間の特徴はありますか? 最初のクエリの時間をサーバーで見られる時間を開始時間とし、最初のクエリとクエリの時間との間の時間差を使って連続するすべてのクエリを記録すると、これらの時間の分布を見ることができます。そして、私たちはこれらの時間差の分布を調べることができます。それらは図4に示されています。

Nxd fig4

図4 - 最初のクエリから再クエリまでの経過時間の分布

特に最初の問い合わせから4秒から12秒の間に、局所的なピークの間に識別可能な1秒の間隔がある。5、10、20秒のピークもバックグラウンドよりはるかに高いです。しかし、そのような規則的なピークは主要な印ではありません。

この再クエリパターンに寄与する要因はおそらくいくつかあります。

Happy Eyeball

図3と図4で厳密に2つのクエリが密集して配置されているという非常に多くのインスタンスは、Happy Eyeballテクニック(RFC 8305)を使用したデュアルスタックの名前解決の副作用を示しています。デュアルスタックホスト上で実行されているHappy Eyeballアプリケーションは、クエリ名が存在するかどうかに関係なく、名前のAレコードとAAAAレコードに対するクエリを本質的に並行して生成します。

これらのクエリレコードを分割して、AおよびAAAAクエリタイプレコードのクエリ数を別々に見てみましょう(図5)。

Nxd fig5

図5 - AクエリとAAAAクエリが分離された、固有の存在しない名前ごとのクエリ数の分布範囲の下限

このデータの見直しでは、6,269,472(または実験の58%)のうち3,689,593の実験で名前が定義されていないことを証明するためにシングルクエリが使用されました。「シングル」は、一つのAクエリ、一つのAAAAクエリ、あるいは1つのAクエリと1つのAAAAクエリの両方です。それでも、40%強の時間で、同じクエリ名に対して複数のAクエリや複数のAAAAクエリが表示されることがあります。

エンドユーザーの約20%がデュアルスタック・プラットフォームを使用していることを考えると、Happy Eyeballアルゴリズムは、存在しない名前を解決しようとする場合、DNSに同様の追加のクエリ負荷を追加するようです。

一方、4,560,076のクエリをシングルクエリのインスタンスとして扱うことができるため、Happy Eyeballアプローチでは存在しない名前に対する追加クエリをいくつか説明していますが、それでも残りの9,443,599のクエリの説明を探す必要があります。私たちは、同じ存在しないドメイン名に対してクエリを繰り返します。

再クエリのリゾルバ

ここで、応答を失った可能性がありますか? リゾルバがNXDOMAIN応答を受信すると、そのリゾルバが「正常に」実行している場合はそれ以上のクエリを中止し、応答を受信しなかった場合(または制御不能のエラー状態になった場合のみ)、再クエリするという合理的な前提があります。同じクエリタイプに対する同じリゾルバアドレスからの再クエリ間隔の分布を図6に示します。

Nxd fig6

図6 - 同じリゾルバに対する再クエリ間隔の分布

同じリゾルバは、4ms以内に同じクエリを約1%繰り返します。リゾルバがミリ秒の再クエリタイマーを使用することは期待されておらず、再帰的リゾルバは未処理のクエリのリストを保持し、未処理のクエリと同じ名前の新しいクエリを生成しないこと、そして未処理のクエリと同じ名前の新しいクエリを生成ないことを考えると予想外です。

0.2秒、0.28秒、0.38秒、および0.8秒で、クエリ間隔の明確なピークがあります。0.8秒のピークをいくつかのDNSリゾルバの実装の再クエリ間隔に関連付けることは可能です。特定のリゾルバでは、0.2、0.28、0.38秒というかなりアグレッシブな再クエリタイマーがあるかもしれません。0.15秒未満の即時再クエリー負荷がこのように高いのはなぜかは不明です。この間隔はおそらく従来の再クエリ間隔には短すぎるが、ネットワークレベルのパケット重複の結果となるには十分に長くはありません。

データの累積分布(図7)は、総クエリ負荷の約12%が同じリゾルバからの反復クエリであり、再クエリ間隔は1.6秒以内であることを示しています。リゾルバの約8%が、前のクエリの200ミリ秒で再クエリします。これは非常に高速な再送信であるように見え、それがローカルの再クエリタイマー値に基づいていることはほとんどありません。

Nxd fig7

図7 - 同じリゾルバの再クエリ間隔の累積分布

同じリゾルバからの繰り返し問い合わせの原因に関する従来の仮定は、ネットワークパスの輻輳またはローカルリゾルバの輻輳が原因で、リゾルバが以前の応答を受け取っていないことです。ただし、このような短い間隔内で多数のクエリが繰り返されることは、その前提と一致しているようには見えません。

考えられる説明は、再帰リゾルバの集中です。クライアントに2つの転送リゾルバが設定されているが、どちらかのリゾルバへのクエリが同じ再帰リゾルバに渡される場合、以前のクエリがまだ応答を待っている間に再帰リゾルバへのクエリが到着する可能性があります。再帰リゾルバがそのタスクキューを管理する方法によっては、これらの重複したクエリは処理キュー内に残り、まだアクティブ前のクエリにもかかわらず順番に解決される可能性があります。

プライミング・リゾルバファーム

同じリゾルバIPアドレスからのクエリ以外にも、クエリが繰り返される可能性があるもう1つの原因が考えられます。これは、構成が不十分なリゾルバファームです。リゾルバファームは、多くの大規模DNSリゾルバで使用されています。全てのクエリを一つのDNSリゾルバインスタンスに渡すのではなく、スレーブリゾルバのコレクションがあり、着信クエリは解決のためにスレーブインスタンスにスケジュールされます。

私たちが見ているのは、共通のアドレスプレフィックスを共有するリゾルバIPアドレスのクラスタが同じクエリ名に対して繰り返しクエリを作成するという多数のインスタンスです。この動作の例を表1に示します。

リゾルバ クエリ時間
7x.xxx.0.178 0.752
6z.zzz.161.146 0.865
7x.xxx.0.230 0.980
6z.zzz.161.220 1.094
7x.xxx.0.188 1.201
6z.zzz.161.182 1.319
7x.xxx.0.180 1.430
6z.zzz.161.144 1.542
7x.xxx.0.226 1.650
7x.xxx.0.138 1.654
6z.zzz.161.134 1.762
6z.zzz.161.222 1.775

表1 - リゾルバファームの繰り返しクエリ

まとめてリゾルバファームを形成する一連のリゾルバを識別する方法について、非常に近似的な仮定をすることができます。最も簡単な方法は、共通の/24 IPv4アドレスプレフィックスまたは共通の/48 IPv6プレフィックスを共有する全てのリゾルバアドレスをグループ化し、それらを同じリゾルバセットのメンバーと見なすことです。

共通のアドレスプレフィックスを共有するリゾルバからの繰り返しクエリ間の間隔時間の分布は、同じリゾルバIPアドレスからのクエリの以前のケースと非常によく似ています(図8)。リゾルバファームからのクエリの全体量は、クエリ全体の負荷の約29%を占めるように見えます。

Nxd fig8

図8 - 共通アドレスプレフィックスリゾルバの再クエリ間隔を最大30秒に設定した場合の累積分布

共通の/24(IPv6の場合は/48)のこの分類を使用したクエリの繰り返しの発生率は重要です。同じリゾルバがクエリ負荷全体の約12%を占め、さらに16%が同じサブネットにあるリゾルバからのものです。

リゾルバファームクエリ間の時間間隔を図9に示します。

Nxd fig9

図9 - リゾルバファームの再クエリ間隔の分布

リゾルバファームの他の要素が同じクエリ操作を実行するように「フロントロード」シグネチャがあることと、0.38秒および0.8秒でピーク時間が再クエリされることの両方があることは明らかです。そして、0.38秒と0.8秒にピーク時間の再クエリがあり、これは同じリゾルバの再クエリの時間間隔と一致しています。

リゾルバクエリファームをロードするための累積時間分布を図10に示します。リゾルバファーム全体のクエリ時間の半分は0.25秒未満です。

Nxd fig10

図10 - リゾルバファームの再クエリ間隔の累積分布

それで、DNSが「NO!」のどの部分を理解できるのでしょうか。

「NO」の回答を効率的に処理できないというDNSの明らかな不能の説明の一部は、Happy EyeballがDNSの負荷を増大させるという副作用をもたらしたIPv6移行にあります。AおよびAAAAレコードに対して2つの連続したDNSクエリを使用することは、すべてのデュアルスタックエンドホストが単純な名前解決機能に対して2倍のDNSクエリ負荷を生成することを意味します。デュアルスタックエンドポイントの数が現在全体の約20%になっていることを考えると、DNS内に存在しない名前に対して平均約1.2回のクエリが発生すると予想されます。ある意味でこれはデュアルスタックの世界では避けられない副産物です。デュアルスタック展開のレベルが上がるにつれて、DNSでのAおよびAAAAクエリーの同時使用の増加が見込まれます。

しかし、存在しないドメイン名の平均クエリ率は、デュアルスタックホストのプールだけで生成できるものよりはるかに高いことがわかります。他に何が起こっていますか?

DNSにUDPを選択すると、いくつかの興味深い妥協点があります。軽量データグラムプロトコルの使用は、単純なクエリ応答アプリケーションモデルをサポートするための非常に効率的な方法です。DNSのスケーリング能力は、一部には、DNSトランスポート・プロトコルとしてのUDPの選択によるものです。これらのUDPベースのトランザクションではパケット損失の可能性が常に存在しており、ある程度まで再クエリの発生率はパケット損失によるものです。しかし、パケット損失だけで観察されたDNS再クエリ結果を得るために、インターネット上で約50%のパケット損失率を経験しています。かなり壊滅的なレベルのパケット損失が発生したことに気付くでしょう!

データグラムモデルはDNSクライアントにさらにいくつかの困難をもたらします。クライアントは、照会または応答のいずれかがドロップされたことを明確かつ明確に決定することはできません。クライアントができるのは、一定時間待機し、その時点で応答がないことがトランザクションの消失を示していると見なすことだけです。非常に短い再送信タイマは、輻輳時に高速の解決サービスを提供する可能性があります。ただし、再クエリタイマーが短いと、DNSの一時的な輻輳インシデントが悪化する可能性があります。そのため、アグレッシブな再クエリタイマーがDNSクエリの負荷に寄与している可能性があります。

この時点で、存在しないドメイン名に対する高い残存クエリ率を説明するため、DNSリゾルバの不正動作の領域に向かいます。共通のアドレスプレフィックスを共有するクラスタ内のすべてのリゾルバが、ほぼ同時に同じ名前に対するクエリを生成するリゾルバファームの動作が観察されています。NXDOMAIN応答を完全に無視し、受信する可能性のある応答に関係なく高いクエリレートを継続するように見える、高頻度クエリーレートモードに陥るリゾルバ動作も観察されます。

Happy Eyeballを考慮に入れると、存在しない名前に対する61%の解決努力が、権威ネームサーバーへの一つのDNSクエリで解決されることが朗報です。もっと悪いかもしれません。

それほど良くない(悪い)ニュースは、存在しない名前に対する解決の努力の39%が権威ネームサーバーへの単純なDNS問い合わせでは解決されないことです。これは印象的な結果ではありません。

この単純なテストでは、クエリ負荷の分類をいくつか実行できました。これを図11に示します。この方法でクエリ全体の約60%を占めることができました。残りの40件は、この段階でまだ不明です。

Nxd fig11

図11 - クエリの動作と相対的なクエリの量

名前が存在し、解決できる場合はどうでしょうか?

DNSは「YES」を「NO」よりもよく把握していますか?

いいのですが、それほどではありません。名前は、73%の割合で一つのクエリで解決されます。しかし、残りの27%は、名前解決を完了するために2つ以上のクエリを観測しました。解決可能な名前を解決するには、平均してDNS 1.65クエリが必要です。

NOの回答がYESよりも多くのフォローアップDNSクエリを生成する理由については興味深い問題です。これまでのところ、答えが何であるかについての明確な考えはありません。

2/23/2019

リーナス・トーバルズ、ARMがサーバースペースで勝てない理由

リーナスがメーリングリストで、ARMがサーバが使われない理由を説明している。

Michael S (already5chosen.delete-AT-this.yahoo.com) on February 21, 2019 12:53 am wrote:
Linusは究極のUnix系(unixoid)です。 私は、あまり忠実ではないUnix系がネイティブ開発で高いことに注目しました。私にとっては、彼のプロとしての生活のすべてにおいて、クロス開発を飲んで息づけるものとして、それは奇妙に聞こえますが、この考え方は少しも珍しくありません。

誰もがクロス開発をしている限り、プラットフォームがそれほど安定していなくても、だいたい保証できます。

あるいは思い通りになります。

「クラウド」とは、命令セットが重要ではないことを意味すると考える人もいます。そういう人は、自宅で開発し、クラウドにデプロイして下さい。

それはたわ言です。もし、あなたがx86上で開発するなら、あなたはx86上でデプロイしたいと思うでしょう。(そして「自宅」とは、あなたの家の中ではなく、あなたの職場の中でという意味です。)

これは、x86クラウドホスティングにもう少しお金を払う方がいいということを意味します。それは、自分のローカル設定でテストできるものと一致するからであり、得られるエラーはより適切に変換されます。

たとえあなたが主にしていることが、単にperlスクリプトを実行するなど、表面上クロスプラットフォームであっても、これは当てはまります。どうしても、できるだけ同じような環境にしたいという理由なだけです。

つまり、クラウドプロバイダーは自分たちのx86側からより多くのお金を稼ぐことになります。つまり、優先順位をつけることになります。そして、ARM製品はすべて二次的になり、おそらく無害な残骸に追いやられます(それはフロントエンドかもしれませんし、ただの静的HTMLなのかも知れません)。

ガイズ、x86がサーバ市場を引き継いだ理由を本当に理解していないのではないですか?

それだけではありませんでした。 それは文字通りこの「自宅で開発する」問題でした。何千もの中小企業が、不揃いのホワイトボックスPCを手に入れて、自分で何かたわいのないことを実行するのが簡単な、小さな内部ワークロードを持つことになりました。その後、作業負荷が拡大するにつれて、「実サーバー」になりました。そしてそれが拡大すると、突然、他の誰かにハードウェアとホスティングを管理させることが非常に理にかなったものになり、クラウドがそれを引き継ぎました。

本当にわかりませんか? これは難しいことではありません。これは作り話ではありません。これは文字通り何が起こったのか、そしてすべてのRISCベンダを殺したこと、そしてx86を他の誰もが単なる丸め誤差になるまでサーバの明白なお山の大将としたものです。何十年も前に全く架空のものに聞こえた何かです。

開発プラットフォームがなければ、サーバー空間のARMはそれを実現することは決してありません。64ビットの「ハイパースケーリング」モデルを販売しようとするのは、そもそも市場全体を獲得するために小さな格安のボックスを売ったことがない上に、顧客がおらず、作業負荷がないのにばかげています。

ARMの価格優位性は、Intelが現在持っているサーバー規模の絶対的に大きな優位性を埋め合わせるのに十分な量を得ない限り、ARMサーバーにとっては決してあり得ません。あなたが大量の開発コストを補うことができない場合、より安いNREでより小さなダイスになることは全くありません。これまでのすべてのARMサーバ製品を見て下さい。それらは遅くなっただけでなく、高価になりました!

そして電力の優位性は依然として理論的なもので、システムレベルではあまり示されていません。また、彼らの負担で開発したものだから、x86ボックスにもっとお金を払っても構わないと思っている場合は、まったく意味がありません。

これはARMには完全に真の利点を残しません。

これが基本的な経済学です。

そして、それを変更する唯一の方法は、見た目で言えば、ARMボックスにもっと安くデプロイすることができ、そしてここにあなたがあなたの仕事をすることができる開発ボックスがあれば、です。

開発者向けの実際のハードウェアは非常に重要です。これがPCが引き継いだ理由、そして他のすべてが死んだ理由であると私は冗談抜きに断言します。

それで、あなたが望むすべてをうんざりさせて、そしてあなたは「単なるクロスビルド」と言うことができます。しかし、あなたがそうする限り、ごく少数派になるでしょう。そして、あなたは全体像を見ていません。あなたは、実際の歴史を無視しています。

そして、これを「Unix系」の考え方と呼んでいるのは、あなたが現実に対して完全に断絶していること、そしてあなたの議論がどれほど愚かであるかを示すだけです。Unixは負けました。そう、それはLinuxの形で生き続けています。しかし、UnixはLinuxだけでなくWindowsにも負けました。実際には、ほぼ間違いなく、むしろWindowsに負けました。

なぜか? ほぼソフトウェア側で、同じ正確な理由です。どちらの場合も。開発者はどこにいましたか? WindowsとLinuxでした。それは開発者がアクセスしたものだからです。それらの作業負荷が「本物の」作業負荷に成長した時、それらはWindowsとLinux上で実行され続け、たとえそれがLinuxで極めて簡単であったとしても、それらはUnixプラットフォームに移されませんでした。いいえ、それは不必要で無意味な作業でした。同じプラットフォームにデプロイし続けるだけです。

ソフトウェア側でもハードウェアと正確に同じ問題です。同じプラットフォームで開発してデプロイするだけの場合は、クロス開発は無意味で愚かです。そう、できはしますが、可能であれば一般的には避けたいと思います。

最終結果: クロス開発は主に、開発が無意味になるほど弱いプラットフォームに対して行われます。だれも組み込みスペースでネイティブ開発をしません。しかし、ターゲットがネイティブ開発をサポートするのに十分なほど強力であるときはいつでも、そのように行うことに大きなプレッシャーがあります。なぜなら、クロス開発モデルはとても苦痛だからです。

上記の当然の結果は、そう、クロス開発はターゲット環境がネイティブ開発を行うには高すぎる場合にも行われるということです。それは高価な超高速大型コンピュータと伝統的な大きなUnixボックスの場合でした。しかし、これは高価なプラットフォームへのサポートを深刻に侵害し、安価な開発プラットフォームをはるかに可能なものにし、その分野に成長する可能性があります。

それがx86が勝った理由です。あなたは本当に世界が根本的に変わったと思いますか?

Linus

Hacker NewsSlashdot

2/22/2019

パスワードマネージャー: 秘密管理の内部で

Independent Security Evaluatorsより

February 19, 2019

概要

パスワードマネージャーを使用すると、暗号化されたデータベースから機密情報の保存と取得ができます。ユーザーは、セキュリティ保護されていないプレーンテキストにパスワードを保存する代替手段よりも、些細な引き出しに対してより優れたセキュリティ保証を提供するそれらを信頼しています。この論文で、私たちはパスワードマネージャーが提供すべきセキュリティ保証を提案し、Windows 10をターゲットにしている5つの一般的なパスワードマネージャ(1Password 7、1Password 4、Dashlane、KeePass、LastPass)の基本的な動作を分析します。パスワードマネージャは、使用されていない時のメモリの機密情報の消去や、パスワードマネージャがログアウトされてロック状態になった後のメモリのサニタイズなど、基本的なセキュリティのベストプラクティスを用いると予想されます。しかし、私たちが分析した全てのパスワードマネージャで、場合によってはマスターパスワードを含むロックされたパスワードマネージャから簡単に機密情報の抽出が可能であることが分かりました。この調査結果から、パスワードマネージャを使用する最大6000万人のユーザは、想定される安全なロック状態から機密情報を取得することができます。

(略)

結論

私たちが分析した全てのパスワードマネージャーは、「実行されていない」状態では、ユーザーの機密情報を十分に保護していました。つまり、パスワードデータベースがディスクから抽出され、強力なマスターパスワードが使用されている場合、パスワードマネージャのブルートフォースは計算上不可能です。

各パスワードマネージャにメモリから機密情報をスクラブしようとしました。しかし、多分メモリリーク、メモリ参照の喪失、あるいは機密情報をサニタイズするための内部メモリ管理メカニズムを暴露しないようにする複雑なGUIフレームワークが原因で、機密情報を含む未処理のバッファが残っていました。

これは、1Password7で最も明白で、マスターパスワードやそれに関連する秘密鍵を含む機密情報がロック状態とロック解除状態の両方で存在していました。これは1Password4とは対照的で、1Password4では、エントリが「実行中のロック解除」状態でさらされ、マスターパスワードは難読化された形式でメモリに存在しますが、簡単に取り出せます。1Password4がロック解除に成功するとマスターパスワードメモリ領域をスクラブした場合、私たちが先に概説したすべての提案されたセキュリティ保証に従います。

この論文は、特定のパスワードマネージャの実装を批判することを意図していません。ともかくパスワード管理者が従うべき合理的な最低基準を立証することです。全てのパスワードマネージャで機密メモリのスクラブを試みることは明らかです。しかし、各パスワードマネージャは様々な理由で適切な隠れサニタイズを実装していません。

下の図21は、評価結果をまとめたものです。

Picture21

図21. 分析した各パスワードマネージャのセキュリティ項目の概要

キーロギングとクリップボード・スニッフィングは既知のリスクであり、パスワードマネージャが提案されている「セキュリティの保証」を厳守しても、キーロギングやクリップボード・スニッフィングのマルウェア/手法の保護はありません。ただし、提案されているセキュリティ保証に対する重大な違反は赤で強調表示されています。ロック解除状態では、機密レコードの全部または大部分をメモリに抽出しないで下さい。積極的に見られているものだけを抽出する必要があります。また、ロック解除された状態では、マスターパスワードは暗号化された形式でも難読化された形式でも存在しません。

対話型レコードまたは全てのレコードを暴露するロックされた実行状態は、ユーザーの機密レコードを不必要に危険にさらします。最もひどいのは、ロックされた状態のマスターパスワードの存在です。

この知識が敵対者の間でどの程度広まっているかは不明です。ただし、これらのパスワードマネージャの最大6,000万人のユーザーが、潜在的に自分の機密情報を保護するためのソフトウェアを標的とした標的型攻撃の危険にさらされています。

私たちの意見では、最も緊急な事項は、パスワードマネージャがロック状態になったときに秘密をサニタイズすることです。通常、ほとんどのパスワードマネージャは、一定期間のユーザの非アクティブ状態の後に自分自身をこのロック状態にします。その後、プロセスはOSが再起動されるまで無期限に残る可能性があります。プロセスはユーザーによって終了されるか、または新しいバージョンが公開されるとプロセスは自己更新ワークフローの一部として自動的に再起動します。これにより、特定のパスワードマネージャの機密情報がメモリ内にクリアテキストで存在し、抽出に利用できるようになるまでにかなりの時間を作っています。

ユーザーが信頼できる最小限の保証を提供することに加えて、パスワードマネージャの開発者は、次の方法で機密情報を保護するために追加の防御策を採用する必要があります。

  • デフォルトでソフトウェアベースのキーロガーを阻止するため、検出あるいは手法を採用する
  • ロック解除された状態での機密漏洩の防止
  • 機密情報を抽出することをより困難にするためにハードウェアベースの機能(SGXなど)を使用する
  • 些細なマルウェアとランタイムプロセスの変更検出メカニズムの採用
  • インストール段階でインストールごとのバイナリスクランブリングを使用して、各インスタンスを独自のバイナリレイアウトにして、些細で高度な標的型マルウェアを阻止する
  • マルウェア作成者が標的にすることができるよく知られたAPIへの機密情報の露出を制限するためにカスタムGUI要素とメモリ管理を実装することによって、OSが提供するAPIへの秘密のトラバースを制限する

エンドユーザーは、いつものように、次のような敵対的活動への露出を制限するためにセキュリティのベストプラクティスを採用する必要があります。

  • OSを最新の状態に保つ
  • よく知られテストされたアンチウイルス・ソリューションを有効にするか利用する
  • 「Secure Desktop」など、一部のパスワードマネージャによって提供される機能を利用する
  • 暗号通貨の秘密鍵など、すぐに悪用可能な機密データにハードウェア・ウォレットを使用する
  • OSのオートロック機能を利用して、標的を絞った悪意のある活動を「防止」する
  • 危険にさらされた暗号化されたデータベースファイルのブルートフォースの可能性を阻止するために、マスターパスワードとして強力なパスワードを選択する
  • クラッシュログおよび関連するメモリダンプ(復号化されたパスワードマネージャデータを含む可能性がある)が発生した場合、機密情報の抽出が行われる可能性を防ぐためのフルディスク暗号化の使用
  • ロックされた状態でも使用されていない時には、パスワードマネージャを完全にシャットダウンする(ロックされた実行状態に置かれたときに秘密を適切にサニタイズしないものを使用する場合)

将来の調査

パスワードマネージャは私たちの生活の中で重要且つ、ますます必要なパーツです。私たちの意見では、ユーザーは私たちが「セキュリティ保証」として概説した最低限の基準に従って、機密情報が保護されていると期待するべきです。当初、パスワードマネージャは、「実行されていない状態」で機密情報を保護するように設計されていると想定されていました。ただし、実行中のロック解除状態、さらに重要なことにはロック状態になると、秘密のサニタイズとメモリ内の保持に矛盾が生じることに私たちは驚きました。

パスワードマネージャがロックされた実行状態で秘密をサニタイズすることに失敗した場合、これはユーザのコンピュータ上で実行されているパスワードマネージャのセキュリティ侵害の成功に対し、抵抗を最小にする道を提供することが簡単に達成できる目標になります。

最低限の「セキュリティ保証」が満たされたら、パスワードマネージャを再評価して、攻撃者がパスワードマネージャを危険にさらすために使用する可能性がある新しい攻撃方法を見つけ出し、それらに対する緩和策を検討する必要があります。

Hacker News

最近の広範なDNSハイジャック攻撃の詳細

シュナイアーが素晴らしい記事と評した、Brian KrebsのDNSハイジャックの詳細記事

米国政府は、多数の有力なセキュリティ企業と共に、イランのハッカー容疑者が多数の政府機関や民間企業から大量の電子メールパスワードやその他の機密データを盗むことを可能にする一連の非常に複雑で広範囲にわたる攻撃について警告しました。しかし、今日まで、その攻撃がどのようにして起こったのか、そして誰が攻撃したのかという詳細は秘密にされていました。

この記事では、これらの攻撃の大きさを文書化し、この圧倒的に成功したサイバースパイ活動の起源を、主要なインターネット・インフラ・プロバイダにおける連鎖的な一連の侵害にまでさかのぼります。

この記事でまとめた広範な調査を詳しく検討する前に、これまでに一般に公開されている事実を確認することが役立ちます。2018年11月27日、CiscoのTalos研究部門は、「DNSpionage」と名付けた洗練されたサイバースパイ活動の概要をまとめた記事を発表しました

この名前のDNS部分は、人間に優しいWebサイト(名example.com)をコンピュータが扱いやすいインターネットアドレスに変換することで、インターネットの一種の電話帳として機能するグローバルな「ドメイン・ネーム・システム」を指します。

Talosは、DNSpionageの加害者は、標的のDNSサーバーをハイジャックすることで、レバノンとアラブ首長国連邦の多くの政府機関および民間企業から電子メールおよびその他のログイン資格情報を盗むことができたと言います。そのため、全ての電子メールおよび仮想プライベートネットワーク(VPN)トラフィックが攻撃者によってコントロールしているインターネットアドレスにリダイレクトされます。

Talosは、これらのDNSハイジャックにより、攻撃者は標的となるドメイン(例: webmail.finance.gov.lb)のSSL暗号証明書を入手し、傍受した電子メールとVPN証明書を復号化してプレーンテキストで表示できるようになったと報告しました。

2019年1月9日、セキュリティベンダーのFireEyeは、「グローバルDNSハイジャック活動: 規模に応じたDNSレコードの操作 (Global DNS Hijacking Campaign: DNS Record Manipulation at Scale)」というレポートを発表しました。これは、スパイ活動の「方法」に関する技術的な詳細です。しかし、その犠牲者についての追加の詳細はほとんど含まれてはいませんでした。

FireEyeの報告とほぼ同じ頃、米国国土安全保障省は、すべての米国連邦民間機関にインターネット・ドメインレコードのログイン資格情報を保護するように命令する珍しい緊急指令を出しました。その命令の一部として、DHSはDNSpionage活動で使用されたドメイン名とインターネットアドレスの短いリストを公表しました。それらの詳細が以前、Cisco TalosやFireEyeによって発表されたもの以上ではありませんでした。

2019年1月25日、セキュリティ会社CrowdStrikeが、今日までスパイ活動によって悪用されていることが知られている事実上すべてのインターネットアドレスを記載したブログ記事を発表した際、それは変わりました。この記事の残りの部分は、この驚くべき -- そして継続的な -- 攻撃の真の範囲をより明確にするためにKrebsOnSecurityが行ったオープンソースの調査とインタビューに基づいています。

Cs ips

パッシブDNS

私は、CrowdStrikeのレポートに記載されている各インターネットアドレスを調べて、世界中の何千万ものWebサイトのドメインに結び付けられたDNSレコードの変更に関するデータをパッシブ(受動的)に収集するサービスであるFarsight SecuritySecurityTrailsの両方を通して、これらを実行することから始めました。

各インターネットアドレスから辿ってみると、2018年の最後の数カ月の間に、DNSpionageの背後にいるハッカーが、エジプト、イラク、ヨルダン、クウェート、レバノン、リビア、サウジアラビア、アラブ首長国連邦など、50以上の中東の企業や政府機関のDNS基盤の主要コンポーネントをセキュリティ侵害することに成功していました。

例えば、パッシブDNSデータは、攻撃者がmail.gov.aeのDNSレコードをハイジャックすることができたことを示しています。mail.gov.aeは、アラブ首長国連邦の政府機関への電子メールを処理します。ここに、このサイバースパイ活動で成功した他のいくつかの興味深いアセットがあります。

  • nsa.gov.iq: イラク国家安全保障勧告
  • webmail.mofa.gov.ae: アラブ首長国連邦外務省への電子メール
  • shish.gov.al: アルバニア国家情報局
  • mail.mfa.gov.eg: エジプト外務省のメールサーバ
  • mod.gov.eg: エジプト国防省
  • embassy.ly: リビア大使館
  • owa.e-albania.al: アルバニアの電子政府ポータルのOutlook Web Accessポータル
  • mail.dgca.gov.kw: クウェート民間航空局用の電子メールサーバ
  • gid.gov.jo: ヨルダンの総合情報局
  • adpvpn.adpolice.gov.ae: アブダビ警察のVPNサービス
  • mail.asp.gov.al: アルバニア警察の電子メール
  • owa.gov.cy: キプロス政府向けMicrosoft Outlook Webアクセス
  • webmail.finance.gov.lb: レバノン財務省の電子メール
  • mail.petroleum.gov.eg: エジプト石油省
  • mail.cyta.com.cy: Cyta通信インターネットプロバイダー、キプロス
  • mail.mea.com.lb: ミドル・イースト航空への電子メールのアクセス

FarsightとSecurityTrailsによって提供されたパッシブDNSデータも、これらの各ドメインがハイジャックされた時期についての手がかりを提供しました。ほとんどの場合、攻撃者はこれらのドメインのDNSレコードを変更したように見えます(すぐに「方法」にたどり着きます)。その結果、ドメインは彼らがコントロールしているヨーロッパのサーバーを指しています。

これらのTLDのDNSレコードがハイジャックされた直後(場合によっては数週間、場合によっては数日または数時間)、攻撃者はこれらのドメインのSSL証明書をSSLプロバイダのComodoLet's Encryptから入手することができました。これらの攻撃のいくつかに対する準備はcrt.shで見ることができ、そこにはすべての新しいSSL証明書作成の検索可能なデータベースがあります。

一例を見てみましょう。 CrowdStrikeのレポートはインターネットアドレス139.59.134[.]216(上記参照)を参照しています。これは、Farsightによれば、長年に渡って7つの異なるドメインの本拠地だったということです。これらのドメインのうち2つは2018年12月にそのインターネットアドレスにのみ現れました。レバノンと -- そして不思議なことに -- スウェーデンのドメインです。

最初のドメインは「ns0.idm.net.lb」で、これはレバノンのインターネット・サービス・プロバイダIDMのサーバーです。2014年の初めから2018年12月までの間、ns0.idm.net.lbは194.126.10[.]18を指していましたが、これは正しいレバノンのインターネットアドレスです。しかし、以下のFarsightのデータのスクリーンショットで分かるように、2018年12月18日に、このISPのDNSレコードは、IDM宛てのインターネット・トラフィックをドイツのホスティングプロバイダに向けるように変更されました(アドレス139.59.134[.]216)。

Idm net lb

Farsightによると、IDMのドメインと一緒に139.59.134[.]216で他に何が記載されているかに注意して下さい。

139 59

ドメインsa1.dnsnode.netおよびfork.sth.dnsnode.netのDNSレコードも、スウェーデンの本来あるべき場所から、12月に攻撃者によってコントロールされているドイツのホスティングプロバイダに変更されました。これらのドメインは、スウェーデンを拠点とする世界的大手DNSプロバイダーであるNetnod Internet Exchangeが所有しています。Netnodはまた、13のルートネームサーバの1つを運営しています。これは、グローバルDNSシステムの基盤となる重要なリソースです。

しばらくして、私たちはNetnodに戻ります。しかし、最初に、DNSpionageハッカーによって悪用された基盤の一部としてCrowdStrikeレポートで参照されている別のインターネットアドレスを見てみましょう: 82.196.11[.]127。オランダのこのアドレスは、mmdasi[.]comドメインの本拠地でもあります。Crowdstrikeは、ハイジャックされた基盤のDNSサーバーとして使用された攻撃者のドメインの1つであると言っています。

82 196

上のスクリーンショットからわかるように、82.196.11[.]127は、一時的に別のNetnod DNSサーバーのペアと、サーバー 「ns.anycast.woodynet.net」のホームになりました。 そのドメインは、Packet Clearing House(PCH)のエグゼクティブディレクターを務めるビル・ウッドコック(Bill Woodcock)のニックネームに由来します。

PCHはカリフォルニア州北部に本拠を置く非営利団体であり、特に500を超えるトップレベルドメインとDNSpionageがターゲットとしている中東のトップレベルドメインのDNSを管理しています。

標的となるレジストラ

2月14日、KrebsOnSecurityが接触したNetnodのCEOであるLars Michael Jogbäckは、攻撃者がNetnodのドメイン名レジストラのアカウントを獲得した後、2018年12月下旬と2019年1月上旬にNetnodのDNSインフラの一部がハイジャックされたことを確認しました。

Jogbäckは、2月5日に同社のWebサイトで発表した声明を指摘し、Netnodは1月2日の攻撃における自分たちの役割を知り、このプロセスを通じて全ての関連当事者および顧客と連絡を取りました。

「国際的なセキュリティ協調に参加していたNetnodは、2019年1月2日にこの波に巻き込まれ、MITM(man-in-the-middle)攻撃を受けたことを認識しました。」と述べています。「Netnodは攻撃の最終目的ではありませんでした。その目標は、スウェーデン以外の国でインターネットサービスのログイン情報を取得することにあったと考えられています。」

2月15日のこの作者とのインタビューで、PCHのウッドコックは、DNSpionageハッカーがそのドメイン名レジストラへの不正アクセスを悪用した後、彼の組織のインフラの一部が侵害されたことを認めました。

それが起こった時、pch.netとdnsnode.netの両方のレジストラの記録は同じ情報源を指していました。それは、ドイツに拠点を置くドメインレジストラKey-Systems GmbHとスウェーデンの会社Frobbit.seです。Frobbitは、Key Systemsの再販業者であり、両社は同じオンラインリソースを共有しています。

ウッドコックは、ハッカーはPCHのレジストラがExtensible Provisioning Protocol(EPP)と呼ばれるシグナリングメッセージを送信するのに使用していた資格情報を偽造したと言います。EPPは、グローバルDNSシステムの一種のバックエンドとして機能するほとんど知られていないインタフェースです。ドメイン登録者は、新しいドメインの登録、変更、転送など、ドメインレコードの変更について地域レジストリ(Verisignなど)に通知できます。

「1月上旬、Key-Systemsは、有効な認証情報を盗んだ人物が、自分たちのEPPインタフェースを悪用したと考えていると言いました。」とウッドコックは言いました。

Key-Systemsはこの話についてコメントを控えましたが、同社の再販業者の顧客の事業の詳細については話し合っていないと述べています。

Netnodの攻撃に関する声明書は、Frobbit.seの共同所有者でもある同社のセキュリティディレクターPatrik Fältströmにさらに問い合わせを言及しました。

KrebsOnSecurityへの電子メールで、Fältströmは、FrobbitとKey Systemsの両方からのDNSpionage攻撃者によって、正式に許可されていないEPP命令が様々なレジストリに送信されたと言いました。

「この攻撃は、私の視点から見れば、明らかに深刻なEPP攻撃の初期バージョンです。」と彼は書いています。「つまり、目的は正しいEPPコマンドをレジストリに送信することでした。 私は将来への外挿に対して個人的には非常にナーバスになっています。レジストリでは、レジストラからのEPPコマンドを許可する必要がありますか? 私たちは常に弱いレジストラを持っているでしょうか?」

DNSSEC

これらの攻撃のさらに興味深い側面の1つは、NetnodとPCHの両方が、DNSSEC(別名「DNS Security Extensions」)の熱心な支持者であり採用者であることです。これは、DNSpionageハッカーが実行できる攻撃のタイプを打ち破るように設計された技術です。

DNSSECは、特定のドメインまたは一連のドメインに対する全てのDNSクエリにデジタル署名を付けることを要求することで、アプリケーションが偽造または改ざんしたDNSデータを使用するのを防ぎます。DNSSECでは、ネームサーバは、特定のドメインのアドレスレコードが転送中に変更されていないと判断した場合、そのドメインを解決してユーザにそのサイトへのアクセスを許可します。ただし、そのレコードが何らかの方法で変更されたか、要求されたドメインと一致しない場合、ネームサーバーはユーザが不正なアドレスにアクセスするのをブロックします。

DNSSECは、DNSpionageがローンチした攻撃を緩和するための効果的なツールになりますが、アジア太平洋地域のインターネットアドレスレジストリであるAPNICによって集められた測定によると、DNSSECを有効にした世界の主要なネットワークとWebサイトは、たったの約20パーセントです。

Jogbäckは、NetnodのインフラはDNSpionageの攻撃者から3つの別々の攻撃を受けたと言いました。最初の2つは、2018年12月14日から2019年1月2日までの2週間の間に発生し、DNSSECによって保護されていないサーバーを標的にしました。

しかし、12月29日から1月2日までの間に行われた3回目の攻撃は、DNSSECによって保護され、独自の内部電子メールネットワークにサービスを提供するNetnodインフラを標的にしたと言います。しかし、攻撃者はすでにそのレジストラのシステムにアクセスしていたため、そのセーフガードを一時的に無効にすることができました — または少なくとも2つのNetnodの電子メールサーバーのSSL証明書を取得するのに十分な長さでした。

JogbäckはKrebsOnSecurityに、攻撃者がこれらの証明書を入手したら、攻撃者がコントロールしているマシンに転送することで、攻撃の第2段階を開始する準備をしながら、攻撃対象のサーバに対してDNSSECを再度有効にしたと言いました。しかし、Jogbäckは、攻撃者が後でインターネット・トラフィックの抜き取りを試みる前に、何らかの理由で、 DNSSECを無効にするためのレジストラへの不正アクセスを怠ったと言いました。

「私たちにとって幸いなことに、彼らは中間者攻撃を開始した時、それを削除するのを忘れていました。」と彼は言いました。「もし彼らがもっと熟達していたら、そのドメインからDNSSECを削除して、完遂していたでしょう。」

ウッドコックによると、PCHは全てのインフラでDNSSEC検証を実行していますが、同社の全ての顧客、特にDNSpionageがターゲットとしている中東の一部の国々では、このテクノロジを完全に実装するようにシステムを設定していません。

ウッドコックによると、PCHのインフラは、2018年12月13日から2019年1月2日までの4つの異なる攻撃において、DNSpionage攻撃者によって標的とされていました。攻撃のたびに、ハッカーはパスワード・スラーピングツールをおよそ1時間オンにしてから、実行後、ネットワークを元の状態に戻す前にそれらをオフにします。

最近のほとんどのスマートフォンは、ユーザーが自分のデバイスに設定したアカウントに対して新しい電子メールを継続的に取得するように設定されているため、攻撃者は1時間以上監視用捜査網を有効にする必要はありませんでした。このように、攻撃者は短いハイジャックで非常に多くの電子メールの資格情報を確認することができました。

2019年1月2日、DNSpionageハッカーがNetnodの内部Eメールシステムを追いかけたのと同じ日、彼らはPCHを直接標的にして、同社の内部Eメールを処理する2つのPCHドメインのためのSSL証明書をComodoから取得しました。

ウッドコックは、PCHがDNSSECに依存していることでほぼ完全にこの攻撃をブロックしたと言いましたが、その時に旅行していた2人の従業員のEメールの認証情報を手に入れようとしていたといいます。2人の従業員のモバイル機器は、ホテルのワイヤレスネットワーク経由で会社の電子メールをダウンロードしていたため、ワイヤレスサービスを使用するための前提条件として、彼らはPCHのDNNSEC対応システムではなくホテルのDNSサーバを使用するように強制されました。

「標的になった2人は、旅行中でiPhoneを持っており、ハイジャックの間は、Captive Portalを越えなければなりませんでした。」とウッドコックは言いました。「彼らが、Captive Portalを使うためには、私たちのネームサーバーの電源を切る必要がありました。その間、携帯のメールクライアントは新しいEメールをチェックしました。それとは別に、DNSSECが、私たちを本当に完全に乗っ取られることから救いました。」

PCHはドメインをDNSSECで保護していたため、このメールインフラに対するハイジャックの実質的な影響は、およそ1時間リモートの2人の従業員以外誰も電子メールを受け取れませんでした。

「基本的にすべてのユーザーにとって、メールサーバーは短期間利用できなかったようでした。」とウッドコックは言います。「自分の電話などを調べていても、しばらくの間は解決しませんでした。各人がそれを不審に思っていたので、しばらくしてからもう一度確認しました。そして、彼らが再びチェックすると、うまくいきました。スタッフがEメールサービスの短い停止に気付きましたが、だれも他の人とそれを論議するとか、チケットをオープンすることを考えませんでした。」

しかし、DNSpionageハッカーを思いとどまらせることはできませんでした。PCHは今月初めに送られた顧客への手紙の中で、1月24日にそのWebサイトのユーザーデータベースを保持しているコンピュータがセキュリティ侵害されたとフォレンジック調査で判断したと言いました。データベースに格納されているユーザーデータには、顧客のユーザー名、bcryptパスワードハッシュ、電子メール、アドレス、および組織名が含まれていました。

「私たちは、攻撃者がユーザーデータベースにアクセスした、またはそれを排除したという証拠は見当たりません。」と、メッセージは読めます。「それで、私たちはあなたのデータが危険にさらされていると思っているからではなく、透明性と予防策の問題としてあなたにこの情報を提供しています。」

改善

この記事についてインタビューした複数の専門家は、DNSベースの攻撃に関する1つのなかなか解決しない問題は、多くの組織が当たり前のように自分のDNSインフラを利用する傾向があるということです。例えば、多くの企業は自分のDNSトラフィックをログに記録することさえしていませんし、ドメインレコードに加えられた変更を監視することもしていません。

疑わしい変更のために自分のDNSインフラを監視しようと努力する企業にとっても、一部の監視サービスはDNSレコードのスナップショットを受動的に取得するか、または1日1回だけしか取得しません。実際、ウッドコックは、PCHは少なくとも3つの監視システムに依存していると言い、PCHのDNSシステムを攻撃する様々な1時間ハイジャックを彼の組織に警告したことはありませんでした。

「私たちは3つの異なる商用DNS監視サービスを持っていましたが、どれもそれを捕まえられませんでした。」と彼は言いました。「それらのどれも事件が起きてから起こった事さえ私たちに警告しませんでした。」

ウッドコックによると、PCHはそれ以来、1時間に数回、自身のDNSインフラにポーリングし、変更があればすぐに警告するようにシステムを設定しています。

Jogbäckによると、Netnodも監視機能を強化し、ドメインインフラを保護するために利用可能なすべてのオプションを確実に使用するようにしました。例えば、同社はこれまで、ドメインのレコードを変更する前にレジストラが追加の認証手順を実行する必要があるサービス「ドメインロック」で、全てのドメインを保護していませんでした。

「私たちは、顧客を保護するためにより良い仕事をしていなかったことは本当に残念なことです。しかし、私たちは一連の攻撃の犠牲者でもあります。」とJogbäckは言いました。「襲われた後は、より良いロックに変更することができました。また、うまくいけば、誰かが再びロックするのをより難しくすることができます。しかし、私たちはこの攻撃の犠牲者であることから非常に多くのことを学んだと言うことができます。そして今、私たちは以前よりはるかに良くなっています。」

ウッドコックは、インターネットの政策立案者やその他のインフラプロバイダが、グローバルなDNSを深刻にあるいは緊急に脅しをかけているのではないかと心配しています。そして彼は、DNSpionageハッカーが今後数カ月から数年以内に他の多くの犠牲者を狙って悪用すると確信しています。

「これはすべて進行中の戦いです。」と彼は言いました。「イランがただちに影響を与えるために、これらの攻撃を行おうとしているのではありません。彼らは、インターネットのインフラに十分に深く入り込もうと試みており、望めばいつでも資料とともに逃げ出すことができます。彼らは将来、特定の目的に使えるように、できるだけ多くの方法を考えています。」

推奨

John Crainは、グローバルなドメインネーム業界を監督する非営利団体であるICANNの最高セキュリティ、安定性、および回復力担当役員です。Crainによると、攻撃者がターゲットのドメインやDNSインフラをハイジャックすることをより困難にすることができる多くのベストプラクティスは、10年以上前から知られています。

「この多くはデータの予防策(hygiene)にかかっています。」とCrainは言います。「大規模な組織から家族経営の事業に至るまで、多要素認証のような非常に基本的なセキュリティプラクティスには注意を払っていません。今日、あなたが準最適なセキュリティスタンスを持っているならば、あなたはやられます。それが今日の現実です。インターネット上で、より洗練された攻撃者が行動を起こしているのを目の当たりにしています。基本的なことをしていないのであれば、彼らはあなたを攻撃するでしょう。」

組織にとってのベストプラクティスには、次のものがあります。

  • DNSSECを使用する(署名ゾーンと検証応答の両方)
  • ドメイン名レコードが変更されないように保護するのに役立つレジストリロックのような登録機能を使用する
  • アプリケーション、インターネット・トラフィック、および監視用のアクセス制御リストを使用する
  • 2要素認証を使用し、関連する全てのユーザーや下請業者が使用することを要求する
  • パスワードが使用されている場合は、固有のパスワードを選択し、パスワードマネージャを検討する
  • レジストラや他のプロバイダとの報告のレビュー
  • 証明書の透過性ログ(Certificate Transparency Logs)などを監視して証明書を監視する

2/19/2019

1つ買えば1つ無料の怪しい経済

The Hustleより。無料、ポイント還元、これらは私たちを騙す怪しい経済。

無料取引は、最も理性的な消費者でさえ、熱狂的な狂人に変えることができる。しかし、彼らには、そう思ったのと同然なのだろうか?

BY ZACHARY CROCKETT
FEBRUARY 17, 2019

商取引では、1つのフレーズで1000人の営業担当者の効果があります。

それは最も理性的な消費者でさえ、3時間行列に並んで、3ドルを節約して、チーズケーキで顔にお互いをパンチする狂った狂人に変身させることができます。

もちろん、私たちは「1つ買えば、1つ無料」という話をしています。

本心では、私たちは本当に無料のものなんて無いことを理解しています。企業は私たちに彼らの真心を分け与えようとはしません。-- 時には、これらのプロモーションはあからさまに欺くことさえ可能です。

それでは、なぜ「無料」の魅力が私たちを虜にするのでしょうか? そして、これらの取引はそれでも価値があるのでしょうか?

「無料」の催眠力

あなたがごちそうを望み、あなたに選択が提供されると想像してみましょう。ハーシェイのKissが0.01ドル、そしてはるかに高品質のリンツ・トリュフが0.15ドルです。どちらを選びますか?

行動経済学者のダン・アリエリーは、彼の著書 『予想通りに不合理』の中でこの精密な実験を行ったところ、73%の人々がより高いリンツを選んだことを発見しました。しかし、ハーシェイのKissの価格を0.01ドルから無料に変更した場合、69%がKissを選びました。

その1つの単語「無料」に導入することで、研究の結果を完全に覆しました。

Chocos2

「無料」オプションが導入されると、それは私たちの意思決定プロセスを完全に変えます。ダン・アリエリー経由の例(写真: Zachary Crockett / The Hustle)

購入選択に直面した際、私たちは通常、迅速な内の費用便益分析を実行し、潜在的な満足度/喜びを価格と比較します。

しかし、アリエリーは、「無料」という言葉が導入された場合、コストが削減されるだけでなく、無料商品のメリットがより高いと考えていると結論付けました。突然、その平凡なハーシェイのKissは人類に知られている最高級のチョコレートになります。

その結果、私たちはゼロ価格効果、つまり無料の場合に商品に対する需要が劇的に増加する現象の犠牲になります。

例えば、私たちは15ドルのために店で低品質の体に合わないTシャツを購入することは決してないでしょう。しかし、同じTシャツが無料で、球場の大砲から発射された場合、私たちは骨を折って、12ドルのビールをこぼして、汚い手で掴もうとするでしょう。

「何かが「無料」を伴った瞬間、私たちは過度に興奮します」とアリエリーは説明します、そして「私たちはもはや合理的に考えません」。

小売業者はこれをよく認識しています -- そして1世紀以上の間、彼らはBOGO(Buy one Get one)として知られているプロモーションに参加することによって私たちの愚かさを利用してきました。

BOGOノミクス

私たちは、テレビ画面で点滅したり、eコマースのランディングページで画面に表示されたり、衣料品店のセーターにピン留めされたりしているのを見ます。1つ買えば、1つ無料!

この悪名高い宣伝の起源ははっきりしていませんが、The Hustleはそれを1908年の新聞の切り抜きまでさかのぼりました。

Bogo ads

カンザス州バーダーカウンティーインデックスで、1つ買えば、1つ無料の広告(1908)

主に女性向けに販売されていたこれら初期の広告では、1着分で2着のウールの婦人服が提供されていました。価格の不透明性がこれらの初期の頃には、最初の婦人服は両方のコストをカバーするために価格が上げられたでしょう。

今日では、これらのオファーは、それらを販売している企業によって「BOGO」と呼ばれ、すべての「無料」プロモーションの推定80%を占めています。買い物客の93%がBOGOを使用したことがあり、66%が自分の好きなタイプの割引だと答えています。

小売業者にとって、BOGOの取引は非常に効果的です。彼らは、忠実な消費者のために「何か良いことをする」ことを装って、低品質の在庫品の有益な整理を可能にします。

ある小売業者が1ペアあたり20ドルの費用をかけ、100ドルの「希望小売価格」を持っているジーンズがあるとしましょう(実際にはこの価格では決して売れません)。彼らが標準的な50%オフセールを実行するならば、彼らは30ドルの利益(50ドル - 20ドル)を得ます。BOGOを使用すると、1つではなく2つの製品を押し付け、ペアごとに同じ利益で持ち去ります。

50off

1つ購入すれば、1つ無料と、称賛された50%セールです(写真: Zachary Crockett / The Hustle)

理論上、彼らは追加費用なしで、完全に無料で2番目の製品を提供するように思われるので、買い物客はこれらの取引を好みます。しかし、業界関係者によると、私たちがBOGO取引で通常獲得する商品は、「低需要、非効率的、品質不足、および/または有効期限に近い」商品です。

コロンビア大学ビジネススクールのリテールスタディーズディレクターのマーク・コーエンは、私に次のように述べています。「BOGOは、準正当な — あまり正当ではないかもしれない — 取引の一つで、消費者が自分たちのしていることにあまり注意を払わないことに頼るものです。」

買い手は「無料」を見て、実際に計算をしなくても信じられないほど説得力があると感じます。

計算は簡単です。あなたがBOGO取引で本当に得ているのは、メーカーの希望小売価格(MSRP)から50%の割引です。そして、しばしば、この価格は最初から人工的に価格を上げられています。

なぜ「無料」取引が通常見かけほど良くないのか

ボニー・パットンは、Truth In Advertisingの偽装広告や虚偽のマーケティングを規制することを目的とした非営利団体のエグゼクティブ・ディレクターです。彼女は日々、公然と怪しい「1つ買えば、1つ無料」プロモーションの「警告の集中攻撃」を受けています。

パットンは、BOGOが見かけほど良くないことが多い理由がいくつかあると私に言います。

怪しいBOGO取引と共通の戦術は、小売業者が単に最初の商品をより高価にするということです。例えば、1枚のシャツを40ドルで購入し、1枚無料で購入するという取引があるかも知れません。しかし、シャツの実際の価格は20ドルで、単に通常価格で2枚購入しただけの可能性があります。

Consumer Reportsによると、過去数年間で80以上の小売業者に対して、誤解を招くような「無料」の宣伝について少なくとも150件の訴訟が発生しています。より注目すべきBOGOの例のいくつか(下記の訴訟へのリンク):

  • バーガーキングは、BOGOクロワッサン取引を提案したが、サンドイッチに通常の価格(2.16ドル)よりも高い価格(3.15ドル)を請求した。
  • MyPillowは枕でBOGOの取引を申し出たが、実際には最初の枕の価格をちょうど2倍にした。
  • VIsionWorksは眼鏡でBOGOを提供したが、彼らが最初の一組の価格を〜40%だけ値上げしたことが分かった。
  • Jos. A. Bankは、衣料品でBOGO取引を提供したが、元の商品のコストを引き上げた(つまり、「取引」の一部として、通常は600ドルで売られるスーツを800ドルで販売した)。
Mypillow

MyPillowに対する2017年の訴訟からの請求(Truth in Advertisingによる)

「小売業者は、しばしばあなたが商品の価格を操作することで得ることができるのと同じくらい有罪であることが多いです」とコーエンは言います。「あなたは、誰も払ったことのない価格を請求することがよくあります。 無料のものは、通常価格から切り取られるだけです。」

1つ買えば、1つ無料に関するもう1つの誤解は、表示価格よりも2つの商品に対して支払う金額が少ないため、合計の効用(満足度または幸福度)が高いことです。

その商品はあなたがゆくゆくは使うことを知っているものなら(練り歯磨きのようなもの)、これは理にかなっています。しかし、BOGOの取り引きはより一般的に期限切れの食物または衣類のような商品に適用されます。

しかし、私たちはしばしば、限界効用逓減の法則と呼ばれる小さなものを忘れてしまいます。

簡単に言えば、この法則は、商品から得られる効用は次の商品ごとに減少することを示しています。

たとえば、1枚買うと2枚のピザを購入する場合、最初の一切れは私たちに大きな喜びを与えます。 2番目の一切れは少し少ないです。2番目のピザにたどり着くまでに、私たちは膨らみ過ぎて、それを食べることの利点は劇的に減少します。

「無料」という言葉が含まれていると、たとえ1つしか必要としていなくても、消費者は2つのものを購入するという調査結果が出ています。1カートンの牛乳を買おうとして、BOGO取引に遭遇して2カートンを買おうとしている店に入った場合、その2つのカートンはほぼ常に無駄になります。

ですから、あなたがすでに2つ購入することを計画している(そして実用的な用途を持っている)何かについてのBOGO取引に遭遇しない限り、それは一般的に価値がありません。

話がうま過ぎる

もちろん、BOGO取引は、小売業者が私たちの消費を増やすために使用するのは「無料」プロモーションだけではありません。

ほとんどのオンライン衣料品ブランドは「無料」配送を提供していますが、資格を得るには最低購入金額(通常100ドル)を満たす必要があります。消費者の約58%が手数料を5ドルから10ドル節約するためだけにカートに商品を追加します — 多くの場合、当初購入予定ではなかったものです。

Amazonのようなプラットフォームでは、無料配送が商品の価格に反映されることがよくあります。通常10ドル+ 3ドルのS&Hで販売されているコーヒーマグカップは、無料配送で13ドルになります。正確に同じ金額を支払っていても、後者の価格設定モデルでマグカップを購入する可能性ははるかに高いのです。

もう1つの一般的な戦術は、商品(たとえば本)を無料で配りますが、元の費用を送料に埋め込むことです。本の価格が通常15ドルの場合、売り手は「寛大な1回限りの無料提供!」を持ち出し、無料で本を宣伝することができます(もちろん、15〜20ドルの送料は細字で)。

「無料」という心理的催眠術の助けを借りて、これらの戦略は小売業者に追加の負担をかけずに売上高の増加をもたらします。

「結局は、私たちは生命を維持するために様々なことに動機を与えられています: 空気、水、食料、住居、セックス、... そして値段などです。」とコーエンは言います。「しかし、人々は古い格言を忘れています。話がうま過ぎるなら、十中八九そうなのだと。」

Hacker News

2/17/2019

私は週末が嫌いな理由...

ブログcdahmedehより

April 15, 2017

月曜日です、不快なカウントダウンが始まりました。あなたは、すでに週末について考えています、そしてかろうじて始まりました。日が経つにつれて、あなたは金曜日の午後5時に執着します。金曜日の午後までには、2日間の休憩の見通しで頭がいっぱいになり、もう何もできなくなります。同僚の何人かはもう机にさえいません。彼らは早く退社しました。あなたが去る番になると、あなたは安堵のため息をつきます。それはあなたが待っていた瞬間です。週末の始まりです。

しかし、とても奇妙なのは、もう月曜日だということです。週末はぼやけていました。就業日に合わなかったすべてのものは週末に絞られました。食料品、洗濯、雑用、診察の予約などです。あなたが全てを終えたのは、日曜の晩です。仕事のように、週末は疲れました。あなたは眠りたいのですが、明日の月曜日には仕事について考え始めました。仕事に間に合うように目覚めるには早く眠る必要があるから、あなたはもう何もする時間がありません。

私たちの生活は手がかかります。私たちは配偶者、友人、家族との関係を維持する必要があります。私たちは運動、健康などで自分の体を大切にする必要があります。家は清潔に保ち、冷蔵庫は食べ物でいっぱいです。そして、それをすべて実行できるようにするには、私たちが生き生きとしているものの代金を支払うことができるように、賃金を稼ぐための仕事が必要です。

たった2日の週末で、私たちは自分がそのような短い期間内に全てのメンテナンスを圧迫しているのに気付きます。土曜日に友達と会います。日曜日に食料品を買います。土曜日の朝に洗濯をします。楽しむ時間はほとんど残っていません。テレビ番組を見ているだけの人もいます。人によっては、新しい芸術を学びます。

私たちが毎週、そんなにまで渇望する2日間では十分ではないことは明らかです。

ほぼ毎月、週末を1日延長する法定休日があります。奇妙なことに、これらの週末が終わった後、私は自分自身が安らぎを感じて休んだのです。その後の仕事の初日はより滑らかになり、私はそれほどストレスを感じません。

個人的には、私はできるだけ週末を延ばすことを試みました。私は平日に洗濯をします、私は平日の夜遅くに食料品を買います。私は平日に友達と会うようにしています。 私は、私の週末にそのような義務がなくなることを願っています。

私は週末には趣味に時間をかけたいです。しかし、私は自分が無力で窓の外をじっと見ていることが多いです。私の心は疲れています、私の体は疲れています。休む頃には日曜日の夜です。その時点で、ベッドに入って、再び仕事のサイクルを始める時が来ました。

私の人生は仕事が中心になっているように感じます。私は、(考えられる)合理的な週40時間労働で働いていますが、私はあまりにも多くの時間が奪われているように感じます。実際にオフィスにいるだけでなく、通勤もしています。私の朝は仕事の準備をすることに専念しています。私が夕方に戻ったとき、仕事の心を空にしなければならず、それはしばらく時間がかかることがあります。一日に数時間しか残っていません。

私はバックエンドのソフトウェア開発者で、コードを書くにはたくさんの創造性と思考が必要です。私の心が離れる前に私が奮い起こすことができるのはそれだけです。それに加えて、私は精神的に病気で、入念に瞑想しているので、もっと休む必要があります。しかし、私がしているのと同じことについて文句を言うより、健康的で生産的な同僚の話を聞きます。仕事でどんなに楽しくても、私はまだ疲れます。誰もがし、その後は誰もが休む必要があります。カフェイン、エナジードリンク、モダフィニルでさえそれを戻すことはできません。

私が、最初にこれを書き始めた時、問題は週末が短すぎることだと思いました。しかし、168時間で構成されている週は、40時間の献身的な仕事を説明するのに十分ではありません。私たちの体と心は、十分な休息と休憩なしには最適に機能することはできません。私達はそのために作られていません。私たちの生活は要求が厳しく、仕事は私たちの生活の多くを要求しています。

たとえ、現代社会は労働倫理から見ると、私たちが本当にこんなところまで来ることを可能にしたとしても、私たちはまだ十分に遠いとは思いません。私たちが倫理的で人道的な週間労働時間がどのようなものであるかを再考する際、基本的なニーズ、自身の欲求、夢、生理学と心理学を考慮に入れる必要があります。

私たちの生産量が会社の売上高に比例するのは、もはや工場労働者ではありません。機械と自動化は、私たちがかつて行っていた改善の役割を引き継いでいます。今日、私たちは芸術家そして開発者そして管理者そしてサービスプロバイダーです。私たちがしていることはまったくお金を稼がないかもしれません。それでも、私たちが自分にかなりの要求をし、そしてもっと提供するために、私たちはもっとする必要があります。

私たちは自身と私たちが気にかけているものにもっと時間をかける必要があると確信しています。私はもっと自分の面倒を見たいのですが、システムにこだわっているからできません。生きるために、私は請求書の支払いをする必要があります。私は運が強くないので、そのために一日のほとんどの時間を費やす必要があります。

このブログ記事がHacker Newsに投稿されました。 そこで議論を続けることをお勧めします。

2/16/2019

不思議な思考の幾何学の新しい証拠

Nautilusのブログより

2014年、スウェーデンの哲学者で認知科学者のペーテル・ヤーデンフォシュが、ポーランドのクラクフで心に関する会議を開きました。彼は概念的な、あるいは「認知的」な空間の理論について、Copernicus Center for Interdisciplinary Studiesの計らいで、ヤゲロニア大学で講演することになっていました。ヤーデンフォシュは、何十年もの間、私たちの脳がどのように概念や物体を描いているかを説明する認知空間のアイデアに取り組んできました。2000年の彼の著書「Conceptual Spaces」の中で、彼は「脳がシンボルを扱うチューリングマシンかニューラルネットワークを使ったコネクショニストシステムのどちらかであることは長い間、認知科学の共通の先入観(prejudice)であった」と書きました。クラクフでは、ヤーデンフォシュはその先入観に反対しました。彼は、講演「思考の幾何学 (The Geometry of Thinking)」で、人間はすぐに言語を学び、簡単に詳細を一般化するような今日の強力なコンピュータではできないことができることを示唆しました。(言い換えれば、多くの訓練をしなくても、ライオンとトラは4本足の猫であることが分かります) — 私たちは、コンピューターとは異なり、幾何学的な空間で情報を描いているからです。

Jacob Bellmund、Christian Doeller、Edvard Moser (ライプツィヒのマックスプランク研究所およびトロンハイムのKavli研究所の神経科学者)らの共著による2018年のサイエンスへの論文で、ルンド大学のヤーデンフォシュは脳科学の最近の進歩の中で、彼の考えを強調しました。彼は、脳の「内部GPS」に同じ神経回路を使用することによって、脳はそれが空間とあなたの位置を描くのと同じ方法で概念を描いていると主張しました。

「認知空間は、脳が世界の知識をどのように体系化するかについての思考方法です」とBellmundは言いました。これは、地理データだけでなく、物体と経験の関係にも関係するアプローチです。「私たちは、海馬における空間コーディングの原則が単なる空間ナビゲーションの領域を超えて関連しているように思われることを示唆する多くの異なるグループからの証拠に興味をそそられました。」とBellmundは言いました。言い換えれば、海馬の場所とグリッド細胞は、物理的な空間だけでなく概念的な空間もマッピングします。物体や概念の表現は、空間の表現と非常に密接に関係しているようです。

ヤーデンフォシュの理論は、認知科学者だけでなく神経学者や機械学習研究者にとっても創造力豊かな道を強調しています。

何十年にも渡る研究で、海馬と内嗅皮質という脳内の領域がGPSのように作用することを発見しました。これらの細胞は、脳の周囲を格子状に形づくり、その上のその位置を記録します。具体的には、嗅内皮質のニューロンは、空間内の均等に分布した位置で活性化します。これらの細胞が活性化する環境で各位置間に線を引くと、三角格子または六方格子をスケッチすることになります。これらの適切に名前が付けられた「グリッド」細胞のアクティビティには、別の種類のセルが特定の場所であなたの体を見つけるために使用する情報が含まれています。これらの「位置」細胞がどのように機能するかの説明は、科学者のJohn O’Keefe、May-Britt MoserとEdvard Moserが2014年のノーベル生理学・医学賞を受賞するのに十分に素晴らしいものでした。これらの細胞は、空間内の特定の場所、またはグリッド細胞で表されるグリッドにいるときにのみアクティブになります。一方、方向細胞は、頭が向いている方向を定義します。それでも、他の細胞は、あなたが自分の環境の境界、つまり壁や崖にいついるのかを示します。げっ歯類モデルは脳の空間グリッドの性質を解明しました、しかも、機能的磁気共鳴画像法で、それらは人間においても検証されました。

最近のfMRIの研究は、認知空間が海馬ネットワークに存在することを示しています -- これらの空間は、潜在的な処理の中心にあるという考えを支持しています。例えば、オックスフォードの神経科学者が率いる2016年の研究の被験者には、鳥の首と脚の大きさが変化するビデオが見られました。以前、彼らはサンタやジンジャーマンのようなクリスマスのシンボルと特定の鳥の形を関連付けることを学びました。研究者たちは、被験者が空間的に描写できない「心象」との関係を二次元地図上に作成したことを発見しました。それでも、fMRIデータのグリッド細胞の応答は、被験者が自分自身を物理的環境の中を歩いていると想像していた場合に見られるものと似ていました。この種の精神的処理は、私たちが家族や友人についてどう考えるかにも当てはまるかも知れません。Doellerは、私たちは身長、ユーモア、または収入に基づいて、身長が高いか低い、ユーモアがあるかないか、または裕福かそうでないかでコード化して、彼らを描写している可能性がある、と言いました。そして、現時点でこれらの次元のどちらが重要であるかに応じて、脳は他の友人に精神的に近い、または遠くにある友人を格納します。

しかし、認知空間の有用性は、既によく知られているオブジェクト比較だけに限定されているわけではありません。「これらの認知空間が私たちの行動に役立つ可能性がある方法の1つは、私たちが今まで見たことのない何かに遭遇した時です」とBellmundは言いました。「新しい物体の特徴に基づいて、私たちはそれを私たちの認知空間に位置づけることができます。それから私たちは古い知識をこの新手の状況でどのようにふるまうべきか推論するために使うことができます。」このように構造化された方法で知識を表現することで、新しい状況で行動する方法を理解することができます。

データはまた、この領域が様々な抽象化レベルで情報を表している可能性があることを示唆しています。あなたが頭の上から顎先に向かって海馬を通って移動したと想像するなら、あなたは環境全体を完全にマッピングするが、様々な拡大度で多くの様々な位置細胞のグループを見つけるでしょう。別の言い方をすると、海馬を移動することは、携帯電話の地図アプリをズームインまたはズームアウトすることに似ています。一箇所の場所の細胞で表される空間内の面積が大きくなります。このようなサイズの違いは、たとえば「犬」から「ペット」、「知覚者」まで、人間が抽象度の低レベルと高レベルの間をどのように移動できるかの基礎になる可能性があります。この認知空間では、ズームアウトされた場所の細胞は多くのタイプからなる比較的広いカテゴリを表し、ズームインされた場所の細胞はより狭くなります。

それでも、心は概念的抽象化だけでなく柔軟性も可能です — 幅広い概念を表すことができます。これを可能にするためには、関係する脳の領域が情報の交差汚染なしに概念を切り替えることができる必要があります。例えば、鳥の概念が車の概念によって影響を受けるのであれば理想的ではありません。げっ歯類の研究によると、動物がある環境から別の環境に移動する時(例えば、青の壁のケージから黒の壁の実験室など)には、位置細胞の発火は環境間で無関係であることを示しています。研究者たちは、ある環境で細胞がどこで活動しているのかを調べ、それが他の環境で活動している場所と比較しました。細胞が黒い部屋だけでなく青いケージの隅でも発火された場合、環境間で交差汚染が発生する可能性があります。研究者は、位置細胞の活動にそのような相関関係があることを確認していません。海馬は混乱することなく2つの環境を表すことができるようです。位置細胞のこの特性は、交差汚染を回避することが不可欠である認知空間を構築するのに有用です。「これら以前の発見をすべて結び付けることによって、私たちは現実の空間を考えているのか、それとも思考の次元間の空間を考えているのかに関わらず、脳は心象地図を保存するという仮定に至りました。」Bellmundは言いました。

科学者たちは依然として、海馬と高次認知機能との関連性を実験的に検証する必要があります。オックスフォードのグループのように、fMRIによる研究はまだ示唆に富んでいます。「fMRI信号の粗い性質はニューロンコードのレベルで結論を出す際に注意を促しますが、我々は非空間認識中のfMRI信号の異常に正確な六角形変調を報告しました。」研究者たちは結論を下しました。位置細胞が実際に認知空間内の特定の位置にある物体を表現できるかどうかも不明です。それらは非常に高解像度の脳のイメージングを必要とするため、人間の被験者との実験でこれを明らかにすることは困難です。しかし、最近の高解像度fMRIの進歩は解決策をもたらす可能性があります。

げっ歯類の研究も認知空間の存在を明らかにする可能性があるとBellmundは指摘しました。例えば、2017年の論文では、細胞をラットに配置すると音の周波数のマップを作成できることが分かりました。海馬の様々な細胞が様々な周波数の音に反応し、音の認知空間を形成します。さらに、海馬で格子状の活動を見調べた人間の研究でも、この活動は皮質の他の部分でも見られます。従って、複雑で高次の認知能力が脳のいくつかの部分の間の相互作用から生じる可能性が非常に高いです。

ヤーデンフォシュの理論は、認知科学者だけでなく神経学者や機械学習研究者にとっても実りある道を強調しています。それはキャンバス上の一種の不完全で一般的なスケッチであり、洗練と精巧さを促します。認知空間は、ヤーデンフォシュとBellmundが述べているように、「人間の思考のための領域一般なフォーマット」で、アルツハイマー病のような神経変性疾患の原因を解明するのを助け、人工知能の新しいアーキテクチャを特徴付けることができる「非常に重要なフレームワーク」です。

Hacker News

RIS Live BGPメッセージ・ストリーム

RIPE NCCのブログより

Chris Amin — 15 Feb 2019

私たちは、BGPメッセージをリアルタイムで提供するフィードするRIS Liveと呼ばれるプロトタイプを立ち上げています。これはRIS Route Collector (RRC)から情報を収集し、WebSocket JSON APIを使用して世界中のルーティングイベントを監視および検出します。

背景

2001年から、RIPE NCCは、Routing Information Service (RIS)を使用して、世界中の複数の場所からインターネットのルーティングデータを収集し、保存してきました。数年前にRIS基盤を完全に再設計したことで、ユーザーがほぼリアルタイムにBGPデータをストリーミングできるようになる実験的なインタフェースを構築することができました。

この実験はすでに学術研究目的でいくつかの組織で使用されています。2017年、INSPIREグループCAIDAはそれを使ってリアルタイムBGPハイジャック検出ツールであるARTEMISを開発しました。そのソフトウェア開発段階はRIPE NCC Community Projects Fund 2017から資金を受けています。

RIS Live

私たちは、完全にサポートされた一般向けプロトタイプとして提供された以前の実験の改良版であるRIS Liveを発表します。RIS Liveには、世界中のルーティングイベントを監視および検出するためのWebSocket JSON APIが付属しています。研究者にとっては、非対話型のフルストリーム(firehose)も利用可能です。

Ris live demo

RIS Liveは、RIS収集アーキテクチャを介してRIS経路コレクターからのメッセージを受け取ります。ユーザーはRIS Liveに接続して、関心のあるメッセージをサーバーにフィルター処理するように要求できます。特に(より具体的な)BGP UPDATEメッセージのCIDRプレフィックス・マッチングやASパス・マッチング(アナウンスおよびWithdraw)に使用できるフィルターがあります。これらのメッセージは通常、元のBGPメッセージが表示されてから1秒以内にRIS Liveで利用できます。

Ris live architecture

ユーザーは、RIS Liveを調べ、テストし、そして使用し、それについて何が役に立つと思うかについてのフィードバックを与えることが奨励されます。私たちは肯定的なフィードバックを受け取ったら、プロトタイプは十分にサポートされた商用サービスの基礎を提供します。短いアンケートに記入することでフィードバックを提供できます。

始める

RIS Liveのホームページにアクセスすると、ストリームのオンラインデモを見ることができます。それから、RIS Liveのマニュアルを見て、より詳細な技術と実装の詳細を得ることができます。これはあなた自身のスクリプト、実験、ウェブサイトおよび他のツールでRIS Liveを最大限に活用することを始めるのを助けるでしょう。

2/15/2019

中国でのRPKI

APNICのブログより

By Yuedong Zhang on 14 Feb 2019

リソース公開鍵基盤(RPKI)は、その開始(RFC 6480)から、広く注目されています。それはBGPルーティングに信頼性を提供することができるRoute Origin Authorization (ROA)を提供することによって、Border Gateway Protocol (BGP)のセキュリティ解決策として使用されます。

RPKIは5つの地域インターネットレジストリ(RIR)の間で広く展開されており、全てのRIRは現在メンバーにRPKIサービスを提供しています。

この記事では、RPKIの中国での展開を取り巻く過去、現在、および将来の取り組みについて説明します。

過去の実績

現在、中国でRPKIに携わっている数少ない組織の中で、中国インターネット・ネットワーク・インフォメーション・センター(CNNIC)とインターネット・ドメインネーム・システム北京技術研究センター(ZDNS)が最も広範囲な研究とプロモーションを行っています。

CNNICは、中国のNational Internet Registry (NIR)として、2014年にRPKI関連の研究を開始しました。

  • RPKI実験環境を確立し、一般的なトラブルシューティングを支援する方法を詳述した「RPKIホワイトペーパー」、データ管理アーキテクチャ、導入のリスクと解決策、RPKIの導入に関する声明など、RPKIに関するいくつかの論文を発表しました。
  • CNNICがSecure Inter-Domain Routing (SIDR)グループでいくつかのインターネットドラフトを提案しているIETF、およびChina Communications Standards Association (CCSA)を含め、国内外でRPKIの標準化に継続的に参加しました。
  • RPKIの様々な側面に関するいくつかの業界標準を主導しました。

導入に関しては、CNNICはAPNICと協力して2015年後半にRPKIパイロット・プラットフォームを立ち上げました。これは中国で最初の実験的RPKIプラットフォームです。 RPKIパイロット・プラットフォーム上での運用経験、およびAPNIC技術チームからの素晴らしいサポートに基づいて、CNNICは2017年半ばにメンバーへのRPKIサービスを開始しました。ISP、ICP、DC、CDN、中国の企業は現在、RPKIを使用してWebベースのユーザーフレンドリーなインターフェースを通して、IPアドレスを管理および保護できます。

ZDNSは同様に忙しく、IETFとCCSAでRPKIオープンソース・ソフトウェアとRPKI標準化に貢献しています。2016年から、ZDNSは、RPSTIR (bgpsecurity.net)、ZDNSのプリンシパル・リサーチフェローであるDi Ma博士やRFC 8211RFC 8416の共著者によって管理されているRPKI Relying Partyソフトウェアのオープンソース・プロジェクトを支援しています。

最近の進歩

CNNICは、2018年も引き続きRPKIを開発および推進しました。これには、中国でのRPKIサービスの運用中に発生した以下のようないくつかの技術的問題のトラブルシューティングが含まれます。

  1. アクセス制御。リソース証明書、ROA、マニフェスト、CRLなど、RPKI CAによって生成されたデータは、グローバルにアクセスする必要があります。
    [私たちの解決策] リポジトリは、いかなるRPもデータを取得するのを制限するための追加のセキュアポリシーを加えるべきではありません。

  2. 時間同期の問題。CAサーバの時刻が標準時よりも遅い場合は、予期しない問題が発生する可能性があります。例えば、有効期間の開始時刻が誤っている証明書は、「データがまだ有効ではありません」、「オブジェクトが拒否されました」、「証明書の検証に失敗しました」というエラーを引き起こす可能性があります。
    [私たちの解決策] ネットワークタイムプロトコルを使用して時刻を同期し、これをcronジョブに追加します。

  3. 証明書の有効期限。CNNIC IPアドレス割り当てアライアンスのメンバーに発行された各リソース証明書は、1年間有効で生成されます。
    [私たちの解決策] 検証の問題を回避するために、この有効期限に注意を払い、時間内に新しい証明書を再発行します。

APNICの助けを借りて、CNNICは2018年10月にCNNICとAPNIC RPKIプラットフォーム間の接続を終了し、CNNICがグローバルRPKIシステムに参加できるようにしました。CNNICは2018年12月にAPNIC-CNNIC合同訓練イベントでエキサイティングなニュースを発表しました。そこでは、CNNICメンバーはシステムについて質問し、自分自身のために子認証局とROAレコードを確立する方法を学ぶことができました。

2019年1月末までに、CNNICのRPKIシステムには、176の証明書、39のROA、および178のCRLが記録されました。

将来計画

CNNICを含む中国の組織は、RPKIサービスに関する運用上の問題のトラブルシューティングおよびRPKIシステム機能の改善に引き続き取り組んでいきます。国内のコミュニティの意見を聞き、RPKIの運用状況に基づいて、次のように予測しています。

  1. 主に国内の組織を対象とした、複数の公的RPサービスが登場するでしょう。
  2. 国内RPKIサービスの成熟度は、分散サイトを使用してさらに強化され、プラットフォームの可用性を向上させる他の方法が徐々に適用されるでしょう。
  3. 中国でのRPKIの採用をさらに促進するために、なお一層のRPKIの技術トレーニングが提供されるでしょう。

インターネットのセキュリティを継続的に強化するために、グローバルなインターネットコミュニティと協力することができて光栄です。さらなる多くの最新情報についてはAPNICブログに注目して下さい、そして、もし質問があればコメントを残して下さい。

2/14/2019

4月6日にGPSの週番号がロールオーバー

Slashdotより

ZorroがThe Registerのレポートを共有する。
古い衛星やそのような装置は、適切に更新されるか、または迫り来るエポック・ロールオーバーを処理するように設計されていない限り、4月6日以降はアメリカの全地球測位システムを適切に使用することができません。衛星からのGPS信号には、自分の位置を計算するために部分的に必要なタイムスタンプ(週番号)が含んでおり、10桁の2進数で保持されています。つまり、週番号は210または1024の整数値を持つことができ、この場合は0から1,023までカウントされます。1024週ごと、または約20年ごとに、カウンターは1023からゼロにロールオーバーされます。4月の最初の土曜日に1024週目の終わりを迎えます。その後、カウンターは1023からゼロになります。このように週の数が溢れたのは1999年で、1980年1月の最初の時期から20年近く経ったことになります。今日使用されているデバイスがこの最新のロールオーバーを処理するように設計またはパッチが当てられていない場合、4月の1024週後の過去年に戻り、位置計算の試みが失敗する可能性があります。システムとナビゲーションのデータが破損する可能性もあります。
米国土安全保障省は今週の記事でこの問題を説明した。GPS.govは、新しいCNAVとMNAVのメッセージフォーマットは週に13ビットの数字を使うので、この問題は近い将来再び起きないはずだとも述べている。このサイトでは、ユーザーが機器の製造元に相談して、適切なアップデートが適用されていることを確認することをお勧めしている。

ブロックチェーンと信頼

シュナイアーのブログより。Bitcoin/ブロックチェーンをここまで言い切ったのは初めて?🧐

匿名のサトシ・ナカモトが、初めてBitcoinを提案した2008年のホワイト・ペーパーの中で、次のように提案を締めくくりました。「私たちは、信頼に頼ることのない電子取引のためのシステムを提案します。」彼は、Bitcoin暗号通貨の背後にあるシステム「ブロックチェーン」に言及しました。信頼の迂回は大いに期待されますが、それは全く真実ではありません。そう、Bitcoinはクレジットカードのような決済システム固有の信頼できる仲介者を排除します。しかし、あなたはまだBitcoinを信頼する必要があります — そして全ての点においてです。

ブロックチェーンについて、それらがどのようにして信頼を置き換え、再構築し、あるいは排除するかについて多くのことが書かれてきました。しかし、ブロックチェーンと信頼の両方を分析すると、価値以上のハイプ(誇大宣伝)があることがすぐに分かります。ブロックチェーンのソリューションは、多くの場合、それらが取って代わるものよりもはるかに悪化します。

まず、注意です。ブロックチェーンに関し、私は非常に具体的なものを意味します。それは、公共のブロックチェーンを構成するデータ構造とプロトコルです。これらには3つの重要な要素があります。1つ目は分散され(複数のコピーの場合でも)、しかしながら、集中管理された台帳で(1つだけの場合でも)、発生したことと順序を記録する方法です。この台帳は公開されており、誰でも読み事ができ、不変であり、過去に起こったことを誰も変更することはできません。

2番目の要素はコンセンサス・アルゴリズムです。これは、台帳の全てのコピーが同じものであることを確認するため方法です。これは一般にマイニングと呼ばれ、システムの重要な部分は、誰でも参加できる事です。それはまた分散されています。つまり、あなたはコンセンサス・ネットワークの中で特定のノードを信頼する必要はありません。また、データストレージとそれを維持するのに必要なエネルギーの両方で、非常に高価になる可能性があります。Bitcoinは、世界でこれまでにない最も高価なコンセンサス・アルゴリズムです。

最後に、3番目の要素は通貨です。これは、価値があり一般に取引されているある種のデジタルトークンです。通貨は、関係者全員のインセンティブを調整するために、ブロックチェーンに必要な要素です。これらのトークンを含むトランザクションは、台帳に保管されます。

プライベートなブロックチェーン(つまり、ブロックチェーンのデータ構造を使用しますが、上記の3つの要素を持たないシステム)は全く面白くありません。一般に、ブロックチェーンとその機能に誰がやり取りできるかについて、外部からの制限があります。これらは新しいものではありません。追加することを承認された個人リストを持つ分散化された追加のみ可能なデータ構造を持っています。コンセンサス・プロトコルは、60年以上に渡って分散システムで研究されてきました。追加のみのデータ構造も同様によく取り上げられています。それらは名ばかりのブロックチェーンです、そして — 私が知る限り — 導入する唯一の理由はブロックチェーンのハイプに乗るためです。

公共のブロックチェーンの3つの要素全てが、新しいセキュリティプロパティを提供する単一のネットワークとして相互に適合しています。問題は、それが実際には何にとって良いのか? ということです。それはすべて信頼の問題です。

信頼は社会に不可欠です。種として、人間は互いに信頼するべく、つながっています。社会は信頼なくして機能することはできません、そして、私たちがほとんどそれについて考えさえしないという事実は、信頼が如何にうまく機能するかの尺度です。

「信頼」という言葉には多くの意味があります。個人的で親密な信頼があります。私たちが友人を信頼すると言う時、私たちは彼らの意図を信頼し、それらの目的が彼らの行動を元気付けることを認識することを意味します。また、親密さや個人的な信頼が低いということもあります。私たちは誰かを個人的に知っているわけでも、その動機を知っているわけでもありませんが、将来の行動を信頼できます。ブロックチェーンはこの種の信頼を可能にします。例えば、Bitcoinのマイナーは誰にも分かりませんが、私たちはマイナー・プロトコルに従ってシステム全体が機能すると確信しています。

ほとんどのブロックチェーンの熱狂者は、不自然に狭い信頼の定義を持っています。「私たちはコードを信じる」、「私たちは数学を信じる」、「私たちは暗号を信じる」などのキャッチフレーズが好きです。これは検証としての信頼です。しかし検証は信頼と同じではありません。

2012年に、私は信頼と安全についての本、「信頼と裏切りの社会 (Liars and Outliers)」を書きました。その中で、私たち人類が信頼できる行動を奨励するために使う4つの非常に一般的な方法を挙げました。最初の2つは道徳と評判です。問題は、それらが特定の人口規模にしか対応できないことです。原始的な方法は小規模なコミュニティには十分でしたが、大規模なコミュニティには委任とより形式主義が必要でした。

3つ目は社会制度です。社会制度には、集団の規範に従って行動するように人々を促す規則や法律があり、そうしない人々に制裁を課します。ある意味では、法律は評判を形式化します。最後に、4つ目はセキュリティシステムです。これらは、私たちが採用している様々なセキュリティ技術です。ドアロックや高いフェンス、警報システムや警備員、フォレンジックや監査システムなどです。

これら4つの要素は、信頼を可能にするために連携して機能します。例えば、銀行取引です。金融機関、加盟店、そして個人は皆、評判に関心があり、盗難や詐欺を防ぎます。銀行業務のあらゆる側面を取り巻く法律と規制は、詐欺の場合のリスクを制限するための防壁となる物を含め、あらゆる人を管理します。そして、偽造防止技術からインターネット・セキュリティ技術まで、多くのセキュリティシステムが整備されています。

ケビン・ワーバックの2018年の著書、「Blockchain and the New Architecture of Trust」で、彼は4つの異なる「信頼のアーキテクチャ」を概説しています。1つ目はピアツーピアの信頼です。お互いを信頼するようになった人々のペアで、これは基本的に道徳と評判システムに対応します。2つ目は、制度的信頼に対応するリバイアサン信頼です。これが私たちの契約のシステムで機能しているのを見ることができます。3つ目は仲介者の信頼です。その好例が、信頼できない買い手と売り手が商取引に従事することを可能にするクレジットカード・システムです。4つ目の信頼アーキテクチャは分散型信頼です。これは、ブロックチェーンを利用した特定のセキュリティシステムへの新しく出現した信頼です。

ブロックチェーンが行うことは、人や機関への信頼の一部を技術への信頼に変えることです。あなたは、暗号、プロトコル、ソフトウェア、コンピュータ、そしてネットワークを信頼する必要があります。そして、それらはしばしば単一障害点であるため、あなたはそれらを絶対的に信頼する必要があります。

その信頼が間違って与えられていることが判明した場合、頼みになりません。あなたが使っているBitcoinの交換所がハッキングされれば、あなたのお金を全て失います。あなたのBitcoinのウォレットがハッキングされれば、あなたのお金を全て失います。あなたのログイン資格情報を忘れたら、あなたのお金を全てを失います。スマート・コントラクトのコードにバグがあると、あなたはお金をすべて失います。誰かがブロックチェーンのセキュリティをハッキングすることに成功すれば、あなたはお金を全て失います。多くの点で、テクノロジーを信頼することは、人を信頼することよりも難しいです。あなたが監査する専門知識を持っていない人的な法制度やコンピュータコードの詳細を信頼できますか?

ブロックチェーンの熱狂者は、より伝統的な形の信託 — 例えば銀行手数料 — を高価なものとして指摘しています。しかし、ブロックチェーンの信頼もコストが掛かります。コストが隠されているだけです。Bitcoinにとって、それはマイニングされた追加のBitcoinのコスト、取引手数料、そして莫大な環境廃棄物です。

ブロックチェーンは、人間の制度を信頼する必要性を排除するものではありません。テクノロジーだけでは対処できない大きなギャップが常にあります。人々は依然として責任を負う必要があり、システム外のガバナンスも常に必要です。これは、Bitcoinブロックサイズを変更することについての継続的な議論、あるいはEthereumに対するDAO攻撃の修正において明らかです。常にルールを上書きする必要があり、恒久的なルール変更を行う機能が常に必要です。ハードフォークの可能性がある限り — それを変更するためにブロックチェーンを担当する人々がシステムの外に出るとき — 人が担当する必要があります。

どのようなブロックチェーンシステムも、他のもっと従来型のシステムと共存しなければなりません。例えば、現代の銀行業はリバーシブルにデザインされています。Bitcoinは違います。それは2つを互換性のあるものにすることを難しくします、そして結果はしばしば不安です。スティーブ・ウォズニアックはこれを無視していたので、Bitcoinで7万ドルを騙されました

ブロックチェーン技術は多くの場合、集中管理されています。Bitcoinは理論的には分散信頼に基づいているかも知れませんが、実際にはそれは真実ではありません。ほぼすべてのBitcoinを使用する人は、数少ない利用可能なウォレットのうちの1つを信頼し、利用可能な数少ない交換所のうちの1つを使用しなければなりません。人々は、ソフトウェア、オペレーティングシステム、そしてその全てが実行されているコンピュータを信頼する必要があります。そして、私たちはウォレットおよび交換所に対する攻撃を経験しています。私たちはトロイの木馬とフィッシングとパスワードの推測を経験しました。犯罪者は、人々がBitcoinを盗むために自分の携帯電話を修理して使用するシステムにも欠陥を利用しています。

さらに、どんな分散型信頼システムでも、こっそり入るための集中型のバックドアが存在します。Bitcoinでは、唯一重要な地位にあるマイナーに影響があります。ほとんどのマイニングハードウェアを提供している会社が1つあります。支配的な取引所はわずかしかありません。ほとんどの人がBitcoinとやり取りする限りでは、これらの集中型システムを介して行われます。これにより、ブロックチェーンベースのシステムに対する攻撃も可能になります。

これらの問題は現在のブロックチェーン・アプリケーションのバグではなく、ブロックチェーンがどのように機能するかに固有のものです。システムのセキュリティを評価するには、社会技術システム全体を考慮に入れる必要があります。あまりにも多くのブロックチェーンの熱狂者がテクノロジーに焦点を当て、残りを無視しています。

人々がBitcoinを使用しないのは、彼らがBitcoinを信頼しないからです。それは暗号化やプロトコルとは関係ありません。実際、鍵を忘れたりマルウェアをダウンロードしたりすると、あなたは蓄えを失う可能性があり、そのようなシステムは、特に信頼できるものではありません。SHA-256が二重支出を防ぐためにどのように機能するのかを説明するだけではそれは解決されません。

同様に、人々がブロックチェーンを使用する範囲については、彼らがそれらを信頼するからです。人々はBitcoinを所有しているか、評判に基づいていません。Bitcoinを所有している投機家にとっても、それは彼らがすぐに金持ちになると思うからです。評判に基づいて、人々は彼らの暗号通貨のためのウォレットと彼らの取引のための交換所を選びます。アルゴリズムの評判に基づいてブロックチェーンを支える暗号化を評価し、信頼することもできます。

これがどのように失敗する可能性があるかを見るために、ブロックチェーンを使用している様々なサプライチェーン・セキュリティシステムを見て下さい。ブロックチェーンは、それらのいずれにも必要な機能ではありません。それらが成功する理由は、誰もがデータを入力するための単一のソフトウェア・プラットフォームを持っているからです。ブロックチェーンシステムは分散信頼に基づいて構築されていますが、人々は必ずしもそれを受け入れるわけではありません。例えば、一部の企業は、彼らのブロックチェーンではないため、IBM/Maerskシステムを信頼していません

非合理か? おそらく、それは信頼が機能する方法です。アルゴリズムやプロトコルに置き換えることはできません。それよりもずっと社会的です。

それでも、ブロックチェーンが信頼の必要性をどうにかして排除できるという考えは存続します。最近、ブロックチェーンを使用して安全なメッセージングを実装している会社から電子メールを受け取りました。「私たちが行ったように、ブロックチェーンを使用することで、信頼の必要性が排除されました。」 この考え方は、作者がブロックチェーンがすることと信頼がどのように働くかの両方を誤解していることを示唆します。

公共のブロックチェーンは必要ですか? 答えはほぼ確実にノーです。ブロックチェーンはおそらくそれが解決すると思うセキュリティ問題を解決しないでしょう。それが解決するセキュリティ問題はおそらくあなたが持っているものではありません。(監査データの改ざんは、おそらくあなたの大きなセキュリティリスクではありません。) ブロックチェーンへの誤った信頼は、それ自体がセキュリティリスクになる可能性があります。特にスケーリングにおける非効率性は、それだけの価値はありません。私は多くのブロックチェーン・アプリケーションを見てきましたが、それら全てがブロックチェーンを使用しなくても同じセキュリティ特性を実現できる可能性があります -- もちろん、それらはクールな名前にはならないでしょう。

正直なところ、暗号通貨は役に立ちません。それらは、一攫千金を求めている投機家、政府支援通貨を好まない人々、およびブラックマーケットでお金を交換する方法を望んでいる犯罪者によってのみ使用されています。

ブロックチェーンが必要かどうかという質問に答えるには、自分自身に尋ねて下さい。まず、ブロックチェーンは信頼システムを何らかの意味のある方法で変更するのか、それとも単にそれをシフトさせるのか? 信頼を検証に置き換えようとしているだけなのか? それは既存の信頼関係を強化するのか、それともそれらに反対しようとするのか? 信頼は新しいシステムでどのように悪用される可能性があるのか、また、これは古いシステムでの潜在的な悪用よりも優れているのか、それとも悪いのか? そして最後に、ブロックチェーンをまったく使用しなかった場合、システムはどのようになるのか?

あなた自身にこれらの質問をすれば、あなたが公共のブロックチェーンを使わない解決策を選ぶでしょう。そしてそれは良いことになるでしょう -- 特にハイプが消える時に。

このエッセイはWired.comにすでに掲載されました

追記 (2/11): 私のエッセイに2つの論評があります。

私は、1年以上このエッセイを書きたかったのです。12月に開催されたHyperledger Global Forumでの講演への招待から、ようやくそれが実現しました。このエッセイは私がそのイベントのために書いた話の説明であり、一般の聴衆にとってよりアクセスしやすくなっています。

ブロックチェーンのテイクダウンの季節のようです。James WaldoはQueueで素晴らしいエッセイを書いています。そして、Nicholas Weaverが、Enigma Conference講演しました。ここに要約があります。それはこの話の短縮版です。

2/13/2019

ビル・ゲイツ、アレクサンドリア・オカシオ・コルテスに「金持ち税」政策で論争

BoingBoingより。「Modern Monetary Theory」は、日本政府のための理論でもある🤔。

Gatesaoc

Microsoftの共同創業者であるビル・ゲイツ氏は今週、アメリカで広まる「金持ち税」という考えについていくつかコメントをしました。

金持ちに課税することは結構です、と彼はThe Vergeとのインタビューで答えました、そして超金持ちに「更に進歩的な」課税もOKです。

それから、ゲイツはアレクサンドリア・オカシオ・コルテス(AOC)を、高所得者層を標的に集中することで、ポイントを見逃している「急進的な」政治家として引き続き特徴付けました。

AOCは民主社会主義者と見なしており、2019年1月には1000万ドル以上の収入に対して70%の累進課税という考えを浮上させました。

ゲイツ氏はインタビューの中で、超富裕層は所得ではなく資産の形で財産を保有する傾向があるため、所得ではなく資産への課税に焦点を当てるべきだと言いました。

「あなたがそれにフォーカスするなら、あなたは事実を見逃しています」と彼は名指しでAOCを言及せずに言いました。

The VergeのNilay Patelより:

今週のThe Vergecastで話したゲイツ氏は、米国の限界所得税率は「より進歩的」だが、— 高い、言い換えれば — 今では「極端な」政治家たちがいます。彼らの提案は裕福な人々が収入を隠し、それを海外に隠してしまうことにつながるだろう。これは、ゲイツ氏が今回のインタビューに応じる1週間前に、新たに最高税率70%を提案したばかりの、アレクサンドリア・オカシオ・コルテス議員(D-NY)のような新しい国会議員たちへの明らかな言及です。

ゲイツ氏はまた、世界で最も裕福な人々は自分たちの資産と比較して「丸め誤差」相当の実収入しかないと言いました。— 彼らは多くのサラリーを得ておらず、その代わりに現金や他の資産を売って収入を得るわけではありません。米国の上位400人の高所得者は、20パーセントの税率のようなものしか払っていない、と彼は指摘しました。「39.6%の限界普通所得税率とは関係ありません。それで、それはミスフォーカスです。それにフォーカスを当てると、事実を見逃してしまいます。」

しかしゲイツ氏は、税収を増やすために、一般的な富裕税、相続税、社会保障への変更について賛成して話しました。「しかし、私たちはもっと進歩的に考えることができます。固定資産税と相続税、FICAと社会保障税が機能する方法です。私たちは、所得創出を本当に脅かすことなく、より進歩的になることができます。」

ゲイツ氏はまた、オカシオ・コルテスやバーニー・サンダースなどの政策チームの注目を集めている経済理論である「Modern Monetary Theory (新表券主義)」にも反対しました。MMTは、知られているように、政府は単純に自分の通貨を印刷することができ、代わりに金利でインフレを管理するはずなので、赤字について心配する必要がないことを示唆しています(あなたはこのVoxの解説でこれについて更に読むことができます。)。GatesはMMTについてどう思いますか?

「それはちょっとおかしな話です。」と彼は私に言いました。「それはいずれ戻ってきて、あなたに噛み付くでしょう。」

統計的特性による有意義なRTT測定基準

APNICのブログより

By Maxime Mouchet on 7 Feb 2019

ラウンドトリップタイム(RTT)系の統計的特性は、ネットワーク管理に役立ちます。例えば、送信元と宛先の間に複数のパスがある場合は、ルーティングオーバーレイコンテキストで言うと、各パスの現在のサービス品質(QoS)に関する推論に基づいて、パスを動的に選択すると便利かも知れません。

この記事では、HDP-HMMを使用してRTTシリーズをモデル化する方法を説明し、そのようなモデル化の可能な用途について説明します。

RTT系の統計的特性

インターネットはそれ自体が研究対象であり、科学者たちはインターネットのパフォーマンスに対する理解を深めるために、様々な測定基準、特にQoS測定基準(遅延、帯域幅、損失率など)を適切な統計モデルで特徴付けたいと考えています。

BGPルーティング設定とロードバランシングがエンドツーエンドのQoSに与える影響のために、時系列のインターネット遅延(RIPE Atlas RTT測定など)の分析により、これらの時系列の動作の特徴的なパターンが明らかになります。

通常、一定の出所地と目的地のペアでは、RTTは少数の基本値を中心にしてランダムに変動する小さな様々な値の組をとります。ランダムな変動は輻輳や測定エラーが原因で発生する可能性がありますが、様々な値は様々なルーティング構成に対応するため、送信元から送信先へのインターネットパスが異なります — RTT値は、数時間後に基準面から別の基準面に切り替わります(図1)。

RTT fig1

図1 — 2つのRIPE Atlasアンカー間のRIPE Atlas RTT測定

統計的観点から、この規則性は適切な統計モデルによって説明することができます。HMM、より正確にはHDP-HMMがRTTシリーズの特性評価に適した確率論的なモデルであることを示し、これらのモデルのパラメータをどのようにトレーニングできるかを説明し、それらが何に役立つのかを説明します。

HMMとモデル評価

マルコフ連鎖は、マルコフ特性が満たされるという意味での確率過程です。つまり、プロセスの現在の値は前の値だけに依存します。

HMMはマルコフ連鎖の「ノイズ・バージョン」です。直接観察されない潜在的マルコフ連鎖、および潜在的マルコフ状態にランダムに依存する観察を想像して下さい。RTT系列の問題に戻ると、様々な「基本レベル」をモデル化すると、マルコフ連鎖の状態x(t)に対応します。 RTT値は、観測値y(t)、またはHMMの軌道(trajectory)に対応します(図2)。

RTT fig2

図2 — HMMの時間発展、x(t)およびy(t)はそれぞれ、時間(t)における隠れ状態および雑音の多い観測である。

HMMはパラメトリック・モデルです。確率モデルは、いくつかのパラメーターによってのみ指定されます。マルコフ連鎖の状態間の遷移確率、およびマルコフ連鎖の特定の状態を与えられた観測の確率分布のパラメーター(例えば、ガウス分布の仮定の下での平均と分散)です。

そのため、最初の問題は、測定値からモデルパラメータを較正することです。期待値最大化(EM)は、HMMのための標準的なトレーニング・アルゴリズムです。しかし、実際には、リアルなデータセットを扱う時に、様々な問題が発生します。

EMに関する最初の一般的な問題は、それが観測の尤度の極大値に収束することであり、EMが非常に慎重に初期化されていない場合、この最大値は大域的なものにはなりません。

2つ目の問題は、マルコフ連鎖の状態数が未知であることが多いことです(EMでは既知の定数であると考えられています)。

これら全ての理由から、EMでトレーニングされた標準のHMMモデルは、RTT測定を特徴付けるのに十分な柔軟性のあるアプローチではないと考えています。これまで、この問題に対処するためにいくつかの技術が提案されてきました。最近、HMMパラメータを推定するための効率的で一般的な方法が開発されました。これは、様々な種類のリアルなデータセットで観察される変動性を捉えるためのより高い柔軟性を提供します。

階層型ディリクレ過程HMM(HDP-HMM)は、ベイズ推定を基礎としています。マルコフ連鎖の各状態における観測の確率分布のパラメータと同様に、HMMの状態の数は、ランダム変数と考えられます。

ベイジアン設定では、事前分布がパラメータ向けに想定されます。それから、事後尤度としても知られている観測に基づいて条件付けられたパラメータの分布は、事前分布によって重み付けされた観測の尤度です。この事後分布が得られると、そのモードまたは平均を見ることによってパラメータの推定値を得ることが可能になります。

実際には、事後分布の正確な計算は困難です。しかしながら、この事後分布からのサンプル、すなわち観測値の集合の特定の値を与えられたモデルパラメータのサンプルは、MCMC(マルコフ連鎖モンテカルロ法)、特にギブスサンプリングを用いて得ることができます。MCMC法は、ベイズ推定のための古典的な確率シミュレーション法です。

複雑なデータセットの場合、HMMの状態数を推定する問題は単純ではありません。考えられるアプローチは、状態数の事前条件としてディリクレ過程(DP)を使用することです。これにより、状態数は有限だが未知であることを指定することができます。

さらに、モデルに十分な柔軟性を導入するため、様々な実際のデータセットに正確に合わせることができるようにするため、HDP-HMMは「階層型」になっています。モデルのパラメータ(マルコフ連鎖の遷移確率、観測のガウス分布の平均と分散など)は別の確率変数の層に依存し、「あいまいな」事前確率はランダム性のこの基底層に設定されます。このようなランダムな依存関係とあいまいな事前確率は、モデルに十分な柔軟性をもたらし、オーディオ録音やRTT測定など、様々な時系列に適応させることができます!

RIPE Atlas測定の実験

IMT Atlantiqueでは、私たちはRIPE Atlasの測定値とHDP-HMMのオープンソース実装を使用して、RTTシリーズの特性評価のためにこのアプローチを検討しました。

全てのRIPE Atlasアンカー間の組み込み測定は、インターネット上のQoSの包括的なビューを提供します。4分ごとに、pingとtracerouteがアンカーの各ペアに対して実行されます。RIPE Atlas APIを使用して、1週間にわたり全てのアンカーペア間のIPv4 RTT測定値を表す81,000件のデータセットを作成しました。任意のタイムスロットでのRTTの最小値を検討した結果、系列あたり2,520データポイントになりました。

各シリーズのHMMパラメータは、HDP-HMMを使用して学習されています。副産物として、HDP-HMMモデルのパラメータを適合させるために使用されてきたギブスアルゴリズムもまた、測定されたRTTに関連する基礎的な状態を推測します。いくつかの結果が図3に表示されています。

RTT fig3
RTT fig3b

図3 — 国は、2つのRIPE Atlasアンカー間で測定されたRTTについて7日間に渡って学習しました。

ここで、同じ背景色は潜在マルコフ連鎖の同じ値に対応します。そのため、同じ「クラスター」に属する観測は、同じ色の背景に表示されます。HDP-HMMはRIPE Atlas RTT時系列の非常に正確なモデルであることが、多くの様々なクラスタリング結果を視覚的に確認することによって明らかになりました。特に、RTT時系列を小さいながらも同種のクラスタのセットに分割することができます。

各出発地-目的地のペアを特徴付けるのにいくつの様々な状態が必要か疑問に思うかも知れません。そのため、私たちは、RIPE Atlasアンカーのすべてのペア間で1週間のRTTデータセットを処理しました。そして、アンカーの各対について、HDP-HMMモデルの状態数が推定されています。図4は、得られた状態数のヒストグラムを示します。

RTT fig4

図4 — 1週間で学習したモデルの状態数の分布。

送信元-送信先のペアの大部分では、5〜6カ国で1週間という長い期間のRTTの分布の変動を捉えることができます。経路の50%が2カ国以下、99%が6カ国以下です。

次に、短いタイムスケールで得られた状態の数を比較しました。図5は、1日から1週間の期間の国数の再区分を示しています。

図5 - 異なる時間枠における状態数の分布

予想されるように、より短い期間はより少ない状態でモデルをつながります。2〜3日間のトレーニング期間では、経路の99%が4カ国以下、1日期間では3カ国以下です。

適用

あなたは、知的満足はさておき、このモデリングが何に役立つか疑問に思うかも知れません。

まず第一に、各状態でのRTTの平均と分散、各状態での平均滞在時間、そしてある世界から他の国への切り替えの確率など、パフォーマンス指標を導出するのに使用することができます。これは、グローバルな平均パフォーマンス指標より意味があります。

提案されたアプローチは、少数の持続的状態を有するデータのセグメント化を可能にし、そして状態の変化を迅速に検出します。これにより、他の検出方法で発生する可能性がある多くの誤警報を回避できます。

異なるパスのパフォーマンスも統計的に比較することができます。例えば、正確な確率モデルが較正されると、遅延が1つの送信元と1つの送信先との間の1つの経路または別の経路で大きくなる確率を計算することは極めて簡単です。

次回の投稿では、このようなモデルがネットワーク管理にどのように使用されるのかを調査します。

2/11/2019

DNSのプライバシー議論

APNICのブログより

By Bert Hubert on 8 Feb 2019

先週末にFOSDEM 2019が集まり、DNS over HTTPに関するプレゼンテーションが3度行われました。

ダニエル・スタインバーグ(Daniel Stenberg)が基調講演「DNS over HTTPS — 良い面、悪い面、および見苦しい面」(ビデオ)を発表し、ヴィットリオ・ベルトーラ(Vittorio Bertola)が「DoHのジレンマ」について議論し、一方、ダニエル、ステファン・ボルツマイヤー(Stéphane Bortzmeyer)、そして私は、ジャン・パイエット・メンズ(Jan-Piet Mens)が主催するDNSのプライバシー・パネルを組織しました。この記事の校正と改善について、ダニエル、ジャン・パイエット、ルドルフ・ヴァン・デン・ベルフ(Rudolf van der Berg)、ステファン、ヴィットリオに感謝します。しかし、これは誰からの支持を意味するものではありません!

次の記事では、ヨーロッパの視点に焦点を当てながら、私たちが学んだと思うこと、そして現在DNS over HTTP (DoH)についてどこにあるのかについて中立的な説明をするつもりです。顕著な偏りがある場合は、早急にお知らせ下さい。それについて説明します。しかし、明確にするために、少数のクラウドプロバイダーにDNSを集中させるのは好きではありません。中立的な説明の後、あなたは「DNS over Cloud」の望ましさについていくつかの強い意見を見つけるでしょう。

言葉と定義

FOSDEMプレゼンテーションの間に、DoHの望ましさについての様々なビジョンが議論されました。私たちは、悲しいことに、雑な定義によってかなり妨げられていました。つまり、DoHはトランスポートプロトコルなので、HTTP経由でDNSクエリを安全に要求できます。

同時に、Google、Firefox、Cloudflareは、DoHを使用してDNSサービスをネットワーク・サービスプロバイダから直接クラウドに移動しようとしています。言い換えれば、以前までサービスプロバイダがDNSクエリを表示(および回答)できていたのに対し、この将来案では、DNSリクエストを無料(free-as-in-beer)のクラウドプロバイダに送信します。

ダニエルが彼の基調講演でかなり指摘したように、これらのことは両方ともDoHと呼ばれていて、それは非常に混乱します。ダニエルがそれをラベル付けする「The Resistance」は、実際に彼らが主にクラウドプロバイダにDNSを集中させることについて不平を言っている場合、「DoH」についての苦情です。私たちは、オペレータが何のためにそれを得るかについてプロトコルを責めてはいけません。

私たちが、FOSDEM DoHプレゼンテーションの時間から得られる最大の利点は、私たちが今から提案するものを提供するためにこのプロトコルの適用についての私たちの関心からDoH(プロトコル)に関する私たちの懸念を切り離すべきで、今からこれをDNS over Cloud(DoC)と呼びます。

DNS over HTTP (プロトコル、DoH)

DoHプロトコルは、HTTPやTLS基盤を使用して、暗号化され認証されたDNS応答を、ネットワーク事業者がブロックするのが極めて難しくなるように設計されています。DNS over TLSと呼ばれる以前のプロトコルは既に利用可能でしたが、それはポート853で動作し、HTTPのようには見えないため、DoTを嫌うネットワーク事業者は簡単にそれをブロックすることができます。ほとんどの企業ネットワークはデフォルトでこれを行います。

DoHは、HTTPの利点と欠点を併せ持っています。HTTPがヘッダーやcookieなどをサポートしているという理由だけで、通常のDNSより追跡可能なデータを送信します。TLSセッション再開(resumption)は、別の追跡メカニズムとしても機能します。プラス面は、HTTPをキャッシュまたは再配布できるものであれば、DNSの強化やプロキシとしても使用できるようになります。また、DoHを使用すると、問い合わせる前でもDNS回答をプッシュすることができるため、ページロードのパフォーマンスが向上する可能性があります。

あなたが誰であれ、何を心配しているかに応じて、HTTPを検出不可能およびブロック不可能にすることができることは良いことでも悪いことでもあります。Googleが「Google.com」でも使用されているIPアドレス上でDNS over HTTPサービスを同じ場所に配置すると、DoHをブロックしたい場合、経済やネットワーク事業者はソロモンの選択、「Google検索をやめるか、DoHを有効にする」に直面するでしょう。

自分のネットワークを管理するべきだと感じるネットワークオペレータは、このこう着状態を好まないでしょう。一方、自分のネットワークオペレータに権限を与えるべきではないと考えるユーザは喜ぶでしょう。2番目のグループのために、FOSDEMで私たちはブロックできないDNSから利益を得ることができる評判のトルコの活動家について議論しました。

最後に、DoHは認証されたHTTPを使用しているので、私たちは通信したいネームサーバーと通信しているかどうかが分かります。それは、おそらくDHCP要求を乗っ取ることによって、または単にIPパケットを偽装するために注入された、不正なネームサーバから保護します。

DNS over Cloud (DoC)

現状では、ネットワーク事業者(ISP、サービスプロバイダ、そしてWi-Fiを提供するコーヒーショップ)は、あなたのDNSトラフィックを見ることができます。さらに、特定のクエリやレスポンスを操作したりブロックしたりすることも可能です。これはDNSサービスを提供することの本質的な特性です — あなたにDNSサービスを提供する人は皆、クラウドベースであろうとなかろうと、これらのことが可能です。

一般的にネットワークDNSとDoCの間の具体的な違いは、DoCがトランスポート・コンポーネントを暗号化できるのに対し、ネットワークDNSは暗号化されない傾向があるということです。 そして暗号化は良いことです。

インターネットへのアクセスにVPNを使用するのと同じように、トラフィックをある場所から別の場所に移動させるだけなので、別のDNSサービスを選択しても、DNSのセキュリティが向上するわけではありません。しかし、あなたが誰を信頼したいかを変更します。そして運がよければ、あなたの信頼できるプロバイダーはあなたにとってふさわしいやり方でより安全です。

現在、その信頼は全く意図的ではありません。インターネットユーザーは多くの場合、どのISPを使用するかについてほとんど選択できません。多くの場合、彼らは知らないかも知れません。地域の規制(GDPR、NIS、ePrivacy、EUの電気通信指令など)によって、プロバイダが許可されていることが制限される場合がありますが、実際のネットワーク事業者がこれらの法律を順守しているかどうかは分かりません。

DoCの支持者は、ユーザーは意図的にブラウザを選択したため、ユーザーのためにDNSプロバイダを提案または選択するのに適した立場にあると主張しています。ユーザーはブラウザを選択できないこともありますが、携帯を選択する自由があるかもしれず、異なるブランドの携帯には異なるブラウザが含まれています。ただし、安価な電話機はすべて同じブラウザを搭載しています。

DNSプライバシーパネルでは、ほとんどのユーザーが自分のDNSプライバシーをあまり気にしておらず、いずれにしてもトレードオフについて十分な情報を得ていないと推定していることも明らかになりました。従って、DNSプロバイダの選択は、電話、オペレーティングシステム、またはブラウザのいずれかによって行われる必要があります。

DNS暗号化に関する簡単な解説

誰もが更なる暗号化が良いことに同意しました。これは、クライアント機器とネームサーバの間、またはリゾルバのネームサーバと権威ネームサーバ間で発生する可能性があります。Googleのウォーレン・クマリは、携帯電話/ブラウザとDNSサービス間のTLSを介した日和見的DNSについての私たちの考えについて立場をテストしましたが、これはダウングレード攻撃を受ける可能性があると指摘された以外は受け入れられました。私はPowerDNSがすでにDoTを有効にするように顧客を促していることを指摘しました。Android Pieは、DoTサービスがある場合はそれを使用しようとするからです。また、リゾルバと権威サーバ間のトラフィックを暗号化するための取り組みについても簡単な議論がありました。これもまた良いことです。

DoHは何に対して保護しますか? 保護のためにとにかくHTTPを使用しているからですか?

ダニエルの基調講演の最後に、DNSのクエリと応答を保護することが重要な点について質問がありました。DNS応答はTLS接続の設定につながり、このTLS接続はそれ自体すでに暗号化されておりプライベートです。そのためにDNSは必要ありません。さらに、TLS接続設定には通常、TLS 1.3(Server Name IndicationまたはSNIフィールド)を使用しても、訪問中のサイトの名前がプレーンテキストで含まれます。結局、最終的に接続するIPアドレスは、この接続が誰に向かっているのかを示す非常に良い情報を提供するかも知れません。そのため、DNSを見なくてもTLS接続がどこに向かっているのかを知ることは一般的に可能です。ステファンのRFC 7626では、これらのトレードオフの多くについて説明しています。

2019年2月現在、DoHを使用する場合、名前は平文のままであるため、プライバシーの違いはほとんどありません。しかしながら、パケットからSNIを抽出することはスヌーピング・ネットワークプロバイダにとってより価値が高くなります。また、SNIフィールドを暗号化するために暗号化されたDNSを使用する作業も進行中です。その場合、DoHは実際に私たちにさらに多くのプライバシーを与えます。

しかし、DoHが今日提供しているのは、DNSベースの検閲に対する保護です。

検閲と破るもの

PowerDNS DoCサービスはすぐに何千人ものユーザーを獲得し、その多くはインドネシアにいます。PowerDNSは、インドネシアのISPが多くのブロッキングを実行しており、DoHサーバーがそのようなブロッキングを回避する優れた方法であることを知りました。doh.powerdns.orgは、インドネシアの検閲に気付かれないように行動する十分収まるほどの小ささかも知れません。

どのようにDoCがVPNやスプリットホライズンのようなものを打破できるかについて、独立して簡単な議論がありました。それが実際に稼働中の物事を破っていくことが指摘されたことを除けば、私たちはこれ以上は探求しませんでした。未解決の問題は、暗号化が実際の毀損の量に見合う価値があるかどうか、そしておそらくそれを回避できるかどうかということです。

クラウドとネットワークのDNSプロバイダーの違い

少なくともここヨーロッパでは、厳格に規制されたサービスプロバイダーの性質は諸刃の剣です。それは、ISPがあなたのデータを使ってできることを制限しますが、彼らが内容をブロックする裁判所命令に応じることを意味し、そのような命令がなくても児童ポルノのブロックを実行するかも知れません。インターネットユーザーは、Torrentに簡単にアクセスしたいという理由で、あるいは単に通信がブロックされているという原則に反対しているという理由で、そのようなブロックには満足できないかもしれません。

さらに、(ヨーロッパの)サービスプロバイダは(まさに明示的な許可なしに)あなたのトラフィックを収益化または販売しないという法的義務を負っていますが、そうしないという意味ではありません。具体的には、ここにある全てのサービスプロバイダは政府の(大量の)傍受命令に答えて、暗号化されていないDNS部分を含む全てのトラフィックの完全なコピーを警察とスパイに提供します。

その一方で、クラウドプロバイダーはGDPRの水域をナビゲートするのが非常にうまく、同時にデータを販売しないことを約束するだけでなく、あなたがオンラインで何をしているかに基づいて広告を販売することで収益の大部分を強化します。さらに、彼らは政府の傍受や妨害命令の範囲から比較的遠く離れており、外国の管轄地に移動するのに何ヶ月も掛かり、ほとんど届くことはありません。

パネル上の異なる見方

私たちは、これらの情報に通じており、異なる意見を持つ3人のスピーカに恵まれていた。

私(Bert)は、ソフトウェアとサービスを電気通信サービスプロバイダーに販売して生計を立てています。私はヨーロッパの多くのISPを親密に知っていますが、彼らが認められていないユーザープロファイリングを必要としているとは思いません。あらゆる種類のDNSデバッグデータを顧客から取得することが含まれるため、 GDPRに取り組むだけでも大変です。従って、私の考えは、サービスプロバイダーは「世のため人のためになる力」ではないかもしれませんが、彼らが監視経済をひそかに運営するために規制を破るのは非常に難しいと思います。しかし、これらの人々は私の会社に多額のお金を払っているため、私は彼らを好きに偏っています。しかし、訪問した全てのWebサイトの記録をGoogleやCloudflareなどのクラウドプロバイダーに送信することはいい考えだと思いません。

その一方、ステファンは政府が実際にインターネットを規制する方法について非常に知識が豊富です。彼は「The Internet — a political space (インターネット — 政治的な空間)」と題した本を書いています。彼の意見では、GDPRやその他の規制は素晴らしいかもしれませんが、データ保護機関がDNSを理解しておらず、優先順位を付けていないため、その実施は十分ではありません。これにより、ヨーロッパのサービスプロバイダでもDNSデータを販売して収益化する余地があります。更に、Stéphaneは、政府がやっとDNSに関心を持つようになった時、それが検閲目的のためであることを心配しています。

ダニエルは、HTTPでの彼の経験に触発された見方を提示しています — 彼はDNSデータを暗号化するだけでなく、そのサーバを認証することの明らかな利点を理解しています。「あなたが誰と話しているのか知っています」。

さらに彼は、ユーザーが様々なネットワークに時間を費やしていること、そしてWi-Fiを使用している全ての学校や喫茶店がプライバシーに関して訓練をしたり勉強することにはとうてい期待できないと正しく気付いています。ユーザーが全てのネットワークで機能する適切なDoHプロバイダーを選択した場合、どのネットワークに接続していても、一定レベルの信頼が得られます。

ダニエルは、プロバイダが適用法令に忠実であることを受動的に信頼するのではなく、クラウドプロバイダのトラフィックを売却しないという明確な約束をより強い保証と見なしていると分けて主張しました。最後に、ダニエルは、あなたが不正なネームサーバに接続している場合、GDPRはあなたを保護していないことを正しく指摘しています。それはあなたを狙っているサービスプロバイダではなく、そのプロバイダへのパス上の他の誰かであるかも知れません。DoHはそのシナリオに対しても保護します。

誰が私たちが信頼すべき人を選ぶのか?

ブラウザが検索にDoCを使用することを決定した場合、どのプロバイダを提供すべきですか? 議論の早い段階で、誰がプロバイダとして提供できるかを決定するための透明性のあるプロセスが存在すべきであることが指摘されていました。Firefox向けのこのプロセスは、これまで透明性からは程遠いものであり、運用可能なものでさえなかったことも指摘されています。聴衆のメンバーは、どの認証局が信頼されるべきかを決定するために使用されてきたCA/ブラウザフォーラムとの興味深い類似性に気付きました。しかし、これはブラウザでの検索エンジンの選択にも似ていると「すべての人がデフォルトを選択し、これが最も利益になる方法です」とダニエル氏は言及しています。

ステファンは、DoCプロバイダの中から選ぶべき人は多いはずだと考えていましたが、選ぶのは難しいので、ブラウザはトップにランダムなものを含むリストを提示するべきです。これにより選択が可能になりますが、ユーザーがデフォルトを選択した場合に無用の集中を防ぐこともできます。

クラウド企業があなたのDNSをホストすることを切望するのはなぜですか?

Googleのウォーレン・クマリは非常に明確な反応を示しました — より良いそしてより速いインターネットはより多くのインターネットの利用、そしてより多くの広告、そしてそれ故にグーグルのためにより多くのお金につながる。そのような正直さはまれであり、高く評価されています。Warrenはまた、8.8.8.8がそのプライバシーポリシーにこだわっており、それが地雷を仕掛けられていないことを再確認しました(FOSDEM 2018で起こったように)。

なぜ、1.1.1.1または9.9.9.9なのか? Cloudflare(1.1.1.1)のリゾルバチームのChristian Elmerotは、他のリゾルバを使用した場合よりも1.1.1.1を利用する人はCloudflareドメインの1.1.1.1から(わずかに)速い回答が得られると説明しました。

しかし、パブリックDoCプロバイダは世界の閲覧行動のコピーを入手することに全く興味を持っているわけではないかも知れません。

それは速いのか?

ダニエルがまだそこで働いていた時、Mozillaで行われた測定によると、DOH(または実際には、Cloudflareによって提供されたDoC)は、実際にシステムリゾルバーより平均で7ミリ秒遅くなります。しかし、彼は、Cloudflare DoCの最悪の場合のパフォーマンスは、実際には最悪の場合のシステムリゾルバのパフォーマンスよりもはるかに優れていると述べています。

あなたは自分でリゾルバを実行すべきか?

遅いかもしれませんが、権威サーバーはサービスプロバイダのIPアドレスではなく、あなた個人のIPアドレスを見るため、あなた自身のマシンにあなた自身のリゾルバを持っていることも実際にはあなたにとって有害であるとステファンは指摘しました。しかし、可能なパフォーマンスとプライバシーのペナルティで、完全なコントロールを提供します。ステファンは、キャッシュミスにDoHプロバイダを使用するミックスモードのローカルリゾルバが最適かもしれないと述べています。

EDNSクライアントサブネットについてはどうか?

録画の終わりからカットされた、私とダニエルとの間での少し感情的になった議論がありました。この議論はEDNSクライアントサブネットと、それがサービスプロバイダによって使用された時、どのようにあなたのプライバシーに影響を与えるかについてでした。

一部の大規模ISPは、(例えば)AkamaiやLevel 3にクエリを送信する際、顧客のIPアドレスの一部を含めるものがあります。これらの大規模CDNはDNSを介してロードバランシングを実行し、ユーザーに適したサーバーを決定するために24または場合によっては25ビットのIPv4アドレスを参照する必要があるためで、これは現在必要です。

これはプライバシーの問題として報告されることがあり、一般的なケースではそうなる可能性があります。ただし、Akamaiなどのホスティングプロバイダとサービスプロバイダの間で使用した場合、実際にはプライバシーが失われることはありません。顧客はAkamaiサービスへの接続を試みているため、Akamaiは常に加入者IPアドレスを確認しているからです。

バランス

これがこの記事での公平性への試みが終わる場所です。

まず、DoH、DoC、デフォルトでDoCを区別する必要があります。これらのうちの最初の2つが問題のないことは明らかです。私たちが安全なDNSトランスポート・メカニズムを持っていて、いくつかのDoCプロバイダーが真にいくつかの経済圏や場所でユーザのプライバシとセキュリティの強化であるかもしれないことは良いことです。

私たちが議論するのは、「デフォルトでDoC」、つまりブラウザベンダーが人々にデフォルトで自分のDNSをCloudflareまたは自分自身に移そうとする試みについてのものです。「Google Secure Lookup Service」の恩恵を受けるには、プロンプトが表示された時に、「Got it」ボタンを押すと、DoC-by-nudgeが表示されるという脆弱な形式にも懸念があります。

私たちは誰を信じるべきだろうか? — 厳しく規制された(ヨーロッパの)サービスプロバイダーは、DNSを使ってユーザーをスパイすることは許されていないと言い、彼らはそれをやっていないと言っている。それとも、サービスプロバイダーがユーザをスパイしていると主張するクラウドプロバイダを信ずるべきか? 彼らは、それを売らないと約束しながら、ありとあらゆるクエリを記録しているにも関わらず、私たちのDNSトラフィックを要求しているのです。

DoCプロバイダは、自分たちのDNSサービスを推進するために多大な努力を払うだけでなく、その結果に影響を与えるものは何もないと主張するのは信頼できるのでしょうか? Googleはより速いDNSが彼らのためにより多くの収入を意味することを進めてきた、それは本当らしいが、DoHは最初にどれもこれも遅くするでしょう!

一方、Cloudflareは、あなたが彼らのDoCサービスを使用するなら、これはCloudflareドメインにアクセスすることが競合他社のドメイン名を訪れるのに比べてわずかに速くなると主張します。これは本当かも知れないが、まず効果が小さく、次に実際のインターネットユーザにとってそれほど大きな売りではありません。

一方、現在、コーヒーショップのWi-Fiがあなたをスパイしているか、あるいは攻撃者がそれをしている可能性があります。しかし、上記のように、最近訪問したサイトの名前はTLS接続によって暗号化されずに送信されているため、DoCは今のところそのようなスパイからあなたを救うことさえしていません。

結局、ブロック不可能なDNSから非常に恩恵を受ける可能性がある抑圧的な政権にあるのユーザの多くがたくさんいますが、これは確かにそうかもしれません。しかし、トルコの反対派が世界とコミュニケーションをとるのを助けることができるのと同じくらい高潔なことですが、彼女を助けるためには、5億人のヨーロッパ人が訪れる全てのWebサイトの記録をCloudflareに送る必要があるのは常軌を逸しているように思います。

あなたがクラウドプロバイダであるなら — デフォルトDoCに対する他の議論はより魅力的かもしれません。DNSデータを販売しない、長期間ログに記録しないなど、あらゆる誓約がありますが、DoCオペレータがユーザが訪問した全てのサーバとサイト名のコピーを送信されるという事実は変わりません。何とかして、いつの日か、データは収益化されるでしょう。そして、これはユーザーに相談されない方法で起こります。

これはDoHプッシュについての他の説明を私たちに残して、これらのどれも非常に良いものではありません。1つには、インターネット体験を完全にコントロールするための単純明白な試みです。例として、ネットワークサービスとして広告フィルタリングを追加することを考えたISPがありました。これはGoogleのような広告企業に受け入れられないため、彼らはそのようなブロックが不可能であることを確認にしたいのです。デフォルトでDoCはそれを彼らに与えます。

私たちは、これまでに著名なユーザーは、自分のDNSのソースについて強い、あるいはよく理解した上での意見を持っていないため、発生することはすべて、インターネットユーザーではなくブラウザベンダによって決定されます。

DoCの相対的なリスクと利点について、私たちが現在理解していることを考えると、私の考えでは、ユーザーが自分のDNSをGoogleまたはCloudflareに提供することを決定することは全く不当に思われるので、実際に自分の生活を向上させるという信頼できる主張することはできません。

Power DNS Technical Blogに掲載されたオリジナル記事からの改作。

Hacker News