アカウント名:
パスワード:
逆説的に、TLS 1.3 は安全だと言っている気がする。TLS 1.2 はもう解読できる、もしくは実用範囲内で解読できるから自由につかっていいよ、と。
TLS 1.3 への移行を更に急いだほうが良いかもしれないですね。
TLS 1.3未満のSSL/TLSには、SNIといって宛先ドメイン名を平文で添える仕組みがあるんです。ec2-12-34-56-78.ap-northeast-1-compute.amazonaws.comが*.amazonaws.comの証明書の代わりにsrad.jpの証明書を選んで返すにはそれが一番見栄えが良くて手っ取り早いので。
で、平文で送信されるということはGFWで見つけて叩き落とせるので、TLS 1.3でESNI(Encrypted SNI)が導入されたわけです。で、平文で送信されないということはGFWで見つけて叩き落とせないわけですね。
ここで例えばupdate.microsoft.comとgithub.comとtiktok.comが全てESNIを強制していて、全て逆引きで*cloudapp.azure.comとかを返してきて、全てIPが時々入れ替わるようになっていたりすると、GFWの運用上は不都合でしょうね。
>TLS 1.2 はもう解読できる、もしくは実用範囲内で解読できるから自由につかっていいよ、と。解読できているわけではなく、そもそも暗号化されていなかっただけです。
TLS1.2ではSNIが平文なのでアクセス先FQDNが簡単に判断できたが、1.3でESNIが導入されFQDNが暗号化されるようになったのでそれが出来なくなった。
これだけだとTLS1.3にすればESNIが使えるように読めるが、実際はDNSに公開鍵を登録しておかなければならないし、更にアクセス先を特定されないという目的を達するためには・DNSクエリからアクセス先を推定することもできるので、DNS over TLS/HTTPSを使わなければならない・DNSの改竄を防ぐためにDNSSECを使わなければならないというハードルがある。
今はホスト名暗号化ができなくても、その内できるようになると中共は考えたんでしょ。FirefoxにはESNIとDNS over TLSが標準では無効化されて搭載されているし。
そこまでやってもアクセス先IPアドレスは生なので、アクセス先が複数のサービスと同じクラウドやらCDNに収容されていて、その対応関係をアタッカーが調査せずに諦める前提の場合のみ有効。攻撃者が正引きしてIPアドレス毎にあたりを付けていたり、収容単位ごとまとめて処理していればあまり意味はない。
アクセス先ドメイン単位でちゃんと逃れたいなら、素直にTorやVPNやHTTPS+CGI-Proxyやらを咬ますべきだね。
ESNIはまだdraftだよね。「導入され」とかいうと、既にreleaseされたかのように見えるので、念為
国別IPアドレス帯でドロップしない理由もなくなりますねログやFail2Banの負荷を減らせますな
GDPRもついでに同じ対応をしちゃいましょう
そして念のための一文はこれですね
Sorry, Japanese Only.
なお、ここでは認知率100%の日本の代表的なサイトであるスラドはTLS1.3に対応してないようだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ソースを見ろ -- ある4桁UID
TLS 1.2 はok (スコア:1)
逆説的に、TLS 1.3 は安全だと言っている気がする。
TLS 1.2 はもう解読できる、もしくは実用範囲内で解読できるから自由につかっていいよ、と。
TLS 1.3 への移行を更に急いだほうが良いかもしれないですね。
Re:TLS 1.2 はok (スコア:5, 参考になる)
TLS 1.3未満のSSL/TLSには、SNIといって宛先ドメイン名を平文で添える仕組みがあるんです。ec2-12-34-56-78.ap-northeast-1-compute.amazonaws.comが*.amazonaws.comの証明書の代わりにsrad.jpの証明書を選んで返すにはそれが一番見栄えが良くて手っ取り早いので。
で、平文で送信されるということはGFWで見つけて叩き落とせるので、TLS 1.3でESNI(Encrypted SNI)が導入されたわけです。で、平文で送信されないということはGFWで見つけて叩き落とせないわけですね。
ここで例えばupdate.microsoft.comとgithub.comとtiktok.comが全てESNIを強制していて、全て逆引きで*cloudapp.azure.comとかを返してきて、全てIPが時々入れ替わるようになっていたりすると、GFWの運用上は不都合でしょうね。
Re:TLS 1.2 はok (スコア:3, 参考になる)
>TLS 1.2 はもう解読できる、もしくは実用範囲内で解読できるから自由につかっていいよ、と。
解読できているわけではなく、そもそも暗号化されていなかっただけです。
TLS1.2ではSNIが平文なのでアクセス先FQDNが簡単に判断できたが、
1.3でESNIが導入されFQDNが暗号化されるようになったのでそれが出来なくなった。
Re: (スコア:0)
これだけだとTLS1.3にすればESNIが使えるように読めるが、実際はDNSに公開鍵を登録しておかなければならないし、
更にアクセス先を特定されないという目的を達するためには
・DNSクエリからアクセス先を推定することもできるので、DNS over TLS/HTTPSを使わなければならない
・DNSの改竄を防ぐためにDNSSECを使わなければならない
というハードルがある。
Re: (スコア:0)
今はホスト名暗号化ができなくても、その内できるようになると中共は考えたんでしょ。
FirefoxにはESNIとDNS over TLSが標準では無効化されて搭載されているし。
Re: (スコア:0)
そこまでやってもアクセス先IPアドレスは生なので、
アクセス先が複数のサービスと同じクラウドやらCDNに収容されていて、
その対応関係をアタッカーが調査せずに諦める前提の場合のみ有効。
攻撃者が正引きしてIPアドレス毎にあたりを付けていたり、
収容単位ごとまとめて処理していればあまり意味はない。
アクセス先ドメイン単位でちゃんと逃れたいなら、
素直にTorやVPNやHTTPS+CGI-Proxyやらを咬ますべきだね。
Re: (スコア:0)
ESNIはまだdraftだよね。
「導入され」とかいうと、既にreleaseされたかのように見えるので、念為
Re: (スコア:0)
TLS 1.3 への移行を更に急いだほうが良いかもしれないですね。
国別IPアドレス帯でドロップしない理由もなくなりますね
ログやFail2Banの負荷を減らせますな
GDPRもついでに同じ対応をしちゃいましょう
そして念のための一文はこれですね
Sorry, Japanese Only.
Re: (スコア:0)
なお、ここでは認知率100%の日本の代表的なサイトであるスラドはTLS1.3に対応してないようだ。