As organizations evolve from private, on-premises communications to unified or cloud-based communications and/or collaboration, security becomes a critical component of any solution. There are so many factors reshaping enterprise communication networks today, from virtualization to mobilization and SIP integration to video collaboration, that administrators need to consider their encryption requirements for communications. Communication over the network poses the risk of interception by persons who might have unauthorized access to the network or intercepting traffic across the internet to any cloud base solution. This risk can be reduced by securing the communication data using digital encryption with certificates.
Encryption is used to protect information from being stolen or copied. However, encryption by itself is insufficient. Suppose that you have some private information that you want to send to a trusted recipient like a cloud base service provider. If you encrypt that information, but you mistakenly send the information to the wrong people and encrypt it in a way that the thieves can read it, then you have not protected the information at all. The certificate system is supposed to provide the basis for you to be able to trust that you are sending the data to the intended people and that you have encrypted it in a way that only the intended recipients can read it.
Understanding TLS for Network TLC
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over computer networks. TLS is the recommended security mechanism for Session Initiation Protocol (SIP). HTTP /HTTPS in SIP environments are based on TLS and SIP client implementations natively supports TLS.
PKI Hierarchy and TLS
TLS handshake has two specific functions, one is Authentication and Verification, the other is Data Encryption. The PKI system is built on the use of public key encryption. With public key encryption, there are two keys. One of those keys is made public and the other is kept private and known only to the owner of the key. In one typical use of PKI (Public Key Infrastructure), a message is encrypted using the public key. Then only the owner of the private key can decrypt it. In an alternative use, a special message is encrypted with the private key and it can be decrypted with the public key. In this use, the message is typically a signature, and the arrangement is intended to allow only the owner of the private key to create the signature while anybody can verify that the signature is correct because it is made public so it is available to everybody.
The mathematical relationship between the public key and the private key is sufficiently complex that it would be extremely difficult to compute the private key from the known public key.
Digital Certificate
The Digital Certificate contains information about whom the certificate was issued to, as well as the certifying authority that issued it. Additionally, some certifying authorities may themselves be certified by a hierarchy of one or more certifying authorities (Intermediate CAs), and this information is also part of the certificate chain.
In TLS, servers are configured with an identity certificate issued by a certificate authority. When clients connect to servers, the server presents its identity certificate for the client to validate. The client checks whether the server identity certificate was issued by a certificate authority that the client trusts (among other items). If everything checks out, then the client proceeds and a secure connection is established.
Certificate Authority
A trusted public body, such as a Certificate Authority (CA) will sign certificates for other servers/applications to use. When you trust a certificate, you are implicitly trusting the CA. If the verification of the certificate handshake succeeds, then you can trust that the certificate was signed by a CA that you have trusted. What you can trust, and how trustworthy a CA is, should be decided outside of the certificate system.
In most cases, CAs have their certification policies posted on their website. Many CAs do some checking of the identity of the server (the name of the certificate owner, as shown on the certificate). However, most do not check whether the server runs an honest business and in cases where the CA does extra checks, their certificate signing process will cost more. However, the final decision on what your organization trusts is yours.
Higher Standards
Digital signatures are composed of two different algorithms, the hashing algorithm (SHA-1 for example) and the signing algorithm (RSA for example). Over time these algorithms, or the parameters they use, need to be updated to improve security.
As computational power increases, the hashing algorithms start to become susceptible to hashing collisions. MD5 was used for a number of years until it was found to have a security flaw in 2004 which set the stage for SHA-1. As a result, Certificate Authorities have aimed to comply with NIST (National Institute of Standards and Technology) recommendations, by ensuring all new RSA certificates have keys of 2048 bits in length or longer.
As with other forms of identification, certificate technology has progressed over the years. Current standards mandate using newer algorithms in this ever-evolving industry.
Aged Security
The CA/Browser Forum, an industry body made up of Certificate Authorities (CAs), web browsers and operating systems, recently passed ballot 193 to reduce the maximum validity period for SSL/TLS Certificates to two years (825 days). Prior to this, the standard validity was three years for Domain Validated (DV) and Organization Validated (OV) Certificates; Extended Validation (EV) Certificates have always been capped at two years.
The change went into effect March 1, 2018, and affects all CAs and all types of SSL/TLS Certificates. Longer certificate validity periods can delay widespread compliance with new guidelines since changes wouldn’t go fully into effect until all existing (issued before the update) certificates expired.
Decreasing the maximum lifetime of certificates from three years to two years helps reduce the presence of older, outdated and possibly vulnerable certificates that were issued before new guidelines were put in place.
This also means that the process and time needed to replace and update certificates will happen more often causing higher operating costs to deal with the time need to update such servers and applications with new certificates.
Live Documentation
Because of everything needed to keep track of on a certificate, administrators should track where certificates are, for what purpose and relationship they might have. The documents used in most organization are forever being updated to include additions or changes. These documents must be considered a live document to stay up to date in order capture all the latest information which mean there must be policies in place to keep them that way.
This is an excellent reminder about the role certificate management and inventory tools can play in simplifying administration. Most CAs offer these types of services, which help centralize certificate activity so you can monitor where you have certificates and when they need to be renewed.
Items that need to be documented include:
• Relationship maps where the communication and handshakes take place
• Certificate FQDN with split DNS considerations
• Certificate expiration and projected project replacement timelines
• Proactive alert/alarms for certificate expirations.
Closing
Equal to the evolution of your Network, attacks are evolving in their own sophistication and their ability to evade detection. Whether it’s by intercepting traffic on the internet or causing a break in security, cyberattacks are becoming more targeted and have greater financial consequences for your organization. Encryption and digital certificates are important precautions that every organization should consider to help fight cyberattacks and stay safe.
