Serveur Apache HTTP Version 2.4
Serveur Apache HTTP Version 2.4
Ce chapitre en guise d'introduction est destin� aux lecteurs pour lesquels
le Web, HTTP et Apache sont familiers, mais ne sont pas des experts en mati�re
de s�curit�. Il n'a pas la pr�tention d'�tre un guide d�taill� sur le
protocole SSL, il ne traitera pas non plus des techniques sp�cifiques de gestion
des certificats dans une organisation, ni des importants probl�mes l�gaux de
brevets ou des restrictions d'importation ou d'exportation. Il se veut plut�t
une base de travail pour les utilisateurs de mod_ssl en
rassemblant diff�rents concepts, d�finitions et exemples comme point de d�part
pour une exploration plus d�taill�e.
La ma�trise de SSL n�cessite la compr�hension des algorithmes de chiffrement, des fonctions relatives aux empreintes de messages (comme les fonctions de type hash ou non r�versibles), et des signatures num�riques. Ces techniques pourraient faire l'objet d'un ouvrage � elles seules (voir par exemple [AC96]) et constituent les bases de la confidentialit�, de l'int�grit� et de l'authentification.
Supposons qu'Alice veuille envoyer un message � sa banque pour transf�rer une certaine somme. Alice souhaiterait que le message soit priv�, car il contient des informations comme son num�ro de compte et le montant du transfert. Une solution consisterait � utiliser un algorithme de chiffrement, technique qui permet de remplacer un message par sa version chiffr�e, illisible jusqu'� ce qu'elle soit d�chiffr�e. Sous sa forme chiffr�e, le message ne peut �tre d�chiffr� qu'en utilisant une cl� secr�te. Sans la cl�, le message est inutilisable : les bons algorithmes de chiffrement rendent si difficile la restitution du texte original par des intrus que ceux-ci y gaspilleraient leurs efforts.
Il existe deux cat�gories d'algorithmes de chiffrement : conventionnel ou � cl� publique.
Tout le monde peut chiffrer un message en utilisant la cl� publique, mais seul le propri�taire de la cl� priv�e sera en mesure de le lire. De cette fa�on, Alice peut envoyer des messages priv�s au propri�taire d'une paire de cl�s (sa banque), en les chiffrant � l'aide de la cl� publique. Seule la banque sera en mesure de les d�chiffrer.
Bien qu'Alice puisse chiffrer son message pour le rendre priv�, il subsiste toujours le risque que quelqu'un puisse modifier le message original ou le remplacer par un autre, afin d'effectuer le transfert de fonds � son profit, par exemple. Une solution pour garantir l'int�grit� du message consisterait pour Alice � cr�er un r�sum� concentr� de son message qu'elle enverrait � sa banque avec ce dernier. A la r�ception du message, la banque cr�e son propre r�sum� et le compare avec celui qu'Alice a envoy�. Si les deux r�sum�s sont identiques, le message re�u n'a pas �t� modifi�.
Un r�sum� tel que celui-ci est appel� empreinte num�rique de message (message digest), fonction irr�versible (one-way function) ou fonction de hashage (hash function). Une empreinte de message constitue une repr�sentation courte et de longueur fixe, d'un message plus long et de longueur variable. Les algorithmes de cr�ation d'empreintes sont con�us pour produire une empreinte unique pour chaque message. Les empreintes de messages sont con�ues pour que la restitution du message � partir de l'empreinte soit d'une difficult� insurmontable, et qu'il soit (en th�orie) impossible de trouver deux messages diff�rents qui produisent la m�me empreinte -- ce qui �limine la possibilit� de remplacer un message par un autre en conservant la m�me empreinte.
Trouver le moyen d'envoyer l'empreinte de mani�re s�curis�e � la banque constitue un autre d�fit auquel Alice doit faire face ; si l'empreinte n'est pas envoy�e de mani�re s�curis�e, son int�grit� peut �tre compromise, et avec elle, la possibilit� pour la banque de v�rifier l'int�grit� du message original. L'int�grit� du message ne peut �tre v�rifi�e que si l'empreinte qui lui est associ�e est envoy�e de mani�re s�curis�e.
Une solution pour envoyer l'empreinte de mani�re s�curis�e consiste � l'inclure dans une signature num�rique.
Quand Alice envoie un message � sa banque, cette derni�re doit s'assurer que le message a bien �t� envoy� par elle, pour �viter qu'un intrus puisse effectuer une transaction sur son compte. Une signature num�rique, cr��e par Alice et incluse dans le message, permet d'atteindre cet objectif.
Les signatures num�riques peuvent �tre cr��es en chiffrant une empreinte de message, ainsi que d'autres informations (comme un num�ro d'ordre) avec la cl� priv�e de l'exp�diteur. Bien que tout le monde puisse d�chiffrer la signature � l'aide de la cl� publique, seul l'exp�diteur connait la cl� priv�e. Ce qui implique que seul l'exp�diteur peut avoir sign� le message. Inclure l'empreinte dans la signature entra�ne que cette derni�re n'est valable que pour ce message ; ceci assure aussi l'int�grit� du message car personne ne peut modifier l'empreinte et ensuite signer le message.
Afin de se pr�munir contre l'interception et la r�utilisation de la signature par un intrus quelques jours plus tard, la signature contient un num�ro d'ordre unique. Ceci prot�ge la banque contre une plainte frauduleuse de la part d'Alice all�guant qu'elle n'a pas envoy� le message -- elle seule peut l'avoir sign� (non-r�pudiation).
Bien qu'Alice soit parvenue � envoyer un message priv� � sa banque, apr�s l'avoir sign� et avoir ainsi assur� l'int�grit� du message, elle doit encore v�rifier qu'elle communique r�ellement avec la banque. C'est � dire qu'elle doit s'assurer que la cl� publique qu'elle utilise appartient bien � la paire de cl�s de la banque, et non � celle d'un intrus. De m�me, la banque doit v�rifier que la signature du message a bien �t� construite avec la cl� priv�e d'Alice.
Si chaque partie poss�de un certificat qui valide l'identit� de l'autre, confirme la cl� publique, et est sign� par un organisme de confiance, alors les deux protagonistes peuvent �tre s�rs que la personne avec laquelle ils communiquent est bien celle avec laquelle ils d�sirent le faire. Un tel organisme de confiance s'appelle une Autorit� de Certification, et on utilise les certificats � des fins d'authentification.
Un certificat associe une cl� publique avec l'identit� r�elle d'un individu, d'un serveur, ou d'une autre entit� plus connue sous le nom de sujet. Comme on le voit dans le Tableau 1, les information concernant le sujet comprennent des informations d'identification (le nom distinctif ou distinguished name - dn), ainsi que la cl� publique. Il comporte aussi l'identification et la signature de l'autorit� de certification qui a d�livr� le certificat, ainsi que la p�riode de validit� de ce dernier. Il peut aussi contenir des informations suppl�mentaires (ou extensions) telles que des informations de gestion destin�es � l'autorit� de certification, comme un num�ro de s�rie.
| Sujet | Nom distinctif, Cl� publique |
|---|---|
| Fournisseur | Nom distinctif, Signature |
| P�riode de validit� | Pas avant, Pas apr�s |
| Informations de gestion | Version, Num�ro de s�rie |
| Extensions | Contraintes de base, Drapeaux Netscape, etc. |
Un nom distinctif sert � fournir une identit� dans un contexte sp�cifique -- par exemple, un individu peut poss�der un certificat personnel, et aussi un certificat en tant qu'employ�. Les noms distinctifs doivent respecter le standard X509 [X509], qui d�finit les champs, les noms de champs, et les abr�viations utilis�es pour faire r�f�rence aux champs (voir Tableau 2).
| Champ du DN | Abr�v. | Description | Exemple |
|---|---|---|---|
| Nom complet (Common Name) | CN | Nom certifi� | CN=Joe Average |
| Organisation or Entreprise | O | Nom est associ� � cette organisation |
O=Snake Oil, Ltd. |
| Unit� organisationnelle (Organizational Unit) | OU | Nom est associ� avec cette unit� organisationnelle, par exemple un d�partement |
OU=Research Institute |
| Ville/Localisation | L | Nom est localis� dans cette ville | L=Snake City |
| Etat/Province | ST | Nom est localis� dans cet �tat/province | ST=Desert |
| Pays | C | Nom est localis� dans ce pays (code ISO) | C=XZ |
Une autorit� de certification peut d�finir une contrainte sp�cifiant
quels champs du nom distinctif sont optionnels et lesquels sont
obligatoires. Elle peut aussi imposer des contraintes sur le contenu des
champs, ce que peuvent aussi faire les utilisateurs de certificats. Par
exemple, un navigateur Netscape peut exiger, dans le cas d'un certificat
de serveur, que le nom complet (Common Name) corresponde � un nom g�n�rique
contenant le nom de domaine du serveur, comme
*.snakeoil.com.
Le format binaire d'un certificat est d�fini en utilisant la notation ASN.1 [ASN1] [PKCS]. Cette notation definit la mani�re de sp�cifier les contenus, et les r�gles d'encodage d�finissent la mani�re dont ces information sont converties au format binaire. L'encodage binaire du certificat est d�fini par les R�gles d'Encodage Distinctives (Distinguished Encoding Rules - DER), qui se basent d'une mani�re plus g�n�rale sur les R�gles d'Encodage de Base (Basic Encoding Rules - BER). Pour les transmissions qui ne supportent pas le format binaire, ce dernier peut �tre converti au format ASCII en utilisant le codage Base64 [MIME]. Lorsqu'il est plac� entre des d�limiteurs de d�but et de fin (comme ci-dessous), on dit que le certificat est encod� au format PEM ("Privacy Enhanced Mail").
-----BEGIN CERTIFICATE----- MIIC7jCCAlegAwIBAgIBATANBgkqhkiG9w0BAQQFADCBqTELMAkGA1UEBhMCWFkx FTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25ha2UgVG93bjEXMBUG A1UEChMOU25ha2UgT2lsLCBMdGQxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhv cml0eTEVMBMGA1UEAxMMU25ha2UgT2lsIENBMR4wHAYJKoZIhvcNAQkBFg9jYUBz bmFrZW9pbC5kb20wHhcNOTgxMDIxMDg1ODM2WhcNOTkxMDIxMDg1ODM2WjCBpzEL MAkGA1UEBhMCWFkxFTATBgNVBAgTDFNuYWtlIERlc2VydDETMBEGA1UEBxMKU25h a2UgVG93bjEXMBUGA1UEChMOU25ha2UgT2lsLCBMdGQxFzAVBgNVBAsTDldlYnNl cnZlciBUZWFtMRkwFwYDVQQDExB3d3cuc25ha2VvaWwuZG9tMR8wHQYJKoZIhvcN AQkBFhB3d3dAc25ha2VvaWwuZG9tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB gQDH9Ge/s2zcH+da+rPTx/DPRp3xGjHZ4GG6pCmvADIEtBtKBFAcZ64n+Dy7Np8b vKR+yy5DGQiijsH1D/j8HlGE+q4TZ8OFk7BNBFazHxFbYI4OKMiCxdKzdif1yfaa lWoANFlAzlSdbxeGVHoT0K+gT5w3UxwZKv2DLbCTzLZyPwIDAQABoyYwJDAPBgNV HRMECDAGAQH/AgEAMBEGCWCGSAGG+EIBAQQEAwIAQDANBgkqhkiG9w0BAQQFAAOB gQAZUIHAL4D09oE6Lv2k56Gp38OBDuILvwLg1v1KL8mQR+KFjghCrtpqaztZqcDt 2q2QoyulCgSzHbEGmi0EsdkPfg6mp0penssIFePYNI+/8u9HT4LuKMJX15hxBam7 dUHzICxBVC1lnHyYGjDuAMhe396lYAn8bCld1/L4NMGBCQ== -----END CERTIFICATE-----
En v�rifiant les informations contenues dans une demande de certificat avant de l'accorder, l'autorit� de certification s'assure de l'identit� du propri�taire de la cl� priv�e issue de sa paire de cl�s. Par exemple, Si Alice demande un certificat personnel, l'autorit� de certification doit d'abord s'assurer qu'elle correspond vraiment � la personne � laquelle la demande de certificat fait r�f�rence.
Une autorit� de certification peut aussi �mettre un certificat � destination d'une autre autorit� de certification. Pour v�rifier un certificat, Alice peut �tre amen�e � v�rifier le certificat de l'�metteur pour chaque autorit� de certification parente, jusqu'� ce qu'elle en atteigne une en qui elle a confiance. Elle peut aussi ne faire confiance qu'aux certificats faisant l'objet d'une cha�ne limit�e d'�metteurs, afin de r�duire le risque de rencontrer un "mauvais" certificat dans la cha�ne.
Comme indiqu� plus haut, chaque certificat n�cessite la validation de l'identit� du sujet par un �metteur de certificats de niveau sup�rieur, et ceci en remontant jusqu'� l'Autorit� de Certification (CA) racine. Ceci pose un probl�me : qui va se porter garant du certificat de l'autorit� racine qui ne poss�de pas d'�metteur de certificat ? C'est uniquement dans ce cas que le certificat est auto-sign�, l'�metteur du certificat et son sujet �tant confondus. Les navigateurs sont pr�configur�s avec une liste d'autorit�s de certification de confiance, mais il est important d'�tre extr�mement prudent avant de faire confiance � un certificat auto-sign�. La large publication d'une cl� publique par l'autorit� racine r�duit cependant les risques encourus en faisant confiance � cette cl� -- si quelqu'un publiait une cl� en se faisant passer pour l'autorit�, il serait vite d�masqu�.
Quelques compagnies, comme Thawte et VeriSign, se sont proclam�es elles-m�mes Autorit�s de Certification. Ces compagnies proposent les services suivant :
Vous pouvez aussi cr�er votre propre autorit� de certification. Bien que risqu� dans l'environnement de l'Internet, ceci peut s'av�rer utile dans un Intranet, o� l'organisme peut v�rifier facilement les identit�s des individus et des serveurs.
Constituer une autorit� de certification repr�sente une responsabilit� qui n�cessite une solide infrastructure administrative, technique et gestionnaire. Les autorit�s de certification ne se contentent pas d'�mettre des certificats, elles doivent aussi les g�rer -- � savoir elles d�terminent leur dur�e de validit�, elles les renouvellent, et elles maintiennent des listes de certificats qui ont �t� �mis dans le pass� mais ne sont plus valides (Listes de r�vocations de certificats, ou CRLs).
Par exemple, si Alice est titulaire d'un certificat en tant qu'employ�e d'une compagnie, mais vient de quitter cette compagnie, son certificat doit �tre r�voqu�. Comme les certificats ne sont �mis qu'apr�s v�rification de l'identit� du sujet, et peuvent �tre envoy�s � tous ceux avec lesquels le sujet peut communiquer, il est impossible de discerner � partir du seul certificat s'il a �t� r�voqu�. Pour v�rifier la validit� d'un certificat, il est donc n�cessaire de contacter l'autorit� de certification qui l'a �mis afin de pouvoir consulter ses listes de r�vocations de certificats -- ce qui n'est en g�n�ral pas une partie automatique du processus.
Si votre autorit� de certification ne fait pas partie de la liste des autorit�s de confiance de votre navigateur, il faut enregistrer le certificat de l'autorit� de certification dans ce dernier, ce qui lui permettra de valider les certificats de serveurs sign�s par cette autorit� de certification. Ceci peut �tre dangereux, car une fois le certificat enregistr�, le navigateur acceptera tous les certificats sign�s par cette autorit� de certification.
Le protocole Couche Points d'Acc�s S�curis�s est une couche protocolaire qui pourrait s'intercaler entre un protocole d'une couche r�seau orient�e connexion (comme TCP/IP) et une couche protocolaire d'application (comme HTTP). SSL fournit une communication s�curis�e entre client et serveur en permettant l'authentification mutuelle, l'utilisation des signatures num�riques pour la v�rification de l'int�grit� des donn�es, et le chiffrement pour la confidentialit�.
Ce protocole est con�u pour supporter un grand choix d'algorithmes sp�cifiques utilis�s pour la cryptographie, les empreintes et les signatures. Ceci permet la s�lection d'un algorithme pour des serveurs sp�cifiques en respectant la l�galit�, les r�gles d'exportation ou autres contraintes, et permet aussi au protocole de tirer parti des nouveaux algorithmes. Ces choix font l'objet d'une n�gociation entre client et serveur lors de l'�tablissement de la session protocolaire.
| Version | Source | Description |
|---|---|---|
| SSL v2.0 | Standard du fournisseur (de Netscape Corp.) | Premier protocole SSL pour lequel il existe des impl�mentations |
| SSL v3.0 | Projet Internet arriv� � expiration (de Netscape Corp.) [SSL3] | Comporte des r�visions permettant de pr�venir certaines attaques de s�curit� sp�cifiques, ajout de chiffrements non RSA, et support des cha�nes de certification |
| TLS v1.0 | Standard propos� pour l'Internet (de l'IETF) [TLS1] | R�vision de SSL 3.0 pour mettre � jour la couche MAC vers HMAC, ajout du bourrage de bloc pour le chiffrement de bloc, standardisation de l'ordonnancement des messages et plus de messages d'alerte. |
| TLS v1.1 | Standard propos� pour l'Internet (de l'IETF) [TLS11] | Mise � jour de TLS 1.0 pour la protection contre les attaques de type Cipher block chaining (CBC). |
| TLS v1.2 | Standard propos� pour l'Internet (de l'IETF) [TLS12] | Mise � jour de TLS 1.2 rendant les condens�s MD5 obsol�tes, et introduisant une incompatibilit� avec SSL ce qui interdit toute n�gociation en vue d'une utilisation de SSLv2. |
Il existe plusieurs versions du protocole SSL, comme le montre le Tableau 4. Comme indiqu� dans ce dernier, un des apports de SSL 3.0 est le support du chargement des cha�nes de certification. Cette fonctionnalit� permet � un serveur de passer au navigateur un certificat de serveur accompagn� du certificat de l'�metteur. Le chargement de la cha�ne permet aussi au navigateur de valider le certificat du serveur, m�me si les certificats de l'autorit� de certification ne sont pas install�s pour les �metteurs interm�diaires, car ils sont inclus dans la cha�ne de certification. SSL 3.0 sert de base au standard du protocole S�curit� de la Couche Transport ou Transport Layer Security [TLS], actuellement en d�veloppement au sein de l'Internet Engineering Task Force (IETF).
La session SSL est �tablie en suivant une s�quence d'�changes d'informations entre client et serveur, comme le montre la Figure 1. Cette s�quence peut varier, selon que le serveur est configur� pour fournir un certificat de serveur ou r�clame un certificat client. Bien que dans certains cas, des �tapes d'�changes d'informations suppl�mentaires soient n�cessaires pour la gestion des informations de chiffrement, cet article r�sume un sc�nario courant. Se reporter aux sp�cifications SSL pour avoir la liste de toutes les possibilit�s.
Une fois la session SSL �tablie, elle peut �tre r�utilis�e. Ceci permet d'�viter la perte de performances due � la r�p�tition des nombreuses �tapes n�cessaires � l'�tablissement d'une session. Pour parvenir � ceci, le serveur assigne un identifiant de session unique � chaque session SSL ; cet identifiant est mis en cache dans le serveur et le client peut l'utiliser pour des connexions ult�rieures afin de r�duire la dur�e des �changes d'informations (et ceci jusqu'� ce que l'identifiant de session arrive � expiration dans le cache du serveur).
Figure 1 : S�quence
simplifi�e d'�changes d'informations SSL
Les �l�ments de la s�quence d'�changes d'informations, tels qu'ils sont utilis�s par le client et le serveur, sont �num�r�s ci-apr�s :
La premi�re �tape, la n�gociation de la suite de chiffrement, permet au client et au serveur de choisir une suite de chiffrement qu'ils supportent tous les deux. La sp�cification du protocole SSL 3.0 d�finit 31 suites de chiffrement. Une suite de chiffrement se compose des �l�ments suivants :
Ces trois �l�ments sont d�crits dans les sections suivantes.
La m�thode d'�change de la cl� d�finit la mani�re dont la cl� de chiffrement sym�trique secr�te et partag�e utilis�e pour le transfert des donn�es de l'application sera accept�e par le client et le serveur. SSL 2.0 utilise l'�change de cl� RSA seulement, tandis que SSL 3.0 supporte tout un choix d'algorithmes d'�change de cl� incluant l'�change de cl� RSA (quand les certificats sont utilis�s), et l'�change de cl�s Diffie-Hellman (pour �changer des cl�s sans certificat, ou en l'absence de communication pr�alable entre le client et le serveur).
Les signatures num�riques constituent une variante dans le choix des m�thodes d'�change de cl� -- utiliser les signatures ou pas, et dans l'affirmative, quel genre de signatures utiliser. La signature � l'aide d'une cl� priv�e fournit une protection contre une attaque "man-in-the-middle" au cours de laquelle l'�change d'informations destin� � g�n�rer la cl� partag�e peut �tre intercept� [AC96, p516].
Comme d�crit plus haut, SSL utilise le chiffrement sym�trique conventionnel pour chiffrer les messages au cours d'une session. Il existe neuf choix possibles pour le chiffrement, y compris l'option du transfert non chiffr� :
"CBC" signifie Cipher Block Chaining (Cha�nage de blocs chiffr�s), c'est � dire qu'une portion du bloc de texte chiffr� pr�c�dent est utilis�e pour le chiffrement du bloc courant. "DES" signifie Data Encryption Standard (Standard de Chiffrement des Donn�es) [AC96, ch12], et poss�de de nombreuses variantes (telles que DES40 et 3DES_EDE). Parmi les algorithmes disponibles, "Idea" est actuellement un des meilleurs et des plus puissants sur le plan cryptographique, et "RC2" est un algorithme propri�taire de RSA DSI [AC96, ch13].
Le choix d'une fonction de cr�ation d'empreinte d�termine la mani�re dont une empreinte est cr��e � partir d'une unit� de donn�es. SSL supporte les fonctions suivantes :
On utilise l'empreinte de message pour cr�er un Code d'Authentification de Message (Message Authentication Code - MAC) qui est chiffr� avec le message afin de v�rifier son int�grit� et de se prot�ger contre les attaques de type "rejeu".
La s�quence d'�changes d'informations utilise trois protocoles :
Ces protocoles, ainsi que les donn�es du protocole de l'application, sont encapsul�s dans le Protocole d'enregistrement SSL (SSL Record Protocol), comme le montre la Figure 2. Un protocole encapsul� est tranf�r� en tant que donn�es par le protocole de la couche de niveau inf�rieur, qui ne se pr�occupe pas du contenu des donn�es. Le protocole encapsul� n'a aucune connaissance du protocole sous-jacent.
Figure 2:
Pile du protocole SSL
L'encapsulation des protocoles de contr�le SSL dans le protocole d'enregistrement signifie que si une session active est ren�goci�e, les protocoles de contr�le seront transmis de mani�re s�curis�e. S'il n'y avait pas de session pr�alable, la suite de chiffrement Null est utilis�e, ce qui signifie que les messages ne seront pas chiffr�s et ne poss�deront pas d'empreinte d'int�grit�, jusqu'� ce que la session ait �t� �tablie.
Le protocole d'enregistrement SSL, comme le montre la Figure 3, est utilis� pour transmettre les donn�es de l'application et les donn�es de contr�le SSL entre le client et le serveur, les donn�es �tant n�cessairement fragment�es en �l�ments plus petits, ou plusieurs messages de donn�es avec protocole de niveau sup�rieur pouvant �tre combin�s en un seul �l�ment. Ce protocole peut joindre des signatures d'empreintes, compresser et chiffrer ces �l�ments avant de les transmettre en utilisant le protocole fiable de transport sous-jacent (Note : actuellement, aucune impl�mentation majeure de SSL n'inclut le support de la compression).
Figure 3:
Protocole d'enregistrement SSL
Une des utilisations courantes de SSL est la s�curisation des
communication HTTP sur le Web entre un navigateur et un serveur web. Ceci
n'exclut pas l'utilisation de HTTP non s�curis� - la version s�curis�e
(appel�e HTTPS) est identique � du vrai HTTP sur SSL,
mais utilise le pr�fixe
d'URL https au lieu de http, et un port
de serveur diff�rent (par d�faut le port 443).
Ceci constitue pour une large part
ce qu'apporte mod_ssl au serveur web Apache.
Applied Cryptography, 2nd Edition, Wiley, 1996. Voir http://www.counterpane.com/ pour diverses autres productions de Bruce Schneier.
Specification of Abstract Syntax Notation One (ASN.1), derni�re mise � jour en 2008. Voir http://www.itu.int/ITU-T/asn1/.
The Directory - Authentication Framework. A titre de r�f�rence, voir http://en.wikipedia.org/wiki/X.509.
Public Key Cryptography Standards (PKCS), RSA Laboratories Technical Notes, Voir http://www.rsasecurity.com/rsalabs/pkcs/.
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045. Voir par exemple http://tools.ietf.org/html/rfc2045.
The SSL Protocol Version 3.0, 1996. Voir http://www.netscape.com/eng/ssl3/draft302.txt.
The TLS Protocol Version 1.0, 1999. Voir http://ietf.org/rfc/rfc2246.txt.
Le protocole TLS Version 1.1, 2006. Voir http://tools.ietf.org/html/rfc4346.
Le protocole TLS Version 1.2, 2008. Voir http://tools.ietf.org/html/rfc5246.
