追記 2019–11–08
Chrome M81で DTLS 1.0 が無効になるようです。
Firefox 71 から DTLS 1.2 のみでのテストが可能になるり、2020 年3 月には無効にしたいとのこと。
追記
M80 までは落とさないことが決定したようです。M74 で落とされるのは Revert されていました。
”This has broken twilio, webex and ntt skyway”
影響範囲がかなり大きかったみたいですね。
かなり大きな変更ではあるので、罠にはまらない人がいないようにするため、情報共有のために書いておきます。
https://webrtc-review.googlesource.com/c/src/+/125141
Disable DTLS 1.0, TLS 1.0 and TLS 1.1 downgrade in WebRTC.Disable DTLS 1.0, TLS 1.0 and TLS 1.1 downgrade in WebRTC. This change disables DTLS 1.0, TLS 1.0 and TLS 1.1 in WebRTC by default. This is part of a larger effort at Google to remove old TLS protocols: https://security.googleblog.com/2018/10/modernizing-transport-security.html For the M74 timeline I have added a disabled by default field trial WebRTC-LegacyTlsProtocols which can be enabled to support these cipher suites as consumers move away from these legacy cipher protocols but it will be off in Chrome. This is compliant with the webrtc-security-arch specification which states: All Implementations MUST implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve [FIPS186]. Earlier drafts of this specification required DTLS 1.0 with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, and at the time of this writing some implementations do not support DTLS 1.2; endpoints which support only DTLS 1.2 might encounter interoperability issues. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Implementations MUST favor cipher suites which support (Perfect Forward Secrecy) PFS over non-PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites.
2019 年 4 月 23 日にリリース予定の Chrome M74 の WebRTC では DTLS 1.0 と TLS 1.0/1.1 が利用できなくなります。なぜ TLS ? と思うかもしれませんが、これは TURN-TLS 向けですね。
つまり DTLS 1.2 と TLS 1.2 への対応が必須になります。とはいえ通常は P2P でやり取りするということもあり、問題になりません。全てのブラウザは DTLS 1.2 に対応していますし、TURN サーバも TLS 1.2 対応しているのがほとんどでしょう。
DTLS 1.2 になるのはまぁ良いとして、 Cipher Suite の方で ECDSA と P-256 が必須なんですよね。
WebRTC の DTLS では証明書のやり取りはブラウザが動的生成した自己署名証明書を利用するんですが、今までは RSA 2048 (1024 だったかも) を利用していましたが、これが ECDSA に変わることになります。
追記
確かに Chrome Canary M75 では ECDSA の証明書をクライアントが生成していました。
ただ CipherSuites 見る限りは RSA でも受け付けてくれそうです。
ECDSA にしなければいけないというのは大丈夫そうです。
問題になるのは SFU や MCU というサーバ経由です。サーバ経由の場合 DTLS に利用する証明書は自動生成されないことが多く、用意した証明書を利用していることがほとんどでしょう。
その場合 ECDSA をあえて使ってることは少ないのでまずは証明書を ECDSA で作成する必要があります。これめんどくさいなと思いました。
SFU / MCU の対応
日本のサービスなどで使われていたりする MCU/SFU の対応状況を適当ですが調べておきました。
Janus
作者が日本大好きで日本語も話せることで有名な Janus ですが、早速対応しています。Mixer が利用していることで有名な OSS です。
古い OpenSSL のバージョンのときに強制的に DTLS 1.2 を利用するようにしています。古い OpenSSL だと DTLS 1.0 のみしか対応していないとかがあったと記憶しています。
証明書周りについてはわからず。
Mediasoup
Mediasoup は動的に証明書を生成しています。ただ、証明書の生成が RSA のように見えるので、ここが ECDSA になるような気がします。
Kurento
Kurento ですが暗号周りは OpenSSL に完全移行したようです。ただ証明書の部分、OpenSSL の最小バージョンや DTLS 1.2 に対応しているかはわかりませんでした、残念。
詳しい情報をお持ちの方、是非 Twitter にてご連絡ください。
Jitsi
Jitsi は現在対応中のようです、 Issues が上がっています。
全然関係ないですが … 中の人からコメントがあって、わかる。ってなりました。
Putting more pressure on the developers is not going to help. This is being worked on.Jitsi を利用している SkyWay は公式で発表していました。さすがですね。
その影響で、Chrome 74 ベータ版で、SkyWayのSFUが利用できない事象が確認されています。本件については、Chrome 74 安定版の正式リリース(4月23日)までに対応完了を目指し、SkyWayにて改修を進めております。おそらく先程の Issue で Jitsi 開発チームである 8x8 と連携していくのだと思います。オープンソースはこの辺りがいろいろできるのがいいですよね
Licode
licode はちょっとパット見わからなかったですが普通に OpenSSL を利用しているので、OpenSSL のバージョンを古いのを使っていない限りは問題なさそうです。おそらく Janus と同じ対応になるのかと思います。
Sora
自社製品は 2015 年に DTLS 1.2 への対応を完了しています。さらに動的に ECDSA な証明書を生成する仕組みが入っていますので問題ありません。 Chrome Dev M74 でも Chrome Canary M75 でも問題なく繋がっています。
OpenSSL も暗号部分のみの利用なうえに組み込みで最新の 1.1.1 を利用しているので問題ありません。
DTLS 1.2 を優先して実装したのは単に 1.0 対応がだるかったからというオチだったりします。
まとめ
WebRTC はスピード感があって、この辺も数ヶ月であっさり変えていったりするのでできるだけ最新に追従していくのが重要です。
今後だと RTP 拡張が 1 バイトと 2 バイトがの混合対応だったり、QUIC 対応だったり、AV1 対応だったり、Simulcast 対応だったりと、山程積まれている課題は多いです。
ただそれが面白いところではあるんですけどね。
おまけ
DTLS 1.3 の策定が進んでいます。
DTLS 1.3 が出たから DTLS 1.2 が無効になるということはありませんので、安心してください。DTLS 1.2 は LTSという感じととってもらって良いです。
DTLS 1.2 が使えなくなるより、 WebRTC のプロトコルが QUIC になる方が早いと思います。
