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.

 

< Retour

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