Last November, we shared our two-stage plan for deprecating TLS 1.0/1.1 on NuGet.org and actions you can take today to ensure your systems use TLS 1.2. In this post, we will go into more details and a specific timeline for Stage 1 i.e.
co-authored by Scott Bommarito
At Microsoft, using the latest and secure encryption techniques is very important to us to ensure the security and privacy of our customers. TLS 1.0 and TLS 1.1, released in 1999 and 2006 respectively, are known to be vulnerable to a number of attacks including POODLE and BEAST.
For the past several months we have focused on various features to improve package security and trust. Around a year back, we had announced our plans on various signing functionalities that we have been implementing at a steady pace. We enabled package author signing and NuGet.org repository signing earlier this year.
In May, we implemented Stage 1 and enabled support for any NuGet.org user to submit signed packages to NuGet.org. Today, we are announcing Stage 2 of our NuGet package signing journey – tamper proofing the entire package dependency graph.
What is a Repository Signature?
In September 2017, we announced our plans to improve the security of the NuGet ecosystem by introducing the ability for package authors to sign packages. Today, we want to announce support for any NuGet.org user to submit signed packages to NuGet.org.
We had previously announced the deprecation of NuGet.org’s home-grown authentication in favor of Microsoft accounts (MSA) that will allow us to add support for additional security systems such as two-factor authentication (2FA). We will be disabling the NuGet.org’s home-grown authentication mechanism starting June 1st,
In our NuGet Fall 2017 Roadmap, we highlighted security as the main area of investment over the next few months. This blog post describes a major part of that roadmap in greater detail – package signing.
We started talking about supporting signed packages on NuGet.org a while ago.
Update on 10/16/2017: Package ID Prefix Reservation is now live. The documentation can be found here.
We want to start this post with a huge thanks to you, the NuGet community. Over the last several months we have been talking to many of you to get feedback on NuGet package identity and trust.
At NuGet, we are constantly improving our security. One of the steps we are taking is to move our HTTPS end points to meet industry standards for algorithms and protocols. This means that connecting to nuget.org services from machines that don’t support modern cipher algorithms will no longer be supported (such as TLS 1.0 support in Windows XP).
In June, we published a blog post announcing Expiring API Keys. We received a lot of great feedback from the community about it. In retrospect, we did not do a great job explaining the motivation and reasoning for this security measure to the community.