自堕落な技術者の日記

 コメント一覧 (14)

1. • 1. hs
   • 2014年10月18日 10:05
   • 「その他のサーバー」で言及されているリンク先ですが、Courier-imapの設定が間違っています。
     
     Courier-imapのマニュアルや設定サンプルにはtypoがあって、
     TLS_PROTOCOL=TLS1
     TLS_STARTTLS_PROTOCOL=TLS1
     という記述は実際は、
     TLS_PROTOCOL=TLSv1
     TLS_STARTTLS_PROTOCOL=TLSv1
     とする必要があります。さらに判別できない文字列が指定された場合は"SSL23"扱いになるため、上記を"TLS1"と記述するとSSLv3でも接続できてしまいます。
     公式サイトからダウンロードしたcourier-imap 4.15のソースとopensslコマンドで確認しました。
     
     リンク先のコメント欄が閉じられてしまっているようなので、こちらにコメントさせていただきました。
2. • 2. kjur
   • 2014年10月18日 13:11
   • 情報ありがとうございました。
3. • 3. T.Takakiyo
   • 2014年10月18日 17:02
   • IBMからも情報が出ています。
     
     SSL 3.0の脆弱性に対するIBM HTTP Serverへの影響について (CVE-2014-3566)
     http://www-01.ibm.com/support/docview.wss?uid=swg21687238
     
4. • 4. kjur
   • 2014年10月18日 17:50
   • Takakiyoさん、情報ありがとうございます。
5. • 5. emk
   • 2014年10月19日 15:45
   • SSLv3を無効にする対策はクライアントが対応するだけでも効果があります。暗号スイートをRC4のみに設定するのは、SSLv3を無効にしたクライアントを危険に晒すことになります。
     TLS_FALLBACK_SCSVに対応したクライアントにとってもSSLv3へダウングレードさせられなければ他の暗号スイートを採用したほうが安全なのに、RC4のほうを優先的に緩和策として紹介するのは首をかしげざるを得ません。
     POODLE脆弱性に比べたらRC4のほうがまだ「安全」というのは五十歩百歩というほかありません。この期に及んで古いクライアントを「救済」しようとしてRC4で悪あがきするのは新しいクライアントに対して禍根を残すことになり本末転倒なので、何もしないほうがまだマシだと思います。
6. • 6. kjur
   • 2014年10月19日 23:58
   • コメントありがとうございます。
7. • 7. ura
   • 2014年10月20日 10:25
   • Tomcatでの対策ですが、Tomcat6とTomcat7ではsetEnabledProtocols(s付き)で使用するSSLプロトコルを指定できます。
     
     setProtocol="TLS"
     setEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
     
     ただし、Tomcat 6.0.37以前はsetEnabledProtocolsの代わりにsetProtocols(こちらもs付き)を使います。Tomcat7にマイナーバージョンの違いがあるかは調べていません。
     
8. • 8. takeshi
   • 2014年10月20日 14:18
   • setProtocols→sslProtocols
     setEnabledProtocols→sslEnabledProtocols
     ではないでしょうか。 > uraさん
     
     sslProtocol（sなし）は、実機で調べた限り何かしら効果を発揮しているようには見えませんでしたし、デフォルトで"TLS"ですので触れないほうが良いかなと思いました。
     
     関連バグ: https://issues.apache.org/bugzilla/show_bug.cgi?id=54691
     sslProtocols（s付き）はドキュメント化されていないので情報が錯綜しがちに思います。
9. • 9. ura
   • 2014年10月20日 14:37
   • すみません、自己訂正です。「setEnabledProtocols」でなく「sslEnabledProtocols」でした。
     下記に訂正したコメントを書いておきます。
     
     Tomcatでの対策ですが、Tomcat6とTomcat7ではsslEnabledProtocols(s付き)で使用するSSLプロトコルを指定できます。
     
     sslProtocol="TLS"
     sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"
     
     ただし、Tomcat 6.0.37以前はsslEnabledProtocolsの代わりにsslProtocols(こちらもs付き)を使います。Tomcat7にマイナーバージョンの違いがあるかは調べていません。
10. • 10. Youngdong.lee
    • 2014年10月21日 15:07
    • 
      HTTPS connector parameter sslProtocol defines which SSL/TLS protocols
      are enabled by default, e.g. for Oracle JDK 7:
      
      1) setProtocol=”TLS” will enable SSLv3 and TLSv1
      2) setProtocol=”TLSv1.2″ will enable SSLv3, TLSv1, TLSv1.1 and TLS v1.2
      3) setProtocol=”TLSv1.1″ will enable SSLv3, TLSv1, and TLSv1.1
      4) setProtocol=”TLSv1″ will enable SSLv3 and TLSv1
      5) setProtocol=”SSL” will enable SSLv3 and TLSv1
      6) setProtocol=”SSLv3″ will enable SSLv3 and TLSv1
      7) setProtocol=”SSLv2″ won’t work
      
      So, in order to restrict available protocols only to TLSv1.1, you need
      to add parameter sslEnabledProtocols=”TLSv1.1″ to your connector.
      
      Note that even if some protocol is not enabled by default, you may
      enable it by specifying sslEnabledProtocols parameter. E.g.
      
      sslProtocol=”SSL” sslEnabledProtocols=”TLSv1.1″
      
      It seems that Tomcat 6.0.32 (and probably other 6.0.xx versions) use
      undocumented attribute for HTTPS connector “protocols”.
      So in Tomcat 7 you might use:
      
      sslProtocol=”TLSv1.1″ sslEnabledProtocols=”TLSv1.1″
      
      and in Tomcat 6.0.32:
      
      sslProtocol=”TLSv1.1″ protocols=”TLSv1.1″
      
      and in Tomcat 5.x
      
      sslProtocol="TLSv1" protocols="TLSv1"
11. • 11. oporih
    • 2014年10月28日 20:43
    • SSLv3にはGCMに対応したcipher specはなかったような。
12. • 12. oporih
    • 2014年10月28日 20:53
    • 失礼しました。
      >SSLv3を 使わなければならないような環境では、GCMモードを使うこともできず
      とありますね。
      
      ＞POODLE脆弱性はSSLv3とブロック暗号のCBCブロックモードを使用した 場合に影響があるので、
      つまり、（SSLv3 AND CBC）＝　True　の場合に影響を受けるので、その対策として
      ＞認証付暗号化方式(AEAD)であるGCMブロックモードの暗号スイートを使用する
      はあまり意味がない気がしてます。
      「GCMが利用できる＝TLSv1.1以降が使用されている＝脆弱でない」なので。
      
      ・SSLv3 , TLSv1.0〜1.2を有効化
      ・CBCモードを使用する暗号方式を無効化
      ではだめなのですかね？
      
      
      
      
      
13. • 13. Cai
    • 2014年11月21日 22:54
    • PS3ですが、「SSL 3.0のみ対応」だったのが直近のアップデート（ファームウェア4.66）で「TLS 1.0のみ対応」に修正されたようです。
      更新履歴には「システムソフトウェアにおいて、動作の安定性を改善しました。」としかありませんが。
      
      しかし、対応しているcipher suiteは
      ・TLS_RSA_WITH_3DES_EDE_CBC_SHA
      ・TLS_RSA_WITH_RC4_128_SHA
      ・TLS_RSA_WITH_RC4_128_MD5
      ・TLS_RSA_WITH_DES_CBC_SHA
      ・TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
      ・TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
      ・TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
      ・TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
      ・TLS_RSA_EXPORT_WITH_RC4_40_MD5
      と泣きたくなる状況のままです……
      PS Vitaよりも貧弱ってのは何とかしてほしいものです……
14. • 14. kjur
    • 2014年11月22日 08:06
    • Caiさん、情報ありがとうございます。EXPORT系を残しているのはイカンですよねぇ。