Sometime after the Druids built a Henge and found much needed rest (some 694224000 seconds after 01-JAN-1970), communications over the wire needed some form of encryption.
Enter NetScape circa the early 1990s and their development of Secure Sockets Layer (SSL). Fast forward to 2015 and the irony that you never used SSL Version 1 will no longer escape you as it was never released. The reason? Too many security holes.
Seem familiar? If not, it should for SSL and TLS (the successor to SSL) are about as open and old as the Alamo sans doors. Sufficed to say, 2014 was an interesting year with successive exploits, vulnerabilities and general cipher cracking, though all of us survived.
None of this came as a shock to myself. Well, that’s not entirely true. What shocked and still shocks me are the horrid names given to the Common Vulnerability Exploits (CVEs) documented at Mitre.org. Part of this lack of shock was my realization that something so immersed in our world, something so heavily used and seemingly taken for granted – like toast – would never be broken.
Another part of my glazed, bored look on this subject is due to previous work lives relating to or brushing against an entire industry. If you haven’t heard of said industry, it is known as Security or IT Security. You see, many projects, books, paperwork and heavy research nights have passed where my title of “Many Titles” had me locked in this industry. Interesting, complex and sometimes fun, it leads to the following disclaimer:
My days spent heavily amidst the ever ambiguous “Security Field” are gone. If the door is locked, secured, but I am missing a house I know I’ve been hacked. Thus, this post represents my own views and ideas… no one else and for no particular reason. If you are looking for hardcore security advice, use The Google to find a CISSP/Security Firm.
With SSL, TLS, etc providing cryptography over the wire and eventually making its way into the application layer, questions will surface regarding countless areas of IT infrastructure having a gaping security hole.
As for XenServer, I can exploits from last year and so on either don’t affect XenServer OR have been mitigated via hotfixes, best practices and more. Still, how can you tell if your XenServers are using “BLAH BLAH” Cipher with WEAK encryption standards?
XenServer uses SSL based technologies and upon installation (unless a private certificate is purchased), it generates its own self-signed certificate. Since this is so, OpenSSL utilites come with the XenServer bundle and these can be used in turn to get an idea of what type of encryption levels, standards and more are in use.
Introduce your friendly openssl command: found at a XenServer host’s command line near you!
A good example to start with is to see if SSLv2 is being utilized on your XenServer host(s)
From the command line, execute the following command to establish a client-based connection to XenServer on port 443. This literally tries to engage in a server/client discussion and will tell us:
- If a particular protocol/cipher is used
- If a connection to the host is viable (or not) with said protocol/cipher
- And if you are unsure: call Citrix Support
So, from the command line:
openssl s_client -connect YOUR_XS_HOST_IP -ssl2 | less
The output is grand (hence the less option), but SSLv2 is disabled and I see these important line items indicating it will not be used for host/client encryption:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 450 bytes and written 53 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Other examples of the openssl utility can be found at OpenSSL.org. Check it out and if you are curious about your Citrix products, also look here to sort by product and version for documents related to security notices, advisories and more.