Discussion :

[PH_OGMI]

Bonjour,

Je dois me connecter à un web service qui à l'origine est écrit en langage Java depuis mon programme qui est en VB.NET 4.0.
Lorsque j'essaie d'appeler une méthode quelconque du web service avec ses bon paramètres je reçois le message d'erreur ci-dessous :

WS-Metadata Exchange Error URI: [http://...] Metadata contains a reference that cannot be resolved
The request was aborted: Could not create SSL/TLS secure channel

Des collègues qui travaillent en Java eux n'ont pas ce problème et peuvent communiquer avec le web service sans soucis.
J'ai essayé de modifier le protocole de sécurité en "SSLv3" ou "TLS1.2" dans mon code VB.NET mais ça ne change rien toujours le même message.
Pour info, j'utilise des certificats pour m'identifier auprès du serveur mais j'ai l'impression que je n'arrive pas au stade de vérification du certificat, mon programme VB.NET n'arrive déjà pas à communiquer avec le serveur...

Merci par avance pour vos réponses,

P.H.

[PH_OGMI]

Re-bonjour,

J'ai utilisé le logiciel "Wireshark" pour sniffer les paquets HTTPS envoyé/reçu lorsque mon programme essaie d'appeler le web service et voici ce que j'ai obtenu :

CLIENT :

Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 140
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 136
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 71
Extension: server_name
Extension: elliptic_curves
Extension: ec_point_formats
Extension: Extended Master Secret
Extension: renegotiation_info

SERVEUR :

Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)

Des idées pourquoi le serveur ne répond pas au "Client hello" ?

[DotNetMatt]

As-tu deja essaye de tester ton web service avec SSL Server Test ?

Si tu regardes l'exemple de api-3t.sandbox.paypal.com tu peux voir que ca fournit de nombreuses informations, dont des simulations de handshake. Ca te mettra peut-etre sur la bonne piste !

[PH_OGMI]

J'ai déjà essayé de scanner l'URL du web service avec des outils online tel que celui que tu suggères. Mais aucun outil n'arrive à établir une communication avec le serveur HTTPS. J'ai remonté ce problème aux responsables du serveur web mais ils avancent que pour communiquer avec leur serveur il faut absolument présenter un certificat même si ce certificat n'est pas vérifié il en faut un.

Je ne pense pas qu'il existe des outils de scan SSL en ligne qui peuvent être "forcés" à présenter un certificat lors de la connexion. Ou bien connais-tu un outil qui peut faire cela ?

Merci par avance

[PH_OGMI]

Des nouvelles !

J'ai pu récupérer un programme "test" côté client mais en JAVA cette fois, je l'ai lancé sur ma machine et effectivement en lançant la "Main" du programme JAVA il arrive bien à se connecter au web service
Lors du lancement de programme en JAVA j'ai utilisé le sniffer de paquets "Wireshark" et j'ai obtenu le Ciphersuite que le serveur utilise : TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

Chose incroyable c'est que ce Ciphersuite et également proposé par mon client en VB.NET au serveur lors du "Client Hello", mais je ne comprends pas pourquoi le serveur ne l'accepte pas ?! Autrement toujours d'après le paquet sniffé, le serveur n'utilise pas d'extension ni d'algorithme de compression, en gros voici ce qu'il répond dans son "Server Hello" :

TLSv1 Record Layer: Handshake Protocol: Server Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 49
Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 45
Version: TLS 1.0 (0x0301)
Random
GMT Unix Time: Jul 5, 2017 11:02:18.000000000 Paris, Madrid (heure d’été)
Random Bytes: 3a7371ad84392992f37b0b123c2d49ef28207d7d35c919ba...
Session ID Length: 0
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Compression Method: null (0)
Extensions Length: 5
Extension: renegotiation_info
Type: renegotiation_info (0xff01)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0

J'ai donc tendance à penser que ce n'est pas un problème de Ciphersuite, d'autres pistes ? Merci.

[DotNetMatt]

Peux-tu poster ton fichier de config ? En masquant bien sur les infos sensibles

[PH_OGMI]

Si tu parles de "app.config" j'ai regardé il n'y a pas grande chose dedans, j'aimerais bien le poster en ligne mais je ne suis pas sûr des éléments confidentiels qu'il faut masquer...

Par contre, je suis entrain d'utiliser "Fiddler" à la place de "Wireshark" pour mieux voir les détails des paquets HTTPS qui passent sur le réseau. Je vous tiens au courant !

[PH_OGMI]

Problème résolu :

Il s'agissait finalement d'une histoire de "Cipher suite". En effet mon programme VB était écrit en .NET 4.0 et dans cette version les Cipher suite RC4 sont proposé dans la liste des Cipher Suites supportées par le client. Ce qui n'était pas du goût de mon serveur Web. En effet le seule présence des deux Cipher Suites ci-dessous dans la liste proposée par le client faisait que le serveur fermait la connexion au moment du "HandShake" :

• [0005] SSL_RSA_WITH_RC4_128_SHA
• [0004] SSL_RSA_WITH_RC4_128_MD5

J'ai donc dû forcer la désactivation des Sipher suites RC4 sur la machine client en allant dans la base de registre (regedit) et en ajoutant la nouvelle clé ci-dessous aux 2 endroits:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001


ET


HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001

=> A noter que ce problème existe seulement dans la version .NET 4.0, à partir de la version .NET 4.6 ce problème n'est plus present.

Pour ceux qui veulent avoir plus d'info :
https://technet.microsoft.com/fr-fr/...y/2960358.aspx


Merci pour votre aide !
A++

P.H.

[DotNetMatt]

Wow pas evident a trouver Merci d'avoir partage ta solution en tout cas !

[François DORIN]

Bonjour,

Effectivement, celui là n'a pas du être facile à trouver ! Surtout que c'est un peu incompréhensible que la présence d'un algo uniquement côté client mène à l'impossibilité de créer une connexion, alors même qu'il existe des algorithmes supportés aussi bien par le client que par le serveur.

Bref, juste pour qu'on ait le maximum d'info, quel service héberge le webservice ? tomcat ? est-ce qu'il y a un proxy ?

[PH_OGMI]

Bonjour,

Oui le serveur Web est hébergé sur une machine Linux donc il y a de forte chance que ça soit Tomcat.
Autrement il n'y a pas de proxy.

J'avoue que ce n'était pas facile de trouver la solution j'y ai passé du temps mais ce qui m'a beaucoup aidé c'était le fait d'utiliser l'application Fiddler. Pour ceux qui ne connaissent pas c'est une application qui permet de sniffer les paquets qui passent sur le réseau et même de déchiffrer les paquets cryptés en lui fournissant bien sûr un certificat valide. => A utiliser sans modération

Bonne journée,
A++