Toutes les communications TCP nécessaires aux échanges entre une application cliente et un serveur utilisent maintenant le protocole TLS (Transport Layer Security). Cela s'applique pour tous les échanges qui reposent sur la couche de transport réseau TCP :

  • SMTP pour envoyer des emails,
  • HTTPS pour interroger une API REST, un webservice SOAP, ou une appeler une page d'un site web,
  • connexion à une socket ...

Ce protocole existe dans différentes versions : 1.0, 1.1, 1.2 et 1.3. A ce jour c'est la version 1.2 qui est couramment utilisée. Les serveurs les plus sécurisés peuvent même l'imposer s'ils doivent répondre aux exigences de sécurité actuelles les plus strictes.


Se pose donc la question du choix de la version utilisée par une application. Réponse rapide : il n'y a rien à faire car c'est automatiquement la version la plus sûre qui est utilisée !


En effet un mécanisme automatique de négociation fait que tout échange va systématiquement se faire avec la version de TLS la plus récente disponible à la fois sur le serveur et sur le client !


En fonction du système qui exécute le processus, différents cas se présentent. Mais dans tous les cas la négociation de la version de TLS est automatique :

  • Exécution sous Android, iOS, Linux :
    Les échanges TCP sont gérés entièrement par le framework de WINDEV, WEBDEV ou WINDEV Mobile, indépendamment du système qui exécute l'application. La version de TLS négociée à la connexion sera systématiquement la plus récente connue du framework WINDEV et acceptée par le serveur contacté :
    • à partir de la version 23, toutes les versions de TLS sont intégrées jusqu'à la 1.2,
    • à partir de la version 26, toutes les versions de TLS sont intégrées jusqu'à la 1.3.
  • Exécution sous Windows :
    Deux cas sont à distinguer car il est possible d'utiliser pour les échanges TCP les API de Windows, ou la gestion intégrée au framework comme sous Android, iOS :
    • les communications sont configurées pour utiliser les API de Windows (WININET).
      Ce mode est actif par défaut, ou si dans le projet en fonction du protocole on a :
      • EmaiParamètre avec emailParamètreMode = 0
      • ou HTTPParamètre avec httpParamètreMode = 1
      • ou HTTPParamètre avec httpParamètreMode = 0 et que le protocole est HTTPS.

        Dans ce mode c'est alors la configuration du poste Windows qui exécute l'application qui est déterminante.
        La version de TLS utilisée, sera la plus récente disponible et configurée sous Windows.
        Par exemple si une application doit appeler un webservice REST hébergé par un serveur qui n'accepte que TLS 1.2, il faudra obligatoirement que TLS 1.2 soit disponible dans le système client qui exécute l'application.
        Le site de Microsoft détaille les versions de TLS supportées en fonction de la version de Windows :
        TLS protocol version support

    • les communication sont configurées pour ne pas utiliser les API du système.
      Ce mode est actif si dans le projet en fonction du protocole on a :
      • EmaiParamètre avec emailParamètreMode = 1,
      • ou HTTPParamètre avec httpParamètreMode = 2 (*).

        Dans ce mode les échanges TCP sont gérés entièrement par le framework de WINDEV, à l'identique de l'exécution sous iOS ou Android. La version de TLS négociée à la connexion sera systématiquement la plus récente connue du framework WINDEV et acceptée par le serveur contacté.

 

Si dans un cas exceptionnel une application doit être interroger un serveur en forçant une version de TLS plus ancienne que celle qui serait négociée automatiquement, c'est possible :

  • à la création d'une socket avec le paramètre <Options SSL> de la fonction SocketCrééSSL,
  • avec la propriété ..VersionSSL du type httpRequête.

 

(*) La valeur 2 de l'option httpParamètreMode de la fonction HTTPParamètre n'est pas encore documentée. Mais c'est bien la valeur à utiliser pour bénéficier dans une application WINDEV sous Windows, de la même implémentation des échanges que sous iOS ou Android, donc sans être tributaire des réglages de Windows. Ce réglage s'applique aux requêtes envoyées avec la fonction HTTPEnvoie ou RESTEnvoie. Il ne s'applique pas dans le cas de la fonction HTTPRequête.

 

===== Mise à jour 20/4/2023 ======

Il est possible de connaître la version de LST négociée, ainsi que le Cipher choisi. Un billet complète ce thème :

Protocole TLS (suite) : version utilisée lors d'échanges TCP avec un serveur ?

< Retour

8 commentaires

Grégory FROGÉ
19/10/2022 - 14:43 - Répondre
Bonjour. est-ce que HTTPParamètre avec httpParamètreMode permet d'exploiter le framework windev dans le cadre d'une consommation d'un webservice SOAP importé dans le projet et utilisant HTTPS ? Merci. Cordialement.

Guillaume BAYLE
19/10/2022 - 14:50 - Répondre
Bonjour, HTTPParamètre(httpParamètreMode, 2) permet en effet de consommer un webservice SOAP dont le WSDL a été importé dans un projet. Bons développements !

Grégory FROGÉ
20/10/2022 - 08:56 - Répondre
Bonjour M. BAYLE, Merci de votre retour. Pour autant l'aide de HttParamètre (https://doc.pcsoft.fr/?1000018985&lang=fr-FR&productversion=xxF270103n) indique : Remarques : Si une requête sécurisée ("https") est exécutée, le mode de gestion des requêtes est toujours effectué par Internet Explorer. Notre webservice est en HTTPS, le HTTPParamètre(httpParamètreMode, 2) aura bien un impact ? Merci encore. Bien cordialement.

Guillaume BAYLE
20/10/2022 - 11:13 - Répondre
Oui avec HTTPParamètre(httpParamètreMode, 2) une application WINDEV, un site ou webservice WEBDEV, utilisent pour les échanges HTTPS une implémentation multiplateforme intégrée au framework, et non plus l'API de Windows. L'aide doit être actualisée.

Grégory FROGÉ
20/10/2022 - 11:38 - Répondre
Merci infiniment. Quelle différence y'a t-il avec le mode 0 HTTPParamètre(httpParamètreMode, 0) qui lui aussi selon l'aide est "Mode de gestion des requêtes classique, effectué par WINDEV et/ou WEBDEV." Merci encore. Bien cordialement.

MANRIQUEZ Ernesto
02/01/2023 - 16:03 - Répondre
Bonjour, Est-il possible de lire la sécurité du serveur SMTP. En effet pour sensibiliser les utilisateurs, j'aimerais pouvoir l'afficher car de nos jours TLS v1.2 est un minima. Si ce n'est pas le cas, une fonction Wlangage du type EmailLitSecurité serait la bienvenue. Par avance merci pour votre retour Cordialement

kab.w
08/02/2023 - 14:30 - Répondre
Bonjour; je souhaite avoir une réponse sur ma question qui est la suivante: j'ai une app mobile qui utilise des API d'un serveur distant sécurisé (SSL), le problème est que je n'arrive pas à me connecter lorsque j'install mon APK sur le téléphone android tant disque les test avec le simulateur pc est réussi. que dois je activé ou touché , car toute els fonction sur SSL et certifaicat ne sont pas disponible pour windev mobile?????? NB: je suis avec la version 28 merci bien d'avance , aimable d'avoir un retour rapide.

Guillaume BAYLE
10/02/2023 - 17:01 - Répondre
Bonjour, un échec d'échange en HTTPS sous Android survient si le certificat utilisé par le serveur web pour chiffrer la connexion, est délivré par une autorité de confiance inconnue de l'appareil. Dans ce cas la fonction CerticatDeConfianceAjoute permet de faire connaître l'autorité à l'application. N'hésitez pas à faire une requête (choix "Requête au support technique" du bouton "Accueil/Aide" du ruban) à notre support en présentant votre cas. Seul un test permet d'avoir l'explication certaine. Bons développements.

Publier un commentaire : 
Votre adresse email ne sera pas publiée