SSL et TLS obsolètes (1.0 et 1.1) pour l’application cliente de service Web sur .Net 3.5

Selon PCI, nous devons cesser d’utiliser SSL et TLS (1.0 et 1.1 dans certaines mises en œuvre) à compter du 30 juin 2016, conformément à http://blog.securitymesortingcs.com/2015/04/pci-3-1-ssl-and- tls.html

Nous avons une application client construite sur .Net 3.5 qui utilise l’object HttpWebRequest pour se connecter aux services Web.

Selon MSDN SecurityProtocolType ( https://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx ) ne prend en charge que Ssl3 et Tls (1.0) sur .Net Framework 4 ou au dessous de. Tls11 et Tls12 ne sont pris en charge que par .Net Framework 4.5 / 4.6

Cela signifie-t-il que pour être dans l’environnement de données de titulaire de carte et entièrement conforme à la norme pci, nous devons mettre à niveau toutes les applications vers .Net 4.5 / 4.6 et autoriser uniquement Tls12 SecurityProtocolType à se connecter à des services Web externes à l’aide de HttpWebRequest?

Tout canal de communication qui utilise actuellement SSL / TLS ancien ou qui est prêt à les accepter en négociation et qui fait partie de l’environnement de données du titulaire de carte en tant que contrôle de sécurité doit être modifié de sorte qu’il utilise uniquement TLS 1.1 ) ou au-dessus.

Vous devez recomstackr sous .Net 4.5 ou une version ultérieure (TLS 1.2 n’est pas activé par défaut si des modifications de code sont nécessaires) ou utilisez une bibliothèque tierce qui prend en charge les protocoles requirejs.

Notez que si vous savez que votre système utilise SSL / TLS précoce, vous devez créer un plan / document de réduction des risques.

SUPPLÉMENT D’INFORMATIONS Migration de SSL et Early TLS

En fait, vous pouvez utiliser TLS 1.2 dans les frameworks inférieurs à 4.5 (au moins, je l’ai géré dans le client .NET Framework 4). Au lieu d’utiliser la commande classic afin de définir le protocole sur Tls12, vous pouvez le contourner à l’aide de l’id de ce protocole.

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; 

Microsoft a réalisé les correctifs impensables et publiés pour cette

  • KB3154518 – Cumul de fiabilité HR-1605 – NDP 2.0 SP2 – Win7 SP1 / Win 2008 R2 SP1
  • KB3154519 – Cumul de fiabilité HR-1605 – NDP 2.0 SP2 – Win8 RTM / Win 2012 RTM
  • KB3154520 – Cumul de fiabilité HR-1605 – NDP 2.0 SP2 – Win8.1RTM / Win 2012 R2 RTM
  • KB3156421 – 1605 Correctif cumulatif via Windows Update pour Windows 10.

La seule chose qu’ils ne semblent pas avoir faite est de mettre à jour wsdl.exe pour prendre en charge TLS1.1 ou 1.2. Voici ce qui se passe si vous essayez de pointer wsdle.exe de .Net 4.7 vers un service Web ne prenant pas en charge TLS1.0:

 Microsoft (R) Web Services Description Language Utility [Microsoft (R) .NET Framework, Version 4.7.2558.0] Copyright (C) Microsoft Corporation. All rights reserved. Error: There was an error processing 'http:///_vti_bin/Authentication.asmx?wsdl'. - There was an error downloading 'http:///_vti_bin/Authentication.asmx?wsdl'. - The underlying connection was closed: An unexpected error occurred on a send. - Authentication failed because the remote party has closed the transport stream. 

Cela me cause de vrais problèmes, et juste abasourdi que cette application n’a toujours pas été mise à jour!