> Tech > Valider votre application pour SSL

Valider votre application pour SSL

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

Tout cela semble bien beau, mais comment pouvez-vous valider pour SSL votre application maison existante ? Il n’existe aucune interface standard pour coder la couche de protocole SSL. C’est pourquoi il y a de multiples interfaces sur l’iSeries pour valider pour SSL une application. Je décris ici mon interface favorite,

l’interface C.

Global Secure Toolkit (GSK ou GSKit) est disponible sur les plates-formes eServer et sur les autres plates-formes supportées par IBM comme Windows. GSKit a été pour la première fois rendu disponible sur l’iSeries dans la V4R5 et, depuis lors, il a été l’API C recommandée. Il est important de noter que d’autres langages ILE via des enveloppes (comme RPG) peuvent utiliser GSKit. Comme la documentation GSKit s’applique au langage C, une bonne compréhension de la manière dont GSKit fonctionne en C est nécessaire pour utiliser les enveloppes.

Les API GSKit peuvent être divisées en plusieurs catégories (figure 3). Les API d’environnement créent un jeu de base d’attributs de sécurité (par exemple, suites de chiffrement, protocoles, timeouts) à utiliser pendant la création de la session sûre. L’API gsk_environment_open fournit un handle pour un environnement peuplé avec les valeurs par défaut du système. Les attributs par défaut peuvent être changés ou extraits à l’aide des API d’attributs. L’API gsk_environment_ init active les attributs configurés dans le système d’exploitation. L’API gsk_environment_close renvoie les ressources au système quand l’environnement sûr n’est plus nécessaire.

Les API de session fonctionnent avec des connexions sûres individuelles. Il pourrait exister un environnement avec des milliers de sessions créées en fonction de cet environnement particulier. L’API gsk_secure_soc_open ouvre une session et requiert un handle d’environnement initialisé. La session hérite des attributs du handle d’environnement. La session sûre peut remplacer ces valeurs héritées en utilisant les API d’attributs. Les changements d’attributs doivent précéder l’appel de gsk_secure_soc_init, lequel initie le flux de protocole handshake décrit précédemment. Côté client, un hello client est envoyé ; côté serveur, nous attendons qu’un hello client arrive. Les API gsk_secure_soc_read et gsk_secure_soc_write sont les cousins sûrs de send et recv et seraient utilisées à leur place. L’API gsk_secure_soc_close renvoie les ressources de session et termine la connexion sûre. A noter qu’un appel d’API sockets close reste nécessaire pour fermer la connexion socket sous-jacente.

L’iSeries a mis en oeuvre trois API GSKit asynchrones qui sont uniques à l’iSeries : gsk_secure_soc_startSend, gsk_secure_ soc_startRecv et gsk_secure_soc_startInit. Bien entendu, elles ne sont pas portables sur les autres platesformes. Cependant, la performance est souvent plus importante qu’une source unique. Ces API améliorent nettement la performance globale d’une application serveur sûre. Bien qu’elles ne puissent pas réduire le nombre d’instructions de protocole SSL, elles permettent à une application de mieux utiliser ses ressources, y compris la CPU. Les API font usage du support socket asynchrone unique iSeries existant. A noter qu’avec l’API gsk_secure_soc_startInt, le handshake peut se faire en utilisant le modèle asynchrone. La figure 4 montre un bref fragment de code qui montre à quoi ressemble une poignée d’appels GSKit.

Téléchargez cette ressource

Préparer l’entreprise aux technologies interconnectées

Préparer l’entreprise aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010