パスワードを忘れた? アカウント作成
14238244 story
セキュリティ

IPA、TLS暗号設定ガイドラインの第3.0版を公開 31

ストーリー by nagazou
猶予期間の終わり 部門より
情報処理推進機構(IPA)が、7月7日に「TLS暗号設定ガイドライン第3.0版」を発表した。2018年5月の第2.0版から約2年ぶりの改訂となる。第2.0版移行のタイミングで設定されたSSL/TLS通信の規格化や、技術環境の変化を反映した内容になっている。

このほかSSL3.0を利用禁止としたほか、TLSバージョン1.0および1.1(TLS 1.0/1.1)の無効化を推奨しているとのこと(TLS暗号設定ガイドライン~安全なウェブサイトのために(暗号設定対策編)~日経過去記事)。
  • by Anonymous Coward on 2020年07月13日 15時53分 (#3850983)

    プライバシーとセキュリティ
    プロファイル
    [IPA TLS暗号設定ガイドライン第3.0版 ▼]

    みたいにプロファイルで推奨セキュリティ設定にできるみたいな機能あってもよさそう。
    実際便利かと言えばピンと来ないけど。
    組織運用するならグループポリシー的な奴の方が良さそうだし。

    ここに返信
    • by Anonymous Coward

      プロファイルで推奨セキュリティ設定にできるみたいな機能あってもよさそう。

      サーバー設定もそうありたいものです
      アプリケーションはパッケージインストールが普及しても
      未だにconf手修正が基本だったり

      うまいやりようはあるけどそれは個々人で頑張って!
      できなきゃCipher suiteも手書きでがんばんな!
      みたいな仕様はいい加減時代遅れにもほどがあるなぁと

      • まあ、なるべくなら https://ssl-config.mozilla.org/ [mozilla.org] とかから基本を生成するように、とか

        自衛するしかないかな...?

        --
        M-FalconSky (暑いか寒い)
      • by Anonymous Coward on 2020年07月13日 16時56分 (#3851024)

        若干違うような気もしますが、RedHat系のGNU/Linuxディストリビューションだとupdate-crypto-policiesコマンドで主要なソフトウェアにおける暗号スイートの設定を一括変更できます。

        https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux... [redhat.com]

      • by Anonymous Coward

        IPAが例示している内容に従うと、例えばApacheなりのConfに下記のような感じで追加すればいいの?
        たしかに厳しい・・・。

        SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-CCM:DHE-RS

        • by Anonymous Coward

          IIS用だとIIS Crypto [nartac.com]という3rd-partyのGUI設定ツールがあります。

          • by Anonymous Coward

            確かに、このツールを使ってレジストリ吐いてサーバーに貼り付ければ作業自体は楽そう。
            # 手元の環境だと、Applyしてもレジストリに変化が見られないのが・・・?

            当たり前だけど、Best Practice ボタンが IPA の定義とは異なるので、やっぱりそれなりの検討が必要そう。

    • by Anonymous Coward

      プライバシーとセキュリティ
      プロファイル
      [IPA TLS暗号設定ガイドライン第3.0版 🖤]

      に見えてしまったorz

  • by Anonymous Coward on 2020年07月13日 17時36分 (#3851052)

    サポートが打ち切られたAndroid(4.4ぐらい)なので殆どのユーザーには関係ない話。
    TLS1.2のみにしても困らない。
    問題はTLS1.3についてだが、IEと旧Edgeはサポートしていない。特にIE利用者は滅ぼさないといけない。

    ここに返信
    • by Anonymous Coward

      Darwin/19.5.0 の webdav クライアントがTLSv1なんだなー。

    • by Anonymous Coward

      > IEと旧Edgeはサポートしていない。

      「TLS 1.3を使用する(試験段階)」」という項目がインターネットオプションにあるけど? まあ今のところデフォルト無効だし、旧Edgeを捨てたからにはずっと試験段階でデフォルト無効のままかもしれないけど

      • by Anonymous Coward

        その「インターネットオプション」はIE・旧EdgeというかOSレベルの設定
        WindowsでのTLS 1.3サポートはまだまだテスト段階の模様

        Microsoft TLS 1.3 Support Reference
        https://devblogs.microsoft.com/premier-developer/microsoft-tls-1-3-sup... [microsoft.com]
        > Will TLS 1.3 be supported in Windows 10 and Server?
        >
        > TLS 1.3 is also supported on Windows 1903 as of release of this article for testin

        • by Anonymous Coward

          IE・旧EdgeはOSレベルのSSL接続機能(schannel)をそのまま使ってるからね。新EdgeはOSの機能に頼らずChromiumが採用しているライブラリ(BoringSSL)をそのまま使っているのか

  • by Anonymous Coward on 2020年07月13日 16時33分 (#3851009)

    基本的に新しめで安全な方式を優先でいいが、
    古いのを禁止までする必要があるのか疑問

    サーバの秘密鍵が漏れるような脆弱性がないかぎり、
    別に禁止までする必要は無いでしょ?

    ここに返信
    • by Anonymous Coward

      6年前、まさに秘密鍵が漏れるような脆弱性があったんだよなぁ

      • by Anonymous Coward

        DROWN脆弱性ね、と思ったら4年前(2016年)だな。他になんかあったっけ?

        • by Anonymous Coward

          BEASTとかPOODLEとかHeartbleedが2013-2014年頃

          • by Anonymous Coward

            Heartbleedは古いプロトコルを有効にしていたことが原因ではない気がするし(むしろセキュリティプロトコルに新機能をむやみに導入してバグ入れた感じ)、BEASTやPOODLEは「有効にしているだけで秘密鍵が漏れる」脆弱性ではないような

    • by Anonymous Coward

      さすがに単に古すぎるからなんて理由で「非推奨」とは別にわざわざ「禁止」カテゴリを作ったりはしない

    • by Anonymous Coward

      SSL 3.0について言えば、POODLE攻撃により部分的であれど解読できることが判明しているのだから、禁止するのが妥当ではないでしょうか?

      • by Anonymous Coward

        自己レス、POODLEはCBCの場合だけでしたね。とは言え、SSL 3.0からCBCを取り除くとRC4を使う暗号スイート(またはNULL)しか残らず、SSL 3.0で安全な通信はもはや達成できないということになるかと思います。

    • by Anonymous Coward

      脆弱性の修正などでWebブラウザは新しいものに更新し続ける必要のあるものですから、古いものを残し続けるメリットなんてほとんど無いように思います。
      更新の止まっている環境は、使うこと自体が危険なので、リプレースが必要でしょう。

    • by Anonymous Coward

      このようなガイドラインを出されても読まない文盲で傲慢の老害に、TLS等のセキュリティ設定の重要さを分からせるために、どう説得するのか、IPAはどのような情報を発信するべきだろうか。

      という意味ですね。まさか本気で言っている訳ないですよね。

  • by Anonymous Coward on 2020年07月13日 19時49分 (#3851156)

    https://www.ssllabs.com/ssltest/ [ssllabs.com]みたいなチェック機能があればいいのになぁ、と思いました。

    ここに返信
  • by Anonymous Coward on 2020年07月13日 21時32分 (#3851217)

    TLS1.4

    セキュリティ関連の人はいみはわかるね?

    ここに返信
  • by Anonymous Coward on 2020年07月13日 23時31分 (#3851290)

    折角こんな資料だしてくれても肝心のシステム管理者や構築に携わる人間が読んでくれない。
    というか今時TLSとSSLの区別も出来ないの連中も・・・
    皆様並びに周りではどういう層が読んでます?

    1.2本書が対象とする読者本ガイドラインでは、主にWebにTLSを利用するシステムを対象に、TLSサーバを実際に構築するにあたって具体的な設定を行うサーバ構築者、実際のサーバ管理やサービス提供に責任を持つことになるサーバ管理者、並びにTLSサーバの構築を発注するシステム担当者を想定読者としている。

    ここに返信
    • by Anonymous Coward on 2020年07月14日 8時51分 (#3851414)

      システム運用関係者はみんな読んでる。
      1.0/1.1 が撲滅できたと思ったら、
      昨今のテレワークで泣く泣く復活...

    • by Anonymous Coward

      セキュリティエンジニア的には「TLS 1.0/1.1は無効にしましょう」と提案することでお賃金が出るので読むけど。
      一般的にはTLSとSSLの区別ができなくても困ることは無いし、サーバ設定する時にググって参考になればそれでいい。
      読んでくれないことを悲観視するのはIPAの中の人くらいでは?

    • by Anonymous Coward

      >というか今時TLSとSSLの区別も出来ないの連中も・・・

      これはバージョンが違うだけなので専門家でもない限り理解できなくても仕方ない。
      むしろ名前を変えた奴(と、TLSを4から始めなかった奴)が悪い。

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...