Exoprise recently released two new CloudReady sensors for monitoring Transport Layer Security (TLS), aka Secure Sockets Layer (SSL), connections end-to-end. TLS/SSL is the foundation for just about every web request and transaction across the Internet today. Arguably, SSL is as important as TCP/IP itself to the formation of our modern-day Internet, SaaS and Cloud world.
The new SSLCheck and SSLMonitor sensors help you protect your organization against expired X.509 certificates, mis-configured servers, and potential Man-in-the-Middle spoofing. Whether protecting your own servers or ensuring the uptime of external SaaS services like Office 365, Salesforce or Workday, administrators should monitor all of their TLS/SSL health, configuration and certificate infrastructure. Now, with the help of Exoprise, you can easily monitor these critical components in real-time.
TLS or SSL
Quickly, TLS and SSL are nowadays the same thing. SSL often refers to older versions of the protocol. Most administrators have moved to TLS 1.1 version or better. Read this this wikipedia article for a more thorough understanding of TLS versioning and history. Or read this Microsoft article, Preparing for TLS 1.2 in Office 365, for an example of the rational and preparedness of a move to TLS 1.2.
Who, How & Why Monitor TLS/SSL Connections
Obviously, we’re big believers of proactive monitoring here at Exoprise. But often, for our customers, its about the changing perspective of cloud and SaaS that requires new approaches to the monitoring of external services and dependencies.
With software-as-a-service you’re now dependent on lots of different pieces that you may not know about. If one of those certificates expire, or there’s a TLS cipher configuration change, your apps and business are going to break badly. Here’s a summary of who, how and why our new SSL monitoring helps and protects:
- Application owners that don’t own the server infrastructure or configuration. CloudReady sensors validate connection handshakes from your Windows® machine. This tests the built-in Windows certificate store, network and all the way through to the server configuration.
- If you don’t own the server configurations or Group policy that’s updating client certificate stores, the applications you’re responsible for can break and break badly.
- When Microsoft or Single Sign-on vendors have upcoming certificate expirations or varying TLS attestation you want to know about it. Usually, when certificates update, there’s accompanying changes to the infrastructure and configuration. Often, they are the cause of cloud outages.
- Network Administrators who don’t control access or the configuration of SSL protected infrastructure. Applications, services and, in particular, cloud access is dependent on TLS protected components. Network admins may not have access to server or client machines but a single SSLCheck sensor can test up to 5 different endpoints — internal or external.
- DevOps teams that may not be aware of end-to-end dependencies. TLS/SSL servers should be continuously tested, end-to-end from real client access points, to ensure certificate stores and root certificates aren’t exploited or altered. CloudReady SSL sensors deployed both inside your firewall and outside in the cloud on our public sites. can provide the assurance and continuous testing that’s needed.
- Security Administrators performing TLS/SSL Web Inspection. SSL Web inspection (man-in-the-middling) is quite common within the Enterprise. If you’re dependent on network security vendors generating certificates, on the fly, you should monitor the performance and authentication.
Monitor up to 5 TLS Servers for Expiration, Performance, and Authentication
The SSLCheck sensor monitors up to 5 TLS protected servers for health, validity, performance AND X.509 certificate expiration. Get proactive notifications when something has changed that may block SSL connections. Get configurable notifications about pending SSL certificate expiration even if you don’t own the servers or certificate infrastructure. Importantly, the sensor make continuous assertions that the TLS encryption and authentication is working correctly as frequently as once a minute. Here’s additional details:
- Mean or average SSL Validation Time for all endpoints
This value is an excellent indicator of overall network performance, end-to-end. TLS negotiation is chatty with a quick succession of packets back and forth so can indicate slower network performance, bandwidth and packet loss.
- Mean TCPIP Connect time for all endpoints.
Good indicator of overall network performance from the client to the server(s).
- Nearest expiration for all endpoints.
By default, alarms are created for this element within 10 days of certificate expiration. Alarms can be customized for any of the endpoints and the notification period can be adjusted.
- Endpoint SSL Get Time
This is the time it takes to successfully handshake the Transport Layer Security for the connection.
- Endpoint TCP/IP Connect time
Time it takes to connect to the server prior to the TLS handshake.
- Endpoint Expiration
Days to expiration for each individual target. Expiration alarms can be configured for each endpoint target.
As with all of the CloudReady, all of the elements can be queried, exported and integrated through any ticketing or existing event management system.
Deep Monitoring for up to 2 TLS Servers, monitor changes, detect MITM spoofing
The SSLMonitor sensor enables administrators to proactively detect TLS/SSL changes to server and certificate changes. Uniquely, the SSLMonitor sensor can detect potential man-in-the-middle attacks against your TLS/SSL infrastructure. SSLMonitor is designed for deep inspection of servers and their certificates, typically mission-critical or heavily used pieces of infrastructure.
The SSLMonitor sensor provides many of the same elements and notifications as the SSLCheck sensor but with additional proactive checks for Server and Certificate changes:
- Certificate changes
Certificates and their chains are analyzed for changes during the operations of the SSLMonitor sensor. If changes aren’t expected then each notification should be investigated as they are indication of a change to the TLS/SSL configuration.
- Cipher/Server changes
When Cipher or Server configuration changes for the TLS handshake and setup, this can affect the authentication clients, some clients may not be capable of authenticating anymore or it could be and indication of a man-in-the-middle attack. Unplanned server cipher changes should be investigated for any of the SSL endpoints being monitored.
- Potential Man-in-the-Middle detected
For each SSLMonitor sensor run, the certificates are retrieved, checked and analyzed from multiple vantage points. By default the servers are checked from the CloudReady servers for external servers. The certificate identifiers and thumbprints are analyzed, as well as the certificate chains and compared historically for potential man-in-the-middle detection. A notification and alarm is generated if differences or changes are detected.
Detecting end-to-end changes for servers and certificates is the right job for the SSLMonitor sensor when it comes to protected infrastructure that’s owned by others but is mission-critical to the operations of your organization and business.
No Exoprise blog article would be complete without evidence and screenshots of its reality. Scan the following gallery of setup and resultant screens that are examples of how easy it is to setup TLS/SSL monitoring and what some of the sample screens look like.
Benefits of CloudReady TLS Monitoring
- Automate TLS/SSL X.509 Certificate monitoring for your own servers
- Monitor TLS/SSL authentication for dependent services like Single Sign-On and your cloud infrastructure
- Improve server and application availability
- Avoid unplanned service disruption and outages
- Reduce or avoid financial impact
Start Monitoring Your TLS / SSL Infrastructure Today
As with all of the CloudReady sensors, they take minutes to deploy, are wizard driven and can be deployed internally or externally for monitoring any website or TLS server. Give them a try.