This post is the second in a three-part series on TLSv1.3 adoption. This post digs deeper into the types of monitoring performed on internal and external networks to better understand considerations for your deployment plans.
Network operators, especially those managing enterprise networks and data centres, have expressed concern with deploying TLSv1.3, which is normal at the start of an adoption curve.
Through much work — listening to operators and their explicit concerns — deploying TLSv1.3 on Internet-based sessions terminating at the edge of the corporate network or data centre is a logical first step that should not be business-impacting. This conclusion is based on discussions with operators in several venues and contributions to ‘The Effect of Pervasive Monitoring on Operations’, a survey of management and monitoring techniques in use by operators on service provider and enterprise networks. Deployments on internal networks may require further study by organizations evaluating their network architecture, security policies, monitoring, and management toolsets.
Service providers share their monitoring techniques
Much insight was gleaned from the survey, as service providers discussed their monitoring techniques on the Internet.
A reliable and trusted operator contributed that most of the monitoring performed is kept to packet headers for the transport, network, and data link layers. This information continues to be available in TLSv1.3, although handshake messages after the SERVER HELLO are encrypted via EncryptedExtensions, leaving some previously available information encrypted.
One such example is application-layer protocol negotiation (ALPN), where the request is in the clear and the response is encrypted. The ALPN response includes the protocol to be used, as selected by the server, offering confidentiality of this information from anyone observing the traffic. This may have some impact on monitoring, requiring a shift in practices based on available information or the point of monitoring, for example edge versus network (if this type of observation is permitted by policy at the edge).
One of our learnings from the survey was that troubleshooting customers’ requests requires additional information to debug an issue; service providers typically request the session capture information from the customer close to the edge. Network monitoring remained limited to the headers previously mentioned.
If the customer is fine exposing that information and provides it via a packet capture from their point of visibility, this type of debugging is still possible with TLSv1.3, or even IPsec, with a lower level of on-the-wire visibility. Note: You may want to consider redacting information from packet content to avoid unintended data leakage.
TLSv1.3 adoption and deployment options
TLSv1.3 is a more secure protocol than TLS v1.2, with improved protection against interception and should be strongly considered to better protect your customers’ Internet-based sessions.
We are in the learning curve prior to an adoption phase; understanding the clear benefits and where to deploy first will assist with adoption. The balance of monitoring and encryption is up to each organization, as is understanding when and where to deploy TLSv1.3.
TLSv1.3 provides forward secrecy and is provably secure (when 0-RTT is not in use) and should strongly be considered to protect sessions from an interception on the Internet. 0-RTT enhances performance on session renegotiation when pre-shared keys are in use. This addition is included in TLSv1.3 to assist with enhanced performance, but may not be right for your TLSv1.3 sessions. I recommend taking a hard look, considering whether 0-RTT is a good match for the applications and data you are hosting.
If performance is critical and outweighs the possible threat of a replay attack and loss of forwarding secrecy, implement TLSv1.3 with 0-RTT and the mitigation options. If you run business-critical servers with sensitive data, think twice about relying on the mitigation options. Instead, favour using an implementation that separates the streams for 0-RTT and 1-RTT, which also helps avoid possible configuration errors.
Contribute to monitoring solutions
Turning toward enterprise and data centre networks, the monitoring performed does include inspection of the packet payload at times. This may be the case for intrusion detection and information leakage monitoring, as well as debugging application-level problems.
The difference for the enterprise scenario is that once inside the data centre, the enterprise owns the data on their servers and has access to it anyway. For user sessions to the Internet, users are typically subject to monitoring per policy and user agreements from the time of employment.
Organizations often have exceptions to this monitoring and exclude financial sites. For example, Germany has a legal expectation that employees have a right to perform some personal business from the workplace without interception.
There have been two drafts submitted to date to the IETF detailing the types of monitoring performed and techniques used specifically in enterprise and data centre settings for visibility. They are open for contribution via the authors or on an IETF mailing list and include: TLS 1.3 Impact on Network-Based Security and Why Enterprises Need Out-of-Band TLS Decryption. Having this type of information as accurate and representative of real operational networks assists protocol designers as they consider use cases and possible solutions.
The first post in this series details this problem a bit better with the transition to TLSv1.3. The final post in this series dives into the proposals for visibility and alternate solutions.
Adapted from the original post which appeared on RSA Blog.
Kathleen Moriarty is Global Lead Security Architect with the Dell EMC Office of the CTO working on technology strategy and standards, and former IETF Security Area Director.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.