With TLSv1.3 approved and in the Internet Engineering Task Force (IETF) publication queue it’s time to think about deployment options and obstacles, and planning for changes inherent in this revision. Regardless of when you plan to upgrade it may require significant planning for internal applications and network architectures, less so for Internet-based sessions. Supporting libraries and browsers are ready for this upcoming release. As the former IETF Area Director responsible for TLSv1.3, I assisted with managing the tough conversations, and making sure they could occur, around monitoring and managing networks with TLSv1.3.
Options exist to maintain visibility, but identifying and implementing the most appropriate choice for your network requires careful planning. In an ideal world, organizations would be able to upgrade usage of TLSv1.2 to TLSv1.3 in their internal networks seamlessly. This will happen for some enterprises, where they have already shifted to a network without a perimeter, or no singe discernable firewalled gateway point of access. These networks already rely upon secure TLS sessions – which are more difficult to intercept – following the deployment best practices for TLSv1.2 in RFC7525. In other cases, where possible, the enterprise moved away from a reliance on out-of-band or passive TLS interception middleboxes to rely on the information available at the end point and active interception for monitoring via a proxy-based solution. If your organization still relies upon TLSv1.0 or TLSv1.1, you should minimally move to TLSv1.2 (Read more...)
*** This is a Security Bloggers Network syndicated blog from RSA Blog authored by Kathleen Moriarty. Read the original post at: http://www.rsa.com/en-us/blog/2018-06/what-are-my-options-session-encryption-protocols-looking-forward.html