Azure DevOps requires TLS 1.2 on all connections including Visual Studio

Ruben R

Permanent rollout of TLS 1.0/1.1 deprecation starts on March 31, 2022


Azure DevOps has provided new guidance and timelines for the TLS 1.0/1.1 deprecation.

While the permanent rollout will start on March 31, 2022, the team plans to temporarily disable support twice during March to help customers identify potential issues before the permanent rollout takes place.

Please review their new blog post for full details.

TLS 1.0/1.1 deprecation change rolled back


The Azure DevOps team rolled back the change it made on Jan 31st, 2022, to deprecate support for older versions of TLS (1.0/1.1) due to unexpected issues. For now, Azure DevOps continues to support calls made over TLS 1.0/1.1. Their team is working on a plan to address the issues and will announce a new deprecation date soon.

Starting Monday January 31st, Azure DevOps will no longer accept connections coming over TLS 1.0 and 1.1 due to security vulnerabilities in those protocols. Developers have increasingly become the target of hackers and these protocols have known security vulnerabilities not specific to Microsoft’s implementation. Going forward Azure DevOps will require TLS 1.2 for all HTTPS connections, including their web API and Git services. To avoid any issues, please upgrade to the latest version of Visual Studio.

Visual Studio 2022, Visual Studio 2019, and the latest release of Visual Studio 2017 (version 15.9 and beyond) already use TLS 1.2 and are not impacted by the upcoming change. Earlier versions of Visual Studio that are running on devices not configured to use TLS 1.2, may begin to see errors when connecting to Azure DevOps services. Features such as signing into Visual Studio, unlocking the IDE, and remote Git operations could be affected.

Some of the error messages may include:

fatal: HttpRequestException encountered. An error occurred while sending the request. while fetching or pushing to a Git repository.

error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

How to enable TLS 1.2

The easiest way to avoid these issues is to upgrade to the latest version of Visual Studio as it already uses TLS 1.2 for all HTTPS connections. If upgrading Visual Studio is not an option, you can set a set a machine-wide registry key to enable TLS 1.2 on all .NET applications including Visual Studio. Last, you can also install the latest Git for Windows tools that also use TLS 1.2.

The Azure DevOps blog has more information on the upcoming TLS changes. You can also read more about the official depreciation of TLS 1.0 and 1.1 in the IETF Data Tracker.

6 comments

Comments are closed. Login to edit/delete your existing comments

  • MK

    This change broke the connectivity to the azure organizations from self hosted agents on Windows server 2012 R2 machines. Not be able to get the connection working even after following the steps to enable TLS1.2. Any pointers on that ?

  • Ben Reisner

    Hello,

    Thank you and/or everyone involved for rolling back this change. A few questions:

    1) Is there any way I can subscribe to some sort of email notifications for upcoming possibly breaking changes that Azure DevOps makes?

    Unless I’m mistaken the only way I could have known about this planned change was if I monitored the blogs and didn’t miss the post. There wasn’t even any banner or notifications from within dev.azure.com’s website.

    I would think that project administrators should have been emailed automatically with increasing aggresiveness if there were any connections being made to their projects with protocols that would soon be deprecated.

    2) I’m sure the discussion is still ongoing on how to best implement this change, but I would like to advocate for having a seperate preview site (dev-preview.azure.com) that supports only TLS 1.2. This would allow myself and others to test the connection and resolve issues at our convenience. The short hour long temporary disabling that was done is really of limited use.

    My organization’s issue is a Microsoft Access 2010 based application that uses a full Microsoft stack for source control. We use Microsoft Access 2010, Access Developer Extensions, Visual Studio 2012 Team Explorer, MSSCCI to bridge between Access Developer Extensions and Visual Studio 2012, and Azure DevOps.

    I expect that it is the Visual Studio 2012 that is making the actual connection, I’m not sure if the ‘system-wide’ registry settings will force Visual Studio 2012 to use TLS 1.2, and I’ve been coming up empty handed on how to find out and test.

    I would comment on the original post but comments are closed on that post