As of October 15, 2014 all SSL versions including SSLv3 are considered as vulnerable in specific situations. Please note the updated Local Installation recommendations!
The SnapComms Client (Client) regularly communicates with the SnapComms Server (Server) in order to check for and download any new content to the Client. The frequency of this communication is configurable and is typically set to 120 seconds but can be set to shorter intervals of 60 seconds.
The SnapComms solution is designed with security in mind, so the security of the communications between the Client and the Server is of extreme importance, especially as this communication occurs over the Internet which is an insecure medium.
Secure Sockets Layer (SSL) is a cryptographic protocol that enables secure communications over the Internet. SSL was originally developed by Netscape and released as SSL 2.0 in 1995. A much improved version, SSL 3.0, was released in 1996. Current browsers do not support SSL 2.0.
Transport Layer Security (TLS) Transport Layer Security (TLS) is the successor to SSL. TLS 1.0 was defined in RFC 2246 in January 1999. The differences between TLS 1.0 and SSL 3.0 were significant enough that they did not interoperate. TLS 1.0 did allow the ability to downgrade the connection to SSL 3.0. TLS 1.1 (RFC 4346, April 2006) and TLS 1.2 (RFC 5246, August 2008) are the later editions in the TLS family. Current browsers support TLS 1.0 by default and may optionally support TLS 1.1 and 1.2. TLS 1.3 is currently in a draft state.
Cipher Suite: a cipher suite is a named combination of authentication, encryption, message authentication code (MAC) and key exchange algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) / Secure Sockets Layer (SSL) network protocols.
Hypertext Transfer Protocol Secure (HTTPS), or “HTTP Secure,” is an application-specific implementation that is a combination of the Hypertext Transfer Protocol (HTTP) with the SSL/TLS. HTTPS is used to provide encrypted communication with and secure identification of a Web server.
More about HTTPS or HTTP over SSL / TLS
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols are a generally accepted and widely deployed protocol for encrypting data sent over the Internet. It is therefore possible to say that the content data is no-more or no-less secure when in transit than any other data that is transferred over the Internet when using HTTPS. In this regard, we consider the download of content to the SnapComms Client to be secure.
There is a certain amount of overhead involved when using SSL/TLS. The initial client/server handshake between Client and Server requires at least 2 round-trips to the Server and consumes approximately 1.5KB of bandwidth before transmission of application data can begin. With “normal” web-browsing activities, this overhead is negligible in comparison to the size of the HTML document and graphics files that constitute a web page. Typically the SSL/TLS overhead is amortized over the lifetime of the HTTPS connection, since HTTP 1.1 web browsers usually maintain persistent connections to the web server.
For SnapComms however, the overhead of SSL/TLS represents a significant waste of bandwidth compared with the amount of actual application data that is transferred each time the SnapComms Client checks for new content, where the SSL/TLS overhead is calculated to be approximately 700 bytes per round-trip (Client-to-Server-to-Client). When the Client communicates with the Server every 60 seconds, this represents 2.1MB per day (24-hours) of bandwidth that is wasted on the SSL/TLS client/server handshake for every user who is running SnapComms Client. Accordingly the use of SSL/TLS by the Client is optional ( configuration option) as it applies to both the content checks and the actual content downloads.
Note: If secure client/server communications across the SnapComms platform are required it is necessary to ensure that secure protocols and cipher suites are supported by the operating systems (OS) being used by both the Client and Server.The availability of protocols and cipher suites are largely depending upon the OS the Client and Server are installed on. Since the SnapComms Clients internally uses Microsoft Internet Explorer (IE), they use the same protocols and cipher suites that are available and configured for the specific IE versions available on the computers the Clients are installed on. Further information about IE and OS version combinations can be found here
SnapComms Hosting & Default ConfigurationsTo satisfy different requirements SnapComms offers a variety of hosting and installation options. Below are the protocol and cipher configuration details of the SnapComms cloud environments which also serve as the protocol and cipher defaults for local installation environments.
We strongly recommend use of tools like SSLLabs to get a fully detailed snapshot report of the SnapComms cloud environment.
|Install Option||Server Protocols *||Client Connection||Notes|
|Shared Cloud Configuration||HTTPS enforced
TLS 1.2, TLS 1.1, TLS 1.0, SSLv3.
|HTTPS always enforced||SSLv3 is enabled to support customers using old Operating Systems and Browser (e.g. IE8 on WinXP). SSLv3 will be phased out by the end of March 2016.|
|Private Cloud Configuration||HTTPS enforced
TLS 1.2, TLS 1.1, TLS 1.0
|HTTPS always enforced||Changes can be requested by the customer|
|HTTP only||HTTP only||Configuration is the responsibility of the customer|
* Server Protocols are listed in order of handshake preference, highest preference first. The actual protocol will depend on the highest supported protocol on both Server and Client.
The following Ciphers are enabled on the SnapComms Shared Cloud and Private Cloud environments. Configurations are listed in order of preference with the highest preference first. The actually cipher used will depend on the highest supported cipher on both Server and Client.
SnapComms Local Installation Recommendations
Data security is always a key consideration for any communications solution and security requirements need to be carefully analyzed and specified. SnapComms does not provide guidance or recommendation on whether it is prudent to use HTTP or HTTPS and suggest that qualified advice is sought as needed.
As with any solution, the SnapComms systems requirements will change with the level of security that is applied. The systems requirements relating to the SnapComms CommService, which handles content checks received from the SnapComms Client, will be heavily impacted by the application of high security settings.
To secure the Client/Server communication, we recommend the following:
- Install an HTTPS certificate on your IIS server
- Disable all SSL versions and configure IIS for use with TLS 1.x only
- Only allow secure strong Ciphers - please note that a combination of strong protocol and strong cipher is crucial (Note: running TLS 1.2 with a 40bit RSA key is as much exposed to a possible attack as is SSLv2 with the same key).
- Install the SnapComms Server with the Enforce SSL option checked - this will force the SnapComms Client provisioning service to create a Client with only HTTPS enabled.
- Ensure that your client Operating System / Browser Versions are safe by referencing SSL Labs. For MS Windows environments we recommend the minimum OS / Browser be Windows 7 & IE11.
- Only install the SnapComms Client on machines where users are not able to disable or change the SnapComms Client settings, secure protocols or ciphers.
Following the above steps will ensure a robust and secure communications environment. If you require enhanced security around data communications, SnapComms suggests the use of encrypting proxies or VPN tunnel connections to ensure full control of the data flow.
SnapComms Mobile Apps and Mac Client Security
The SnapComms Mobile Apps and Mac clients connect to the API (Application Programming Interface) which is located in the SnapComms Server Software within the IIS Server. On our Cloud service, this address is https://content.snapcomms.com/API/