I’ve seen a lot of excellent guides around on optimising SSL parameters on NetScaler which is awesome. A lot of them are geared towards obtaining the coveted A+ rating from Qualsys’ excellent SSLLabs test which I think is important as it gives people an easy way to ensure they are compliant to certain level in a world where the goalposts are frequently rapidly moving even if only their SSL settings.
Because there are so many guides out there I was reluctant to write one myself but as you can tell I have.
I also wanted to provide some background as to why we are making these decisions as I have experienced a lot of people blinding following guides but not really having any idea why it is they’re doing what they’re doing which is, I think, quite dangerous. So here we are, if you find it useful, cool, if not, contact me for a full refund.
It’s important to say that I am not some kind of SSL wizard, I’m just someone who’s spent a lot of time working with and thinking about SSL for lots of different customers with sometimes vastly different requirements.
When and what to encrypt
This may seem fairly obvious but the first step on your journey to good encryption determining what is it you want to encrypt. Personally I would advise that you encrypt the communication of any data you wouldn’t be happy to shout out loud in a room full of strangers or tattoo on your forehead but probably more realistically at an absolute minimum you need to ensure that sensitive and exploitable data be encrypted such as personal data, user credentials, payment information, intellectual property.. the list is endless. Thankfully the concept of Always On SSL (AOSSL) has become commonplace bringing upon us an expectation of encryption no matter what data we and sending or receiving.
As we all know implementing encryption for any service will increase the overhead and impact performance as not only do you need to serve the content to the user, your system needs to both encrypt and decrypt communication.
This is obviously where we can implement NetScaler SSL Offload to absorb the resource overhead of processing the large numbers of SSL sessions established by your vast user base greatly decreasing the amount of work required on your back end servers, the ones actually providing the service for the user leaving it free to perform optimally.
Obviously if we are offloading all our front end SSL workload to the NetScaler we need to ensure that our SSL implementation is as good as it can be (or as good as we can make it while still meeting the customer requirement).
Which certificate type is appropriate for your need
There are a number of different options when it comes to purchasing an SSL certificate and it pays to consider which may be best for you or your customer prior to diving in. the two key factors are:
- What level of validation is required
- What do you need to protect
Product offerings vary a lot between Certificate Authorities but the following are the core offerings you should expect.
The levels of validation are important as SSL is built on us being given enough information to trust that the certificate used website we’re browsing has been issued
Domain validation (DV) is the minimum level of validation available . The CA will require that you demonstrate a control over the domain that the certificate is being issued for. This is usually done by either the CA sending an email to a well known email address on the domain, for example firstname.lastname@example.org, email@example.com, firstname.lastname@example.org or email@example.com, and the recipient of the email authorising the request by clicking a link or returning a unique string within the email or by creating a DNS record with a specific unique name and value that the CA can lookup and validate.
This shows the user that the certificate has been issued to someone in control of the domain, who will hopefully be the rightful owner of the domain.
although a little out of date (January 2015) Netcrafts’s SSL Survey shows at that time DV certificates made up for 70% of all certificates although this was due to them being traditionally the cheapest type of certificate available however out friends at LetsEncrypt have changes this with their offer of free SSL certificates.
Organisation Validation (OV) is the next step up from DV. As well as having to prove your control over the domain in much the same way as you would with a DV certificate you will need to submit to the CA proof that you are acting on behalf of the organisation that owns the domain. How you do this does vary quite a lot between CAs but in my experience validation has required:
- The CA will attempt to verify that you are in fact a registered legal entity, for example in the UK are you registered with Companies House and do the details you provided the CA with match the details on your registration.
- You may need to be able to prove you can receive verification by post via the Companies registered address
- The CA will attempt to contact your using the companies registered telephone number for verification.
Once you have completed verification your CA can issue you with an OV certificate with, should the user check, provide them the assurance that not only does the certificate in use belong to the person who owns the domain, but it also can trust that the certificate has been issued to an real registered organisation i.e. someone they would be able to contact though they wish rather then someone who just has access to an email account and DNS configuration.
As greater validation is required you can expect these to cost more.
If you’re serious about validation and really want your users to have the greatest level of trust in your certificate we have Extended Validation (EV) certificates.
As you would expect you must achieve all the validation you would need for an OV certificate as well as needing to prove business ownership.
A good overview of EV requirements can be found here on the CA/B forum site
The EV certificate enables the green address bar which some organisations find very important as it gives their end users, even if they dont know what it means, further cause to trust that the site they’re on is actually owned and operated by the company they’re intending to do business with at a glance.
Single domain certificates
A standard SSL certificate will provide protection for a single domain (although it’s fairly common now for CAs to sign the certificate to protect a specific sub domain – foo.bar.com – as well as the second level domain – bar.com).
If you need to secure multiple subdomains you have a couple of choices, you either purchase multiple single domain SSL certificates, one for each subdomain you need to secure, or you can look at purchasing a wildcard or SAN certificate.
- From an operational standpoint although the overhead for managing multiple single domain certificates is greater the impact of a single wildcard or SAN certificate expiry or renewal is a lot greater if you potentially need to update a large number of systems with the updated single certificate.
- From a security standpoint if the private key for a single wildcard certificate is compromised it all services using that wildcard or SAN certificate are compromised. The use of a single domain certificate reduces the impact of a private key compromise.
- You cannot be issued an EV wildcard certificate so if Extended Validation (although you CAN be issued a EV SAN certificate)
- You will either need to have a single public IP address per subdomain, which are in increasingly short supply until we see some traction with IPv6, to bind the certificates to or enable Subject Name Indication (SNI) which although widely can cause some problems with some browsers or applications (see below)
- Their could cost less to buy a single wildcard or SAN certificate then it would to purchase large numbers of single domain certificates
- The overhead to managing large numbers of individual certificates is greater then managing a single certificate.
A wildcard certificate, as the name suggests, allows you to utilise a wildcard in the common name field of the certificate. This is commonly deployed to allow any subdomain of the domain it’s issued to however it can be used within a specific string for example foo*.bar.com would be a valid certificate for any subdomain of bar.com starting with foo for example foovar.bar.com, foo1.bar.com, fooanythingiwant.bar.com – you get the idea.
Wildcards are convention for users who have lots of sub domains of the same domain to protect, you can bind a single certificate to your web server or NetScaler Content Switch allowing you to use a single public IP for multiple subdomains using the HTTP host header to identify which service the end user should be returned or alternatively the wildcard certificate can be installed on multiple different web servers.
- You can use the same single certificate for all your sub domains reducing the management overhead to managing multiple single domain certificates.
- The potential to reduce the number of public IP addresses consumed by utilizing NetScaler Content Switching, web server virtual hosts or dealing with the limited client support of SNI.
- after a certain point it may be cheaper to buy a wildcard certificate rather then multiple single domain certificates
- You cannot be issued a wildcard certificate with Extended Validation so if this is a requirement a EV SAN certificate may be a more appropriate choice.
- If the wildcard certificate private key is compromise all sub domains protected with the wildcard certificate are vulnerable
- If the wildcard certificate and private key were stolen or leaked it could be used to create a fraudulent web service that would look like a legitimate web service signed with the organisations certificate.
Subject Alternative Name (SAN) certificates
A Subject Alternative Name (SAN) certificate is a certificate that can be valid for, according to RFC5280, an unlimited number of different sub domains across different domains (when issuing form Windows CA the SANs must combined must fit within the 4KB limit allocated to the extension in the CA database).
SAN certificates are useful for people who may not want a certificate with such a broad scope as you would have with a wildcard but need to support multiple names on the same certificate. A common use case if for service providers/hosting companies who want to offer their users SSL encryption but do not want to purchase/manage a single domain certificate or single public IP address per customer due to the potentially vast costs and limitations associated.
- Allows you to protect multiple sub domains across different domains with a single certificate which can reduce management overheads, the number of public IPs required and reduce costs.
- SAN certificates can be issued with Extended Validation.
- SAN certificates are particularly useful for web hosting companies and service providers as they can offer cheap SSL encryption to their customers.
- Unlike a wildcard certificate SANs are specifically listed so if the SAN certificate was stolen or leaked it could only be used with the specific FQDNs listed.
- If the SAN certificate private key is compromise all sub domains protected with the wildcard certificate are vulnerable
- although there is theoretically no limit to the number of SANs you can add to a single SAN certificate most public CAs will offer a specific number, for example 25, then charge more for additional SANs
Subject Name Indication (SNI)
SNI is an extension to TLS that allows multiple certificates to be bound to the same IP access and TCP port which is very useful in a world where our public IPv4 pool is rapidly depleting. During the SSL handshake the correct certificate is selected by matching the certificate common name to the host name being requested by the client.
I like SNI as a feature, I think it’s cool but unfortunately at the moment due to issues with client side supportability of SNI I hesitate to recommend it. We all know Windows XP is still very much alive despite it being way past it’s best. The following table should allow you to assess whether SNI is an option based on the client base you need to support.[table caption=”SNI Support” width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”] Software,Type,Supported,Notes
Internet Explorer,Browser,Yes, Since version 7 on Vista (not supported on XP)
Mozilla Firefox,Browser,Yes, Since version 2.0
Chrome,Browser,Yes, Since version 6.0
Blackberry OS,Mobile Browser,Yes, Since version 7.2
Windows Mobile,Mobile Browser,Yes, Since version 6.5
Android default browser,Mobile Browser,Yes, Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones
Nokia Browser for Symbian,Mobile Browser,No,
Opera Mobile for Symbian,Mobile Browser,No,
Microsoft IIS,Web server,Yes, Since version 8
Apache Tomcat,Web server,Yes, Not supported in version 8.0 or earlier
Apache HTTP Server,Web server,Yes, Since version 2.2.12
IBM HTTP Server,Web server,No,
cURL,Command-line tool and library,Yes,Since version 7.18.1
wget,Command-line tool and library,Yes,Since version 1.14
Java,Library,Yes,Since version 1.7
Go,Library,Yes,Since version 1.4
Perl,Library,Yes,Net::SSLeay since version 1.50 and IO::Socket::SSL version 1.56
PHP,Library,Yes,Since version 5.6
Python,Library,Yes,Supported in 2.x from 2.7.9rc1 and 3.x from 3.2alpha4 (in ssl urllib and httplib modules)
Citrix Receiver,Application,No,No documentation available so suggest this is on the roadmap
Which Certificate Authority to obtain your certificate from
I’m often asked which certificate authority I would recommend a customer buy their SSL certificates from. Along with researching the reputation and liability (should you foresee your organisation financial compensation should the CA become compromised) the only answer I can give is that you should use a CA you trust with the data you’re encrypting.
An important factor is the CAs root distribution when it comes to supportability for the Certificate you’re purchasing.
If you’re implementing an SSL certificate for public web services that will be consumed by the general public, potentially from any device they happen to have lying about you need to determine whether the CA’s root certificate is distributed by default with the client OS/browser you intend to support.
The latest list of CAs currently participating in Microsoft’s Trusted Root Certificate Programme can be found here:
The latest list of trusted root certificates supported in Apple OSX can be found here:
The latest list of trusted root certificates supported in Apple IOS can be found here:
If you support Linux users there is no central root certificate store however common practise tends to be to utilise the Mozilla’s Network Security Services (NSS) included CA certificate list which can be found here:
As with Linux Android has no central root store and the available root certificates may differ depending on changes made by the vendor or carrier however you can check the trusted roots on an Android device by going to Android Settings, then Security and Trusted Credentials.
Now to the techincal implementation..
Before we even start looking at SSL ciphers we need to ensure the certificate has been signed using an SHA256 or greater algorithm. As with everything there is a trade off between security and compatibility. This is demonstrated quite well when we take into account NetScaler Gateway and SHA1 vs SHA256 compatibility.
A cryptographic hash function is a function that is used to map digital data of arbitrary size to digital data of a fixed size in order to validate its authenticity with the goal of assuring the integrity of destination and data transmission.
A good cryptographic hash function aims to be one way function but typically as technology enhances the level of difficulty and effort required to extract the input value form any one hash value is reduced which is why new cryptographic hash functions are continuously developed to try and stay ahead of the curve.
SHA-1 hashing function which is now known to be weaker than initially thought and it is widely recommended that and SSL certificates that are signed with the SHA-1 cryptographic hash function be replaces with those signed by the SHA-256 cryptographic hash function.
The following table demonstrates past, present and future algorithms, their comparative ‘strength’ (calculated by the taking the number of operations required to find a collision in a practical attack, 64bits=2 64 =18446744073709552000) and the current NIST recommendation on the algorithm[table caption=”Hash function” width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”] Algorithm (Variant),Security (Bits),Benchmark data (MiB/s),Current Recommendation
MD5,<64,335,As of 2010 Cryptographically broken and unsuitable for further use
SHA-1,<80*,192, SHA-1 signed certificates should not be issued by CA beyond the 1st of January 2016 and should not be trusted beyond the 1st of January 2017.
SHA-2 (256 variant),128,139,Acceptable for all signing
SHA-3 (512 variant),256,No benchmark data available, NIST announced SHA-3 as a hashing standard on the 5th of August 2015.[/table]
*a theoretical attack has been documented to suggest the private key can be found in 261 making it 61 bit however this has not been practised.
While Citrix have not published benchmark figures for SSL throughput based on certificates signed with different encryption algorithms on the NetScaler product range benchmarking tests performed by the University of Illinois at Chicago show the use of SHA-256 introduces a 27.6% capacity overhead over SHA-1 benchmark figures.
Real world performance will vary due to a variety of factors however these figures have been provided to give an example of the impact changes to the signing algorithm can have.
It is currently thought, assuming a malicious party were to use a platform such as AWS and their compute rental fees remain constant but server capacity keeps pace with Moore’s law, that by 2018 the cost to a malicious party to forging a SHA-1 signed certificate will be £111,490 and by 2021 as little as £27.700.
These attacks could be achieved significantly quicker and potentially cheaper by utilising GPUs and custom hardware. As such NIST recommended that certificates signed with the SHA-1 hashing function should no longer be trusted.In addition to the NIST recommendation organisations such as Microsoft have announced the Windows operating system will no longer support and SHA-1 SSL certificates as of the first of January 2017 and Google are have advised that Chrome browsers and operating systems will treat SHA-1 signed SSL certificates valid beyond the 1 st of January 2017 will be treated as “affirmatively insecure”. The CA/Browser forum also dictated that it’s member CAs must not issue any new subscribe certificates or subordinate CA certificates using SHA-1 certificates past the 1 st of January 2017.
While Microsoft and google will be removing support for SHA-1 signed SSL certificates, rightly forcing the use of SHA-256, older client operating systems and browsers do not support SHA-256 SSL certificates.
I’ve put together a briefcompatibility matrix for those who are currently using SHA-1 signed certificates who should be looking (really quite quickly) to SHA-256 signed certificates.
[table caption=”Minimum operating system support for SHA-256″ width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”] Operating System,SSL Certificates (Client side),SSL Certificates (Server side)
ChromeOS,All Versions,All Versions
Windows Desktop, XP SP3+,XP SP3+
Windows Server,2003 SP2 with MS12-095,2003 SP2 with MS12-095[/table]
[table caption=”Minimum browser support for SHA-256″ width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”] Browser,Minimum browser version
Internet Explorer, 6+ (On Windows XP SP3+)
Safari, 3+ (on OSX 10.5)[/table]
[table caption=”Citrix receiver” width=”500″ colwidth=”20|100|50″ colalign=”left|left|center|left|right”] Browser,Minimum browser version
Apple OSX, 11.8.2
Blackberry 2.2, Not Supported
Blackberry 10, 1.0
Blackberry Playbook,Not supported
Windows Standard, 4.1
Windows Phone (8), 1.1
Windows 8.RT, 1.4[/table]
A large part of optimising out SSL setting revolves around offering only the most secure ciphers to our connecting clients and ensuring we order out ciphers in such a way that during the SSL handshake the stronger ciphers are most preferred.
So we create a customer cipher group:
add ssl cipher APlus
Thankfully as I am not a crypto god or math genius a whole bunch of incredibly clever people have, and will continue to, spend a lot of their life working this out for us. A good place to start for those in this world who do not wear tin foil hats to shield their thought from the government is to look at recommendations from the NSA/NIST who compile a list of ciphers they deem acceptable for classified information, they call this ‘NSA Suite B Cryptography’. If it’s good enough for them, it’s probably good enough for us.
Suite B algorithms differ dependant on the classification of data:
- Encryption Algorithm AES (FIPS 197)
- AES 128 and 265 bit or greater Galois Counter Mode (GCM), Cipher Block Chaining (CBC) cipher suites may be employed when GCM cipher suites cannot be employed, for data classified as secret
- AES 256 bit or greater in Galois Counter Mode (GCM), Cipher Block Chaining (CBC) cipher suites may be employed when GCM cipher suites cannot be employed, for data classified as top secret
- Digital Signature (Draft FIPS 186 Digital Signature (Draft FIPS 186-3)
- ECDSA with 256 ECDSA with 256-bit prime modulus is recommended for data classified as secret
- ECDSA with 384 ECDSA with 384-bit prime modulus is recommended for data classified as top secret
- Key Agreement (NIST SP 800 Key Agreement (NIST SP 800-56A)
- EC Diffie-Hellman or EC MQV with 256 Hellman or EC MQV with 256-bit prime modulus for data classified as secret
- EC Diffie-Hellman or EC MQV with 384 Hellman or EC MQV with 384-bit prime modulus is recommended for data classified as top secret
- Hash Functions (FIPS 180 Hash Functions (FIPS 180-2)
- SHA-256 or greater for data classified as secret
- SHA-384 or greater for data classified as top secret
In case you’re wondering, like I was, why we would want to use a Suite B when logically there is a much better Suite A out there? it is because Suite A is comprised of algorithms that are not publicly available and are themselves secret. Some may say using a secrete algorithm to protect your secrets makes them.. double secret. Some may say that reducing the number of people who have access to the algorithm reduces the probability of a flaw being found via peer review. Either way this doesn’t concern us.
As of version 10.5 build 53.0 we have had support in NetScaler for ECDHE (Elliptical Curve Diffie-Hellman key Exchange) ciphers. ECDHE ciphers use ECC (Elliptical Curve Cryptography) which requires smaller keys to achieve the same level of security provided non-ECC cryptography using larger keys. For example the following demonstrates an ECC key size equivalent to and RSA key size:
ECC key length (bits) |RSA key length (bits) -------------------------+------------------------- 224 - 255 | 2048 256 - 383 | 3072 384 - 511 | 7680 512+ | 15380
Practically this means a reduction the the amount of resources that are required to perform encryption on the NetScaler appliances which means faster encryption (increased performance) and the potential to increase the number of SSL transactions we can support on one appliance (greater ROI) then if we were not using ECDHE.
This, as well as it’s current inclusion within the NSA suite B, is why we have our ECDHE ciphers as the highest priority in our custom cipher group. Note that the ciphers chosen comply with the requirements for suite B secret algorithms as they are ECDHE, greater then AES 128 and SHA256 and greater
bind ssl cipher APlus -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384 -cipherPriority 1 bind ssl cipher APlus -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256 -cipherPriority 2 bind ssl cipher APlus -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384 -cipherPriority 3 bind ssl cipher APlus -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256 -cipherPriority 4
Non ECDHE ciphers that comply with NSA suite B classification are also added for clients that do not (can not) support ECDHE ciphers.
As with the ECDHE ciphers above the GCM ciphers are prioritised over non GCM and CBC ciphers. This is because GCM ciphers provide an additional layer of *authentication on top of being proven to be far more performant (although performance gains increase with higher transfer sizes GCM will outperform CBC on smaller data transfers even if the gains are less) due to minimal operational overheads.
*it’s useful to know the construct of the cipher names to determine what they do, This is as follows:
For example if we compare two ciphers:
The above uses TLS v1.2 – DHE key exchange – RSA authentication – AES 256 Algorithm – GCM Mode – SHA384 Hash function
The above uses TLS v1.2 – DHE key exchange – No authentication (Note the absence of auth parameter) – AES 256 Algorithm – SHA256 Hash function
The above uses TLS v1 – RSA key exchange (Note NetScaler doesn’t reference this when using RSA) – No authentication (Note the absence of auth parameter) – AES 128 Algorithm – SHA Hash function
One you break down the cipher name it makes it much easier to determine why you’re using them.
bind ssl cipher APlus -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384 -cipherPriority 5 bind ssl cipher APlus -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256 -cipherPriority 6 bind ssl cipher APlus -cipherName TLS1.2-DHE-RSA-AES-256-SHA256 -cipherPriority 7 bind ssl cipher APlus -cipherName TLS1.2-DHE-RSA-AES-128-SHA256 -cipherPriority 8
The following two ciphers will accommodate clients that do not support TLS 1.2 (and the authentication allowed introduced in it).
you would be forgiven for thinking that because the hash function on these ciphers is stated as SHA that these would be subject to the same sunset as SHA-1 signed certificates however this implementation of the SHA-1 hash function is not deemed to be weak allowing us to continue using these ciphers.
bind ssl cipher APlus -cipherName TLS1-AES-256-CBC-SHA -cipherPriority 9 bind ssl cipher APlus -cipherName TLS1-AES-128-CBC-SHA -cipherPriority 10
The last cipher should not be enabled however you may still need it, it depends entirely on whether you need to support Windows XP client devices (IE8 and above) as Windows XP does not support AES. We reluctantly enable this as it is the strongest cipher we can offer to Windows XP and IE8 users however personally I would suggest that as mainstream support ended on the 14th of April 2009 (over 7 years ago) and extended support ended on the 8th of April 2014 (over 2 years ago) that supporting these operating systems in in fact an indication that security is clearly not a priority and quibbling over the ciphers you allow is probably the least of your problems. I have however added it with the above caveats as I live in the real world and no matter how painful it is Windows XP will not die.
bind ssl cipher APlus -cipherName SSL3-DES-CBC3-SHA -cipherPriority 11
NetScaler currently supports the following ECC curves and are applied in the following order of priority:
Note: As per RFC5349 P_256 adn P_384 are supported across all platforms but P_244 and P_521 are not supported on the MPX platform when using TLS 1.2
NetScalers as of 10.5 build 53.0 will bind all 4 ECC curves by default.
If you have upgraded your NetScaler appliance from a version 10.1 build 10.1 121.10 you must explicitly bind ECC curves to existing SSL virtual servers using the following command (new SSL virtual servers created after the appliances had been upgraded will have all four curves bound by default.)
bind ssl profile ns_default_ssl_profile_frontend -eccCurveName ALL
before we bind our custom cipher group we need to ensure the ns_deafult_ssl_profile_frontend has the desired settings. The reason for this will be explained later in this post.
In order to allow us to configure our SSL profile using a single command the first thing I want to do is create myself a Diffie-Hellman key. The reason for this is that we will want to enable Perfect Forward Secrecy (PFS) to ensure that the compromise of one message cannot compromise others as well, and there is no one secret value whose acquisition would compromise multiple messages. It does this by creating a random key per sessions to complete a key agreement, without using a deterministic algorithm.
The first step is the creation of a Diffie-Hellman key
create dhParam DH_key.key 2048
Once created we want to create a SSL profile with this Diffie-Hellman key defined as well as the following parameters:
- SSLv3 should be disabled to prevent against the POODLE vulnerability (CVE-2014-3566) – this is disabled by default when you create a SSL profile on a version 11.0 NetScaler appliance but tI have included the parameter to make a point
- TLS versions 1.0, 1.1 and 1.2 should be enabled (again this is done by default but I feel that being explicit is the best way forward.
- SSL renegotiation should be denied for NONSECURE requests to mitigate the risk of the following vulnerability: CVE-2009-3555: TLS Protocol Session Renegotiation Security Vulnerability
set ssl profile ns_default_ssl_profile_frontend -dh ENABLED -dhFile "/nsconfig/ssl/DH_key.key" -denySSLReneg NONSECURE -ssl3 DiSABLED -tls1 ENABLED -tls11 DiSABLED -tls12 EnABLED
As we want to apply all out SSL optimisations via SSL Profile where possible we should apply our custom cipher group to the SSL Profile we’ve created. Before the NetScaler will allow us do that we need to make a change to the NetScaler global SSL parameters which will bind the default NetScaler SSL profile to all SSL virtual servers. This is the reason that I have modified the existing default NetScaler SSL Profile to meet the requirements for the SSL Labs A rating rather then create my own SSL Profile as:
1. It means although all your existing SSL parameter setting are overridden the will be overridden with preferred settings.
2. It saves you having to apply a new SSL profile to each SSL virtual server, it’s done automatically for you
As always this wont be ideal for everyone, you can create your own profile and apply it specifically to those virtual services you wish but if you do make sure you set the default profile to comply with your minimum requirements before enabling.
It’s important to note that once the default profile SSL parameter is enabled it CANNOT be disabled and that the default SSL profile will override any SSL parameters you may have set per SSL virtual server on ALL SSL virtual servers.. You have been warned!
set ssl parameter -defaultProfile ENABLED
Now the default SSL profile is enabled we can bind our custom cipher group
bind ssl profile ns_default_ssl_profile_frontend -cipherName APlus -cipherPriority 1
At this point if you’re after an SSL labs rating you’re good for an A rating and hopefully you’ve a reasonable understanding of why it is you’ve obtained that score. This rating will degrade over time, that is the nature of the security world and the reason people continue to pay us. For example we can expect ECDHE to fall out of favour as despite they have huge performance advantages it is expected (as per a statement from NIST/NSA in August 2015) that advanced in quantum computing will threaten ECDHE which could cause it to be dropped from the NSA suite B, until then we will just have to enjoy it while we can but we aware that we should not take it for granted.
This is one of the reasons you should always take into account the potential changes in cryptography standard into account when sizing you NetScaler platform – while you can plan for X many SSL transactions per second when employing current best practises next week could be different and all of a sudden the SSL TPS figure could change if we need to increase our key length or discontinue the use of faster algorithms.
Lastly, for the coveted A+, we want to instruct the client browser to only allow HTTPS traffic by setting the ‘Strict-Transport-Security’ cookie. Unfortunately we cant set this via our SSL profile however rather then binding a rewrite policy individually to SSL virtual servers I would prefer to set this cookie whenever the NetScaler detects the client is connecting using SSL.
This header tells our client browser that the subdomain/domain should only attempt communication over HTTP and never use unencrypted (HTTP) communication.
add rewrite action ReAct_sts_header insert_http_header Strict-Transport-Security "\"max-age=157680000; includeSubDomains; preload\"" add rewrite policy RePol_sts_header_IsSSL CLIENT.SSL.IS_SSL ReAct_sts_header bind rewrite global RePol_sts_header_IsSSL 10 NEXT -type RES_OVERRIDE
While it is good practise that we declare strict transport security by setting a header on connection it does mean we are making the assumption that the first connection being made will be encrypted. We can reduce the risk of unencrypted connections by submitting your domain to Chromes HSTS preload list which tell supported browsers (Chrome, Firefox, Safari, IE11 and Edge) that your domain should only use encrypted communication.
Prerequisites for being added to the HSTS preload list are:
- Domain/Subdomains are configured with a valid certificate.
- All HTTP traffic is redirected to HTTPS
- All subdomains are are HTTPS only, specifically including the www subdomain if a DNS record for that subdomain exists.
- Serve an HSTS header on the base domain for HTTPS requests:
- Expiry must be at least eighteen weeks (10886400 seconds).
- The includeSubDomains directive must be specified.
- The preload directive must be specified.
- If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (not the page it redirects to).
you can submit your domain using the following link:
Obviously as specified earlier different scenarios may dictate a global setting is not appropriate so instead of binding globally this policy can be bound to a specific SSL virtual server.
Now I hope I have provided a reasonable explanation as to how you can optimise SSL on you NetScaler appliance as well as why exactly you are doing it.
If you have any feedback I’d love to hear it!