トップ 追記

インターノット崩壊論者の独り言

過去の日記
EPIC2014
Google Public DNS (8.8.8.8, 8.8.4.4) 経由では本サイトにアクセスできないよう措置させて頂いております。

2019-02-18 木で鼻をくくっていない藤原さん

- Measures against cache poisoning attacks using IP fragmentation in DNS

2/16 の DNS 温泉番外編に参加された皆さま、聴講、意見交換ありがとうございました。さてこのイベントの前日 2/15 にJPRS の藤原さんが書かれた Internet Draft draft-fujiwara-dnsop-fragment-attack-00 Measures against cache poisoning attacks using IP fragmentation in DNS が公開されました。これによれば EDNS0 のサイズを 1220 としてそれ以上のサイズは TCP にフォールバックするとしたうえで 、(この値では通常フラグメントは起きないものと仮定し) フラグメントパケットは破棄するというプロポーザルです。

個人とはいえ JPRS の肩書きではこれが限界 (512 とは言えない) なのでしょう。JPRS さんは組織として木で鼻をくくったような回答していないで、公式に注意喚起して欲しいところです。私が主張する 512 バイトでなくとも、最低限このプロポーザルでよいのではないでしょうか。それとも「それは俺たちの仕事ではない」ということなのでしょうかね。あと去年の総務省らの注意喚起は無視でいいと思います。

土曜の DNS 温泉番外編では JP ゾーンのキャッシュへの毒入れが想像以上に容易であることのデモを見て頂くことができたかと思います。参加者の皆さんは注意喚起は必要だと思われたことでしょう。

以下、 draft-fujiwara-dnsop-fragment-attack-00 Measures against cache poisoning attacks using IP fragmentation 抜粋

4.  Proposal
 
   To avoid cache poisoning attacks using IP fragmentation by full-
   service resolvers,
 
   o  Full-service resolvers set EDNS0 requestor's UDP payload size to
      1220.  (minimal size defined by [RFC4035])
 
   o  Full-service resolvers drop fragmented UDP responses related to
      DNS.
 
   o  Full-service resolvers may retry name resolution by TCP.

本日のツッコミ(全1件) [ツッコミを入れる]

_ tm [まだ、JPRSからの警告はでませんね。fujiwaraのI-Dを知らないはずはないので、日本語での警告はするつもりは..]


2019-02-07 木で鼻をくくったような回答

- 第一フラグメント便乗攻撃についてJPRSに質問してみた

以下が JPRS の回答。特段、差し障りないようなのでそのまま公開します。EDNS0バッファサイズについて、ルート KSK キーロールオーバー騒ぎで出ていた 4096 バイトという値や、JPRS の『DNSがよくわかる教科書』に出てくる 1220 バイトという値は推奨値というわけではないということですね。危険性を承知のうえでこうした値を推奨するわけがありませんものね。やはり 512 バイトが安全なのでしょう。

追記: 木で鼻をくくっていない藤原さん

From: info@jprs.jp
To: "T.Suzuki" 
Cc: info@jprs.jp
Subject: Re: [JPRS info 352068] Re: 第一フラグメント便乗攻撃について
Date: Wed, 06 Feb 2019 16:05:19 +0900
 
中京大学
鈴木 様
                                        株式会社日本レジストリサービス
                                                      お客様サポート係
 
ご意見・ご指摘、ありがとうございました。
 
第一フラグメント便乗攻撃については、当社でも動向を注視しており、頂いた
ご意見・ご指摘を今後の取り組みの参考とさせていただきます。
 
EDNS0バッファサイズについてはそれぞれの環境・運用の中で判断されるものと
考えているため、現状ではJPRSとして特定の値を推奨するということは行って
いません。
 
何かございましたらお手数ですが、以下の窓口までお問合せください。
 
J┃P┃R┃S┃--------------------------------------------------------
━┛━┛━┛━┛
株式会社日本レジストリサービス  
                                
  お客様サポート係
    メールでのご質問  … info@jprs.jp
    お電話でのご質問  … 03-5215-8457(9:00-18:00 土日祝祭日は除く)
    よくあるお問合せ  … 
------------------------------------------------------------------------

以下が私の問い合わせメール。一部伏せ字にしています。

To: info@jprs.jp
Subject: 第一フラグメント便乗攻撃について
Date: Thu, 31 Jan 2019 15:50:21 +0900
Organization: Chukyo University
 
中京大学鈴木です。お世話になっております。
2つ質問があります。2.については回答を公開させて頂く可能性があります。
 
1. 
学生の卒業研究で第一フラグメント便乗攻撃の PoC システムが完成しました。
また付随して権威サーバが偽装 PMUTD に追従するかを判定するスキャナーも
出来ております。これで JPサーバを調べたところ■■■■■■■■■■■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■。5, 6年前には
明らかにされた脆弱性なので、現在この状態であることは承知の上での運用で
あろうことは推察されますので、特段秘密にしておく必要はないと思いますが、
いかがでしょうか。対策の予定があるようであれば考慮しますのでご連絡くだ
さい。また承知の上での運用ということであればその理由を教えて頂けますと
幸いです。(見掛け上脆弱にみえても実際の攻撃は成功しないことがわかって
いる等)
 
今のところ 2月16日 の DNS 温泉番外編で第一フラグメント便乗攻撃に関する
解説と JP あるいはその SLD のゾーンのキャッシュへの毒入れのデモを予定
しております。
 
2. 
また、現時点において JPRS 様が推奨する EDNS buffer size があれば教えて
ください。552 バイトを越える応答は第一フラグメント便乗攻撃に脆弱である
と考えておりますが、御社の EDNS buffer size へのお考えがありましたら、
ご教授くださいませ。
 
-- 
鈴木常彦 / 中京大学工学部
本日のツッコミ(全7件) [ツッコミを入れる]

Before...

_ tm [そうですね。短時間でのデモが可能な脆弱性ばかりではないということを伝えられるといいのでが、難しい。 長いと3日..]

_ tm [referral返答による毒盛は短縮の余地があるので、可能かもしれませんね。]

_ tm [JPRSのひとだった。JPRSも中はバラバラということでしょう。 draft-fujiwara-dnsop-f..]


2019-01-17 知らないってのは恐い

- DNS 温泉 番外編 (第一フラグメント便乗攻撃の理解のために)

DNS温泉 番外編 (2019年2月) を有志たちが企画してくれました。DNS のなかでも特に理解者が少ないと思われる否定応答に焦点をあてた 2017年の DNS 温泉 4 (山代温泉) をベースとして、新たな知見を加えて理解が困難な DNSSEC の不存在証明の闇に迫ろうと思います。

基本的な話は私が引き受けさせてもらい、闇の部分については今年度の卒業研究で第一フラグメント便乗攻撃 (別名アイコラ攻撃) の PoC (Proof of Concept) システムを作ってくれた私のゼミの B4 太田健也くんに任せようと思います。危険性がよくわかるデモをご覧いただけることと思います。第一フラグメント便乗攻撃は理論的には可能でも実際の攻撃は難しいのではないかと思っている方には特に参加をお勧めします。

なお第一フラグメント便乗攻撃の PoC については春の情報処理学会全国大会でも発表予定ですが全国大会は時間が短いので、DNS温泉番外編のほうが詳しく聞いて頂けるかと思います。日本ではあまり注意喚起がなされていないのですが、これを知らないでいるのは怖いことだと思います。

追記: 当日の太田健也くんの発表「DNS第一フラグメント便乗攻撃 (アイコラ攻撃)」のスライドが公開されています。


2019-01-16 気が長いのか宗教なのか

- 浸透とやらを待っている人は何を待っているのか?

JPRS の『DNSがよくわかる教科書』を読んでさえ「浸透を待っている」人を目撃しました。ほんとうによくわかる教科書なんでしょうかね。(あれよりまともなものを見たことはないのですけれど)

DNS の運用においては浸透という言葉の問題よりも、そもそも無闇に (あるいは根拠のない期間) 待つことの問題の方が大きいのです。長く待ってその末に設定ミスがわかるというケースがよく観察されます。いったい浸透を言う人たちは何を待っているのでしょう。待つことに意味はあるのでしょうか? 事業者が待てというのは単なる責任回避のデタラメですから信用してはいけません。以下に分析してみますので参考にしてください。

  1. 自分のキャッシュサーバで新しいレコードが引けるのを待っている?
    • 自分が引けたから誰もが引けるとは限らないのでそれだけではいけませんね (自分以外ずっと引けないケースも存在します)
    • 逆にキャッシュサーバが古い権威サーバ兼用のせいでその利用者だけが古いままという事例もありました)
    • 無闇に待たなくとも TTL である程度の目処はつくはずですね
    • TTL をみてもわからない例外は色々あるのでは?
      • 短すぎる TTL を切り上げる設定がなされているケースもありますが 1 時間以上は非推奨です
      • TTL より早くキャッシュが切れる (上限が切られている) 運用は割と一般的です
      • サーバの実体がたくさんあって負荷分散されているかもしれませんので丁寧な観察が必要です
      • NS キャッシュの TTL が 0 になる前にリセットされ、いつまでも新しい NS を参照しないなら幽霊ドメイン名脆弱性の対策が必要です
    • 急いでいるなら自分の hosts ファイルを編集すればよいでしょう (可能ならキャッシュをフラッシュ)
  2. 世界中のキャッシュサーバが更新されるのを待っている?
    • 残念ながらそういう仕組みは DNS にはありません
    • 利用者が検索を行うまで新しいレコードはキャッシュに入りません
    • なので浸透完了などという状態は存在しません
  3. 世界中のキャッシュサーバから古いキャッシュが消えるのを待っている?
    • 多様な実装があり一部を観察しても無意味でしょう (チェックサイトがあったりしますが大部分は実装が悪く、古いデータやネガティヴキャッシュをわざわざ入れてしまう危険性がありますから使わないほうが良いです)
    • やはり浸透完了などという状態は存在しません
    • TTL で判断するしかありませんが、どの TTL で判断するべきかが問題です
    • TTL は事前に短くしておきましょう (それができない事業者は避けましょう)
    • NS レコードやその A (glue) レコード (の値やTTL) は権威サーバに設定したものではなく、委譲(委任)元のものが使われる場合があります
    • NS 移転時は委譲元の NS の TTL だけ気長 に待ちましょう (確認方法を知りましょう)
    • NS と他のレコードの変更を同時に行わなければ急ぐ必要はなく徹夜で見守る必要もありません
  4. 権威サーバの応答が設定したゾーンデータに変わるのを待っている?
    • これを待つのが正解ですが、それがわかっている人は浸透とは言わないでしょう
    • 権威サーバの応答の確認方法をしらない人が浸透と言っている気がします
    • 気の短い人はどういうタイミングで更新されるかを事前にサーバ管理者に確認するのをお勧めします
    • NS 移転時は新旧のサーバのゾーンデータを一致させておけば不一致で困ることはありません (それができない事業者は避けましょう)
  5. 天に祈って新しいウェブコンテンツが見えたりメールが届いたりするのを待っている?
    • 一ヶ月近くキャッシュが更新されないブラウザなんてのが以前存在しました
    • むやみに待ったうえに失敗したくないなら DNS を学びましょう
  6. ゾーン転送を待っている?
    • ゾーン転送は許可されていますか? シリアルは増やしましたか?

以上を承知のうえで浸透とやらを待っている人はいったい何を待っているのでしょう?

本日のツッコミ(全2件) [ツッコミを入れる]

_ tm [最近は「浸透」を言わないようです。待っていることには変わりはないのですけど。]

_ tss [反映をよく見ますが同じことですね。言い換えればいいわけではないということです。]


2018-11-04 DNSSEC は危ない (その2)

- Unbound を安全にしよう

現代的な DNS キャッシュサーバは RFC 4035 の要請により、DNSSEC 署名の検証を必要としないポリシーのもとにおいても無駄な DNSSEC 応答を要求する DO bit フラグが立ってしまっており、第一フラグメント便乗攻撃に脆弱になっています。

またデフォルト設定の Unbound は否定応答に付随する NS や A をキャッシュに取り込んでしまうため非常に危険な状態で動作してしまいます。

12/5 追記:
Unbound 1.8.2 releasedに "The nameserver records in large returned negative responses are scrubbed out of the packet to avoid fragmentation based DNS cache poisoning, from a report from T.Suzuki." とあるようにこの否定応答における深刻な脆弱性は 1.8.2 で解消されました。すぐにバージョンアップしましょう。(各種バリエーションのある第一フラグメント便乗攻撃すべてが解消したわけではありません)

追記その2: rec: Skip NS records in authority/additional sections of NXD / NODATA #7258のようにPowerDNS Recursor も対応してくれました。

第一フラグメント便乗攻撃に対して耐性を強くするためには、DO bit を 0 にして、Unbound では edns-buffer-size: 512、harden-referral-path: yes を設定するとよいでしょう。(10/31の記事参照)

Unbound で DO bit を 0 にする方法を以下に示します。FreeBSD の ports を利用の場合です。DO=0 にする設定はないのでパッチ (以下の sed の部分) が必要です。自分の環境に合わせて作業してください。

# portsnap fetch
# portsnap update
# cd /usr/ports/dns/unbound
# make clean
# make extract
# sed -i '' -e 's/EDNS_DO 0x8000 \/\* Dnssec Ok \*\//EDNS_DO 0x0000 \/\* Dnssec NO \*\//' work/unbound-1.?.?/util/net_help.h
# grep Dnssec work/unbound-1.?.?/util/net_help.h
# make
# make deinstall
# make reinstall
# echo 'unbound_enable="YES"' >> /etc/rc.conf
# echo 'unbound_anchorflags="-l"' >> /etc/rc.conf (注: 起動スクリプトが trust anchor を取り寄せようとするのを抑止するため)
# echo 'module-config: "iterator"' >> /usr/local/etc/unbound/unbound.conf
# echo 'harden-referral-path: yes' >> /usr/local/etc/unbound/unbound.conf
# service unbound restart

これだけで安全になるわけではありませんが、第一フラグメント便乗攻撃のリスクはかなり低減できるはずです。なお当然ながらこの記事により生じた問題、あるいは私を信用しなかった場合に生じた問題等に私は一切の責任を持ちません。自分の頭脳で考えて行動しましょう。

本日のツッコミ(全13件) [ツッコミを入れる]

Before...

_ tss [どちら側でも有効ですね。]

_ tm [DNSSECでなくとも危ない。というのが正しそう。]

_ tm [Unboundだけではなさそうなので、もっと広く警告したい。]


2018-10-31 DNSSEC は危ない

- これを NSEC/NSEC3 Replacement Attack と呼ぶのはどうだろう?

二週間ほど前に恐ろしい毒入れ手法が成立しうることに気づいて、どうやって公表したらよいか悩やんだのだけれど、何と Herzberg と Shulman の論文を読み返したところアバウトながらしっかり書いてあったので躊躇することなく解説することにした。なぜ私はこれを読み流してしまっていたのか。どうしてこれを誰も騒ぎにしていないのだろうか。

DO bit を常に on にしろという RFC 4035 の傲慢な要請は修正されるべきだと思う。そして RFC 2308 という酷い RFC (私なら査読通さない) も SOA に付随する NS を許さないよう書き直されるべきだと思う。(私に IETF に行けというのは無し)

以下、第一フラグメント便乗攻撃の原論文 Fragmentation Considered Poisonous の II 章の C. Circumventing the Cache が示唆していると思われる攻撃手法の解説 (11/4 追記: こっちの論文のほうが詳しい。同じ内容かと思ってちゃんと読んでいなかった。迂闊。https://arxiv.org/pdf/1205.4011.pdf 4.1.1 Injecting NS RR to NSEC3 Response)

  1. 第一フラグメント便乗攻撃は成立しうる
  2. だが Answer 応答の差し替えはバッファとキャッシュに阻まれて連続的な攻撃が困難 (うちの学生が卒研で検証中)
  3. 否定応答であれば連続的な攻撃が可能となる
  4. RFC 2308 は否定応答の SOA レコードに NS や A が付随することを許している
  5. 否定応答の SOA レコードに付随する NS や A をキャッシュする実装が存在する
    検証用のゾーンを作成したのでご利用ください。
    dig hoge.sub.mufj.jp txt ; dig fuga.sub.mufj.jp txt
    などと二度 (負荷分散されている環境では多数回) 繰り返して
    "Your_cache_server_is_vulnerable."
    と出たら使用中のキャッシュサーバは第一フラグメント便乗攻撃への耐性が低いと考えられます。ただし EDNS0 への対応等は別途検査が必要です。
    (Unbound で検証済/harden-referral-path:yes にしないと危険 (追記: 1.8.2 で対策されました))
  6. NSEC/NSEC3 とその署名 (RRSIG) のついた否定応答の応答は大きい
  7. 第二フラグメントに追い出された NSEC/NSEC3 や RRSIG の一部を NS や A に差し替えることが可能である
    (NSCOUNT,ARCOUNTの数合わせとパディング等によってチェックサムを合わせることは難しくない)
  8. つまり否定応答を用いた第一フラグメント便乗攻撃により、移転インジェクションが可能となる (たぶん委任インジェクションも)
  9. RFC 4035 の要請により現代的なキャッシュサーバは DO bit が常に on になっており、署名検証をしない場合この攻撃が成立する
    (検証しても DoS になる / 鈴木が示したように条件によっては検証していても成立しうる )
  10. 応答内容が分かっていて変化しない場合、IP ID が完全にランダムであってもエントロピーは高々 16 bit だ (ポートランダマイズは役に立たない)

要するに DNSSSEC 署名しているドメインは、どうぞ未検証のキャッシュに毒入れしてくださいと言っているようなものである。そして検証もしないのに DO bit を常に立てているキャッシュサーバはマヌケである。(パッチが提供されるべきであろう)
(「DNSSEC はなぜダメなのか」もどうぞ)

11/5 追記: シャルマンらの論文 5 Conclusions and Defenses の以下の指摘はとても重大な指摘だと思う。大きな議論になっていないのが不思議だ。

We want to caution against drawing the conclusion that DNSSEC should not be used. In fact, the best defense is to apply DNSSEC correctly in all resolvers and domains (without using NSEC3 opt-out); this will certainly prevent many of our poisoning attacks, and even defend against more powerful Man-in-the-Middle adversaries. However, incremental DNSSEC deployment is vulnerable to our cache poisoning attacks, and complete adoption of DNSSEC may take considerable time, since it depends on adoption by both name server and resolver.

追記: Let's Encrypt は EDNS バッファサイズを 512 にしたとアナウンスしています。正解ですね。

p.s.
この件でも思うのだが脆弱性はぼやかさずはっきりと解説されるべきだろう。悪いやつらだけが高いモティベーションで攻撃方法にたどり着き、守備側は何が危ないかも理解できないまま放置されることになる。

本日のツッコミ(全15件) [ツッコミを入れる]

Before...

_ tm [additional sectionのすり替えが可能だと書きましたが、 それがキャッシュを上書きして、毒となる..]

_ sk [今までの狼少年的な騒ぎ方が問題だったのではないでしょうか?]

_ tm [フラグメント化されるくらい大きなAnswerあり返答で、Authority Sectionを置き換える攻撃を検討して..]


2018-08-27 5年目を迎えて地元愛知で

- DNS 温泉 5 無事終了

台風一過の 8/25 - 8/26、無事に DNS 温泉 5 が終了しました。参加した皆さん、お楽しみいただけましたでしょうか。前回は台風迫る山代温泉でしたが、今回は 5 周年記念に第 1 回を行なった猿投温泉&中京大学へ戻りました。やはり地元はやりやすい。

開催地も最初と同じ場所へ戻ったこともあり、内容も今回は初心に戻って超初心者向けに基礎から解説をさせて頂きました。1日目は基礎のお勉強がてら台風一過で晴天の中京大学で自慢のアイスアリーナ (スケートリンク) もみなさんに見ていただくことができました。オリンピック強化選手たちの滑りを見て頂き、有名な Y コーチとも遭遇したりとか。夜の部では猿投温泉も満喫頂けたかと思います。呑兵衛グループが就寝したのは午前3時半くらいでした。アイルランドへ転職されて今回参加できなかった常連 O さんからのアイリッシュウィスキーなど皆様からの差し入れの数々を美味しく頂きました。

2日目はゾーン作成からネームサーバ移転まで全員参加でハンズアウトに取り組んで頂いて終了。さらにリニモに乗って名古屋へ出てオプショナルな懇親会で夜遅くまで意見を交わさせて頂きました。皆様ありがとうございました。

交通の便は悪かったかもしれませんね。普段東京へ情報収集に出かけている身からすると、ざまあお気持ちはわかりますがご勘弁を。

資料はこちらです。後藤さんがツダってくださったログがこちら(Day1, Day2)。

参加した皆さんの振り返りレポートに期待したいと思います。


アイスアリーナ AURORA RINK 前にて 2018.8.25

2018-04-08 ささやかな抵抗 2

- 8.8.8.8 に加え 1.1.1.1 を用いたアクセスも拒否させて頂きます。

国が著作権侵害を行っているサーバを DNS ブロッキングで遮断する措置を 電気通信事業者へ要請しようとしているというニュースが入って来ました。これは検閲の禁止や通信の秘密と公共の福祉が真っ向からぶつかる話になるでしょう。慎重な議論が必要です。

児童ポルノのブロッキングの際には長い議論があって、児童の人権と生命のほうが大切ということから、ISP たちは「自主的に」ブラックリストを共有してブロッキングを行いました。今回の著作権問題が人命が危険に晒されていた問題と同様に扱って良い話だとは思えません。いきなり政府から電気通信事業者への要請という危険な方向へ走る前にできることがあるのではないでしょうか。

問題とされている著作権侵害のサイトに配信サーバを提供し幇助しているのは Cloudflare だとのことです。彼らは米国の裁判所から著作権侵害の幇助が成立するという判決を受けています。わが国もまずは配信サーバのテークダウンの要請あるいは裁判を彼らに対して起こすべきでしょう。

そして国から要請を受ける前に我々もできることはあるでしょう。とりあえず私は Cloudflare が運営しているパブリック DNS キャッシュサーバ 1.1.1.1/1.0.0.1 を利用した私のサイトへの接続を拒否し、ささやかな抵抗としたいと思います。

これは別途論じたいと思っていますが、電気通信事業法も見直されるべき時に来ているのではないでしょうか。私はインフラとしての電話とあくまで実験でしかないインターノットを同列に扱うのがおかしいと思っています。自律ネットワークには自律的に何を流すのかを決める権利と、協調のための自律の努力義務があると思います。そのうえで検閲やまっとうな定義での盗聴(機械的にヘッダを見るのも違法だが正当業務行為だという現状の法解釈と運用は詭弁でしょう)を禁ずることは可能でしょう。さもなくば私の AppleTalk を流してくれないのは通信の秘密に抵触することになりますよ。IPv6 しかり。ネット中立論なんて絵に描いた餅にすぎません。

本日のツッコミ(全4件) [ツッコミを入れる]

Before...

_ tss [入れました。ありがとうございます。]

_ 14.192.44.4 www.e-ontap.com [14.192.44.4 www.e-ontap.com]

_ tss [現在は解除しています。]


2017-12-13 インターネットの子供たちへ

- 子供たちに知っておいて欲しい話がある。

昔インターネットと呼ばれたネットワークがあったんだ。

インターネットよりも昔の時代には一握りの巨大な電話会社たちが提供する通信サービスしか人々は利用できなかったんだ。何が出来るかは彼らが決めていたんだ。決められたこと以外はやっちゃいけなかった。罰せられたんだ。

昔はパソコンというものもなくて、コンピュータはお金のある組織の一部の特権的な技術者だけが扱うことを許されていたんだ。

だけど45年ほど前にイヴァン・イリイチという人が道具は誰もが自由に使えてお互いを助け合えるもの (コンヴィヴィアリティのための道具) でなくてはいけないと人々に説き、同様に考えた人たちがパーソナルコンピュータ(パソコン)を生み出したんだ。アラン・ケイの書いた論文 "あらゆる年齢の「子供たち」のためのパーソナルコンピュータ" とか読んでみて欲しい。

そしてパーソナルなコンピュータを使って誰とでも自由にいろんなデータをやり取りしたい、自由なコミュニケーションがしたいという人たちが集まって新しいネットワークを生み出したんだ。それがインターネットだったんだ。

彼らはまず自分の会社や大学で自分たちのネットワークをつくった。そしてそれらを寛容な合意形成をしながらお互いにつなぎ合ってどんどん大きなネットワークにして行ったんだ。手を繋いでみんなで輪をつくるように。そのネットワークには中心はなかった。それぞれの人たちが自分で作ったネットワークを互いに繋いだだけだったからね。

そのつながりあったネットワークはインターネットと呼ばれるようになり、そこでは他人に迷惑をかけない自律と、話し合い譲り合い困った人を助ける協調と、そして全体を支配する人のいない分散した管理が尊ばれたんだ。通信ソフトウェアもそのような「自律分散協調」の動作をするように作られていたんだ。

誰かがこんな通信をしたいと思いつくと、彼はソフトウェアを書き、それを皆に分け与えた。それを気に入った人はそれをまた周りの人に配り、使い方を教え、使える人が増えて行った。ほとんどのソフトウェアは自由に改良できるようになっていて、人々は好みにあったソフトウェアを自由に作り出し選択できたんだ。

でも結局そういうインターネットは理想的な世界を作り出す前にうまく行かなくなったんだ。インターネットってのは幻想だったのかも知れないね。

通信の秘密とやらのおかげで自律と協調ができない人たちもお金を払えば合意の輪に入れるようになってきて、どんどん全体の協調が崩れていったんだ。

そしてそれに対抗しようとする頭の良い人たちのおかげで仕組みが複雑になりすぎたんだ。技術は大きく複雑になると管理できなくなって人々の手を離れるんだ。頭の良い人たちに管理してもらわなくちゃいけなくなる。頭の良い人たちがそうやってどんどん主導権を握るようになるんだ。主導権とりたい人たちは頭良いよね。

最初自分で自由にやるのが楽しかった人たちも、協調できない人たちや複雑になりすぎた技術が手に負えなくなってくると、誰かに任せた方が楽だと思い出すようになる。

そのうち対価をもらって自由な人たちを手助けしていた人たちにも手に負えなくなってくる。手が掛かりすぎて商売にならなくなるんだ。もともと技術がないのに適当にごまかして引き受けていたりした人たちも多かった。残念なことだね。

そして失敗が重なると安全・安心じゃないといわれて、技術力のない人たちの居場所がなくなっていった。国もインターネットはインフラだ、安全・安心が大切と言っていろんな規制を始めようとしている。

安全・安心な仕事を引き受ける人がいなくなってくると仕事の対価はどんどん高くなる。高いのに十分な技術を持った人は見当たらないという状況が生まれてきちゃった。

インターネットをインフラにしたいなんていう無理な相談しているのだから当たり前だよね。インターネットを構成している君の学校、会社のネットワークがインフラだと言っているに等しいんだから。そんなの担えきれないよね。

そこへ大勢まとめて面倒みるから安く出来ますよ、我々のやり方に従ってもらいますけどね、というところが出てくると皆はそこに頼まざるを得なくなってきちゃった。

こんな風にして気がついたときにはもう大勢まとめて面倒みているところにしか優秀な技術者の居場所はないという世界になってしまっていたんだ。絶滅寸前の古い技術者も巷にちょっとだけ生き残ってはいるけどね。大事にしてあげてね。

そして世界は情報の消費者ばかりになり、中央のコンピュータに日々の行動を自ら監視してもらうようになり、コンピュータの提案に無意識に従うようになりつつあるんだ。(星新一の『声の網』って読んだことあるかな。あんな風になってきてるの気づいているかな。そしてその方向は加速してる。皆が見えない塀の中に閉じ込められ管理されつつあることに気づいて欲しいな。

人々は与えられるもので満足してしまうから、自由のなさをなかなか不自由に感じられなくなってしまう。塀の中ではそれなりに幸せなんだろうね。むしろ皆と同じものを使わないでいると息苦しくなるんだ。管理された技術は社会を技術に合うように変えちゃうからね。

自律分散協調を尊び自由を求めたインターネットはもう存在しないんだよ。今あるネットはなんと呼べば良いんだろう。インターノットかな。

それでも塀の外には自由はあるんだと信じている人たちはまだ残っていて、新しい世界をつくろうとがんばっている。貴重な存在なので応援したいね。そもそも新しいものを生み出す道具を手にする人たちが絶滅しかけているのだし。

自由な人たちに絶滅して欲しくないんだ。自由な世界が崩壊して欲しくない。そんなに管理されたい? インターネットが何だったかをぜひ学んで欲しいな。このリンク先とか参考にしてね。そして戦おうよ。自律分散協調の旗を再び掲げ、自由のための道具を手にして。それこそがネットリテラシー、情報リテラシーだ。

p.s.

『インターネットの子供たち』を書かれた故三宅なほみ先生に本エッセイを捧げます。また、「子供/保護者/学校」×「情報リテラシー」 Advent Calendar 2017 の13日目のための記事でもあります。

過去の記事


2017-09-18 台風迫る中

- DNS 温泉 4 無事終了

台風迫る 9/16 - 9/17、無事に DNS 温泉 4 が終了しました。参加した皆さん、お楽しみいただけましたでしょうか。

資料はこちらです。後藤さんがツダってくださったログがこちら(Day1, Day2)。

参加者の皆さんのレポートもありがたいですね。


なお、台風で予定の旅程で帰れないかもと判断した私ともう一人が延泊し、楽しく補講を行いました。


最近の日記

リンク

Copyright by T.Suzuki