Perché utilizzare SSL per il repository NuGet?

Question

Abbiamo avuto un problema con la nostra macchina di compilazione automatica ieri. Stiamo usando un server TFS Build e, quando ha provato a scaricare automaticamente i pacchetti NuGet, abbiamo ottenuto il famigerato "La connessione sottostante è stata chiusa: impossibile stabilire una relazione di trust per il canale sicuro SSL/TLS".

Ci sono molti fili attorno alla rete riguardo al perché questo accade. Questa non è la mia domanda. Può essere fissato abbastanza facilmente cambiando il repository NuGet da

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

a

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

o

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

Quello che mi piacerebbe sapere è il motivo per cui il repository è utilizzando SSL in il primo posto? Presumo che sia lì per una ragione, ma non riesco a capire cosa. Non c'è accesso che richiederebbe sicurezza. Non riesco a pensare a nessuna informazione inviata che dovrebbe essere sicura. Voglio solo assicurarmi che usando una connessione non protetta (che funziona bene) non stiamo compromettendo in qualche modo la nostra macchina di compilazione.

Qualcuno può spiegare cosa si ottiene dalla connessione a NuGet utilizzando una connessione protetta?

Answer 1

Non riesco a pensare a nessuna informazione inviata che dovrebbe essere protetta .

Non è necessariamente perché le informazioni scambiate con nuget.org contengono qualcosa di segreto e quindi devono essere sicure. Usando l'SSL sarai certo che in realtà è nuget.org con cui stai parlando. Senza SSL, qualcuno potrebbe in teoria nutrire pacchetti fasulli, e questo potrebbe essere un problema di sicurezza.

Per quanto riguarda il tuo problema con "Impossibile stabilire la relazione di fiducia per la SSL/TLS canale sicuro", abbiamo avuto un problema simile quando abbiamo iniziato a utilizzare un nuovo server di generazione:

Se si guarda il certificato SSL presentato da https://nuget.org/, il percorso di certificazione è: GeoTrust Global CA> RapidSSL CA> * .nuget.org

GeoTrust Global CA mancava come CA attendibile sul nostro nuovo server di build, quindi il problema è stato facilmente risolto aggiungendoli all'elenco dei build server delle CA radice affidabili (utilizzando la console MMC con lo snap-in Certificati).

Aggiornamento:
su un servizio più tardi, ho sperimentato lo stesso problema SSL, e l'aggiunta di GeoTrust come un CA di fiducia da sola non ha risolto il problema. Nell'aggiunta ,, il server mancava anche alla CA radice per https://go.microsoft.com/, che è Baltimore CyberTrust Root (vai a https://microsoft.com e sarai in grado di visualizzare e scaricare il certificato). Aggiungendo questo alla lista dei server delle CA radice affidabili risolto il problema.