HTTPSで見えていたドメイン名とSNI
今回は ECH エンクリプテッドクライアントハローの話をしていけたらなと思うんですけど、 正直言ってですね、この ECH 全く分かってないんですよね。
まずどんなものかってところからちょっと話していってもらえると非常にありがたいかなと思ってるんですけど、どうでしょうか?
そうですね、結構説明が大変なんで、少しずつ話していければと思うんですけど、 まず HTTPS ってTLS で暗号化されているわけですけど、
実は暗号化されていない領域があって、それがドメイン名なんですよね。 その辺からちょっとずつ話していければと思います。
なるほど、ドメイン名が暗号化されていなくて、そこが何でしょうね、攻撃者からこう見えてしまうみたいなイメージなんですかね。
そうですね、見えちゃいますね。 アクセスしているサイト名のドメイン名が分かってしまうと。
今は分かっちゃいます。
じゃあその話からしていければなと思うんですけど。
そうですね、まずまともとインターネットの歴史をひも解いていくと、 HTTP が当時は主流だったんで、その HTTP にバーチャルホストっていう概念が生まれたんですよね。
その一つの IP アドレスで複数のウェブサービスを運営したいとか、それは当然あるじゃないですか。
ありますね。
それのためにバーチャルホストっていう概念を生みましたと。
それでホストヘッダーって、 HTTP ってホストヘッダーの中にそのドメイン名が入ってるんですよね。
なのでそのホストヘッダーを見て、どのシステムを動かすかっていうのを決めればいいっていうのが HTTPのバーチャルホストだったんですよね。
クライアントから HTTP でサーバーに対して通信する際に、IP アドレスは一つですもんね、もちろんその場合。
一つのサーバーで。
IP アドレスは複数のケースもあると思うんですけど、今回のバーチャルホストは一つの IP アドレスで複数のサービスを動かしたいっていうケースなんで、そうですね。
その場合、どのサービスに振り分ければいいか、リクエストを振り分ければいいかっていうのが分からないので、バーチャルホストのホストヘッダー部分を見て、
Apache とかが振り分けてたみたいな感じですかね。
そうですね。これは今でも多分ほとんどのサイトがやっている設定なんですけど、っていうのが生まれたんですよ。
これを HTTPS でできるかっていう話で同じことをできるかっていうと、実は昔できなかったんですよ。
できなかったんですね。
なんでかっていうと、HTTPS って暗号化されてしまっているので、どのドメインの証明書を使えばいいのかが最初の通信時には分からないんですよ。
どのドメインの証明書を使えばいいか分からないというのはクライアント側のことですか?
サーバー側ですね。
サーバー側がクライアントから送られてくるじゃないか、クライアントからのリクエスト時に、どのサーバーの証明書を、複数持っているサーバーの証明書を使えばいいかが分からないというような問題があったと。
分からないですね。
なので、HTTPSのバーチャルホストみたいに、HTTPSは一つのIPアドレスで複数のドメインを扱えなかったんですよ、もともと。
そういう時期があったってことですね。
そうですね。それだとさすがにまずいよねと。
そもそもIPv4のIPアドレスって今枯渇していてほとんどないっていう状況なんですよね。
そんな状況下でHTTPSのサイト一つ一つにIPアドレス割り当てなんて100%無理なんですよ。
現実的ではないですね。
なので、HTTPSって最初TLSのハンドシェイクをするんですけど、その時に一番最初にクライアントハローっていうのを送ってくるんですよ、クライアント側が。
で、このクライアントハローの中にドメイン名を入れておくと。
そうすればそのドメインを見て、この人このドメインで通信してきたからこの証明書使えばいいなってサーバー側が分かるわけですよね。
そのリクエストの一番最初、クライアント側のリクエストの一番最初にクライアントハロー部分でホストを分からせてあげる。
ホスト名を入れておくと。
そう、サーバー側に伝えてあげると。
その考え方としてはバーチャルホストでのホストヘッダーと同じですよね。
同じです。考え方としては全く同じで、ただHTTPSなのにドメイン名はSNIの中に暗号化されずに平文で入っているっていうのが特徴になります。
なるほど、そこだけ暗号化されてないんですね、SNIという部分が。
そうですね、そのSNIとしてそのホスト名が暗号化されてないと。
でこういうこと言うと、あれなんか昔の方がむしろセキュアだったんじゃないのっていう人いるんですけど、それは間違っていて。
なんでかっていうとSNIが出てくる前ってそのIPアドレスとドメインが完全に固定だったんですよね。
このIPアドレスはこのドメイン専用って感じだったんですよ、昔は。
1対1対応してるからですね。
なのでそのIPアドレスと通信してるってことが分かった時点でどのHTTPSのサイトを見ようとしてるかっていうのは分かってしまってたんですよね、昔は。
確かによく考えたらその通りですよね。
そうなんですよ、だからSNIによって何か安全じゃなくなったとかそういうわけではないですよね。
ただHTTPSで通信してるのにドメイン名は暗号化されてないっていう状況になってしまったんですよね。
今回話すECHはそのクライアントハロー自体を暗号化しようというやつで、
今回のSNIのドメイン部分も暗号化しようっていうのが今回話すECHになります。
話整理するとあれですよね、いろんな用語が出てきてるんであれなんですけど、
クライアントハローの中にSNIが含まれてるって理解で合ってますか?
それではい、合ってます。
クライアントハローの中にSNIが含まれてて、ECH、エンクリプテッドクライアントハローでは、
クライアントハロー自体を暗号化するのでSNIの中に含まれてるドメイン名も暗号化されるっていうようなロジックですね。
そうですね、そういう理解で大丈夫なんですけど、この後ちょっとずつそんな単純な話じゃないっていうのがちょっとずつわかってくるという感じになってきます。
なるほど、ちょっと難しいところが出てくるってことですね。
その理解で全然問題はないんですけど、実際の実装は実はそうはなってないので、理解としてはそれでいいんですけどっていうところですね。
その辺もちょっとずつ話していきます。
なるほど、実装はちょっと違うと。
そうですね。
お願いします。
ESNIの限界とECHの登場
もともとちょっと歴史から話したくて、歴史ってことは昔じゃないんですけど、そのSNIが暗号化されてないっていうのは以前から問題になっていたので、
エンクリプテッドSNI、ESNIってやつがまず出てきたんですよ。
これはクライアントハローじゃなくてSNIだけを暗号化しようっていう考え方でした。
SNI部分だけ暗号化することでドメイン名も隠せるよねってことですね。
そうですね。これをやるためにはニワトリ卵の問題があって、まず暗号化するには暗号化するための鍵ファイルをクライアント側が持ってないと暗号化できないじゃないですか。
そうですね、サーバーに対して通信する際に公開鍵を持ってる必要性がありますよね、クライアント側が。
なんでSNIが今まで暗号化されてなかったかっていうと、そこで結局クライアントハローって一番最初の通信時に送るものだから、その時って暗号化の鍵って持ってないんですよ、クライアント側が。
公開鍵を持ってないので暗号化することができないと。
クライアントハローを送った後にじゃあこの鍵で暗号化してって話になってやっと暗号化ができるんですよね。
そうだよなって感じですよね。
これニワトリ卵の問題で最初の通信は鍵持ってないんだからそれは暗号化できないよねっていう話で、なのでSNIはそのDNSで伝えようってなりました。
DNSで鍵を伝えるっていうことですか?
そうですね、なんでかっていうとそこしかなくて、結局今のインターネットの通信ってどうなってるかっていうと、まず最初にDNSでドメイン名見て、そのDNSで解決してIPアドレスを取ってきますと。
そのIPアドレスに対してTLSハンドシェイクをして暗号化通信、TLSの通信が始まるっていうのが現代のインターネットの通信、ウェブかな、ウェブの通信なんですけど。
なのでそのIPアドレスに対して通信する前に1回DNSでドメイン名の解決をしていると。
なのでそのIPアドレスだけじゃなくて、その暗号化の鍵も渡しちゃえば、そのIPアドレスに対して暗号化されたSNIを渡すことができるよねっていうのがESA9の考え方でした。
考え方かなりシンプルですね。アプリケーションサーバー、本当にアクセスしたいサーバーにアクセスする前にそもそもDNSに対してアクセスしてるでしょ。だったらそこに鍵置いておけばいいじゃんって考えですよね。
そうですね。そこしかないっていうのが一番大きいんですけど、DNSしかないんだよねっていう。それでいいじゃんって思いきやなんですよ。
これってSNIが暗号化されちゃうと、今まで見えていたものが見えなくなっちゃうんですよね。
それは見えていたものという、最初は誰ですかね。
盗み見てる人ですね。傍聴者ですね。マインザミドルしてる人たちが見えなくなっちゃうと。今まで見えていたものが見えなくなっちゃうので、
この人はEncrypted SNI、ESNIを使ってるなっていうのが分かっちゃうんですよ。
なるほど。否得にしているということが分かるということですね。
そう、否得しようとしてるって分かっちゃうんですよ。
私隠してますっていうのが攻撃者に対して。
そう、私隠してますっていうリクエストを流しちゃうんですよ。
なるほど。ちょっと悪そうですね。悪そうというか。
悪いというか、これを使ってブロックできるよねっていう通信を。
そもそも通信自体をブロックしてしまえるよね。通すことをしないっていうことができるよねってことですね。
技術的にできちゃうよね。
で、これ実は韓国、お隣の韓国ってかなり児童ポルノとかにかなり厳しい国で、このEncrypted SNIを使っているとブロックするっていうのが実際に行われました。
それは政府主導でみたいな感じなんですかね。
そうですね。要はSNIが使えなくなっちゃうと、そういうブロックとか検閲できなくなっちゃうので、ブロックしますってなったんですよ。
なるほど。政府が別に攻撃対策ではなくて、自国のアクセスをちゃんと監査したいから制限をかけたってことですね。
韓国に関しては基本的には児童ポルノが厳しいので、その児童ポルノのサイトを見てるか見てないかっていうのが判断できないっていうのが多分一番大きいかなと思いますね。
一番最初に多分自分が知る限り結構最初にやったのは韓国が早かったかなと思いますね。
そのEncrypted SNIがまだ策定中だった段階でブロックされちゃったんですよね。
なるほど。その策定中でも対応していたサーバーとかブラザーとかはあったってことですもんね。
ちょっとずつこれからやっていこうかって感じでブロックされてしまったと。
そのちょっと後に中国でもESNIがブロックされてしまいましたと。
具体的に中国がどういうブロックしてるかっていうと、ESNIの通信が発生したらそのIPアドレスに対してはしばらく通信ができない。
中国国内からしばらく通信ができないっていう状態になります。
グローバルに適用させるってことですね。
グローバルにそのIPアドレスに対して通信が。これだいたい120秒とか180秒ぐらいらしいんですけど。
なんでESNI使った瞬間になんかそのIPアドレスは中国全体からブロックされちゃう。しばらく。
ブラックリストに入るってことですね。
そうですね。それずっと入っちゃうと他の人もみんな困っちゃうんだけど。
120秒とか180秒ぐらい。要は数分ぐらい長通信できなくなっちゃう。
結構強い対応しますね。
そうっていうのが入っちゃったんですよ。これでESNIはもう使用として死んだんですよ。これ使えないねってなったんですね。
実質使えなくされてますよね政府によって。
そう。それで生まれたのが今回話すECHです。
じゃあECHが生まれた背景はこのESNI、前にあった仕様のものがブロックされたからそれを対策しようというので生まれたという。
そうです。ESNI自体暗号化しちゃうとESNIみたいにブロックされてしまうからクライアントハロー全体を暗号化してしまえばブロックされないんじゃないかっていうので生まれたのがECHです。
なるほどそういう考えで生まれたと。であればECHであればブロックがされないっていうことなんですかね。
ECHのOuter・InnerとGREASE ECH
これがねそうも言い切れないのでどんどん話していくんですけどこれかなりね難しいのがそのクライアントハローの中でインナーとアウターっていう概念が生まれたんですよ。
インナーとアウター。
要は真のクライアントハローと偽物のクライアントハローみたいな概念なんですよね。
なるほどこの通信は本当にECHとして暗号化してるけどこっちの通信はちょっと見せかけで暗号化してるように見せてるよみたいないう通信が存在すると。
というかそのなんていうのかななんかそのSNI自体を暗号化したらバレちゃうじゃないですか。
まあさっきの事例でそうですね。
だからSNI暗号化してないよって見せかけて実は真のクライアントハローは別のとこにあるでそっちは暗号化されている。
偽物のSNIの中にダミーのドメインを入れておいてそれを流して実際のクライアントハローは暗号化されていると。
で外で見えるクライアントハローがアウターで真のクライアントハローがインナーなんですよね。
ダミーとして暗号化されてないダミーのドメインを情報として含めておくと。
そうです。
それによってすり抜けるという手法を取ってるということですね。
そうですね。
かしこい。
ただね結局ダミーのドメインは入れないといけないわけですよ。
まあそうですよね。
で今クラウドフレアが結構ECH代々的にデプロイしてるんですけど、
クラウドフレアのECHってクラウドフレア-ECH.comっていうドメインに全部なるんですよ。
でこれをやることによって要はクラウドフレアのECHを使うことで、
外から見た時にこの人はクラウドフレア-ECH.comっていうサイトにアクセスしているのか、
それともECHで暗号化、実際のドメイン暗号化しているのかっていうのは外から見た時に判別できないっていう状態にできるんですね。
クラウドフレアが丸め込んでくれてるってことですよね。
そうですね。
けどクラウドフレア-ECH.comって見てもらうとわかるんだけど、
なんかペライチのサイトなんですよ。
テスト用というか。
そうテスト用みたいな。でこれをそんなみんなが見るわけないじゃないですか。
あり得ないですよね。そんなにアクセスする人せないページですし。
だからクラウドフレア-ECH.comに外から見た時にアクセスしてるなってなったら、
それはもうジョッジファックECH使ってるんですよ。
イコールそうですよね。
なので要はクラウドフレア-ECH.comっていうサイトの通信見かけたらブロックしちゃえばいいんだよね。
クラウドフレアのECHの場合。
それでESNIをブロックしたこととほぼ一緒のことができるってことですよね。
そうですね。で実はねロシアはすでにこれをやっています。
なるほど。
中国はまだやってないらしいんだけどロシアはすでにクラウドフレア-ECH.comとの通信をブロックしています。
ちょっとイタチごっこじゃないですかこれ。
そうなんでイタチごっこなんですよ。なんだけどESNIと違ってECHはまだそのやりようがある。
まだいける。
そうですね。で実はねあのECH使ってるかどうかっていうのは分かっちゃうんですけど通信を見ちゃうと。
ただあのグリースECHっていうんですけど現在のChromeは基本的にTLSの通信は全部グリースECHって言ってもうECH使ってるように見せかけた通信しか送ってきてないんです実は。
なるほどブラウザ側がクライアント側がECHを使ってるよっていう偽装をしていると。
そうECH実際使ってないんだけどECH使ってるように見えるようになってる。
それがサーバー側が対応しているか否かとか関係なく。
そう関係なくChromeはECH俺使ってますよ感がすごい出てる。リクエストしか送ってない。実際にECH使ってるかどうかは判断できない外からは。
それによってあのもしこのECHをすべてブロックしてしまったらChromeからのアクセスができなくなるっていう状況で。
そうChromeからのアクセスを全部ブロックしちゃうことになるそれをやっちゃうと。
結果そうなるからつまりブロックできないよねってことにしてるってことですね。
そうですねなので一応なんかESA9の時よりはかなり進んだ。要はそんな簡単にはブロックできない状況にはなっている。
これはあれですよね。Chromeが対応してくれたからそのブラウザ側クライアント側がすべからくグリースECHに対応してくれたからこういう状況になったけどもっていうのがでかいですよね。
そうですね。
なんかあの仕様の技術的な解決方法というよりかは環境みたいなところが大きそうですかね。
そうですね環境が整ってきて今もうすでにChromeの通信はECHかどうかわからなくなっている。
なのでECH有効にしても外からは基本的にはわからないっていう形にはなったっていうのが今の状況です。
いいですねハッピーな気がしますけどね。
ハッピーなのかというとなんかいろいろねじゃあ実際ECH使うとしたらどうするのって話もこれからしていくので。
結構ねそんな簡単な話ではないんですよ実は。
ここからはあれですかねECHを運用する観点みたいなところですかね。
そうですね。じゃあ実際にどういう設定したらECH使えるのか話少しずつしていきますか。
はい。
DNSとECHを暗号化する条件
まずそのECHはさっきの言ったECIと同じで結局DNSしかないんですよ。
通信する前に鍵ファイルを配らないといけないから。
そうやってDNSしかない。
ロジックとしては一緒ってことですね。
そうですね。
DNSにアクセスした時に鍵をもらってで暗号化してクライアントハローするっていうのは一緒と。
一緒ですねと。なんでDNSで配りましょうと。
でそのためにDNSにHTTPSリソースレコードっていう新しい仕様が追加されてますと。
はいはい。
でこのHTTPSリソースレコードの中にECHイコールっていうのを書いてその後にECHコンフィグリストって呼ばれてるんですけど
そこにベースロック読んで暗号化の鍵みたいなのをベースロック読んで文字列化したやつなんですけど
それを貼っておけばブラウザー側がそのHTTPS経由リソースレコード経由で鍵を持ってこれる。
仕様としてはかなりシンプルですね。DNSの設定だけで鍵ファイルを置くとかそういう話ではないってことですね。
鍵ファイル置きますね。
DNSの設定の中で鍵ファイルを置かないといけない。ベースロック読み化されてるとはいえ置かないといけないし
もちろんその置くのは公開鍵みたいな、公開鍵だけじゃないんだけどその設定公開鍵とかその諸々の設定なんだけど
結局それプラス暗号鍵はNGX使うんだったらそのNGX内に置かないといけないし
CDN事業者とかでも結局その鍵プラスその設定全部ドメインごとに持ってるはずなんだよね。
なのでその鍵とかを全部管理する必要はある。
それは証明書とは別で鍵管理をしないといけないっていうことですかね。
証明書とは別ですね。
ECHのための鍵の管理をする必要性があるってことですね。
オープンSSLだったらバージョン4以降かなだったらECH対応してるので
オープンSSLECHなんとかみたいなコマンドを打つとこの辺の鍵ファイルを作ることができますね。
なのでそういうそれを作って配ればいいのかっていうところなんですよ。
それだけじゃないんですよ実は。
なるほど単純にDNSで設定してで暗号化鍵をアプリケーションサーバーに置いておくだけではダメと。
ダメというか結局そもそもなんでECHやりたいのかっていうと
そのドメイン名を暗号化して要はどのドメインと通信してるかわからなくしたいわけじゃないですか。
クライアントがどのドメインに対してアクセスするのかっていうのを隠したいわけですよね攻撃者から。
そうだったらDNSってそもそも暗号化されてるんだっけっていう根本問題があるんですよ。
そうですよねDNSサーバーに対してこのドメインのIPアドレス何って聞いてる時点でもうアクセスしに行く気満々ですよね。
そうもうそれやった時点でこの人このドメインにアクセスこれからするなって割れちゃうから
結局DNSが暗号化されてなかったらECHどんなに頑張っても意味ないんだよね。
ちょっと根本の原因にたどり着いてしまいましたね。
根本的にDNSが動かされてないと意味ないっていうのとあとちょっとこれまた別件でその鍵ファイルをDNS上に置いてしまうと
DNSって基本的にUDPで通信するので512バイト制限っていうのがあるんですよ。
なるほど。
なので512バイト以上って載せられないんですよねDNSって基本的に。
そこの制約が出てくるんですね。
そうなのでHPSリソースレコードに鍵ファイルでっかいやつ置いたら512バイト超える可能性があると。
なので一応言っておくとDNSって512バイト超えるとTCPでフォールバックするっていう仕様があるので
別に大丈夫じゃないのって思ってる人いるんですけど実際には512バイト超えると壊れる環境で全然あるので
実際にはTCPのフォールバックの仕様って使えないんですね。
それはクライアント側が対応してないから。
そうですね。動かない環境あるので世の中には。
なので512バイトを超えられないとか色々考えてくると
HPSリソースレコードは結局その普段みんなが使っているようなDNSの環境では結局使えない現実的に。
なのでDNSを暗号化するっていう技術もあるんですよ。
DNSをエンクルイプテッドするという技術が。
そうですねそれが2つあってDNS over HTTPSとDNS over TLSの2つあります。
聞いたことありますねその単語。
DNS over HTTPSは普通にHTTPSで通信できます。
DNSにドメイン名を問い合わせるときにHTTPSで通信するって考えですかね。
そうですね。
DNS over TLSはDNS通信をTLSで暗号化するってやつでこれはちょっと特殊というか
そのDNS over HTTPSはみんなが慣れ親しんだHTTPSで通信しているだけなんだけど
DNS over TLSはちょっと新しいやつになりますね。
なんかどっちもあれですよね結局のところクライアントが対応してないとっていう話にはなるのかなと。
そうですねどっちもそうなんですけど今回検閲の話をしているので検閲観点で言うと
DNS over TLSは853番ポートを使うんですよ。
なのでこのポート番号を使って通信している時点で
DNS over TLSを使っているってことはバレる。
またその問題出てくるんですね。
そうなんですよ結局ECHの話をするとこの辺の話とは結局切り離せないというか
結局その辺考えないとやる意味ないんだよね。
ポート番号を変えるにしてもクライアント側が853番ポートでDNSを解決しようと来るから
ポート番号なんて変えられないってことですよね。
そうですねなのでこのポート番号を使った時点でバレちゃうと。
じゃあDNS over HTTPSの方がいいのかっていうと
一番有名なDNS over HTTPS提供しているのって
多分クラウドフレアの1.1.1.1っていうやつ
これはDNS over HTTPS使えるんですけど
当然このIPアドレスは中国国内からアクセスできないです。
ブロックされてるんですね。
ブロックされている。
なのでDNS over HTTPSを提供しているIPアドレスは中国からブロックされる可能性が高い。
一番有名なDNSでいうと8.8.8.8Googleがやってるやつなのかなと思うんですけど
こっちは対応してるんですかね。
Google自体はDNS over HTTPSのやつ配ってるんだけど
8.8.8.8でやってたからちょっと自分は使ったことないですね。
ただ対応してたとしても中国国内からはブロックされてる。
どうせ中国はGoogleアクセスできないからGoogleのIPアドレスは全部。
なので結局意味はないね。
なのでそもそも暗号化されたDNSを取得できるのかっていうまた別の問題もある。
無理じゃないですか。ロジック的に破綻してません?
結局DNS over HTTPSが検閲されてないDNS over HTTPSを手に入れるのが中国国内だとだいぶ困難です。
突破的な話で言うともうドメイン名を使わないみたいな世界観になってくるってことですね。
もう直IPアドレスアクセスみたいな話になってきちゃうってことですよね。
それで言うと中国国内だと日本だとエトセ保室いじるのってエンジニア以外たぶんいじんないと思うんだけど
中国国内だと結構普通の人もいじります。
なるほど普通にターミナルとかで書き換えるんですよね。
ターミナル使ってるかわかんないけど普通に中国のWeiboとかのSNSで保室にこれ書いたらこのサイトアクセスできるぞみたいなやり取り宣伝されてるから
日本人だと保室書き換えるって言ったらそれエンジニアしかやんないよって思うと思うんだけど
中国国内だと全然普通の人もやります。
なるほどじゃあそういうので迂回するっていうのが中国国内では結構やられてる。
一般的です。なのでこの辺の常識がね日本だと全然わかってない人多いので
結構文化違和だと思うと思うんですけどその辺がわかってないとこのECHの重要性ってあんまりわかんないと思いますね。
わかんないしでもそもそもECHで隠せてないですもんね今のところそのDNS
DNSが暗号化されてないと結局意味ないけど暗号化されているDNSに通信するのがかなり難しい中国だと。
で今のECHは基本的にDNS over HTTPSを使わないと有効にならないです基本的に。
なるほどそのDNSホスト名ドメイン名の解決の時にもうすでにそこから入らないと
ブラウザーが有効にしてくれない。
なるほど
有効にしても意味ないから。
使用上はECHとDNS over HTTPSって使用上は全く関係ないんだけど
ブラウザー側が結局暗号化されてないDNSで通信してる人はECH興味ないだろうってみなしているので
ECHは有効にしてくれないです。
省くんですねその後の処理を。
そうですねなのでブラウザー側でDNS over HTTPSを有効にしてないと基本的にECHは有効にならない。
なるほどちなみにその環境中国の環境だとDNSを暗号化してる人いるんですかねちゃんとやってる人は。
いやわかんないですねその辺は。
まあその辺もちょっとね後でちょっと事例とかも話しますが
あの中国国内の人が実際どうやってるかっていうのは正直わかんないですね。
まあそうですよね。
まあまあ今回はねちょっとECHの技術的にじゃあどうやって有効にできるのかとかの話の方を多めにしますか。
そうですねまあちょっとじゃあ話戻ってECHをどうやって使っていくのか運用していくのかみたいな話が。
ECH鍵のローテーションと世代ずれ
ECHまずその重要なのってこれあの鍵のローテーションなんですよ実際デプロイしようとすると。
鍵の交換をどうするのかってことですかね。
そうですねクラウドフレアだと何か数時間に1回ぐらいやられているらしいんですけど
あのこの鍵をちゃんとローテーションするっていう運用が必要になると。
その鍵をローテーションする短くローテーションしていかないといけないみたいなのはどういった理由でなんですかね。
そうですねあのECHの鍵ってDNSで配っているので全員同じ鍵なんですよね。
そうなると後からその秘密鍵が漏れた時に保存されていた過去のやつとかも全部複合化できちゃうと。
なので短期間でローテーションして遡って複合できる範囲っていうのを制限したいっていう理由らしいです。
なるほどできる限りその復元できる情報の期限っていうのを短くしたいからできる限り短くローテーションする方がいいよねっていう考えなんですね。
そうですねなのでローテーションしないといけないってなると例えばサーバーが複数台あった場合は鍵を作って全部にデプロイしないといけない。
めちゃくちゃめんどくさそうなんですけど。
しかもそれを更新した時にDNS更新しないといけない。
しかもその更新が差があったらめんどくさいことになりますね。
その話をしないといけなくて結局別のシステムDNSとCDNって別のシステムだから絶対に食い違うタイミングが出てくるんですよ。
それがたとえ数秒だったとしてもなんかありそうですよね絶対に。
しかもDNSって結構各クライアントでTTLの間キャッシュしてるのが普通なんだよね。
なのでたとえそんなことありえないんだけど完全に同時に更新できたとしても結局意味はない。
キャッシュされてしまってるからね。
DNSはキャッシュされてるから結局意味はないという根本的な問題があって。
むずいですね。ちょっと根本的な質問なんですけどDNSで鍵配布してるわけじゃないですか。
ここを複数鍵配布することはできないっていう感じなんですかね仕様として。
っていうのをちょっとこれから話そうと思ったんですがDNSで配布できる鍵は基本的には一つですね。
ただサーバー側で複数使えるようにすることはできて一応ECH Configの中にConfig IDっていうのを入れられるんですよ。
1バイトだけなんですけど。
1バイトだけすごいな。
そこの中に鍵ごとに何か値とか入れておけばこのConfig IDの値だったらこの鍵だよねみたいなのがわかるんですよねサーバー側で。
対応関係を記録しておいてこの鍵使われてたらこっちのConfig使うよねみたいな対応関係で対処できるってことですね。
そうですねなのでクライアント側で入れてくれるのでそのDNSの設定の中にConfig IDと鍵ファイルと他にも設定いくつかあるんですけど
そのConfig IDと鍵ファイル入ってるのでそのConfig IDクライアント側が教えてくれるんですねどのConfig ID使ったか。
なのでサーバー側はこのConfig IDだったらこの鍵だからこうすればいいやっていうのがわかると。
なのでサーバー側で複数鍵を使えるようにしておいてローテーションされてもその古い鍵もちゃんとサーバー側で使えるようにしておくっていうことはできる。
DNS側が浸透待ちだったりとかキャッシュで古い鍵を使ってたとしてもサーバー側でキャッチできるから問題ないよねってことなんですね。
そうですね。それができれば大丈夫だよねっていうのとあともう一個ねこれが結構すごい仕様なんですけど
と言ってもやっぱりどうしようもない、世代ずれってどうしようもないケースあり得るんですよね。
まあすごいエッジケースではあり得るだろうなという気はしますね。
やっぱどうしてもDNSってすごい古いキャッシュしてる可能性とかもあるし
もうやっぱり例えば何世代まで保持しておけばいいのかって問題もあるじゃないですか。
そうですね。そのコンフィグ、サーバー側が10世代まで保持しておけばいいのかいなかってしかもそこに対して何か正解わかんないですよね。
retry_configsとnginxの実装
そう正解もないし、なので実はこれリトライコンフィグっていうすごい仕様があって
リトライコンフィグ。
というのもそのECHに失敗しちゃうと通信できないんだよね。問題として。
ですよね。だからそもそもドメインの解決ができなくて、IPアドレスわかんないからクライアント側からの通信が失敗するみたいな挙動になると。
これ最悪じゃないですか。
ユーザーとしては最悪ですね。
ユーザー側からするとなんか通信できないけど理由わかんない。
わかんないし、多分トラブルシューティングというかサーバー側、開発者としてもめちゃくちゃわかりづらいと思いますね、その失敗。
そうなんですよ。なのでリトライコンフィグっていうのがあって、ECHの不効果に失敗したらリトライコンフィグって言って、これでもう一回リトライしてくださいってサーバー側、クライアントに伝えることがなんとできます。
なるほど、このコンフィグでやってみてくれっていうことが言えるんですね、クライアントに対して。
鍵ファイル渡してもう一回、この鍵ファイルでもう一回やり直してくれっていうことができる。
なるほど、普通だったら、普通の道だったらDNSで鍵を配布するんだけど、それが失敗したらリトライコンフィグの中でこの鍵使ってよ、でもう一回通信してよっていうことがサーバー側から言えるんですね。
言える、これすごい仕様だと思ってて、だってDNSで例えばIPアドレス帰ってきてそのIPアドレス通信したら、そのIPアドレスじゃなくてこのIPアドレスに通信してくれなんて言われないじゃないですか。
プロキシとかだったらそういうのもあり得るのかなという気はしますが、でもそうですね。
リトライコンフィグってかなりなんかすごい特殊な仕様だなと個人的には思うんですけど、これやっぱりECH失敗した時にユーザー側からするともうどうしようもないから、だからもうこの鍵でもう一回やってくれっていう仕様が入ったんですよ。
最終フォールバックですよね本当に。
最終フォールバックでもう鍵ファイルを直接サーバーから渡しちゃうっていう、DNSじゃなくてもうサーバーから渡しちゃうっていう。
そしたらもう一回ECHやり直して通信できるっていう仕様があるんですよ。
なんとなく考えてそのリトライコンフィグでもう一回失敗したらどうなるんだろうという気はなんか若干しますが、無限ループに陥る可能性。
それは無限ループになっちゃうし、基本的に同じサーバーに対して通信してくるので、それはないはず。ないと思いたい。いやバグってたらなるだろうけど。
そうですね。クライアント側がそのリトライコンフィグ何回まで受け入れるみたいなそういう実装がもしかしたらあるかもしれないですね。
まぁまぁ、ていうのあるけど、まぁって感じですね。
実はねこれ、エンジンX、今回自分エンジンXやってるのでこの辺の運用、エンジンXの話するんですけど、
エンジンXだとどうなってるかっていうと、エンジンXはSSL ECHファイルっていう設定があります。
この設定は複数個指定できる。なので複数個書けば複数の鍵を同時に扱うことができる。
さっき言ってたサーバー側が対応する鍵を複数個持つことができるってことですね。
持つことができるエンジンXは。ただここがね面白いんだけど、リトライコンフィグとして返されるのはなんと先頭に指定したSSL ECHファイルだけなんだよね。
それちょっとやめた方がいいなと今直感的に思っちゃったんですけど、
なぜ先頭なのか、リトライコンフィグ専用の設定が書きたくなっちゃうんですけど、直感的には。
そうですね。リトライコンフィグの時ってユーザーにデータ送りつけちゃうので、あんまりでかい通信送りたくないんですよ。
なるほど。
そうなんで最低限にしないといけない。だから鍵ファイル2つ3つ送る意味はない。鍵ファイル1つだけ送ってほしいんですね。
ただこれの問題はねドキュメントに書いてないんだよねこれ。
暗黙的な仕様になってる。
そう暗黙的な仕様でアンドキュメンテッドになっていて、SSL ECHファイル複数書けるっていうのは書いてあるんだけど、複数書いた時に実は一番先頭だけ特別扱いされてるっていう仕様は書かれてないけど、ソースコードを見ると一番上のやつだけ特別扱いされている。
なるほど。まああの先頭だから絶対あるよねっていう判断ですよね。実装時の。
まあ多分その一番重要なのを先頭にして、2個目3個目とかはフォールバック先、ユーザー側が使ってきた時に仕方なくやるやつっていう認識なんだと思うんですけど、これはね何かドキュメントに何故か書いてなくて、自分はNginxの何か威嚇書に何でドキュメントないのとかって書いたんですが特に反応はないです。
まあきっとあれですよね、仕様としてリトライコンフィグがそこまで重要視されてないってことなんですかね?
いやけどなんかその疑問に自分は疑問に思ったんですよね。これって失敗した時にどうするのかなと思って、で調べたらなんとリトライコンフィグっていうサーバーからDNSじゃなくてサーバーからもう送り付けちゃうっていう仕様があるってことに気づいたんですよ。
でNginxどうなってるのかなって調べたらなんとアンドキュメテッドで一番先頭のやつが送られてきますっていうのが出てきて結構僕はびっくりしましたね。
いやびっくりですね。そこかっていうところがありますね。まあでも仕方ないというかしょうがない実装部分の都合とかももしかしたらあるのかもしれないですが、Nginxの場合はそういう感じですね。
Nginxの場合はそういう感じになっているというところですね。なのでNginxでOpenSSL4Kを使ってECHのカギを作って、でさっき言ったSSL ECHファイルだっけな、この設定を渡してあげれば一応有効にはなりますと。
CDN・DNS運用とCloudflare
なので使いたければそうやって使うことはできるんだけど、結局ローテーションを考えるとそのSSL ECHファイルを作り直して、で作ったタイミングでDNSを更新しに行って、でNginxが複数台あった場合は前代に対して同じファイルをデプロイして、
で設定ファイルを書き換えて、新しいやつを先頭に置いて、古いやつを真下に置いて、でそれでNginxをリロードすると。
いやーこれ誰がその操作するんですかね。今ちょっと聞きながら考えてたんですけど、そのアプリケーションサーバー自体がその操作をするっていうのはあんまり考えづらいので外側から操作するのかなと。
TLSのレイヤーなんで、TLSのレイヤーって問題はそのアプリケーションサーバーまで貫通させるってできなくはないけど基本やんないんだよね。
なんでかっていうとその暗号化されちゃってるから処理ができないんですよ、エッジで。一回暗号化解かないとその処理ができないので基本的にはエッジでやらないといけないんですよね。
だから基本アプリケーション側でやるっていうのは基本的にできない。
さっきのやつはリトライ、リトライコンフィギュアじゃないエンジンXのコンフとかを書き換える処理とDNSのカギをアップデートする処理っていうのをどのタイミングでどのサーバーでもしくは手動でやるのかっていうのが気になったんですけど。
運用として。
運用としてクラウドフレアは数時間に1回やってるらしいので基本的に手動でやるっていうのは想定されてないんだと思うんですよ。
ローテーションを?
ローテーションを自動でちゃんとやってDNSちゃんと更新されるような仕組みを多分自分でやらないといけない。
どうやるかは多分会社によるだろうけどどうやるんでしょうねみんな。
小さい会社だったらエンジンX数台しかないだろうから何等とでもなると思うんだけどやっぱりCDNみたいなCDN事業者とかってなるととんでもない数サーバー台数あるだろうからどうやってデプロイするのかっていうのはかなり難しい問題になってくる。
デプロイの順番も重要ですしその処理がどこかでコケた時のリカバリーも重要ですし。
一部のこの辺のクラスターだけ古い鍵ファイルしか持ってませんとかが起こり得る。
ですよね。
そうだからこれねかなり考えるとすごい難しいしだからさっき言ったリトライコンフィグって結構大事な仕様でこれが失敗した時に通信できないとなるとまずいんですよ。
リトライコンフィグの仕様のおかげで最悪リトライコンフィグで通信ができるはず。
ただ一個問題点があってリトライコンフィグまでサーバー側の設定にかかれるっていう点が若干ちょっと脆弱的かなと思うんですけどリトライコンフィグすらもアップデート対象じゃないですか設定値の。
なので別の値で書き換えてこうミスってしまうみたいな言うのもまあ起き得るのかなっていうのを考えるとちょっと運用大変そうだなってどこまで考えるのかっていうところだとは思うんですけど。
これねどこまで考えるのかって話なんだけど真面目にちゃんとローテーションしましょうとかっていろいろ考えていくと結構大がかりな仕組みが必要になってくる。
ですよねでしかもすごい強調的ないろんなサーバーを強調的に動かす理想のデプロイシステムが必要になってくるってめちゃくちゃ難しいですこれ。
そうしかもCDNのCDN事業者の場合そのいろんな会社のドメインを扱うわけじゃないですか。
その会社のドメインのDNSサービスにアクセスしてDNSを書き換えないといけないんですよこれって。
それって現実的にできるのっていう話もある。
勝手に書き換えユーザー空間のデータを勝手に書き換えないといけないってことですね。
例えばroot53とかだったら例えばそのAWSのIAMとか設定すればできるかもしれないけど、
それってそのCDN事業者が限りローテーションしたタイミングでそのDCDNを使ってるドメイン全部を書き換えないといけないから
root53に短期間に一気に書き込みが走るってことになるんですよ。
それってAWS側もさすがに耐えられないんじゃないかって話もある。
めちゃくちゃ難しいですねこれ。
ほぼ同時にすごい数のDNSを書き換えないといけなくなる。
これ運用できてるんですかね。
だからこれ今やってるのはクラウドフレアしか多分ないんですよ。
なんでかっていうとクラウドフレアってDNS持ってるじゃないですか。
自社で持ってますね。
DNSを自社で持ってて実はクラウドフレアのDNS使ってる人しか使えないんですよ今。
自室?
なんでかっていうと結局このDNSをその限りローテーションされたタイミングでDNSを書き換えるっていうのが
クラウドフレアみたいにDNS自前で持ってる会社以外は不可能だからなんですよね。
クラウドフレアはDNS自前で持ってるから限りローテーションされたタイミングで
DNSを多分書き換えなくてもいい仕組みとか多分持ってるんだと思うんですよ。
要はDNS解決された時に取りに行くような仕組みとか多分そういうの持ってるんだと思うんですよね。
DNSとは別でってことですよね。DNSの前段にサーバーがあってみたいな。
ここだけ特別扱いされていて多分全部更新しなくていいような仕組みがあるんじゃないかな。
そういうブログは多分なかったと思うけど多分あると思いますよさすがに。
ここまで大々的にやってたら。
ぐらいしないとなかなか厳しいし
そもそもそこまでやったところでどうなるんだろうというところにも行き着くってところなんですかね。
そんなかな。どうなんですかね。みんなどう思ってるか正直わかんないんだけど
これ真面目に考えるとこれDNSの更新がやばいってことに気づくはずなんですよ。
ECHがもたらす中央集権化と用途
そうなると結局DNS持ってない会社。
例えばCDNだけ持っててDNS持ってないっていう会社は果たして対応できるのかっていう問題もある。
さっきの途中の話でもあったDNSそもそも暗号化で通信しないと
ドメインの暗号化もできてないよねっていうところにつけた話だったじゃないですか。
なので全てはドメインを隠したかったらDNSを頑張らないといけないっていう話に結論になるんですかね。
どうなんですかね。結局自分が思ってるのは
あともう一個別の観点もあって
これって結局最初にもちょっと話したこのIPアドレスを通信してたらこのドメインだよねっていうのがわかったら結局
ドメインを否得化しても意味ないんですよね。そのIPアドレス通信してるIPアドレスがわかるから。
IPアドレスの否得化はできないってことですよね。
IPアドレスの否得化はできないのでそのIPアドレス通信してたらこのドメインだってわかっちゃうんだったらこれをやる意味はない。
意味ないですね。
そうなるとそのECHの意味があるのってCDNみたいにたくさん
一つのIPアドレスでそのたくさんのドメインを扱っているサービスで
そのIPアドレスを通信しててもどことどこのサービス通信してるかわからないみたいな状況でECH使うとわからないっていう風になるんですよね。
一番効果的ですよね。いっぱいIPアドレスを持っている会社がいっぱいサービスを運用していたらとても効果的ですね。
そうなんですよ。それ以外基本的に意味がないんですよね。
そうなると結局IPアドレスたくさん持っててサービスもたくさん持っていて
CDNだけじゃなくてDNSも持っているっていう会社のサービスを使わないと結局あんまり嬉しくない。
そうなるとこれインターネットの過線化というか
結局インターネットの良さって誰でも適当になんか自宅サーバーとかで適当にサービス立てられたのが元々の良さだったと思うんだけど
結局こういうのやるとクラウドフレアみたいにCDNとDNS両方持ってますみたいな会社以外のサービスは
現実的に使えなくなる可能性がある。
ちゃんと暗号化したかったらクラウドフレア以外使えないよねみたいな話になってきてしまう可能性がある。
そうなるとあれこれってインターネットなのかっていう。
結局クラウドフレアの世界なんじゃないの。
クラウドフレアに監視されるだけなのでは。
そうっていう話になってくる。
そうなのでこれって結局いろいろ突き詰めていくとあれこれってインターネットとして本当にみんな嬉しいのかって話になってくる。
ちょっと気な臭いというか嬉しくないですね。自由ではない。
そう自由じゃないその結局巨人の肩の上に乗る以外の方法がなくなってくる。
これ真面目に考えると。
っていうのでECHは暗号化できて便利って自分も最初思ったんだけど
結局いろいろ考えていくとあれこれってめっちゃ大変だし
そもそもクラウドフレア以外まともに今できてないけど
これって大丈夫なのかみたいな気持ちにだんだんなってくる。
この仕様でしか現実無理なんだけど運用するには巨大なところがちゃんと運用しなくてはいけなくて
そこに乗っかる必要性があるっていうインターネットのジレンマが存在すると。
そうですねなので今後どうなる今後のインターネットどうなるのかなって自分は結構考えたりしますねこのECHで。
どうすればいいんですかね。
わかんないんですけどただ現実的にその嬉しいケースってあって
例えばそのテナントドメインでテナントが書いてるみたいなケースってあるじゃないですか
例えばそのコンパスとかって会社名.コンパス.コムっていうので分かれてるじゃないですか
サブドメインがサービス上で決定できるやつですね
そうサブドメインではたくさんあるやつ
あれって例えばコンパス全部コンパス.コムに通信してますって扱いに
ECHで使えばできるんですよ
そうすればコンパスに通信してるってのはわかっちゃうけど
どこの企業のやつを見ていたのかっていうのは分からなくできる
なのでそういうケースではECHは普通に便利だと思いますよ
なるほどサブドメイン以下のドメインを取得することっていう仕様もあるんですね
選べるんですよ
結局そのアウタークライアントハローでどのドメイン入れるかっていうのは選べるので
そこを自社のドメインにして
被特化する実際の通信してるドメイン被特化するっていうのはできる
今のクラウドフェラーはできないはずだけど
ECHの使用上はできる
なるほどそういうのをコンパス側がコンパスのサーバー側が対応したら被特化すること
被特化することができるコンパスだけじゃないけどね全然
我々がよく見てるサイトコンパスだからだけなんだけど
そういうことができるからメリットもあるよね
そういうサブドメインめっちゃ使ってますみたいな会社だったら今でも十分メリットはある
ただ通信してるドメイン自体を隠したいって思うと
それってそもそもすごいでかい企業すごい大企業のCDNに乗っかって
そのCDN事業者がDNS持ってないとできない現実的にできないよねっていう話になる
難しいですね
サブドメインでアクセスしているのを被特化したいみたいな需要って
大企業のエンタープライズとかであるのかなっていうのは何となく今想像したんですけど
企業が使ってるサーツとかだとそのテナントごとで農民分かれてたりとかって割と一般的なので
そういう需要はあると思うんですよそのドメインがサブドメインたくさん分かれてるみたいなケース
そういうケースだったらECHは今でも全然有用だと思いますよ
ただ使ってるエンタープライズ企業が社内セキュリティ的に
サブドメインでアクセスしていることを被特化したいという社内セキュリティの都合あるのかなと思って
社内セキュリティの話をしちゃうとDNSの暗号化ってそことも実はちょっとぶつかるんですよ
企業によるんだけど企業によってはそのDNSでどこのサイトと通信してるかっていうのを監視して
通信しちゃいけないサイトに対しては通信させないとかそういう制御をDNSでやってるっていう会社全然あるんですよ
たしかに社内PCで社用PCでアクセスしてはいけないところを制御してるみたいなことですね
そうですそれをDNSでやるっていうケースは全然あって
確かに
それがDNS over HTTPSとか使われちゃうとそういうのもできなくなっちゃう
なんかあれですね国が会社になっただけで同じ構造ですね
そうそうそうです
だからDNS over HTTPS使われちゃうと結局その会社側も監視ができなくなっちゃう
けど今のECHの仕様上はDNS over HTTPS使わないと有効にはならない
ちょっとあれですね何を守りたいか
そうですね何を守りたいかが本当に重要なんだけど
要はDNS over HTTPSで指定するIPアドレスを自分たちが会社側が管理するやつになってれば一応技術的にはできるんだけど
基本的にこれDNS over HTTPSの指定ってブラウザー側の設定なので勝手に変えられちゃったらもうわかんないんだよね
各従業員が勝手に変えたらわかんないよね
中国国内でやられている設定を書き換えるみたいなことと同じことが起きるということですね
そりゃそうですよね
ECHの現時点での実用性とインターネットの未来
だからねECHは暗号化できてみんなハッピーっていう理解だと実は全然足りなくて
結構真面目に考えるとあれこのケースどうなのこのケースどうなのっていろいろ考えていくと
結構難しい問題を払っているということが分かってきます
じゃあもしかするとこのECHがもっと普及してもう全然使うよねみたいな話になってきたら
次頭を悩ませるのは社内ITなんですね
社内ITプラス要はCDNを使わないとダメだよねっていう感じになって
インターネットの中央集権化っていうのが進んでいっちゃう
難しいです
多分今後どうなっていくのかみたいなところも含めて
今後どうなっていくか正直自分も分からなくてずっとウォッチしているっていうのが顕著ですね
ちなみに片杉さん的にこのECHプロダクションサービス会社でやってるサービスだったりとか個人のサービスだったりとかで
使うか使わないかで言ったらどっちとかあったりします
正直今会社とかだったらセキュリティの会社とかだったらやってみるのはいいと思うんですけど
普通のウェブサービスやってますって会社が今ECH有効にするメリットって正直ないですよね
現実的にクラウドフリア以外設定できないし
自分は自分のサークルのVPS上で色々設定してるんで実は自分のサイトは今ECH有効になってるんですけど
そういうエッチなことやってる人以外は正直あんまり現状関係ないっていうのが現状ですね
現時点では普通のウェブサービスだったら必要ないし運用上不可能な面もあるので
そうですねなのでさっき言ったサブドメインめっちゃ使ってますみたいなサービスだったら考えて
特にそのサブドメインと通信してるっていうことがわかると
結構その人のアクセス履歴とか結構わかっちゃうよねみたいなサービスもあるので
そういうサイトは今からでも考えていいと思いますね
確かにそうですね
今パッと思いついた事例なんですけど
転職を考える時に転職サイトを見ている時にその会社ごとにサブドメインが分かれていて
そこに社内からアクセスしたことを隠したいという時にはサブドメインで隠れてたら嬉しいですね
でもあれか転職サイトのドメイン自体は一緒だからそれ見てたら
さっきの異論だと転職サイトにアクセスしたこと自体はわかっちゃうけど
どこの企業を見たかはわからなくできるECHを使うと
ちょっと隠せるみたいな感じですね
ちょっと隠せると嬉しいかもしれないですね
これあれなんですよねアウターのSA9の中に実在するドメイン入れないといけないんですよ
なんでかっていうと存在しないドメインを入れちゃうと
ECH使ってるのバレバレじゃないですか通信としてありえないから
だから実在してるドメインかつ証明書もちゃんと存在してるやつを入れないといけないので
だから自分たちが持っているその会社のサービスのドメインを入れるのが普通なんですよね
そうしないとそのドメイン自体が変なことやってるって言われると
中国とかからそのドメインがブロックされる可能性があるんで
なのでその例えば全然関係ないサイトのドメインとか入れちゃうとそれがブロックされる可能性があるんですよ
まあexample.comとかgoogle.comとか
そうexample.comとかそういうの勝手に入れちゃうと多分ブロックされちゃう可能性があるので
だから結局自分たちが持っているサイトとかもしくはクラウドフレアとかサービス使うんだったらそのクラウドフレアが持ってるやつとか
そういうのにせざるを得ないっていう事情があります
やっぱ結論難しいですね運用していくので
一般的なウェブサービスだったらなかなか今ECH対応していくっていうのは難しいタイミングなのかなっていうところですね現実的には
現実的にはねなかなか大変だなと思いますね
やっぱこういうのが自分が極力発信してるつもりなんですけど
なんか正直多分ECHあんまりみんなが理解してないみたいで
発信してもね結構反応鈍いですね正直
考えたくないというか多分意識できる限りしたくない部分ではありますよね
クライアント側がいい感じにブラウザがいい感じに通信してくれて接続してくれて
しかもプラスアルファ一復してくれてたら一番いいよねっていうようなものかなと思うので
そういった面でウェブサーバーの方で何かやる
アプリケーションサーバーの方で何かやるっていうのは極力少なくしたいかなと思うので
そういうクラウドフレアとかが勝手に対応してくれてたらいい感じになるみたいなのが一番
運用者目線アプリケーションの開発者目線からすると一番いいのでね
ここらへん気にするのはきっとクラウドフレアとかそういうCDN事業者なのかなというのは
なんとなく今話聞いてて思いましたね
そうなんですけどただやっぱりクラウドフレア以外だとDNS持ってないCDN事業者が多いので
なかなか難しいんですよね実際の対応っていうのが
なのでそこも考えないといけないし結構ね
現実ECH自分は面白いと思ってるんだけど
じゃあ実際どれだけ広まるかっていうのは正直自分も分からないし
さっき鍵のローテーションの話したけど自分のサーバー鍵のローテーションしてるかっていうとしてないので
鍵のローテーションやろうとするとDNSの更新も必要だから結構めんどくさいんですよ
うんですよね
なのでなかなかね個人で真面目にやるっていうのはなかなか厳しいっていうのが正直なところですね
ありがとうございますっていう感じですかねECHに関しては
そうですねなんかいろいろあるんですけどこんなところでしょうか
ありがとうございますじゃあいい時間になったのでここまでに今回はしたいかなと思います
結論的にはECH今使うの難しいかなっていうところではありつつもでもOSSというかその技術的なところ
ECHの仕様だったりとか成り立ちみたいなところかなり面白かったかなと思うので
やっぱここら辺を追っていくと勉強になるところはかなり多いなという
そうですね今からでも自分を追ってほしいなと思っていて
実際自分の会社とか仕事で使うかっていうと難しい会社が多いと思うんですけど
それこそ自分みたいに個人のサイトで有効にしてみるとか面白いと思うし
実際考え方とか知るとこれからのインターネットとかウェブがどういうところに向かっていくのかとかも分かると思うので
本当ECHの仕様を追うだけでもこれからのインターネットの行く先が結構想像できるので自分は結構お勧めです
不穏になっていくのかどうなのかっていうところですねちょっと見ていけたらなと思いますねそこについてはインターネットの未来について
そうですね
はいということで今回はここまでにしたいと思います
ヤウヨルズのOSSは毎回一つのOSSやそれらの周辺のものを取り上げて
それについて片付いた返答後で入座席のところも深掘りしながら話をしていく番組になっています
今後もですねそのままの通りヤウヨルズのOSS取り上げていけたらなと思ってますので
ぜひお聞きのプラットフォームでフォローと高評価の方をお願いします
またですねこのOSSとかこういうものについてもちょっと取り上げてほしいところがありましたら
コメントやXなどで教えていただけると嬉しいので
ハッシュタグをつけて投稿していただけると見つけやすくなるのでよろしくお願いします
番組についての感想もお待ちしております
それでは今回もありがとうございました
ありがとうございました