In this post and in follow up posts I will take this topic further and explain details of what we do in RD Traveler to enable security end-to-end.
This first post is an introduction to security aspects of web communications and of the RD Traveler sites in particular. In the next post I will describe details of how you can enable a secure communication between the web browser and your on-premse version of the RD Traveler web server.
If you are not familiar with acronyms like "SSL", "TLS", "SHA", "DES" etc. this series of posts is for you. You will learn about basics of securing a network connection using industry standard technologies. If you are a system administrator in charge of installing the RD Traveler on premise, even if you have experience in working with web applications, you will benefit from learning how to enable your RD Traveler installation for secure communications.
It is typical for all web sites providing a log in capability to any kind of private or sensitive information, to provide a secure connection. A "secure" connection for a web site means that the identity of the site is verified by a known authority and the communication with the site is encrypted using standard encryption protocols. I will explain more about site identity and encryption later.
How do you tell if a particular web site is secure?
If you ever used a web browser, you may have noticed that web sites have an indicator, provided by the web browser, that the connection to this particular web site is "secure". This indicator may take different forms in different browsers. For example, Google Chrome shows a green lock at the beginning of the address bar to indicate that the site is secure:
Firefox browsers may show different color locks for secure sites with color of the lock signifying various levels of site identity validation:
Whatever pictorial indicator there might be in a specific browser, the web address itself for secure sites always starts with "https://" as opposed to insecure "http://". Many sites, even if you explicitly enter "http://" at the beginning of the web address, will switch automatically to "https://" (This is the behavior of the RD Traveler server, but more about this later). The "s" at the end of "https" stands for "secure" and indicates that the communication to this site is using a set of security standards commonly known as SSL and TLS.
The first main goal of the secure communication is to verify site identity. This is necessary for the clients to be sure that they are connecting to the site that they think they are connecting to. It might sound silly but consider for example a simple typo in a web address which leads to a malicious site that exploits common misspellings of popular legitimate sites. Site identity must be verified by an independent organization that maintains and verifies site information and, many times, reputation. These organizations are called Certificate authorities (CAs) and they issue certificates for known web sites. Certificates form a "chain of trust" that is used in Public Key Infrastructure (PKI) to positively establish the identity of the certificate owner.
Once the identity of the site is established, the second major part of the secure communication is establishing a secure connection which encrypts all information exchange between the site and the clients using the security keys. The security key exchange is part of the protocol handshake that takes place after the identity of the site is established.
All popular web browsers and other clients accessing the internet have databases that store signed certificates of registered CAs and sites that are registered by these CAs. The certificates are encrypted with keys issued by CAs and are only available to the registered sites. This is how browsers and clients know that the identity of the site is legitimate.
If anything is suspected to be wrong, or if a browser does not have a certificate key for a particular site, but the site insists on secure communication, the browser will issue a warning similar to the one issued by a Chrome browser shown here:
This does not necessarily mean a bad thing, as in this case when the warning is about the "localhost" server that runs on my laptop and which only has a self-signed certificate. Self-signed certificates are not issued by CAs and are usually temporarily generated for testing or development purpose, as is the case with my laptop. If you run RD Traveler server within your Intranet, it is usually ok to have either a self-signed certificate or a certificate from your company's internal certificate authority. The process for enabling your company's internal certificate is similar to enabling an external one but you will need to manually import the certificate authority information into your browser certificates database so that the browser will know not to issue the warning.
In general however, you and your clients should be very cautious if you get a warning message from a web site. This is why the RD Traveler sandbox site is secured with a proper certificate as indicated by the lock on its address bar:
This is why it is also important that if you get an on-premse version of the RD Traveler and run it for you users, you secure it with a proper certificate. In my next post, I will show how to enable the RD Traveler application server with a certificate. Stay tuned.