Are TLS vulnerabilities considered critical for internal network
- Exploring TISAX Version 6 – A Comprehensive Guide - 10/01/2024
- TLS Based Attacks - 11/12/2023
- Are TLS vulnerabilities considered critical for internal network - 11/12/2023
Are TLS vulnerabilities considered critical for internal network?
We will not go into what is TLS, how it works, why its important to security etc. We will assume that everyone know about it and directly jump to answering the question.
The answer is Yes – it is of critical nature for internal networks.
Why TLS is critical for LAN?
Lets look at some considerations:
- External Interfaces: Disabling TLS 1.2 and lower versions externally is commonly recommended to protect against external threats. Many security standards and best practices advise using modern TLS versions to benefit from the latest security features and cryptographic algorithms.
- Internal Networks: While it’s crucial to prioritize security internally, disabling older TLS versions within internal networks might have some flexibility. Internal systems may have dependencies on older protocols, and the risk of external attackers exploiting vulnerabilities might be lower within a well-secured internal network.
What is exactly caused by TLS vulnerabilities
Short answer is MITM (Man in the middle attack).
All the attacks (for ex. Poodle, SWEET32 etc) exploit the TLS vulnerabilities to be able to hijack an existing TLS session. Please note, this session has nothing to do with HTTP application session. This session takes place at Layer 3 and Layer 6.
Having this in mind, now lets see whether TLS will be more serious for internal network or external network.
Since in the external network the source (connecting machine) and the victim (vulnerable TLS machine) are away from each other in physical sense and in separate IP range from network sense, it is almost impossible for the hacker to assume the MITM position. Its possible only if hacker is sitting with the source in the same network, or is sitting in datacentre or office, in the network with vulnerable TLS machine. Since both these situations are far remote, TLS vulnerability is hardly possible in external networks.
Applying the same scenario for internal network, we can imagine that its very easily possible that within an office network there can be an attacker who is exploiting a TLS session by being in the same network as the connecting machine. Hence TLS vulnerability is very much possible in the internal network.
For internal network, the TLS must be fixed on the servers as well as on the desktops which connect to the server.
Whereas for external network, TLS is recommended to be fixed.
Many can argue about this and say opposite but what is mentioned above is the technical fact. Of course it ultimately depends on other factors implemented or not implemented in the network.
For ex : Disabling TLS 1.2 and lower versions for external interfaces is generally a good security practice, as it helps mitigate vulnerabilities associated with older TLS versions. However, the decision to disable these versions internally depends on various factors, including your organization’s specific security policies (for ex ipsec, switch level security, patching, usage of HTTPS in general etc), the types of systems in use, and the overall security requirements.
Its important to remember that the landscape of security is dynamic, and vulnerabilities can emerge. Regularly reviewing and updating security configurations, both internally and externally, is essential to maintaining a robust security posture.
Always consider your organization’s specific security policies, conduct risk assessments, and stay informed about the latest security developments when making decisions about TLS protocol versions. Additionally, ensure that any decisions align with compliance requirements that may apply to your organization.
For those who are intrigued to know more, here is our blog about TLS Vulnerabilities and Attacks.