Compatibility and Security
does not support Microsoft Internet Explorer 8 and earlier versions.
DX APP Synthetic Monitordoes not support Microsoft Internet Explorer 8 and earlier versions.
HTTPS Monitors and Ciphers
If an encrypted connection to a server is considered, the secure ciphers that are used in the encryption must be strong enough. Cryptography libraries that are used by both web servers and browsers (for example, OpenSSL) support many different ciphers. During handshake the web server and client (browser) agree on the most secure cipher that is supported and trusted by both sides. If they do not find such a cipher the connection fails.
Two problems arise. One is that the "trusted" cipher list changes in time with new vulnerabilities discovered and growing computer power. If an administrator does not check and update, the web server regularly the configured cipher list becomes weak. After some time, modern browsers might report that a site is not trusted and might discourage users from visiting such sites.
The second problem is that the cipher list exchange is not symmetric - the browser offers a cipher list. The web server selects one of the ciphers or rejects the connection. It might seem that the more ciphers that are included in the cipher list, the bigger is the chance that the server accepts one of them. Unfortunately, some web servers refuse to communicate with browsers offering weak ciphers because the browser is flagged as not trustworthy, even though a common strong cipher is available. Browsers usually include an option (browser specific) to retry the connection, if the first handshake fails. This situation complicates the decision over what is a failed test and what is not. The ASM HTTPS monitor does not retry with alternative cipher suite lists.
Any handshake which fails is reported as a failed connection.
To handle these situations with HTTPS monitors, use the option to select the cipher list. The easiest and recommended way is to use the default which is a balanced list of ciphers. Take the ciphers from the underlying library (OpenSSL). If your server does not work (handshake errors failure), try "All cipher suites" or "Low encryption cipher suites". This solution is only temporary and we recommend that you ask your administrator to update the web server. If your server is configured not to trust and communicate with browsers that are offering anything but strong ciphers, use the
High Encryption Cipher Suitesoption.
SSLv3 Not Supported by Default
Due to several vulnerabilities found in the SSLv3 protocol, we are moving away from it. This situation primarily affects HTTPS monitors. SSLv3 connections are not attempted when the Encryption option is set to “Negotiate” (default). If you still need SSLv3, set the Encryption option to “SSLv3” explicitly.
You might find other consequences of SSLv3 not being supported by default. The handshake process has changed and your server (the monitored service) can start reporting handshake errors even if it does not rely on SSLv3. This condition depends on the server settings. For maximum compatibility, the TLS handshake process starts with TLS 1.0. The process tries higher versions if their support is announced by the server. If, on the other hand, the server drops the TLS 1.0 connection attempt right away, the HTTPS monitor might report an SSL handshake error. In that case, we recommend setting the desired TLS version precisely in the monitor settings Encryption option.