[ubuntu-jp:6380] Re: Ubuntu 20.04でのOpenSSLのバージョン

2020年 12月 9日 (水) 07:35:31 UTC

この件、Ubuntu 20.04にするにはMySQL 8へのマイグレーション方法も考えんとなあと思っているうちに、JPCERT/CC
Alertから以下のメールが来ました。-----------------------------OpenSSL の脆弱性 (CVE-2020-
1971) に関する注意喚起https://www.jpcert.or.jp/at/2020/at200048.html
II. 対象対象となるバージョンは次のとおりです。
  - OpenSSL 1.1.1 および 1.0.2 のすべてのバージョン
なお、OpenSSL Project によると OpenSSL 1.0.2、OpenSSL 1.1.0
については、既にサポートが終了しており、アップデートを受け取ることはできないため、開発者は、OpenSSL1.1.1i
へのアップグレードを推奨しています。-----------------------------これは待っていればUbuntu
20.04でもOpenSSl 1.1.1iにアップグレードされると思っていいでしょうか？
2020-10-19 (月) の 17:24 +0900 に Toshiaki Koike さんは書きました:
> 吉田さん
> ありがとうございます。ひとつ確認ですが、私が「独自にビルド」と書いたのは、ひょっとしたら誤解があるかもしれません。「問題を回避したパッチを
> あてた、本家からフォークしたソースを独自にビルド」ではなく「1.1.1fを退避して、本家（
> https://www.openssl.org/source/）よりダウンロードした1.1.1gをビルドして置き換えた」ものです。（「本家」ではすでに1.1.1hが出てますが、私が試したのは7月だったため、4/21〜9/21の間の
>  https://www.openssl.org/source/old/1.1.1/openssl-1.1.1g.tar.gz）
> その場合に、・
> www.openssl.orgから1.1.1g（あるいは1.1.1h）をダウンロードしてビルドして置き換える・ご提示いただいた(d)のいずれか
> でリスクはどんなものでしょうか？
> > (D')Ubuntu Advantageのコストを支払える（or 個人利用で数台の範囲にある）
> > 　のであれば、ESMを使って16.04を延命しつつ、(D) のための時間を稼ぐ
> 
> openssl以外にもMySQLのバージョンが8になり、過去のdumpをそのまま移行できないので検証が必要とか、php-
> gettextパッケージが無くなってるとか、今後の動作検証で気になることもあり、この選択肢の魅力も高いです。（残りのサポート期間が短くても
> 18.04にする、という選択肢のほうが若干上）
> 
> ＊個人で運用している（＝サービスを何日かとめてもさほど影響がない）自宅サーバでは18.04から20.04にアップグレードを試したのですが、
> MySQLのバージョンとphp-
> gettextにひっかかり、ownCloudの移行で失敗して（onwnCloudはいまだにOfficially Supported
> Environmentで20.04が書かれてない）結局18.04継続という経験をしてます。
> 
> 2020-10-18 (日) の 20:08 +0900 に Fumihito YOSHIDA さんは書きました:
> > > Ubuntu 20.04 ServerでのOpenSSLのバージョンは1.1.1fですが、これには
> > > curl: (35) error:141A318A:SSL routines:tls_process_ske_dhe:dh key
> > > too small
> > > というエラーが発生する問題があります。これWeb
> > > APIなどを使う際に引っかかるので、そういうのを使ってる場合は結構クリティカルです。
> > 
> > これはそもそもの問題の捉え方を変えるのが良さそうで、次のように考えていく必要がありそうです。
> > ・そもそもこの挙動は、「短い鍵長を用いた接続で警告/Error扱いされる」ように
> > 　なったというものであって、互換性に影響はあるが必ずしもバグではない。　
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907788
> > ・リスクを考慮して適切な設定で回避する（＋そもそもはサービス提供側が適切に
> > 　管理して、この問題をクライアント側に発生させないようにする）べきもので、
> > 
> > 　問題を正しく解決しないと、HTTPSである意味を壊してしまう。・その環境のライフサイクルによっては将来、真剣に危殆化する可能性がある。
> > で、独自ビルドで回避できてしまった部分は、「問題を回避した」というよりは「問題を再現できなくしてしまった」属性のもので、本来の意図と合
> > 致していない可能性がありそうな気がします。
> > で、対策としてどうするか、を考えると、次のようなものになりそうです。
> > (D) 適切な設定を行って回避する
> > 具体的には以下あたりでしょうか。
> > D-1)
> > その接続にHTTPSが必須かどうか考える。必須であれば、そのサービスは（少なくともアップデートされて適切な暗号系で処理されるようになる
> > まで）死んだものと捉え、代替サービスを探す。
> > D-2) その特定の接続だけ、DH鍵を使わない or 弱い暗号系を許容するように設定する。・curlに--ciphers
> > 'DEFAULT:!DH' を足す。・
> > https://askubuntu.com/questions/1233186/ubuntu-20-04-how-to-set-lower-ssl-security-level
> > にある、許容する暗号系を引き下げるssl.confを作って　export OPENSSL_CONF
> > する環境変数経由の設定を使う。・などなど。
> > D-3) システム全体の許容する暗号系を下げてしまう。・system wideのssl.confを更新する。
> > 　ただし正直なところ、未来に向けて地雷を作り込む処理なので非推奨　としか言いようがない。
> > なんとなくどれも、ヘタなことをすると「HTTPSを使っているつもり」状態を伴う危険なシステムを作り上げました、みたいな展開になる予感も
> > あるので、対策はそこそこ考える必要があります。腕の見せ所感はありますが、考慮するべきものを整える必要もあり、
> > (D')Ubuntu Advantageのコストを支払える（or 個人利用で数台の範囲にある）
> > 　のであれば、ESMを使って16.04を延命しつつ、(D) のための時間を稼ぐ
> > という手もありえる感じはします。（16.04のまま使っていくのも暗号系リスクを抱えることになりますが、D-
> > 3のような不適切な手当をして20.04にする、という手と本質はイコールですが、「問題が残っていることを認識しやすい」という点で圧倒的に
> > マシそうです）
> -- 
> -------------------------------------------------
> 小池利明
> t-k ＠ dive2.blue
> Toshiaki Koike
> -------------------------------------------------
-- 
-------------------------------------------------
小池利明
t-k ＠ dive2.blue
Toshiaki Koike
-------------------------------------------------
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <https://lists.ubuntu.com/archives/ubuntu-jp/attachments/20201209/fd3439f8/attachment.html>