May 2020
M T W T F S S
« Mar    
 123
45678910
11121314151617
18192021222324
25262728293031

Categories

WordPress Quotes

History is a relentless master. It has no present, only the past rushing into the future. To try to hold fast is to be swept aside.
John F. Kennedy
May 2020
M T W T F S S
« Mar    
 123
45678910
11121314151617
18192021222324
25262728293031

Short Cuts

2012 SERVER (64)
2016 windows (9)
AIX (13)
Amazon (40)
Ansibile (19)
Apache (135)
Asterisk (2)
cassandra (2)
Centos (211)
Centos RHEL 7 (270)
centos8 (3)
chef (3)
cloud (2)
cluster (3)
Coherence (1)
DB2 (5)
DISK (25)
DNS (9)
Docker (30)
Eassy (11)
ELKS (1)
EXCHANGE (3)
Fedora (6)
ftp (5)
GIT (3)
GOD (2)
Grub (1)
Hacking (10)
Hadoop (6)
health (2)
horoscope (23)
Hyper-V (10)
IIS (15)
IPTABLES (15)
JAVA (7)
JBOSS (32)
jenkins (1)
Kubernetes (7)
Ldap (5)
Linux (188)
Linux Commands (166)
Load balancer (5)
mariadb (14)
Mongodb (4)
MQ Server (24)
MYSQL (84)
Nagios (5)
NaturalOil (13)
Nginx (35)
Ngix (1)
openldap (1)
Openstack (6)
Oracle (35)
Perl (3)
Postfix (19)
Postgresql (1)
PowerShell (2)
Python (3)
qmail (36)
Redis (12)
RHCE (28)
SCALEIO (1)
Security on Centos (29)
SFTP (1)
Shell (64)
Solaris (58)
Sql Server 2012 (4)
squid (3)
SSH (10)
SSL (14)
Storage (1)
swap (3)
TIPS on Linux (28)
tomcat (62)
Ubuntu (1)
Uncategorized (30)
Veritas (2)
vfabric (1)
VMware (28)
Weblogic (38)
Websphere (71)
Windows (19)
Windows Software (2)
wordpress (1)
ZIMBRA (17)

WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.

Who's Online

0 visitors online now
0 guests, 0 bots, 0 members

Hit Counter provided by dental implants orange county

Web Server’s SSL Ciphers

How to Disable Weak SSL Protocols and Ciphers in IIS

 March 17th, 2011  Wayne Zimmerman

I recently undertook the process of moving websites to different servers here at work. This required that university networking group scan the new webserver with a tool called Nessus. Unfortunately this turned up several errors, all of them had to do with Secure Sockets Layer or SSL which in Microsoft Windows Server 2003 / Internet Information Server 6 out of the box support both unsecure protocols and cipher suites. These problems would have to be solved before they would allow the new server though the firewalls. The report they university sent me was generated by Nessus generated errors like this:

SSL Version 2 (v2) Protocol Detection

Synopsis :

The remote service encrypts traffic using a protocol with known
weaknesses.

Description :

The remote service accepts connections encrypted using SSL 2.0, which
reportedly suffers from several cryptographic flaws and has been
deprecated for several years. An attacker may be able to exploit
these issues to conduct man-in-the-middle attacks or decrypt
communications between the affected service and clients.

See also :

http://www.schneier.com/paper-ssl.pdf

http://support.microsoft.com/kb/187498

http://www.linux4beginners.info/node/disable-sslv2

Solution :

Consult the application's documentation to disable SSL 2.0 and use SSL
3.0 or TLS 1.0 instead.

Risk factor :

Medium / CVSS Base Score : 5.0
(CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:N)

Nessus ID : 20007
----------------------------------------------------------
SSL Medium Strength Cipher Suites Supported

Synopsis :

The remote service supports the use of medium strength SSL ciphers.

Description :

The remote host supports the use of SSL ciphers that offer medium
strength encryption, which we currently regard as those with key
lengths at least 56 bits and less than 112 bits.

Note: This is considerably easier to exploit if the attacker is on the
same physical network.

Solution :

Reconfigure the affected application if possible to avoid use of
medium strength ciphers.

Risk factor :

Medium / CVSS Base Score : 4.3
(CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N)

Plugin output :

Here are the medium strength SSL ciphers supported by the remote server :

Medium Strength Ciphers (>= 56-bit and < 112-bit key)
SSLv2
DES-CBC-MD5 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5
SSLv3
DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1
TLSv1
EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES(56) Mac=SHA1 export
EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export
DES-CBC-SHA Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1

The fields above are :

{OpenSSL ciphername}
Kx={key exchange}
Au={authentication}
Enc={symmetric encryption method}
Mac={message authentication code}
{export flag}

Nessus ID : 42873
--------------------------------------------------------------------
SSL Weak Cipher Suites Supported

Synopsis :

The remote service supports the use of weak SSL ciphers.

Description :

The remote host supports the use of SSL ciphers that offer either weak
encryption or no encryption at all.

Note: This is considerably easier to exploit if the attacker is on the
same physical network.

See also :

http://www.openssl.org/docs/apps/ciphers.html

Solution :

Reconfigure the affected application if possible to avoid use of weak
ciphers.

Risk factor :

Medium / CVSS Base Score : 4.3
(CVSS2#AV:N/AC:M/Au:N/C:P/I:N/A:N)

Plugin output :

Here is the list of weak SSL ciphers supported by the remote server :

Low Strength Ciphers (< 56-bit key)
SSLv2
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
SSLv3
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
TLSv1
EXP-RC2-CBC-MD5 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export
EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export

The fields above are :

{OpenSSL ciphername}
Kx={key exchange}
Au={authentication}
Enc={symmetric encryption method}
Mac={message authentication code}
{export flag}

Other references : CWE:327, CWE:326, CWE:753, CWE:803, CWE:720

Nessus ID : 26928
-----------------------------------------------------------------

These three error messages pretty much mean that you need to turn off SSL 2.0 due to exploits that were found after the standard was created. You need to turn off any encryption suites lower than 128bits. The third error message says we need to turn off anything for less than 56bits, but this will be accomplished by turning of anything less than 128bits. Basically your are modifying the settings that restrict the use of specific protocols and ciphers that are used by the schannel.dll. More detailed information can be found at Micorsoft’s KB187498 or KB245030

How do we do this?

Disabling SSL 2.0 on IIS 6

  1. Open up “regedit” from the command line
  2. Browse to the following key:
    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
  3. Create a new REG_DWORD called “Enabled” and set the value to 0
  4. You will need to restart the computer for this change to take effect. (you can wait on this if you also need to disable the ciphers)

Disable unsecure encryption ciphers less than 128bit

  1. Open up “regedit” from the command line
  2. Browse to the following key:
    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\DES 56/56
  3. Create a new REG_DWORD called “Enabled” and set the value to 0
  4. Browse to the following key:
    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC2 40/128
  5. Create a new REG_DWORD called “Enabled” and set the value to 0
  6. Browse to the following key:
    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128
  7. Create a new REG_DWORD called “Enabled” and set the value to 0
  8. Browse to the following key:
    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128
  9. Create a new REG_DWORD called “Enabled” and set the value to 0
  10. You will need to restart the computer for this change to take effect.

How to verify the changes?

Now that you have made these changes how can you be sure that they have taken place without having to go to your boss or higher authority just to find that you did them wrong. Well I found a nice tool called SSL-SCAN which you can download at http://code.google.com/p/sslscan-win/ for the Windows port or you can download an compile for your favorite operating system at the original project SSL-SCAN site http://sourceforge.net/projects/sslscan/. This tool provides some great detail about what is allows and not allows plus some analysis of the SSL certificate itself.

Below the screen shot shows that we have disabled any ciphers that attempt to use the SSL 2.0 protocol and we’ve disabled all ciphers that less than 128bit.

sslscan1-595x1024

Be Sociable, Share!

Hardening Your Web Server’s SSL Ciphers

  • ?
There are many wordy ar­ti­cles on con­fig­ur­ing your web server’s SSL ci­phers. This is not one of them. In­stead I will share a con­fig­u­ra­tion which is both com­pat­i­ble enough for today’s needs and scores a straight “A” onQualys’s SSL Server Test.

Dis­claimer: I’m up­dat­ing this post con­tin­u­ally in order to rep­re­sent what I con­sider the best prac­tice in the mo­ment – there are way too many dan­ger­ously out­dated ar­ti­cles about TLS-de­ploy­ment out there al­ready.

There­fore it may be a good idea to check back from time to time be­cause the crypto land­scape is chang­ing pretty quickly at the mo­ment. You can fol­low me on Twit­ter to get no­ti­fied about note­wor­thy changes.

If you find any fac­tual prob­lems, please reach out to me im­me­di­ately and I will fix it ASAP.

Rationale

If you con­fig­ure a web server’s SSL con­fig­u­ra­tion, you have pri­mar­ily to take care of three things:

  1. disable SSL 2.0, and – if you can afford it – SSL 3.0 (Internet Explorer 6 is the last remaining reason to keep it around; you can’t have elliptic curve crypto with SSL 3.0 and downgrade attacks exist),
  2. disable TLS 1.0 compression (CRIME),
  3. disable weak ciphers (DESRC4), prefer modern ciphers (AES), modes (GCM), and protocols (TLS 1.2).

You should also put ef­fort into mit­i­gat­ing BREACH. That’s out of scope here though as it’s largely ap­pli­ca­tion-de­pen­dent.

Software and Versions

On the server side, you should up­date your OpenSSL to 1.0.0+ so you can sup­port TLS 1.2GCM, and ECDH as soon as pos­si­ble. For­tu­nately that’s al­ready the case in the cur­rent Ubuntu LTS.

On the client side, the browser ven­dors are start­ing to catch up. As of now, Chrome 30, In­ter­net Ex­plorer 11 on Win­dows 8, Sa­fari 7 on OS X 10.9, and Fire­fox 26 sup­port TLS 1.2 (but no GCM, Chrome 32 is going to be the first one to sup­port that). Fire­fox also has TLS 1.2 dis­abled by de­fault which changed re­cently in Au­rora.

RC4

There used to be a bul­let point sug­gest­ing to use RC4 to avoid BEASTand Lucky Thir­teen. And iron­i­cally, that used to be the orig­i­nal rea­son for this ar­ti­cle: when Lucky Thir­teen came out, the word in the streets was: “use RC4 to mit­i­gate” and every­one was like “how!?”.

Un­for­tu­nately shortly there­after, RC4 was bro­ken in a way that makes de­ploy­ing TLS with it nowa­days a risk. While BEAST et al re­quire an ac­tive at­tack on the browser of the vic­tim, pas­sive at­tacks on RC4 ci­pher­text are get­ting stronger every day. In other words: it’s pos­si­ble that it will be­come fea­si­ble to de­crypt in­ter­cepted RC4 traf­fic even­tu­ally. Mi­crosoft even is­sued a se­cu­rity ad­vi­sory that rec­om­mends to dis­able RC4.

The String

Until re­cently, Qualys pre­ferred RC4 over CBC-mode ci­phers and I gave you two ci­pher strings to choose from: one that gave you an “A” but used RC4 and one that gave you a “B” but was ac­tu­ally se­cure. Since they fi­nally changed their mind – and as of Sa­fari 7 there’s no main­stream browser left that is sus­cep­ti­ble to BEAST – I can jump di­rectly to the se­cure one:

ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

You can test it against your OpenSSL in­stal­la­tion using

openssl ciphers -v 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'

to see what’s sup­ported.

You’ll get:

  • Best possible encryption in all browsers.
  • Perfect forward secrecy; if your web server, your OpenSSL, and theirbrowser support it.
  • It doesn’t offer RC4 even as a fallback. Although its inclusion at the endof the cipher string shouldn’t matter, active downgrade attacks on SSL/TLS exist and having RC4 as part of the the cipher string you potentially expose all of your users to it. Even IE 6 does 3DES just fine.

The string also prefers AES-256 over AES-128 (ex­cept for GCM which is pre­ferred over every­thing else). It does so mostly for li­a­bil­ity rea­sons be­cause cus­tomers may in­sist on it for bogus rea­sons.

How­ever quoth a cryp­tog­ra­pher:

AES-128 isn’t re­ally worse than AES-any­thin­gelse, at least not in ways you care about

So if AES-128 is fine for you, feel free to add an ‘:!AES256’ to the end of the ci­pher string to keep your ci­pher suite shorter which will also ex­pe­dite your TLS hand­shakes.

Apache

1
2
3
SSLProtocol ALL -SSLv2
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS

This works on both Apache 2.2 and 2.4. If your OpenSSL doesn’t sup­port the pre­ferred mod­ern ci­phers (like the still com­mon 0.9.8), it will fall back grace­fully but your con­fig­u­ra­tion is ready for the fu­ture.

Please note: you need Apache 2.4 for ECDH and ECDSA. You can cir­cum­vent that lim­i­ta­tion by putting an SSL proxy like stud or even nginx in front of it and let Apache serve only plain HTTP.

TLS com­pres­sion is a bit more com­pli­cated: as of Apache 2.2.23, it’s not pos­si­ble to switch it off in­side of Apache. For Apache 2.2.24+ and 2.4.3+, you can switch it off using:

1
SSLCompression Off

Cur­rently the de­fault is On, but that changed from 2.4.4 on.

The good news for Ubuntu ad­mins is that Ubuntu has back portedthat op­tion into their 2.2 pack­ages – and set it to off by de­fault – so you should be fine. The so­lu­tion on Red Hat based OS (RHEL, Fe­dora, Cen­tOS, Sci­en­tific Linux…) is set­ting an en­vi­ron­ment vari­able in­side of your Apache startup script:

1
export OPENSSL_NO_DEFAULT_ZLIB=1

nginx

1
2
3
ssl_prefer_server_ciphers On;
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS;

SSL 2.0 is off and the best pro­to­cols on by de­fault. How­ever it may be that you have some ar­ti­fact from pre-TLS 1.2 times lurk­ing some­where in your con­fig so it’s bet­ter to be ex­plicit.

TLS com­pres­sion de­pends on the ver­sion of nginx and the ver­sion of OpenSSL. If OpenSSL 1.0.0 or later is in­stalled, any­thing after nginx 1.0.9 and 1.1.6 is fine. If an older OpenSSL is in­stalled, you’ll need at least nginx 1.2.2 or 1.3.2.

For more de­tails, have a look at this server­fault an­swer.

TL;DR on TLS com­pres­sion & nginx: if you’re using Ubuntu Pre­cise (i.e. the cur­rent LTS re­lease) you’re fine (OpenSSL 1.0.1/nginx 1.1.19).

Bonus Points

Qualys up­dated their re­quire­ments on 2014-01-21 and the ci­pher suites here are still “A”–ma­te­r­ial. If you want an “A+” though, you’ll need to add HSTS head­ers too, which is out of scope for this ar­ti­cle but the linked Wikipedia ar­ti­cle will get you started.

Finally

Make sure to test your server af­ter­wards!

If you want to learn more about de­ploy­ing SSL/TLS, Qualys’s SSL/TLS De­ploy­ment Best Prac­tices are a de­cent primer.

For in­ves­ti­gat­ing the SSL/TLS be­hav­ior of your browserHow’s My SSL?will give you all the de­tails you need.

The (Near) Future

2013 has gal­va­nized the whole in­dus­try. This is a good thing. In 2012 barely any­one lost a thought about con­fig­ur­ing their TLS ci­phers, how many bits their cer­tifi­cates had, or even for­ward se­crecy. That made it way too easy for the bad folks. Nowa­days, peo­ple are ques­tion­ing their own prac­tices, open source pro­jects work on en­hanc­ing their TLS sup­port, and the pub­lic started to lis­ten to cryp­tog­ra­phers again in­stead of dis­count­ing them as crazy tin­foil crowd.

Good things are shap­ing on the hori­zon and Google’s Adam Lan­g­leygiven the power of hav­ing con­trol over both servers and the most pop­u­lar browser is press­ing ahead. Their servers widely sup­port TLS 1.2 with AES-GCM. Chrome has the best TLS sup­port al­ready. Ad­di­tion­ally, its Ca­nary re­leases now have grown sup­port for ChaCha20 which is an ex­tremely fast yet se­cure stream ci­pher by Dan Bern­stein and Poly1305a great MAC of the same pedi­gree.

Now if peo­ple just stopped using old browsers and we could roll outSNI and manda­tory TLS 1.2.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

Blue Captcha Image
Refresh

*

Protected by WP Anti Spam