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_list@xxxxxxxxxxx
<mailto:david_list@xxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxxxx
<mailto:389-users@xxxxxxxxxxxxxxxxxxxxxxx>
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
