Why use SSL for the NuGet repository?

Question

We had an issue with our automated build machine yesterday. We are using a TFS Build server, and when it tried to automatically download NuGet packages, we got the infamous "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel" error.

There are a lot of threads around the 'net regarding why this happens. That isn't my question. It can be fixed easily enough by changing your NuGet repository from

https://nuget.org/api/v2/

to

http://nuget.org/api/v2/ 

or

http://packages.nuget.org/v1/FeedService.svc/

What I'd like to know is why the repository is using SSL in the first place? I assume it is there for a reason, but I can't figure out what. There is no login that would require security. I can't think of any information being sent that would need to be secure. I just want to make sure that by using an unsecured connection (which works just fine) we aren't somehow compromising our build machine.

Can anyone explain what is gained from connecting to NuGet using a secured connection?

Answer 1

I can't think of any information being sent that would need to be secure.

It is not necessarily because the information you exchange with nuget.org contains anything secret and thus needs to be secure. By using using SSL you will be certain that it actually is nuget.org you're talking with. Without SSL, somebody might in theory be feeding you bogus packages, and that might be a security problem.

As for the issue you're experiencing with "Could not establish trust relationship for the SSL/TLS secure channel", we've had a similar problem when we started using a new build server:

If you look at the SSL certificate presented by https://nuget.org/, the certification path is: GeoTrust Global CA > RapidSSL CA > *.nuget.org

GeoTrust Global CA was missing as a trusted CA on our new build server, so the problem was easily solved by adding them to the build servers list of trusted root CAs (using the MMC console with the Certificates snap-in).

Update:
On a later service, I've experienced the same SSL issue, and adding GeoTrust as a trusted CA alone didn't solve the problem. In addition, the server was also missing to root CA for https://go.microsoft.com/, which is Baltimore CyberTrust Root (go to https://microsoft.com, and you'll be able to view and download the certificate). Adding this to the servers list of trusted root CAs solved the issue.