Fear of failure never stopped me from looking like an fool before - so here goes...
SSL is an acronym for secure sockets layer. Without SSL when you establish a connection between your computer and another computer using a socket all data that flows back and forth does so "in the clear". What this means is that if someone else was able to get hold of the packets of data they could take a look at them and - assuming the knew the protocol being used - read the data. With TCP/IP and the world wide web, computer A could be your PC with a browser, and computer B could be your bank or a shop where you're entering credit card details to buy a new skateboard you've been saving up for. If you were logged on at an internet cafe or perhaps a wireless network in a cafe (not saying anything bad about wireless networks in cafes - nothing better than a bit of web surfing while sipping a latte and eating a tasty almond croissant) there is a risk that the flow of data between your PC and your bank/shop's web site, is going via something that has a villanous piece of software looking at the data packets.
So, to take care of this, SSL was created. When an SSL conversation has been established all data that flows back and forth between the two computers can't be read by anyone else. This is what IT folks rather cutely call "sniffing data packets". SSL means no-one can sniff your packets. (Stop sniggering if you think that's funny).
At the heart of SSL is something called certificates. Certificates are important. For example, I have certificates from various sailing exams I've taken over the years, and when I go to charter a boat I have to show these to the charter company - they take a look at them - see they were issued by the Royal Yachting Association - and let me sail the boat. Life is good for me and the charter company.
Now back to the chap in the internet cafe, or even at home, logging onto his bank or skateboard shop. How does he, or she, know that it really is their bank or shop. The trojan horse from Greek mythology was a troop carrier pretending to be a horse. Just as rascals these days can make horsemeat look like beef, the same rogues can can register a web site with a domain that looks reasonable claming to be your bank/skateboard shop, and worse than that with the way that TCP/IP packets are routed around networks anyone in the middle between your lattee and your real bank can in theory pop-up an alternative to the original web site that has the same address and spoof you into entering your details over a connection that to all intents and purposes looks like the real one and could even if they wanted to establish the connection using SSL with a cute padlock icon. How do you know who to trust ?
This is where certificates come in - just like the body who issues certificates to competent sailors is one that is a recognized authority - so is the case with SSL certificates. A number of recognized bodies issue certicates - at a fee - to companies and whoever asks for one - after doing due diligence that the person asking for it really is who they say they are. The certificate is signed with an expiry date, and for a specific web site.
What this all means at the end is that to do minimal SSL - you need a certificate held by the server that says "This is me - want to talk SSL?". The client PC then has to make a choice - do I trust this person or not ? The first thing that happens is to look at who signed the certificate - if it looks like a recognized authority, and it's valid, and it's for the TCP/IP address that the client has asked to contact, then the SSL protocol is established. If not - then typically a pop-up will appear saying "Do you trust this certificate - here's some information about it". Once a certificate has been accepted it typically gets put into a trust store, which is then checked against the next time the certificate is offered by the web site to avoid a zillion "Do you accept, do you accept" for the same certificate - which could get mightily annoying. A certificate store is a special kind of file which itself is protected by a password/passphrase to stop malware and other bad folks looking inside and messing with the contents (such as adding their own rogue certificates). More on trust stores later though, let's do a quick recap...
An SSL conversation means data is encrypted on the wire and data packets cannot be sniffed - if anyone does sniff them then they can't see inside them. This means data you don't want others to know is safe.
To conduct SSL the computer you are contacting has to present you with a certificate. Your computer will look at it - see if it likes it - if not throw a pop-up - and then if you like the certificate store it in a trust store file and do subsequent checks to avoid having to asking you over and over whether you trust the site you site that you already said you did.
SSL is all about several things - a server presents a certificate - if the client doesn't trust straight away who signed it then it challenges the user - if the user accepts the certificate it remembers - and after that all conversation is private between the client and the server and no-one else can spy on the data packets's contents.
The CICS Explorer is a client in that it connects to z/OS which is the server. There are four ways that the CICS Explorer can connect to z/OS - two to CICS regions - and one to z/OS. There are more ways when plugins for CICS tools are loaded, but for now let's just cover the basic four: CMCI and CPSM Data which are connections made to CICS regions, and FTP or z/OSMF to z/OS itself.
One thing that we do in CICS Explorer 5.1 is now have an explicit checkbox for whether the connection is secure or not.
Before 5.1 we didn't have the checkbox - and what we did was attempt a secure connection and if this failed then attempt an unsecure one. We were very proud of this, because what it meant was that a user didn't have to know whether the connection was secure or not. However... it had a downside - in the circumstances where we dropped from SSL to unsecure mode we flowed the user ID and password down the non SSL connection. So, to avoid this occurring you - the user making the connection - must specify whether it should begin as SSL or not - and we don't ever automatically down from SSL to clear, or vice-versa.
If you do get it the wrong way round- we'll put an error at the bottom of the CICS Explorer - and also a redX next to the connection which shows the error when you hover over it. The error below is where SSL was checked but the connection was actually unsecure.
The error that you get if you specify the wrong SSL option and try to make SSL over unsecure, or vice-versa, varies based on the type of connection. Unfortunately we don't have a single message that says "Hey there - you got the SSL option wrong" however we do our best to analyze the various responses and try to figure out that you might have got the option wrong, but it's a best guess rather than a definitive message.
The checkbox is on all connections, where SSL is supported. This is CMCI and CPSM Data for CICS, and also for z/OS for the two connections types FTP and z/OSMF. Because the checkbox mode for SSL is explicit on the connection, we're able to show this against a connection even when it's disconnected with the padlock icon overlay. Beforehand we only "calculated" that a connection was SSL once we had connected so we didn't put the graphic against the connection in its disconnected state. We also always show the padlock in the trim widget to indicate at a glance that the connection is SSL.
What an SSL connection means for the CICS Explorer is that everything is secure - the initial user ID and password request to logon to CICS or z/OS - and all subsequent data - cannot be sniffed by a "man in the middle" type scenario.
One thing we do to be helpful (we like being helpful) is that if you enter a connection as unsecure, and we detect that it probably should have been secure, is give you the chance to "correct" this with a pop-up that you're presetned when we realize this during the connect phase.
If you select Yes on the dialog - we'll switch the connection and you're good to go - and we'll update the SSL flag on the connection definition.
Prior to CICS Explorer 5.1 we didn't have explicit SSL on connection - however we did store internally whether or not when a connection was made whether it was secure or not. This was so that we attempted the right one to reconnect, and going forward from a pre-5.1 CICS Explorer workspace to 5.1 we migrate this flag into the SSL flag, which hopefully means that old workspaces work fine going forward.
Now certificates. Remember the opening blurb - how do you know you can trust that the CICS system you're connected to really is who it says it is ? This might not be a realistic vulnerability for folks who always connect at work through a VPN, however if you were at an internet cafe or other wireless network there is a feasible risk that someone is spoofing your server, and doing server side certificate authentication is something that folks who audit computer systems like to make sure is all present and correct.
When the CICS Explorer connects it examines the certificate and first sees whether it has been signed by a recognized certificate authority. The list of recognized authorities is defined by the Java runtime environment, and includes the big players such as verisign or thwate. If the certificate isn't recognized or more likely is "self signed", then it gets presented to the user in a friendly "Do you trust this" pop-up.
The certificate shown above is a "self signed" one - which is where the system programmer for the z/OS system I'm connecting to (which is one in IBM) has created their own certificate. I can see this because of the issuer and because I'm working on my network within IBM I'm comfortable to acept this. The red text at the top is warning me that the system programmer in this case has been a bit lazy because he's created the certificate for a different URL and copied it accross - certificates have an explicit URL they work with when they are created. However I know the fellow who did this and after a quick e-mail chat I'm good to accept. Press OK.
I won't be challenged again for the same certificate. This is because it's held in a certificate store. A certificate store is a folder on your PC. The location of the certificate store can be changed in the Window>Preferences dialog on the Explorer>Certificate management page.
The preference page has the file name in the group box "Trust store details". The default location is "explorer_keystore.jks" inside a folder in the workspace. When we were coding and testing this feature we did use the keystore location inside the JRE itself, however under Windows7 this required administrator rights to update and we didn't want to insist that CICS Explorer users had to have admin rights, so we created a keystore in the workspace to use by default. This does have the disadvantage that if you are running multiple workspaces connecting to the same hosts you'll have to accept any self signed certificates on each CICS Explorer workspace, however you could create a shared directory if this became really annoying for you. When we create the keystore for the first time - we attempt to copy the file cacerts from the Java runtime environment - which will be pre-populated with the known certificate signing authorities. This means that pucca certificates which have been signed by recognized folks will be accepted without any challenging. The passphrase is used by the CICS Explorer to access the certificate store - for the one we created it will be changeit. The keystore type is JKS by default which is "Java Key Store". There are other types of file format for certificate stores, and the other two we support are the SunJCE cryptography extension JKECS, or PKCS #12.
If you're thinking "This certificate store stuff sounds cool - I wish I could look inside a certificate store and see what's there and remove certificates", then I salute you. We, however, l'explorer de CICS, do not provide a fancy wizz bang facility to do this. However, there is a utility that comes with Java itself. It's called ikeyman, and it's in the /jre/bin directory that's part of the CICS Explorer folder structure. The screen shot below shows me running ikeyman and opening the trust store that I have in my CICS Explorer workspace. You can see the preloaded pucca certificates from verisign and others, along with a self signed winmvs28:32208 certificate I accepted when connecting to my z/OSMF system. ikeyman lets you view certificates and remove them.
So, having shown how to look at the contents of a certificate store without the CICS Explorer - let's get back to the CICS Explorer and the certificate management preference page. A checkbox you might have noticed that is super useful is one that allows you to bypass all certificate checking/prompting. This doesn't bypass SSL - it just means that if a certificate is presented we'll always accept it without a prompt. If you know you're always going to be connecting via a work network or you have a VPN that does its own host authentication, then you might decide that having the CICS Explorer present certificates is overkill, in which case check the box "Disable certificate management for secure connections".
There are a few other options on the certificate management preference page that I'll quickly rattle through. The key store location, and type, is very similar to the trust store. It's used to hold the location of where client side certificates are stored. Client side certificates are where you - the server - can actually give a certificate to the clients that they must present to you when trying to establish an SSL connection. This is to ensure that if a computer tries to connect - even if it has the right user ID and password - you can reject it becuase it's not one that you trust. A whie back folks tried to do this kind of security with IP address and domain, however IP address are possible to spoof and tunnel to pretend you're someone else. When an SSL connection is made the client gets a chance to trust/accept/reject the server certificate ... and the keystore is presented to the SSL connection allowing the server a chance to reject the client if it has secured itself to restrict access to only authorized client side certificates. One thing that you can do with z/OS is use client side certificates to bypass userID and password - the client side certificate is used to associate a RACF (or other security manager) user ID and password, however we don't currently implement this in the CICS Explorer. Let us know if you think we should - maybe with a comment in this blog or an RFE - but for now even if you are using a client side certificate you'll still have to have a userID and password to connect.
The SSL protocol combo box allows you select the level of SSL or TLS that the CICS Explorer is going to use to connect. This needs to match, or be higher, than the SSL level of the server you're connecting to. The default option means that the CICS Explorer will try to match the level of the server, however if you want to restrict or explicitly state the level you can select it in the drop down. What this means is that, for example, you could select a high level based on the fact your company had a requirement to secure at a high level, and if for some reason the server was at a lower level the CICS Explorer wouldn't connect.
What about the CICS tools ?
For CICS Explorer 5.1 as well as adding all of this great SSL stuff - the explicit mode on connections and the preference page (and a lot of under the covers code as well you can't see but is doing the heavy lifting) a number of CICS tools were update to support SSL. These are CICS Interdependency Analyzer and CICS Performance Analyzer which will now connect to an SSL secure DB2 port, as well as CICS Configuration Manager which can establish an SSL connection to the configuration manager server port.
If you need any help with getting SSL set up, give us a shout and we'll be happy to help.
Enjoy !!!
Likes 1
