Re: [389-users] How relevant is Poodlebleed Bug to 389?
You probably want to disable SSLv3 on the admin server too. Add the following line to /etc/dirsrv/admin-serv/console.conf: NSSProtocol TLSv1.0,TLSv1.1 Documentation here: https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html Regarding the directory server, I didn't find nsTLS1 under cn=encryption,cn=config, but setting nsSSL3: off did the trick, the openldap command line tools, the 389ds-console and sssd still works. (We have nsslapd-minssf: 128 in cn=config). You can test like this: openssl s_client -connect hostname:389 -ssl3 openssl s_client -connect hostname:636 -ssl3 openssl s_client -connect hostname:9830 -ssl3 If the above commands says something like: 140183413589832:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: New, (NONE), Cipher is (NONE) Then SSLv3 is disabled. If the s_client output looks like this: New, TLSv1/SSLv3, Cipher is AES128-SHA and it's waiting for input, then SSLv3 is enabled! Have a nice day, Paul On 2014-10-15 20:20, Rich Megginson wrote: On 10/15/2014 12:34 PM, Michael Gettes wrote: Hi David (et al), what is the right way to do this in the DS? (i am on 1.2.11.32) i see under cn=config there is cn=encryption and there are nsSSL3Ciphers and nsSSLSupportCiphers (lots of these). The documentation just shows the simple on/off for SSL/TLS. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsssl3ciphers and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL2 and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL3 and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsTLS1 You might be able to just set nsSSL2: off and nsSSL3: off and nsTLS1: on For me, my admin server has SSL on but it is behind a firewall so I am not concerned with adjusting it. Thanks for pointers. /mrg On Oct 15, 2014, at 12:12 PM, David Boreham david_l...@boreham.org mailto:david_l...@boreham.org wrote: On 10/15/2014 8:16 AM, Jan Tomasek wrote: is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. From http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 : Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support? The current attack vector as shown by the researchers works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser. Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and the do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable. Conclusion: disable SSLv3 for HTTPS *now*, disable SSLv3 for other services in your next service window. -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
On 10/17/2014 02:55 AM, Paul Tobias wrote: You probably want to disable SSLv3 on the admin server too. Add the following line to /etc/dirsrv/admin-serv/console.conf: NSSProtocol TLSv1.0,TLSv1.1 Documentation here: https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html Regarding the directory server, I didn't find nsTLS1 under cn=encryption,cn=config, It is not in dse.ldif by default, but if you do an ldapsearch you should see it. It is on by default which is why it worked. The recommendation is to ldapmodify -x -D cn=directory manager -w 'password' EOF dn: cn=encryption,cn=config changetype: modify replace: nsSSL3 nsSSL3: off - replace: nsTLS1 nsTLS1: on - EOF Then restart dirsrv but setting nsSSL3: off did the trick, the openldap command line tools, the 389ds-console and sssd still works. (We have nsslapd-minssf: 128 in cn=config). You can test like this: openssl s_client -connect hostname:389 -ssl3 openssl s_client -connect hostname:636 -ssl3 openssl s_client -connect hostname:9830 -ssl3 If the above commands says something like: 140183413589832:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337: New, (NONE), Cipher is (NONE) Then SSLv3 is disabled. If the s_client output looks like this: New, TLSv1/SSLv3, Cipher is AES128-SHA and it's waiting for input, then SSLv3 is enabled! Have a nice day, Paul On 2014-10-15 20:20, Rich Megginson wrote: On 10/15/2014 12:34 PM, Michael Gettes wrote: Hi David (et al), what is the right way to do this in the DS? (i am on 1.2.11.32) i see under cn=config there is cn=encryption and there are nsSSL3Ciphers and nsSSLSupportCiphers (lots of these). The documentation just shows the simple on/off for SSL/TLS. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsssl3ciphers and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL2 and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsSSL3 and https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Core_Server_Configuration_Reference.html#cnencryption-nsTLS1 You might be able to just set nsSSL2: off and nsSSL3: off and nsTLS1: on For me, my admin server has SSL on but it is behind a firewall so I am not concerned with adjusting it. Thanks for pointers. /mrg On Oct 15, 2014, at 12:12 PM, David Boreham david_l...@boreham.org mailto:david_l...@boreham.org wrote: On 10/15/2014 8:16 AM, Jan Tomasek wrote: is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. From http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 : Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support? The current attack vector as shown by the researchers works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser. Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and the do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable. Conclusion: disable SSLv3 for HTTPS *now*, disable SSLv3 for other services in your next service window. -- 389 users mailing list 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
update… this advice (quoted below) ended up being the simplest path to take. Please note on none of my DS was nsTLS1 an existing attribute so I had to add this attribute to the cn=encryption,cn=config object. I had to do a “service dirsrv restart” as doing a restart from console would only stop but not start (i haven’t had time to figure out why this was the case but i suspect it had something to do with interactions with the admin server and a change of SSL types on the DS). Thanks so much for the quick and extremely useful advice. /mrg On Oct 15, 2014, at 3:20 PM, Rich Megginson rmegg...@redhat.com wrote: You might be able to just set nsSSL2: off and nsSSL3: off and nsTLS1: on -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
[389-users] How relevant is Poodlebleed Bug to 389?
Hello, is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. I've found: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html but new syntax with -SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesn't seem to be working on my system: ldap-dev:~# yum list installed |grep 389 389-admin.x86_64 1.1.29-1.el5 389-admin-console.noarch 1.1.8-1.el5 389-admin-console-doc.noarch 1.1.8-1.el5 389-adminutil.x86_64 1.1.20-1.el5 389-console.noarch1.1.7-3.el5 389-ds.noarch 1.2.1-1.el5 389-ds-base.x86_641.2.11.28-1.el5 389-ds-base-devel.x86_64 1.2.11.28-1.el5 389-ds-base-libs.x86_64 1.2.11.28-1.el5 389-ds-console.noarch 1.2.6-1.el5 389-ds-console-doc.noarch 1.2.6-1.el5 389-dsgw.x86_64 1.1.11-1.el5 I'm running on CentOS 5 with EPEL sources. Thanks -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
On 10/15/2014 08:16 AM, Jan Tomasek wrote: Hello, is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. I've found: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html but new syntax with -SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesn't seem to be working on my system: The new syntax might not yet be supported on 1.2.11 (el5) https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html ldap-dev:~# yum list installed |grep 389 389-admin.x86_64 1.1.29-1.el5 389-admin-console.noarch 1.1.8-1.el5 389-admin-console-doc.noarch 1.1.8-1.el5 389-adminutil.x86_64 1.1.20-1.el5 389-console.noarch1.1.7-3.el5 389-ds.noarch 1.2.1-1.el5 389-ds-base.x86_641.2.11.28-1.el5 389-ds-base-devel.x86_64 1.2.11.28-1.el5 389-ds-base-libs.x86_64 1.2.11.28-1.el5 389-ds-console.noarch 1.2.6-1.el5 389-ds-console-doc.noarch 1.2.6-1.el5 389-dsgw.x86_64 1.1.11-1.el5 I'm running on CentOS 5 with EPEL sources. Thanks -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
Hello, On 10/15/2014 04:58 PM, Rich Megginson wrote: is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. By not commenting this, I assume that. Yes. This bug is relevant even to 389. I've found: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html but new syntax with -SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA doesn't seem to be working on my system: The new syntax might not yet be supported on 1.2.11 (el5) https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_SSL-Setting_Security_Preferences.html For 1.2.11.28-1.el5 I've succeeded with this setting: nsSSL2: off nsSSL3: off nsSSL3Ciphers: +all, -rsa_rc4_40_md5, -rsa_rc2_40_md5, -rsa_des_sha, -dhe_dss_des_sha, -rsa_rc4_128_md5, -fortezza_rc4_128_sha, -tls_dhe_dss_rc4_128_sha, -tls_rsa_export1024_with_rc4_56_sha, -tls_dhe_dss_1024_rc4_sha, -tls_dhe_rsa_aes_128_sha, -tls_dhe_dss_aes_128_sha Thanks -- --- Jan Tomasek aka Semik http://www.tomasek.cz/ -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
On 10/15/2014 8:16 AM, Jan Tomasek wrote: is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. From http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 : Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support? The current attack vector as shown by the researchers works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser. Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and the do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable. Conclusion: disable SSLv3 for HTTPS*now*, disable SSLv3 for other services in your next service window. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Re: [389-users] How relevant is Poodlebleed Bug to 389?
Hi David (et al), what is the right way to do this in the DS? (i am on 1.2.11.32) i see under cn=config there is cn=encryption and there are nsSSL3Ciphers and nsSSLSupportCiphers (lots of these). The documentation just shows the simple on/off for SSL/TLS. For me, my admin server has SSL on but it is behind a firewall so I am not concerned with adjusting it. Thanks for pointers. /mrg On Oct 15, 2014, at 12:12 PM, David Boreham david_l...@boreham.org wrote: On 10/15/2014 8:16 AM, Jan Tomasek wrote: is http://poodlebleed.com/ related to 389? I think it is, this is not implementation flaw in OpenSSL, this seems to be related to the SSLv3 design. From http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566 : Is it relevant for HTTPS only or also for IMAP/SMTP/OpenVPN and other protocols with SSL support? The current attack vector as shown by the researchers works with controlling the plaintext sent to the server using Javascript being run on the victim's machine. This vector does not apply to non-HTTPS scenarios without using a browser. Also, normally an SSL client doesn't allow the session to be downgraded to SSLv3 (having TLSv1+ seen in the handshake capabilities), but browsers want to be very backward compatible and the do. The combination with controlling plaintext and the specific way a HTTP header is built up makes it exploitable. Conclusion: disable SSLv3 for HTTPS now, disable SSLv3 for other services in your next service window. -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
