Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Lorsque vous utilisez HTTP comme transport, la sécurité est fournie par une implémentation SSL (Secure Sockets Layer). SSL est largement utilisé sur Internet pour authentifier un service auprès d’un client, puis pour fournir une confidentialité (chiffrement) au canal. Cet article explique comment SSL fonctionne et comment il est implémenté dans Windows Communication Foundation (WCF).
SSL de base
Le fonctionnement de SSL est mieux expliqué par le biais d’un scénario classique, dans ce cas, le site Web d’une banque. Le site permet à un client de se connecter avec un nom d’utilisateur et un mot de passe. Une fois authentifié, l’utilisateur peut effectuer des transactions, comme afficher les soldes de compte, payer les factures et déplacer l’argent d’un compte vers un autre.
Lorsqu’un utilisateur visite d’abord le site, le mécanisme SSL commence une série de négociations, appelée négociation, avec le client de l’utilisateur (dans ce cas, le navigateur web). SSL authentifie d’abord le site bancaire auprès du client. Il s’agit d’une étape essentielle, car les clients doivent d’abord savoir qu’ils communiquent avec le site réel, et non pas une usurpation qui tente de les attirer en tapant leur nom d’utilisateur et leur mot de passe. SSL effectue cette authentification à l’aide d’un certificat SSL fourni par une autorité approuvée, telle que VeriSign. La logique est la suivante : VeriSign se porte garant de l’identité du site bancaire. Étant donné que le navigateur approuve VeriSign, le site est approuvé. Si vous souhaitez vérifier avec VeriSign, vous pouvez également le faire en cliquant sur le logo VeriSign. Cela présente une déclaration d’authenticité avec sa date d’expiration et à qui elle est émise (le site bancaire).
Pour lancer une session sécurisée, le client envoie l’équivalent d’un « hello » au serveur, ainsi qu’une liste d’algorithmes de chiffrement qu’il peut utiliser pour signer, générer des hachages et chiffrer et déchiffrer avec. En réponse, le site renvoie un accusé de réception et son choix d’une des suites d’algorithmes. Durant ce protocole de transfert initial, les deux correspondants envoient et reçoivent des valeurs à usage unique. Un nonce est un élément de données généré de manière aléatoire qui est utilisé, en combinaison avec la clé publique du site, pour créer un hachage. Un hachage est un nouveau nombre dérivé des deux nombres à l’aide d’un algorithme standard, tel que SHA1. (Le client et le site échangent également des messages pour accepter l’algorithme de hachage à utiliser.) Le hachage est unique et est utilisé uniquement pour la session entre le client et le site pour chiffrer et déchiffrer les messages. Le client et le service possèdent la valeur à usage unique d'origine et la clé publique du certificat ; ils peuvent donc tous deux générer le même hachage. Par conséquent, le client valide le hachage envoyé par le service par (a) à l’aide de l’algorithme convenu pour calculer le hachage à partir des données et (b) en le comparant au hachage envoyé par le service ; si les deux correspondances, le client a l’assurance que le hachage n’a pas été falsifié. Le client peut ensuite utiliser ce hachage en tant que clé pour chiffrer un message qui contient un autre nouveau hachage. Le service peut déchiffrer le message à l’aide du hachage et récupérer cet avant-dernier hachage. Les informations accumulées (nonces, clé publique et autres données) sont désormais connues des deux côtés, et un hachage final (ou clé principale) peut être créé. Cette clé finale est envoyée chiffrée à l’aide du hachage suivant. La clé principale est ensuite utilisée pour chiffrer et déchiffrer les messages pour le reste de la session. Étant donné que le client et le service utilisent la même clé, il s’agit également d’une clé de session.
La clé de session est également caractérisée comme une clé symétrique ou un « secret partagé ». L’utilisation d’une clé symétrique est importante, car elle réduit le calcul requis par les deux côtés de la transaction. Si chaque message exigeait un nouvel échange de valeurs à usage unique et de hachages, les performances s'en trouveraient dégradées. Par conséquent, l’objectif ultime de SSL est d’utiliser une clé symétrique qui permet aux messages de circuler librement entre les deux côtés avec un plus grand degré de sécurité et d’efficacité.
La description précédente est une version simplifiée de ce qui se passe, car le protocole peut varier d’un site à un autre. Il est également possible que le client et le site génèrent tous deux des valeurs à usage unique combinées de façon algorithmique durant le protocole de transfert, afin d'ajouter de la complexité, et par conséquent de la protection, au processus d'échange de données.
Certificats et infrastructure à clé publique
Pendant le protocole de transfert, le service envoie également son certificat SSL au client. Le certificat contient des informations, telles que sa date d’expiration, l’autorité émettrice et l’URI (Uniform Resource Identifier) du site. Le client compare l'URI à celui qu'il a contacté initialement afin de s'assurer qu'ils correspondent, et il vérifie également la date et l'autorité émettrice.
Chaque certificat a deux clés, une clé privée et une clé publique, et les deux sont appelées paires de clés exchange. En bref, la clé privée est connue uniquement du propriétaire du certificat tandis que la clé publique est lisible à partir du certificat. L’une ou l’autre clé peut être utilisée pour chiffrer ou déchiffrer une synthèse, un hachage ou une autre clé, mais uniquement comme opérations contraires. Par exemple, si le client chiffre avec la clé publique, seul le site peut déchiffrer le message à l’aide de la clé privée. De même, si le site chiffre avec la clé privée, le client peut déchiffrer avec la clé publique. Cela garantit au client que les messages sont échangés uniquement avec le possesseur de la clé privée, car seuls les messages chiffrés avec la clé privée peuvent être déchiffrés avec la clé publique. Le site est assuré qu’il échange des messages avec un client qui a chiffré à l’aide de la clé publique. Cet échange n'est sécurisé que pour une poignée de main initiale ; c'est pourquoi beaucoup d'autres mesures sont prises pour créer la véritable clé symétrique. Néanmoins, toutes les communications dépendent du service ayant un certificat SSL valide.
Implémentation de SSL avec WCF
La sécurité du transport HTTP (ou SSL) est fournie en externe à WCF. Vous pouvez implémenter SSL de deux façons ; le facteur de décision est la façon dont votre application est hébergée :
Si vous utilisez Internet Information Services (IIS) comme hôte WCF, utilisez l’infrastructure IIS pour configurer un service SSL.
Si vous créez une application WCF auto-hébergée, vous pouvez lier un certificat SSL à l’adresse à l’aide de l’outil HttpCfg.exe.
Utilisation d’IIS pour la sécurité du transport
IIS 7.0
Pour configurer IIS 7.0 en tant qu’hôte sécurisé (à l’aide de SSL), consultez Configuration de la couche Sockets sécurisés dans IIS 7.0.
Pour configurer des certificats à utiliser avec IIS 7.0, consultez Configuration des certificats de serveur dans IIS 7.0.
IIS 6.0
Pour configurer IIS 6.0 en tant qu’hôte sécurisé (à l’aide de SSL), consultez Configuration de la couche Sockets sécurisés.
Pour configurer des certificats à utiliser avec IIS 6.0, consultez Certificates_IIS_SP1_Ops.
Utilisation de HttpCfg pour SSL
Si vous créez une application WCF auto-hébergée, utilisez l’outil HttpCfg.exe .
Pour plus d’informations sur l’utilisation de l’outil HttpCfg.exe pour configurer un port avec un certificat X.509, consultez Guide pratique pour configurer un port avec un certificat SSL.