Définir la SecurityProtocol (Ssl3 ou TLS) sur l' .net HttpWebRequest par demande

Malheureusement, il n'a pas l'air comme vous pouvez le personnaliser par point de service. Je voudrais vous suggérer de déposer une demande de fonctionnalité à la MS se Connecter site web pour ce domaine.

Comme un sale solution de contournement, vous pouvez essayer d'exécuter les sites qui nécessitent un protocole de sécurité différents dans un nouveau domaine d'application. Statique instances sont par domaine d'application, ce qui devrait vous donner l'isolement dont vous avez besoin.

Après certains de nos fournisseurs cessé de soutien pour ssl3 tandis que d'autres l'utilisent exclusivement, de nombreuses questions apparaissent dans notre système, qui pourrait être résolu avec la fonctionnalité de cette question. Mais six ans après, nous n'avons pas encore intégré dans le mécanisme pour y parvenir. Notre solution de contournement consiste à définir explicitement le protocole de sécurité qui prendront en charge tous les scénarios, comme ceci:

    System.Net.ServicePointManager.SecurityProtocol = 
System.Net.SecurityProtocolType.Ssl3 
| System.Net.SecurityProtocolType.Tls12 
| SecurityProtocolType.Tls11 
| SecurityProtocolType.Tls;

Vous pouvez atteindre cet objectif par le présent code pour fermer tous les liens sous-jacents et de la vigueur d'une nouvelle poignée de main.

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(uri);
...
...
...
request.ServicePoint.CloseConnectionGroup(request.ConnectionGroupName);

Vous pourriez faire un HttpWebRequest utilitaire "classe" avec un statique d'utilité méthode pour la fabrication de HttpWebRequests. En statique méthode utilitaire utiliser l'instruction c# lock autour de réglage de la ServicePointManager.SecurityProtocol et la création d'un particulier HttpWebRequest. L'instruction lock empêche les autres threads du même domaine d'application pour exécuter le même code en même temps, donc le protocole TLS que vous venez de définir n'obtiendrez pas changé jusqu'à ce que l'ensemble de la serrure de bloc (= section critique) est exécutée.

Mais conscient, pour vraiment performante des applications de (très haute performance!) cette approcah pourrait avoir un impact négatif sur les performances.

Je sais que cette question est ancienne, mais la question reste la même .Net 4.7.2. Dans mon cas, j'ai une application multi-thread qui est en train de parler à deux points de terminaison. D'un point de terminaison ne fonctionne qu'avec TLS 1.2, et l'autre extrémité fonctionne uniquement avec le protocole TLS 1.0 (l'équipe responsable pour que l'on travaille sur la fixation de leur point de terminaison de sorte qu'il sera également en charge de TLS 1.2).

Pour contourner ce problème, j'ai déplacé les appels de service pour le point de terminaison qui fonctionne uniquement avec le protocole TLS 1.0 à une classe distincte dans la même assemblée, puis chargé de l'assemblage dans un autre domaine d'application. En faisant cela, je peux utiliser cette variable globale:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls; 

juste pour les appels vers le point de terminaison cassé, tout en ayant aussi des appels à la TLS 1.2 point de terminaison (qui ne nécessitent pas de réglage ServicePointManager.SecurityProtocol à rien de précis) de continuer à travailler. Cela garantit également que lorsque le bon point de terminaison est mis à niveau vers TLS 1.3 je n'ai pas besoin de re-publier mon application. Mon application est multi-thread et de haute capacité, donc, de verrouillage ou de try/finally ne sont pas des solutions adéquates.

Voici le code que j'ai utilisé pour charger l'assembly dans un domaine distinct. Notez que je charge le montage à partir de son emplacement actuel (Aspnet Tempfiles), afin de ne pas bloquer l'ensemble dans le répertoire bin et de bloquer les futurs déploiements.

Il est également à noter que la classe de proxy hérite de MarshalByRefObject, de sorte qu'il est utilisé comme un proxy transparent qui préserve le Système.Net.ServicePointManager avec sa propre valeur dans son propre domaine d'application.

Cela semble comme une bête limitation de la part de l' .Net framework, je souhaite que nous pourrions il suffit de spécifier le Protocole directement sur le web demande au lieu de sauter à travers des cerceaux, surtout après des années de cela. 🙁

Ce code fonctionne, espérons que cela vous aide! 🙂

private static AppDomain _proxyDomain = null;
private static Object _syncObject = new Object();
public void MakeACallToTls10Endpoint(string tls10Endpoint, string jsonRequest)
{
if (_proxyDomain == null)
{
lock(_syncObject) //Only allow one thread to spin up the app domain.
{
if (_proxyDomain == null)
{
_proxyDomain = AppDomain.CreateDomain("CommunicationProxyDomain");
}
}
}
Type communicationProxyType = typeof(CommunicationProxy);
string assemblyPath = communicationProxyType.Assembly.Location;
//Always loading from the current assembly, sometimes this moves around in ASPNet Tempfiles causing type not found errors if you make it static.
ObjectHandle objectHandle = _proxyDomain.CreateInstanceFrom(assemblyPath, communicationProxyType.FullName.Split(',')[0]);
CommunicationProxy communicationProxy = (CommunicationProxy)objectHandle.Unwrap();
return communicationProxy.ExecuteHttpPost(tls10Endpoint, jsonRequest);
}

Puis, dans une catégorie distincte:

[Serializable]
public class CommunicationProxy : MarshalByRefObject
{
public string ExecuteHttpPost(string tls10Endpoint, string jsonRequest)
{
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
//<< Bunch of code to do the request >>
}
}