アカウント名:
パスワード:
韓国の SNI を使ったこの方式のブロッキングは「先見の明」がある最先端の方法です。
Contributes to HTTP, TLS, QUIC development at IETF という肩書を持つ Kazuho Oku 氏でさえも、(とはいえ、SNI blocking するISP箱や国家レベルブロッキングしてる設備でも、たまたま入れてる設備が同等・互換で見て遮断しちゃうとかはあるんだろうな的な。)というツイートに対して、「そういう話は聞いていませんし、実際、大規模なブロッキングではTLSの中身を見てどうこうするというコスト高の手法はこれまで避けられてきたと理解しています」と返答 [twitter.com] しているほどです。
特定の FQDN をブロッキングするのは DNSブロッキングで簡単にできますが、何故そっちの方式を採用せず高負荷な SNI blocking にしたのかというと、DNSブロッキングは Chrome などの主要ブラウザが DNS over TLS を標準にしてしまえば、簡単に回避できるからです。
一方、TLS 1.3 については、対応しているWebサーバは現時点ではほどんどないうえ、ブラウザが対応すれば終わりのDNS over TLSと違ってアクセスするWebサイトのサーバ側が TLS 1.3 に対応しなければ SNI blocking を回避できません。
しかも、SNI blocking の方は、TLS 1.3 を検出すれば(ホスト名が平文で送信される TLS 1.2 以下を検出できなければ)ブロッキングの対象とすることで、TLS 1.3 の使用を妨害することができます。そうなると、韓国のユーザはブラウザの設定で TLS 1.2 以下を使うようにせざるを得ないので、ブロッキングは効果的に機能することになります。Webサーバ側がTLS 1.2以下に対応せずにTLS 1.3専用にするのは現時点では考えにくいですしね。
しかも、SNI blocking の方は、TLS 1.3 を検出すれば(ホスト名が平文で送信される TLS 1.2 以下を検出できなければ)ブロッキングの対象とすることで、TLS 1.3 の使用を妨害することができます。
TLS 1.3をサポートしていても、ESNI(暗号化SNI)をサポートしていないブラウザもあるので、TLS 1.3以上でESNI非対応は許してあげてもいいんじゃないですかね。
手元のブラウザがESNIに対応しているかどうかは、ここ [cloudflare.com]で判定可能です。
ところで、SNI blockingは、UTM/FWでもサポート [fortinet.com]されている機能ですね。これらの製品は、どう対応していくんですかね?
しかし指摘にあるようにHTTP/HTTPSに対していちいちプロトコルまでデコードするのは設備的に大がかりじゃありませんか。あの国だからISPも寡占化が進んでいるのでしょうけど、すべてのHTTP/HTTPSリクエストに対してデコードとDNS名マッチングするのは大変な計算リソースが必要な気が。
p.s.ポート名を変えたプロクシを日本に立てれば、彼らは抜けられるかも。
2008年だったかな07年だったかな、そこら辺の実情を韓国で見てきた人の勉強会に参加したことがあったんですけど、その時点で、すでに、韓国のネット検閲装置を開発してる企業は、パケット自体を(TLSやSSLの中身に介入して)チェックして検閲回避を阻止したり、検閲回避をする人をブラックリスト化するシステム・それも相当高速なシステムを多くの国や企業・公的機関に売り込んでたんですよね。勿論、その会社だけではなく、韓国だけでそのような会社が数社あり、ISPやなんやに売り込んでて、営業先には日本の企業やIHCのような準公的機関も含まれてる。と言う話でした。
10年ほど前でそんな状態だったのですから、今はもっとえげつないでしょう。TLS1.2までのセキュリティホールを高速に破壊したり、TLS1.3以降で回避しようとしたりする人をブラックリスト化したりパケットをすり替えたりするようなシステムが、すでに韓国企業や他国企業によって商品化されてておかしくない。
「先見の明」があればこんなことやらないだろうあっさり検閲サーバーが落ちたりして
某衰退国なんかはDNSをいじってブロッキングしようっていって笑いの的にされていましたね。バカすぎる案で検討段階で潰れてくれましたが。
実際に運用して問題点を出してくれるんだから、大変にありがたい社会実験じゃないですか。当の韓国国民からしたら堪ったものじゃないですが。
Webサーバ側がTLS 1.2以下に対応せずにTLS 1.3専用にするのは現時点では考えにくいですしね。
SSL3.0やTLS1.0だって脆弱性見つかるまでは無効化されるなんて考えにくかったですけどね。
TLS1.2がダメだとなったらどうやって対応するんですかねぇ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:1)
韓国の SNI を使ったこの方式のブロッキングは「先見の明」がある最先端の方法です。
Contributes to HTTP, TLS, QUIC development at IETF という肩書を持つ Kazuho Oku 氏でさえも、
(とはいえ、SNI blocking するISP箱や国家レベルブロッキングしてる設備でも、たまたま入れてる設備が同等・互換で見て遮断しちゃうとかはあるんだろうな的な。)というツイートに対して、
「そういう話は聞いていませんし、実際、大規模なブロッキングではTLSの中身を見てどうこうするというコスト高の手法はこれまで避けられてきたと理解しています」と返答 [twitter.com] しているほどです。
特定の FQDN をブロッキングするのは DNSブロッキングで簡単にできますが、何故そっちの方式を採用せず高負荷な SNI blocking にしたのかというと、
DNSブロッキングは Chrome などの主要ブラウザが DNS over TLS を標準にしてしまえば、簡単に回避できるからです。
一方、TLS 1.3 については、対応しているWebサーバは現時点ではほどんどないうえ、ブラウザが対応すれば終わりのDNS over TLSと違ってアクセスするWebサイトのサーバ側が TLS 1.3 に対応しなければ SNI blocking を回避できません。
しかも、SNI blocking の方は、TLS 1.3 を検出すれば(ホスト名が平文で送信される TLS 1.2 以下を検出できなければ)ブロッキングの対象とすることで、TLS 1.3 の使用を妨害することができます。
そうなると、韓国のユーザはブラウザの設定で TLS 1.2 以下を使うようにせざるを得ないので、ブロッキングは効果的に機能することになります。
Webサーバ側がTLS 1.2以下に対応せずにTLS 1.3専用にするのは現時点では考えにくいですしね。
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:3, 興味深い)
しかも、SNI blocking の方は、TLS 1.3 を検出すれば(ホスト名が平文で送信される TLS 1.2 以下を検出できなければ)ブロッキングの対象とすることで、TLS 1.3 の使用を妨害することができます。
TLS 1.3をサポートしていても、ESNI(暗号化SNI)をサポートしていないブラウザもあるので、
TLS 1.3以上でESNI非対応は許してあげてもいいんじゃないですかね。
手元のブラウザがESNIに対応しているかどうかは、ここ [cloudflare.com]で判定可能です。
ところで、SNI blockingは、UTM/FWでもサポート [fortinet.com]されている機能ですね。
これらの製品は、どう対応していくんですかね?
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:1)
しかし指摘にあるようにHTTP/HTTPSに対していちいちプロトコルまでデコードするのは設備的に大がかりじゃありませんか。
あの国だからISPも寡占化が進んでいるのでしょうけど、すべてのHTTP/HTTPSリクエストに対してデコードとDNS名マッチングするのは大変な計算リソースが必要な気が。
p.s.
ポート名を変えたプロクシを日本に立てれば、彼らは抜けられるかも。
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:1)
2008年だったかな07年だったかな、そこら辺の実情を韓国で見てきた人の勉強会に参加したことがあったんですけど、その時点で、すでに、韓国のネット検閲装置を開発してる企業は、パケット自体を(TLSやSSLの中身に介入して)チェックして検閲回避を阻止したり、検閲回避をする人をブラックリスト化するシステム・それも相当高速なシステムを多くの国や企業・公的機関に売り込んでたんですよね。
勿論、その会社だけではなく、韓国だけでそのような会社が数社あり、ISPやなんやに売り込んでて、営業先には日本の企業やIHCのような準公的機関も含まれてる。と言う話でした。
10年ほど前でそんな状態だったのですから、今はもっとえげつないでしょう。TLS1.2までのセキュリティホールを高速に破壊したり、TLS1.3以降で回避しようとしたりする人をブラックリスト化したりパケットをすり替えたりするようなシステムが、すでに韓国企業や他国企業によって商品化されてておかしくない。
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:2)
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:1)
「先見の明」があればこんなことやらないだろう
あっさり検閲サーバーが落ちたりして
Re: (スコア:0)
某衰退国なんかはDNSをいじってブロッキングしようっていって笑いの的にされていましたね。
バカすぎる案で検討段階で潰れてくれましたが。
Re: (スコア:0)
実際に運用して問題点を出してくれるんだから、大変にありがたい社会実験じゃないですか。
当の韓国国民からしたら堪ったものじゃないですが。
Re: (スコア:0)
Webサーバ側がTLS 1.2以下に対応せずにTLS 1.3専用にするのは現時点では考えにくいですしね。
SSL3.0やTLS1.0だって脆弱性見つかるまでは無効化されるなんて考えにくかったですけどね。
Re:韓国のブロッキングは「先見の明」がある最先端の方法 (スコア:2)
TLS1.2がダメだとなったらどうやって対応するんですかねぇ