Mise en œuvre TLS1.2 avec openssl entre Serveur et Client (IoT)

[alain]

Dernier message de la page précédente :

@Armaggion

Ha! Je savais bien que j'allais apprendre des choses

[corso66]

Salut Armaggion,

Merci pour toutes tes explications.

... mais en gros, avec ces explications, j'espère que ça t'aura un peu débrouillé le terrain ?

Bien-sur que ça m'aide ! Et ton lien aussi m'a bien instruit.

Du coup, ce que je comprend : avec mon dernier test avec d'une part un certificat serveur, un certificat client d'autre part, le tout signé par un CA fait que seul mon module IoT peut communiquer avec mon serveur et vice-versa, le tout en liaison crypté...
En recoupant les infos de ton lien et de ce qu'il me semble avoir compris, de manière générale cela veut dire que :

• Avec cette technique, on peut faire communiquer un couple serveur/client de manière exclusive et unique, et même s'il y a plusieurs clients de mêmes types avec les mêmes certificats, on se passe de tout autre moyen d'authentification à savoir mot de passe etc ... ?
• Tout autre client sera rejeté ??

Ben du coup si c'est ça, ça m'en bouche un coin !

Autre chose : Le fait d'avoir juste une clé privée et publique coté serveur, et rien coté client permet une communication cryptée. Comme tu disais, c'est bien le client qui initie la conversation, le serveur ne contrôle rien. Sur mon module, j'active la fonction TLS, mais ne donne aucune clé ou certificat ... Et cela fonctionne !
Mais est-ce que ça veut dire que mon client, c'est à dire mon objet connecté, a nativement un certificat par défaut permettant de s'identifier un minimum ?

Comment comprends-tu ces quelques lignes du fabricants de mon module, surtout ce que j'ai mis en vert ?

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), use asymmetric encryption for authentication. In some scenarios, only a server needs to be authenticated, in others both client and server authenticate each other. Once authentication is established, clients and servers use asymmetric encryption to exchange a secret key. Communication then proceeds with symmetric encryption, using this key.

TLS/SSL application hosts use separate digital certificates as a basis for authentication in both directions: to prove their own identity to the other party, and to verify the identity of the other party. In proving its own authenticity, the XPort EDGE will use its own "personal" certificate. In verifying the authenticity of the other party, the XPort EDGE module will use a "trusted authority" certificate.

[Armaggion]

je comprends qu'il y a encore des choses à creuser du côté du "mutual TLS" (mTLS en abrégé) qui permet une authentification des deux côtés dans le cadre du protocole TLS. C'est d'un usage plus spécifique mais ça existe, notamment dans le domaine du B2B (business-to-business) quand deux serveurs se parlent en s'authentifiant mutuellement par exemple, mais aussi avec OAuth que tu peux croiser dans le cadre des authentifications à un serveur de messagerie où il est important que les deux parties se reconnaissent précisément.
Tu peux fouiller à partir d'ici : https://en.wikipedia.org/wiki/Mutual_authentication (y'a même une section sur le mTLS qui te redit en mieux ce que je te raconte ici)

[corso66]

Salut,

mTLS, voilà un nom donné sur ce cas de figure bien spécifique et pris en charge par mon module. C'est donc ce que j'ai réussi à faire.

Il faut maintenant que je comprenne mieux la chaine de confiance dans ce module entre Higher et Trusted Authority.

Merci pour toutes ces infos et ton aide