POPS/IMAPS TLS uses weak ssl cypher encryption?

L

lkbryant

Verified User
Joined
Aug 16, 2005
Messages
283
The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all. This vulnerability is valid for all SSL/TLS sessions that are passing sensitive information.
PCI defines strong cryptography, for secret key based systems, as anything above 80 bit encryption.

Vulnerability found on port 995 and 993.


I saw 995 and 993 as pop/imap SSL .

How do i disable weak encryption on those?


I know for Apache I used:

SSLCipherSuite ALL:-ADH:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP

but what about for the pops/imaps?
 
Does anyone know the answer to this? It's pretty much illegal now for people taking credit and/or debit card details over the Internet in the UK to have this flagged up on their servers, so it's a pretty important thing to resolve. :)

On this note, DirectAdmin itself enables weak SSL ciphers in its default vhost configuration. Can I recommend adding the following to the *_secure*.conf templates and the :2222 vhost block in one of the coming updates?

Code: 
SSLProtocol -All +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:+HIGH:+MEDIUM:-LOW:!SSLv2:-EXP

The ! in front of SSLv2 and ADH removes them completely from the server config and prevents them from being re-loaded by a later directive.
 
Last edited:
Hello,

For pop3s and imaps, I googled and found:
http://wiki.dovecot.org/SSL/DovecotConfiguration
By default Dovecot v1.1+ allows all except the "LOW" and SSLv2 ciphers. See http://www.openssl.org/docs/apps/ciphers.html for a list of the ciphers. Disallowing more won't really gain any security for those using better ciphers, but it does prevent people from accidentally using insecure ciphers. You can change the cipher list with:

ssl_cipher_list = ALL:!LOW:!SSLv2
Click to expand...

For ciphers and DirectAdmin+SSL I'd have to go back to the books to read up on how to code that in c. If it's a priority for you, piping through apache+ssl to plaintext DA may be an easier solution for now.

John
 
I guess what I'm still confused about is which version of SSL should we be using.

If not v2, then what?

Thanks.

Jeff
 
SSlv3? See http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_record_protocol under "Version", TLS is the new SSL (v3.x).
Above in the same page:
The SSL protocol was originally developed by Netscape. Version 1.0 was never publicly released; version 2.0 was released in February 1995 but "contained a number of security flaws which ultimately led to the design of SSL version 3.0", which was released in 1996 (Rescorla 2001). This later served as the basis for TLS version 1.0, an Internet Engineering Task Force (IETF) standard protocol first defined in RFC 2246 in January 1999.
Click to expand...
 
Last edited:
jlasman said:
I guess what I'm still confused about is which version of SSL should we be using.

If not v2, then what?

Thanks.

Jeff
Click to expand...

SSLv3 or, preferably, TLSv1. :) Is there a way to change the cipher suite used by DirectAdmin itself? Our PCIDSS compliance scanner is currently flagging it up as a failure. :( Does DirectAdmin have its own httpd.conf hidden somewhere in amongst all the files in /usr/local/directadmin, or does it not tie in with Apache to serve the control panel?
 
Last edited:
DirectAdmin Support said:
For ciphers and DirectAdmin+SSL I'd have to go back to the books to read up on how to code that in c. If it's a priority for you, piping through apache+ssl to plaintext DA may be an easier solution for now.

John
Click to expand...

Hmm... Not entirely sure how to do that without having the plain-text port accessible. Any suggestions?
 
Just noticed another DirectAdmin-related one on the latest scan:

Missing Secure Attribute in an Encrypted Session (SSL) Cookie

Description:
The application sets a cookie over a secure channel without using the "secure" attribute. RFC states that if the cookie does not have the secure attribute assigned to it, then the cookie can be passed to the server by the client over non-secure channels (http). Using this attack, an attacker may be able to intercept this cookie, over the non-secure channel, and use it for a session hijacking attack.

General solution:
It is best business practice that any cookies that are sent (set-cookie) over an SSL connection to explicitly state secure on them.
Click to expand...

This is easy to fix as you just need to set the https-only flag on the session cookie when you send it. :) This prevents people taking advantage of any potential XSS issues (there's at least one, even if no-one's found it yet. There's always one.) to nab the logged-in user's session cookie and get in to the server that way.
 
Hello,

I couldn't find any flags for "https-only", but I did find the "secure" cookie flag and added it to the end of the Set-Cookie line for secure connections. Avaialble for the next release. If you'd like to test it now, email me your OS version and I can create some binaries for you (to make sure it passes the tests you're using)

John
 
DirectAdmin Support said:
Hello,

I couldn't find any flags for "https-only", but I did find the "secure" cookie flag and added it to the end of the Set-Cookie line for secure connections. Avaialble for the next release. If you'd like to test it now, email me your OS version and I can create some binaries for you (to make sure it passes the tests you're using)

John
Click to expand...

Apologies. I meant the secure attribute. :) There's a http-only attribute which prevents a cookie being sent over a secure connection, and I got the names mixed up.

I think we'll wait until this is pushed through the auto-update system; the server's now in constant use, and I don't want to risk breaking it (again :s).

Thanks. :)
 
You must log in or register to reply here.
Back
Top