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

[corso66]

Bonjour à tous,

Ce forum est une mine d'informations pour moi pour beaucoup de choses ...

Je me permet d'ouvrir ce sujet mais je ne sais pas si quelqu'un pourra m'aider... un membre ici pourrait-il m'aider a générer les clés et certificats avec openssl afin de sécuriser les données entre un serveur (ici Node-Red) et le client (un objet connecté que je développe pour un client) et qui gère les connexion TLS.

N'étant pas expert dans ce domaine, je rédige de la doc sur mon produit et ayant tout essayé en fouinant sur le web, la connexion ne se fait pas.

En vous remerciant par avance,

Sylvain

[Armaggion]

Bonjour,

Je n'ai pas de réponse directe sur ton sujet, juste une remarque : TLS 1.2 vieillit doucement et TLS 1.3 est disponible depuis maintenant pas mal de temps (2018). Quitte à faire des efforts et si tu n'as pas de contraintes à respecter...

Ceci étant dit :

m'aider a générer les clés et certificats avec openssl

La génération de clés et leur utilisation dans le cadre d'une connexion sont deux choses distinctes. Je ne sais pas si c'était clair pour toi ?

Pour générer les clés, ça passe par openSSH qui fait ça très bien et peut créer les clés de la qualité requise (à base de courbes elliptiques plutôt que du RSA, mais laissons-ça de côté). Regarde du côté de la commande

Code : Tout sélectionner

ssh-keygen

qui te génèrera les fichiers nécessaires à consommer ensuite dans le cadre de la communication en TLS. L'option "-t" te permet de spécifier l'algorithme que tu veux utiliser.

[corso66]

Bonjour à vous,

Merci d'avoir répondu. Je suis parti en famille quelques jours...

Je voulais m'assurer déjà que l'on pourrait m'aider ici, conscient que ma demande n'est pas vraiment en lien avec cette magnifique distribution qu'est Mint

Bien sûr, je vais vous donner tous les détails de ma demande, ce que j'ai fait où que j'essaye de faire... bref, je vais vous aider à m'aider si ça vous va

Bon we à vous

[corso66]

Bonsoir à tous,

Alors voilà ce que je souhaite faire, en essayant d'être le plus clair possible.

J'ai conçu une passerelle ZigBee/Ethernet avec tout un écosystème de recueil de données à distance. C'est bien sûr la partie que je maitrise.

Pour "faire passer" les données UART Zigbee vers Ethernet et inversement, et pour ce dernier, j'utilise un module xPortEDGE qui gère tout un tas de protocoles réseaux comme TCP, UDP, MQTT... en tant que serveur ou client. Mais surtout offre une couche supplémentaire de sécurité comme TLS (1.0 - 1.1 - 1.2) ou AES.
Le domaine qui est bloquant pour moi, ce sont les possibilités étendues que permet la connexion TLS. Car comme vous l'avez compris, je ne suis pas un expert dans cet aspect crypto de la couche TCP. Mais j'ai bien fouiné le web pour mieux en comprendre les mécanismes.

TLS 1.2 vieillit doucement et TLS 1.3 est disponible depuis maintenant pas mal de temps (2018)

La réponse est simple, ce module ne prend pas encore en charge cette évolution. Mais au vu des mises à jour régulières, j'estime que TLS1.3 viendra.

La chose pour mes essais se résume à :

• l'objet IoT Ethernet connecté à un serveur (Node-Red) en réseau local.
• l'objet IoT Ethernet connecté à un serveur (Node-Red) Internet.

Les caractéristiques de config TLS coté serveur ne sont à priori pas contraignantes :


Les caractéristiques de config TLS coté client, soit mon module se présente comme ceci :


Plus présicément, la doc constructeur indique ceci :

Data Communication Security (TLS)
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.

On the gateway, you use a TLS Credential to configure the TLS properties between two communicating applications.

Creating a TLS Credential
The TLS Credential contains the private key and certificate details. You can use TLS for TCP and UDP connections as well as for secure HTTP Server.

Note

The xPort EDGE supports TLS credentials only in the PKCS1 and PKCS12 formats (PKCS12 via Web Manager only).

Les exigences du modules sont donc :
- Format de cryptage : PKSC1 ou PKSC12
- Fichier en format PEM
- Nombre d'octets KEY, CERT, CA, ROOT CA : 4000 bytes.

Ce que j'arrive à faire aujourd'hui (avec ma propre compréhension):

Sachant que :

• Client IP (module) : 192.168.1.17
• Server IP : 192.168.1.36

1. Communication TLS établie sans vérification du client
   C'est la première chose que j'ai essayé et qui à fonctionné du premier coup :
   • Coté serveur : j'installe un certificat auto-signé ainsi que sa clé privée RSA 2048.
   • Coté client : J'active TLS, mais je laisse tous les champs vierges
2. Communication TLS établie avec vérification du client Ce qu'ils appellent, "Asymmetric encryption" ?
   Je viens tout juste de réussir à faire cela :
   • Coté serveur : j'installe un certificat auto-signé ainsi que sa clé privée RSA 2048.
   • Coté client : j'installe un certificat auto-signé ainsi que sa clé privée RSA 2048.
   • Pour les 2 : J'installe l'Autorité de Certification (CA) (même fichier) qui a signé le certificat serveur d'une part, le certificat client d'un autre part.

Maintenant, voici ce que j'ai fait pour ce dernier cas avec OpenSSH :
J'admet volontier avoir pondu ça en partie grâce à de l'IA

1. Création de l'Autorité de Certification (CA)

Génération de la clé privée de la CA :

Code : Tout sélectionner

openssl genrsa -out ca.key 2048

Génération du certificat auto-signé de la CA :

Code : Tout sélectionner

openssl req -x509 -new -nodes -key ca.key -sha256 -days 1825 -out ca.crt

Ici, lors des renseignement demandés, je renseigne CN avec un nom générique.

2. Génération des certificats pour Node-RED et xPortEdge

Pour Node-RED : Serveur

Génération de la clé privée :

Code : Tout sélectionner

openssl genrsa -out nodered.key 2048

Création de la demande de signature de certificat (CSR) :

Code : Tout sélectionner

openssl req -new -key nodered.key -out nodered.csr

Ici, lors des renseignement demandés, je renseigne CN avec l'IP du serveur soit :
192.168.1.36.

Configuration des extensions pour le certificat de Node-RED : Création nodered.ext avec le contenu suivant :

Code : Tout sélectionner

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth

Il y a là une demande d'identification de la part du client ?

Signer le certificat de Node-RED avec la CA :

Code : Tout sélectionner

openssl x509 -req -in nodered.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out nodered.crt -days 365 -sha256 -extfile nodered.ext

Convertir la clé privée et le certificat au format PEM PKCS#1 :

Code : Tout sélectionner

openssl rsa -in nodered.key -outform PEM -out nodered.pem
openssl x509 -in nodered.crt -outform PEM -out nodered-cert.pem

Pour xPortEdge : Client

Génération de la clé privée :

Code : Tout sélectionner

openssl genrsa -out xportedge.key 2048

Création de la demande de signature de certificat (CSR) :

Code : Tout sélectionner

openssl req -new -key xportedge.key -out xportedge.csr

Ici, lors des renseignement demandés, je renseigne CN avec l'IP du module client soit :
192.168.1.17.

Configuration des extensions pour le certificat de xPortEdge : Création fichier xportedge.ext avec le contenu suivant :

Code : Tout sélectionner

authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = clientAuth

Il y a là une demande d'identification de la part du Serveur ?

Signer le certificat de xPortEdge avec la CA :

Code : Tout sélectionner

openssl x509 -req -in xportedge.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out xportedge.crt -days 365 -sha256 -extfile xportedge.ext

Convertir la clé privée et le certificat au format PEM PKCS#1 :

Code : Tout sélectionner

openssl rsa -in xportedge.key -outform PEM -out xportedge.pem
openssl x509 -in xportedge.crt -outform PEM -out xportedge-cert.pem

3. Configuration de Node-RED
Comme dans la capture d'écran ci-dessus pour le serveur, j'uploade ces 3 fichiers :

nodered.pem
nodered-cert.pem
ca.crt

4. Configuration de xPortEdge
Comme dans la capture d'écran ci-dessus pour le module client, je copie colle le contenu de ces 3 fichiers :

xportedge.pem
xportedge-cert.pem
ca.crt.

Ce que je ne comprend pas :
Pour ce dernier cas, où j'estime que seuls mes modules xPortEdge client peuvent ce connecter au serveur, quel type de CA ai-je généré car il y a CA et CA racine ... et pour preuve :
Dans la capture ci-dessous que je vous remet, j'avais apparemment fait une erreur.

• CA copié/collé dans Certificate Higher Authority ---> ERR_CERT_CHAIN_NO_TRUST_ANCHOR venant du xPortEdge
• CA copié/collé dans Certificate Trusted Authority ---> ça fonctionne.

Quelle différence ?


Ensuite, quel intérêt dans ce module d'avoir plusieurs possibilité de CA racines ou de confiances ?

Pour finir comment remplit-on correctement les renseignements au moment de la demande de signature de certificat que ce soit pour la partie client (dont l'IP peut-être changeante) ou serveur (entre IP, nom de domaine etc...) surtout pour le champ CN (Nom commun) ?

Voilà désolé pour ce pavé bien pesant, mais en espérant avoir été assez clair
Et merci d'avance pour votre aide

Sylvain

[Armaggion]

On est un peu loin du coeur de métier de ce forum, mais pour répondre à quelques-unes de tes questions (pas toutes, loin de là hélas) :

Communication TLS établie avec vérification du client Ce qu'ils appellent, "Asymmetric encryption" ?

Non, le propos est plus général : il signifie que tu te bases sur des méthodes de chiffrements avec une clé publique et une clé privée.

J'admets volontiers avoir pondu ça en partie grâce à de l'IA

Attention, l'IA n'est pas un outil qui dit la vérité, c'est un générateur de texte qui répond ce qu'il y a de plus probable. Le fait que ça puisse être la vérité est un hasard heureux qui tient au fait que ce qui est vrai est statistiquement le plus probable, mais ce n'est pas toujours le cas. Tant mieux si ça aide

Trusted Authority et Higher Authority font référence au principe de délégation dans la création de certificats. Tu peux tenir ton certificat d'une autorité qui détient elle-même son certificat d'une autorité supérieure qui la détient elle-même d'une plus haute, etc... jusqu'au certificat racine. Il y a plusieurs certificats racine, stockés dans le magasin de ton navigateur pour valider les transactions HTTPS qui se basent sur le même type de chiffrement.

Plus d'informations ici : https://www.keyfactor.com/fr/education- ... tificates/

Je t'invite à décocher les options TLS 1.0 et 1.1 dans la configuration, ce qui limitera ton exposition à un risque de sécurité.

Pour le reste, c'est vraiment très spécifique, mais peut-être avons-nous un spécialiste parmi nous ?

[corso66]

Salut Armaggion,

Merci pour ta réponse, le lien que tu m'as donné m'a beaucoup plus.
Pour la suite, je vais essayé d'autres choses avec OpenSSH, histoire de me faire la main avec ce que je sais plus ou moins

J'ai encore un peu de mal avec les champs à remplir avec la demande de signature, si quelqu'un à plus d'infos à ce sujet ?
Comment remplit-on correctement les renseignements au moment de la demande de signature de certificat que ce soit pour la partie client (dont l'IP peut-être changeante) ou serveur (entre IP, nom de domaine etc...) surtout pour le champ CN (Nom commun) ?

Bien sur, je comprendrais si vous souhaitez clôturer ce sujet, vu le domaine que c'est sur ce forum.

Merci à vous,

[alain]

Bonjour Corso.

Il est hors de question de fermer ce sujet.
Je n'y comprends rien, je suis nul en communication et encore plus en sécurité, mais justement, c'est une bonne occasion d'apprendre quelque chose.
Faut dire que ça change des imprimantes non reconnues et des disques pleins
Et comme le dit Armaggion : " c'est vraiment très spécifique, mais peut-être avons-nous un spécialiste parmi nous ?"

Si tu n'as pas de réponses, je t'invite à faire un up de ton sujet de temps en temps.

Notre corps de métier, comme tu dis, c'est l'informatique libre...Avec une spécialisation Linux Mint, mais nous ne sommes pas sectaires

[corso66]

Bonjour Corso.

Il est hors de question de fermer ce sujet.
Je n'y comprends rien, je suis nul en communication et encore plus en sécurité, mais justement, c'est une bonne occasion d'apprendre quelque chose.
Faut dire que ça change des imprimantes non reconnues et des disques pleins
Et comme le dit Armaggion : " c'est vraiment très spécifique, mais peut-être avons-nous un spécialiste parmi nous ?"

Si tu n'as pas de réponses, je t'invite à faire un up de ton sujet de temps en temps.

Notre corps de métier, comme tu dis, c'est l'informatique libre...Avec une spécialisation Linux Mint, mais nous ne sommes pas sectaires

Salut Alain,

Et bien je te remercie, ça c'est très sympa de ta part, en espérant trouver des passionnés du SSH

[Armaggion]

Bonjour Corso,

Je vais commencer par plein de choses que tu sais :

TLS est une norme de communication qui permet de garantir à un client que le serveur qu'il interroge est bien celui qu'il prétend être. Autrement dit, quand tes objets connectés vont joindre le serveur, ils vont lancer une connexion vers un nom de domaine qui prouvera son identité (authentification) en produisant son certificat (= sa clé publique). Ce certificat sera validé localement par le client. Il garantit que www.microsoft.com a bien été enregistré auprès du certificateur et appartient bien à l'entité Microsoft Corp.

Quand une application se connecte à un site, elle valide le certificat en faisait appel au système d'exploitation ou dispose de son propre magasin de certificats. Ce magasin a plusieurs entrées possibles, car plusieurs autorités de confiance (AC) se partagent le marché des rares et précieux certificats racine. Cette capacité de délivrance de certificat est le plus souvent déléguée à un intermédiaire, on parlera alors de certificat intermédiaire. En conséquence, le mécanisme de validation remonte la chaîne des certificats jusqu'à remonter à un certificat racine au format X.509 présent dans le magasin de clés du système d'exploitation ou de l'application cliente. C'est ce qu'on appelle la chaîne de confiance.

S'il n'y a pas moyen de remonter à un certificat de confiance, l'authentification échoue.

Note 1 : Un certificat a une durée de vie limitée. Il peut donc expirer et doit être renouvelé régulièrement.
Note 2 : Est-ce que certificat intermédiaire et "higher authority" sont synonymes dans ton cas ? A tester.

De plus, différents niveaux de validation sont possibles, comprendre "valeur probatoire" du certificat. Selon ton besoin, tu peux choisir le niveau de validation le plus faible (auto-signé) ou le plus fort, EV (Extended Validation) en passant par OV (organization validation) et DV (domain validation, le plus faible, celui qu'on obtient quand, typiquement, on demande un nom de domaine chez OVH ou autre hébergeur de ce type ). En fonction de l'activité sous-tendue par l'échange électronique, les autorités de régulation exigent que l'entité emploie un certificat plus ou moins fort selon le cas d'usage.

La communication s'établit toujours à l'initiative du client vers le serveur et c'est au serveur de prouver son identité, c'est-à-dire de fournir le certificat confirmant qu'il est le propriétaire légitime du nom de domaine ciblé. Le client, lui, sait qui il est, par définition. C'est pourquoi la communication s'établit toujours à son initiative, fut-ce pour demander au serveur s'il a une question à lui poser.

Tu comprends donc que le client n'a pas besoin de certificat en ce qui le concerne. Le serveur peut néanmoins se protéger des requêtes intempestives en mettant en place du filtrage à différents niveaux, du plus précoce (matching d'IP ou d'adresse MAC) au plus tardif (login/password pour faire simple). A ce stade, rien n'interdit de faire de l'authentification du client par certificat, mais ce n'est plus dans le cadre du chiffrement de la communication elle-même. On est à un autre niveau qu'il ne faut pas confondre.

https://sectigostore.com/page/client-ce ... rtificate/

Par suite, les formulaires pour demander des certificats ou les interfaces pour en déclarer dépendent respectivement de la terminologie du fournisseur et de l'outil que tu utilises, mais en gros, avec ces explications, j'espère que ça t'aura un peu débrouillé le terrain ?

[alain]

@Armaggion

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