Online services and remote access platforms have become common place, with more and more sensitive information being made accessible via these tools, it is more important than ever to protect these services from interception, manipulation and impersonation; the primary control in this space is ensuring only services intended for public use are exposed to the open internet, with all other services concealed behind a VPN, wherever possible; while this does introduce a deployment and maintenance headache, it would have thwarted a significant, and growing, portion of recent successful compromises handled by Janet CSIRT.

A robust certificate, protocol and cipher management process is key to protecting your services both externally and internally. The Jisc SOC frequently see evidence, during investigations and in Open Source intelligence, of services hosted on Janet that are not following best practice when it comes to digital certificates, supported protocols and ciphers. Common issues include services that: use SHA1 certificates (deprecated in 2017), support insecure protocols and ciphers (including some deprecated in 2015), and, present self-sign certificates; all of which are likely to trigger “Not Secure” warnings to users of these services, teaching them to ignore such warnings.

A culture of ignoring security warnings makes it much easier to successfully socially engineer users, how do they know which warnings they should ignore and which they should be alarmed by? Every effort should be made to ensure that legitimate services do not trigger such warnings, making a warning an unusual, noteworthy event for a user to report to their security team.

Certificates

Digital certificates are used to distribute a public key and cryptographically prove the identity of a system, or user, that holds the corresponding private key for secure communications. Certificates are issued by Certification Authorities (CAs) who are responsible for validating all information to be included on the certificate. While it is possible to generate self-signed certificates, these cannot be revoked by a CA if the private key is compromised and without distributing this certificate to all clients, users will see certificate warnings.

In order for users to access a secured service without receiving certificate errors the certificate has to be:

• Issued for the domain name being used to access the service,
• Within its validity period,
• Signed by a CA trusted by the users device, and,
• Not be revoked by the CA that signed it.

A significant portion of users have come to accept certificate warnings without a second thought, due to poor certificate management by a wide range of organisations from the smallest to the biggest players in internet technology, particularly through failure to renew certificates in a timely fashion, this learned behaviour fundamentally undermines the value of certificates.

Protocol & Cipher Management

Certificates are exchanged using encryption protocols, typically TLS, once a certificate is accepted, an encrypted session is established using a mutually agreed cipher suite. Despite SSLv3, TLSv1.0 and TLSv1.1 still being widely supported by systems across the internet, at the time of writing, cryptanalyst only consider TLSv1.2 and TLSv1.3 sufficiently secure for continued use. The same issue is widespread when looking at the myriad of cipher suites used behind these protocols.

A careful balance has to be struck between security and compatibility when selecting protocols and cipher suites, for example an email server that mandates TLS1.3 with AES256-GCM for all connections may be considered quite secure (for protocol and cipher suite support anyway), however, a significant portion of other mail servers on the internet will be unable to connect to it, due to either only supporting older protocols or in some cases not supporting encryption at all.

Without periodically assessing compatibility requirements to feed into building and enforcing a strong security baseline of allowed protocols and ciphers TLS will almost certainly offer a false sense of security.

Recommendations

In order to secure systems from impersonation, manipulation and interception attacks, it is highly recommended that members take the following steps:

1. Educate users on the importance of checking connections are secure, being suspicious of certificate warnings and reporting concerns; users are your first line of defence.
2. Keep all systems, especially those offering external services, patched and within vendor support; ensuring known security vulnerabilities are addressed regularly.
3. Adopt a TLS everywhere policy, where practical, users can then be suspicious of anything served insecurely.
4. Adopt Single Sign On (SSO), e.g. using the UK Access Management Federation service, ideally with two factor authentication, for all services, where practical, users will find it easier to check they are on https://sso.myuni.ac.uk before entering credentials, instead of trying to remember every domain they are legitimately prompted on.
5. Utilise certificates from a recognised CA for all services accessed via unmanaged devices, members can use the Jisc Certificate Service to achieve this. If a user sees a warning, it is likely due to an actual problem.
6. For systems only accessed via managed devices, use either certificates from a recognised CA or establish a well-documented, strictly controlled internal CA, securely distributing the CA certificate to the managed devices (e.g. via Group Policy or puppet). Be sure to review and, where practical, align to the CA/Browser Forum’s Baseline Requirements and Certificate Policies and Certificate Practice Statements from recognised CAs before doing so.
7. Utilise a tool such as Mozilla’s SSL Configuration Generator for a strong starting point for developing an SSL/TLS Security Baseline that meets your compatibility needs, document and roll out this security baseline to all services, then, periodically review it. Consider including a review of, and compliance checks against, this baseline in the scope of Penetration Tests.
8. Implement Certification Authority Authorisation (CAA) DNS records for your domains, preventing participating CAs from issuing certificates unless specifically authorised to do so.
9. Once a strong management regime is in place, implement HTTP Strict-Transport-Security (HSTS), DNS-based Authentication of Named Entities (DANE) and/or other TLS Enforcement standards; instructing clients to refuse to connect if TLS cannot be securely negotiated and verified.
10. Investigate complementary standards, such as Content Security Policies (CSPs) to restrict which external resources can be injected into content you serve.
11. Store private keys in export-proof hardware stores, such as a Trusted Platform Module (TPM) or Hardware Security Module (HSM); reducing the chance of keys being stolen should a successful compromise occur.

Jisc’s Trust and identity consultancy service may be able to support you with a number of these steps.

A number of links have been provided in this post in the hope they are useful, however, Jisc cannot take responsibility for their content, please be sure to take due care and follow your local security policies when accessing links.