Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Scan revealed weak ssl cipher.

I'm new to these ESAs C170s and one of our guys ran a scan and it came up with "SSL weak cipher vulnerability".

Looking in the GUI under System Administration > SSL Configuration I see SSL v3 enabled.

Also via the CLI:

sslconfig settings:
GUI HTTPS method: sslv3tlsv1/tlsv1.2
GUI HTTPS ciphers:
RC4-SHA
RC4-MD5
ALL
-aNULL
-EXPORT
Inbound SMTP method: sslv3tlsv1/tlsv1.2
Inbound SMTP ciphers:
RC4-SHA
RC4-MD5
ALL
-aNULL
-EXPORT
Outbound SMTP method: sslv3tlsv1/tlsv1.2
Outbound SMTP ciphers:
RC4-SHA
RC4-MD5
ALL
-aNULL
-EXPORT

So it looks like these are the default settings of the C170.  I've come across numerous articles that state SSL v3 should be disabled and only to run the following to set all three interfaces, (GUI HTTPS, Inbound SMTP:, Outbound SMTP):

MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:
-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

Per the tech note here:
http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117855-technote-esa-00.html

So since I'm new to this, I'm assuming I can uncheck SSL v3 in the GUI interface and also just put in the string in the GUI interface for all 3 SSL Ciphers to use: MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

So in the end my config should look like this screenshot?
http://www.cisco.com/c/dam/en/us/support/docs/security/email-security-appliance/117864-configure-esa-02.png

Any risk of disabling SSL v3 and adding the above cipher command as shown exactly like the screenshot above?

1 ACCEPTED SOLUTION

Accepted Solutions
New Member

We just had a TAC opened a

We just had a TAC opened a couple of weeks ago about the same issue.  This is what was recommended from TAC:

GUI HTTPS:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: MEDIUM:HIGH:-SSLv2:-aNULL:!RC4:-EXPORT:@STRENGTH


Inbound SMTP:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: EDH+TLSv1.2:ECDH+TLSv1.2:EDH+HIGH:EDH+MEDIUM:ECDH+HIGH:ECDH+MEDIUM:HIGH:MEDIUM:!LOW:!EXP:!aNULL:!RC4:!DSS:!SEED:!IDEA:!MD5:!PSK:!3DES:!SRP


Outbound SMTP:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: EDH+TLSv1.2:ECDH+TLSv1.2:EDH+HIGH:EDH+MEDIUM:ECDH+HIGH:ECDH+MEDIUM:HIGH:MEDIUM:!LOW:!EXP:!aNULL:!RC4:!DSS:!SEED:!IDEA:!MD5:!PSK:!3DES:!SRP

21 REPLIES
Cisco Employee

Only risk would be the

Only risk would be the senders that would still only be sending at SSL v3 -- but, in this day and age, you are protecting yourself, rather than relying on others to be secure.

SSL v3 took a major decline after heartbleed and other vulnerability headaches from last year or so.  With our current defaults, we do not have SSL v3 enable --- only relying on TLS v1, TLS v1.2.

-Robert

New Member

What is the risk of changing

What is the risk of changing the default cipher strength from:

RC4-SHA:RC4-MD5:ALL:-aNULL:-EXPORT

TO:
MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

Cisco Employee

I see no adverting risk.  You

I see no adverting risk.  You would be just setting the ciphers to use all medium and high strength ciphers, and then not allowing the ones as singled out.

(And of course not allowing null, and preferring strength before weaker)...

You can review the mail_logs to see in time period after change if there were any dropped/not allowed messages due to the ciphers set.  Hopefully senders will be smart enough to be sending properly.

Only risk again is someone sending at one of the disallowed singled out ciphers -- but, again, security on your own side before allowing weaker/threat from outside.

-Robert

New Member

The ciphers in question

The ciphers in question (generated by reporting to have weak SSL ciphers) were the following:
SSL3_RSA_RC4_128_MD5
SSL3_RSA_RC4_128_SHA
SSL3_RSA_WITH_SEED_SHA
SSL3_EDH_RSA_DES_64_CBC_SHA
SSL3_RSA_DES_64_CBC_SHA
TLS1_RSA_RC4_128_MD5
TLS1_RSA_RC4_128_SHA
TLS1_EDH_RSA_DES_64_CBC_SHA
TLS1_RSA_DES_64_CBC_SHA

If I wanted to add all those to the "NOT ALLOWED" list of ciphers to be used I would just add them like this -RSA_DES_64_CBC_SHA:-EDH_RSA_DES_64_CBC_SHA:-RSA_RC4_128_SHA and so on by removing the first 5 characters from each?

Cisco Employee

Correct.

Correct.

From the following, Alter the Methods and Ciphers Used with SSL/TLS on the ESA

Any of the SSL ciphers that you do not want configured and available should be removed with the "-" option that precedes the specific ciphers. Here is an example:

 

[]> MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:
-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA

 

The information in this example would negate the NULLEDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, and DES-CBC3-SHAciphers from advertisement and prevent their use in the SSL communication.

 

You can also accomplish similar with the inclusion of the "!" character in front of the cipher group or string that you desire to become unavailable:

 

[]> MEDIUM:HIGH:-SSLv2:-aNULL:!RC4:@STRENGTH

 

The information in this example would remove all of the RC4 ciphers from use. Thus, the RC4-SHA and RC4-MD5 ciphers would be negated and not advertised in the SSL communication.

 

If changes are made to the SSL configuration, ensure that you commit any and all changes.

And from earlier portion of the thread ---

Tip: Secure Sockets Laver (SSL) Version 3.0 (RFC-6101) is an obsolete and insecure protocol. There is a vulnerability in SSLv3 CVE-2014-3566 known as Padding Oracle On Downgraded Legacy Encryption (POODLE) attack, which is tracked by Cisco bug ID CSCur27131 . Cisco recommends that you disable SSLv3 while you change the ciphers, use Transport Layer Security (TLS) only, and select option 3 (TLS v1). Refer to Cisco bug ID CSCur27131  for complete details.

The above note/tip is from, Prevent Negotiations for Null or Anonymous Ciphers on the ESA and SMA

New Member

Thank you for your help.  I'm

Thank you for your help.  I'm going to play around with the GUI SSL section first and run our scans against that and then change the INBOUND and OUTBOUND when I get the scan to come through clean.

New Member

I tried to append the string

I tried to append the string on the GUI interface like this and it didn't like the underscores.  Do I just replace the underscores with dashes?

MEDIUM:HIGH:-SSLv2:-aNULL:@STRENGTH:-EDH-RSA-DES-CBC3-SHA:-EDH-DSS-DES-CBC3-SHA:-DES-CBC3-SHA:-RSA_RC4_128_MD5:-RSA_RC4_128_SHA:-RSA_WITH_SEED_SHA:-EDH_RSA_DES_64_CBC_SHA:-RSA_DES_64_CBC_SHA:-RSA_RC4_128_MD5:-RSA_RC4_128_SHA:-EDH_RSA_DES_64_CBC_SHA:-RSA_DES_64_CBC_SHA

I'm not familiar with ciphers.  The below list is what exactly shot out from the report.  Do I just cut off the SSL3_ and put the rest in along with substituting the underscores with dashes?
SSL3_RSA_RC4_128_MD5
SSL3_RSA_RC4_128_SHA
SSL3_RSA_WITH_SEED_SHA
SSL3_EDH_RSA_DES_64_CBC_SHA
SSL3_RSA_DES_64_CBC_SHA
TLS1_RSA_RC4_128_MD5
TLS1_RSA_RC4_128_SHA
TLS1_EDH_RSA_DES_64_CBC_SHA
TLS1_RSA_DES_64_CBC_SHA

Do I need to find an open SSL equivalent like here and input that instead?

I've read the cisco docs but it doesn't help me since all I have to go off is a printout someone gave me with the info above.  I need to know if the above need to be converted or just cut off the first 5 characters and replace the underscores with dashes.

Yes, you should the OpenSSL

Yes, you should the OpenSSL equivalents... I think the "ssl3" and "tls1" are what's breaking it for you.

I'd probably start with unchecking the SSLv3 box, and then using something like this below, and then testing again:

!aNULL:!eNULL:!SSLv2:!SSLv3:!EXP:!RC4:MEDIUM:HIGH:@STRENGTH

No auth null ciphers

No encryption null cyphers

No ssl2, ssl3, export, or RC4...

The ! means, they can't be added back in, no matter what gets appended. (some upgrades to Ironports will append to the ssl list)

add medium and high, sort by strength...

That ought to be more sane and maintainable...

New Member

I only have TLS v1/TLS v1.2

I only have TLS v1/TLS v1.2 checked  for GUI, Inbound, and Outbound.  With your statement above, will that filter out the TLS1_ ciphers I listed as a vulnerability or do I have to find OpenSSL equivalents for the following:

TLS1_RSA_RC4_128_MD5
TLS1_RSA_RC4_128_SHA
TLS1_EDH_RSA_DES_64_CBC_SHA
TLS1_RSA_DES_64_CBC_SHA

Are the first 2 above the same as this?

TLS_RSA_WITH_RC4_128_MD5                RC4-MD5
TLS_RSA_WITH_RC4_128_SHA                RC4-SHA

So I would just put a :-RC4-MD5:-RC4-SHA at the end of your statement?

I really don't want to break mail flow.

New Member

We just had a TAC opened a

We just had a TAC opened a couple of weeks ago about the same issue.  This is what was recommended from TAC:

GUI HTTPS:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: MEDIUM:HIGH:-SSLv2:-aNULL:!RC4:-EXPORT:@STRENGTH


Inbound SMTP:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: EDH+TLSv1.2:ECDH+TLSv1.2:EDH+HIGH:EDH+MEDIUM:ECDH+HIGH:ECDH+MEDIUM:HIGH:MEDIUM:!LOW:!EXP:!aNULL:!RC4:!DSS:!SEED:!IDEA:!MD5:!PSK:!3DES:!SRP


Outbound SMTP:

Methods: TLS v1/TLS v1.2
SSL Cipher(s) to use: EDH+TLSv1.2:ECDH+TLSv1.2:EDH+HIGH:EDH+MEDIUM:ECDH+HIGH:ECDH+MEDIUM:HIGH:MEDIUM:!LOW:!EXP:!aNULL:!RC4:!DSS:!SEED:!IDEA:!MD5:!PSK:!3DES:!SRP

New Member

do you know what that string

do you know what that string for inbound and outbound means?

EDH TLS1.2 allowed
ECDH TLS1.2 allowed
EDH high allowed
EDH medium allowed
ECDH high allowed
ECDH medium allowed
HIGH and MEDIUM allowed
low disabled
export disabled
auth null disabled
all others listed disabled

Does that sum that up???

Yes, your summary looks to be

Yes, your summary looks to be accurate.

New Member

why not add :!SSLv2:!SSLv3 to

why not add :!SSLv2:!SSLv3 to the inbound and outbound that Doug posted as well just to make sure they are not used (even though I have them unchecked)

New Member

Doug - Thank you very much.

Doug - Thank you very much.  We made the same changes and our scan came back clean now.

New Member

Just an update.  We had to

Just an update.  We had to add back in :DES on our Outbound SMTP.  Had a mail server that we could not sent to and they wouldn't check their ciphers.  What security cipher impact will I have by allowing DES again.

Thanks,

Doug

New Member

I've had 4 external companies

I've had 4 external companies I've had to work with now due to "no shared cipher" problems.  Most all of them were running Exchange 2007 on Server 2003.  

Having them run this patch will enable them to handshake using AES128-SHA or AES256-SHA

https://support.microsoft.com/en-us/kb/948963

I'm seeing the following when they send to my Gmail account:

version=TLS1 cipher=DES-CBC3-SHA bits=112/168
Highlighted
New Member

I'll give that a shot.  Not

I'll give that a shot.  Not sure of what the other system is running.  The person I'm dealing with is "hell bent" on it's a Cisco problem not be able to "train down" from TLS1.2 to TLSv1.  Tried to explain many times that it was a cipher problem, but got the typical "My system, my rule" game.

New Member

Normally what I've been doing

Normally what I've been doing is grepping the ip address and then doing a grep on the icid and it will show a "no shared cipher" error.  I take a sceenshot and email it to them.  Most of the time that works.

New Member

The error that I was seeing

The error that I was seeing in my logs was "Network Error".  As soon as I put in 3DES in my ciphers, I was able to send TLS to them.  I don't want to have 3DES in the cipher as the one that I was using was very secure.  Just trying to find out the impact of have 3DES on.

New Member

I did see those errors as

I did see those errors as well but also saw the "no shared cipher" error.  I'm a cipher newb and don't know much about all this stuff.  Still learning.

SSLLabs has a document and it states:

3DES provides about 112 bits of security. This is below the recommended minimum of 128 bits, but it’s still strong enough. A bigger practical problem is that 3DES is much slower than the alternatives. Thus, we don’t recommend it for performance reasons, but it can be kept at the end of the cipher list for interoperability with very old clients.

New Member

Thanks for the info.  No

Thanks for the info.  No expert on ciphers either.  I know that I was able to pass our PCI testing with the ciphers that I posted here.  Not sure now what's going to happen on the next scan.  Probably have to create an exception, which sucks.

I have it at the end of my allowed ciphers, but until this other site upgrades the mail product so that it supports TLS1.2 or better ciphers, I guess I'm stuck having 3DES for now.

1155
Views
0
Helpful
21
Replies
CreatePlease login to create content