Tweet
SSL/TLS, la voie de la sécurisation passe par HTTPS
En ce moment, on entend beaucoup parler de cette nouvel URL HTTPS. Je me suis penché sur cette nouvelle manière de communication et essayer de clarifier son fonctionnement. De plus, cerise sur le gâteau, j'ai découvert des sites qui proposaient des services HTTPS gratuit en ligne.
On peut même fabriquer soi-même son propre certificat d'authentification en local, ce qui reste assez simple au premier abord.
HTTPS, un simple S ajouté propose de sécuriser votre connexion, incroyable pourtant ce S cache des manipulations réseaux plus complexes qu'il n'y paraît.
Véritable cheval de bataille de Facebook ou encore tweeter, comme on a pu le voir dans mon dernier article, il n'en reste pas moins un bouclier contre la plupart des attaques de piratages, malheureusement pas toutes. J'ai essayé de résumer et simplifier au maximum ce type de protocoles. Étant un vaste sujet de discussion, je ferais d'autre article plus tard. De plus, je travaille sur un article réseau assez conséquent qui est le travail d'une année complète entrecoupée du travail, formation et famille.
SSL/TLS
C'est un ensemble de protocoles qui s'accompagne d'un algorithme de chargements de données mais aussi d'une signature.
Il faut savoir qu'à l'heure actuelle, TLS permet de chiffrer pratiquement tous les protocoles, ce qui est un plus pour ne pas avoir par exemple une connexion chiffrée en HTTPS mais nos courriels en STMP non protégés par le chiffrement
Cette authentification SSL/TLS du serveur se décompose en 3 :
- Authentification faible du serveur
- Authentification forte du serveur (EV, facultative)
- Authentification du client (facultative)
Pour la petite histoire, SSL est né avec Netscape lors des années 1990, avec pour but de chiffrer les données transitant entre un serveur et le client. En effet, avec des outils perfectionnés comme Whireshark, TC Dump,… un pirate pouvait non seulement intercepter les paquets mais en plus les lire distinctement.
Pour cela, il lui suffisait de siniser par exemple sur le réseau. Encore, de nos jours ce type d'attaque fait rage et est largement utilisé (MITM). Pour cela, il a décidé de signer, ce que l'on appelle la norme X 509 hérité des Télécommunication.
Grâce à la normalisation RFC, SSL est devenu progressivement SSL/TLS. Le système est ainsi devenu plus générique et fiable. Pour le rendre plus abordable, les grands hébergeurs ont fait pression sur les groupes afin de pouvoir proposer à leurs clients des certificats low cost.
Les protocoles clients/serveurs SSL ont la particularité d'être très long, car ils dépendent de négociation et de mise au point technique conséquente et qui durent des années avant de lancer une nouvelle version.
Les protocoles à la charge d'SSL
Les autres protocoles se sont emparées de cette sécurité aidé par TLS et ont permis de voir le jour à SMTP(S), pop(S),…
Cependant, des protocoles utilisent des chiffrements indépendants de TLS comme par exemple DNS DNSSEC.
Le problème est qu'avant, on devait passer par plusieurs ports différents, car, par exemple le port 80 est celui d'http mais si vous faites https://twitter.com:80, vous aurez une erreur. En faite, vous ouvrez la mauvaise porte. Il faut alors faire https://twitter.com:443, là impeccable puisque vous ouvrez la porte vers le tunnel de chiffrement SSL/TLS.
D'ailleurs lorsque twitter mettront à jour ses liens de redirection t.co comme je l'ai précisé dans mon article les sites en http auront des ralentissements. Cependant, on peut lire du HTTPS dans du http mais pas le contraire.
Je m'explique si vous mettez une vidéo avec une URL en http dans une page en https, elle ne s'affichera pas. Ce qui est logique puisque la tunnelisation crypté ne peut fonctionner.
Lorsque HTTPS pousse la porte, votre navigateur demande à parler crypto et demande ses papiers d'identité (certificat d'autorité). Il pousse en quelque sorte la porte qui est vérouillé (port) et une fois vérifié, les clés pour l'ouvrir sont disponibles.
C'est pour cela, qu'ils ont essayé de ne créer qu'un seul port pour que la connexion passe comme dans un tunnel plutôt que dans un acheminement de ports trop lourds à supporter.
Un chiffrement symétrique
Comme, le chiffrement asymétrique revenait excessivement cher, ils ont préféré passer par un arrangement du symétrique. C'est-à-dire, qu'ils créaient ce que l'on appelle une clé de session unique qui est en fait une clé asymétrique au départ entre le serveur et le client, mais qui devient symétrique chez le serveur et le client. Chacun déchiffre sa clé dans son coin puis les compare ensuite.
C'est assez complexe à entendre ainsi, mais cela permet de ne pas avoir à générer constamment des clés et surtout à fluidifier la navigation.
Comment voir ces certificats et autres clés. Simplement, vous cliquez sur le cadenas à gauche de l'URL, vous pourrez y voir dans un premier temps est coordonné de la société, nom de domaine, adresse,…
En cliquant sur les détails, dans un deuxième temps vous serez comme dans le Screen devant l'arborescence présentant les informations sur le NDD mais aussi les différents attributs relatif au certificat.
On peut voir que twitter passe par un chiffrement SHA-256 RSA et d'autres informations.
La plupart des clés sont intégrées dans la conception des navigateurs, c'est ainsi qu'ils communiquent et reconnaissent les certificats d'autorité. Sinon, nous devrions les lire nous-même et acceptons manuellement ensuite la connexion, heureusement tout est intégré et donc cela se passe assez facilement et rapidement.
Le fonctionnement des certificats est dit "chaîné", car lorsque l'on regarde sur Twitter, on remarque qu'il y a au-dessus d'autres autorités. En fait, seules les grandes instances d'autorité sont reconnues, les autres étant comme enveloppées par celles-ci.
C'est un peu comme un hébergeur qui loue un emplacement à un site web, là il s'agit d'un certificat.
Donc, il est raisonnable de retrouver ce certificat au-dessus du vôtre qui en fait et désolé du pléonasme va certifier votre certificat.
Ces certificats fonctionnent à partir de deux clés :
- une clé publique
- une clé privée
C'est un peu comme un coffre à la banque, vous possédez d'une clé publique fournie par tous les navigateurs qui vous permettent d'entrer, mais ensuite une fois authentifié le serveur vont fournir la clé privée qui vous permettra d'accéder au site.
On a des sites qui le font comme par exemple chez OVH :
https://www.globalsign.com/repository/
Mais on pourrait très bien le faire soi-même sur son serveur local ainsi :
Code:
### certificats CA et serveur auto-signé ### # option sans mot de passe (pour éviter d'avoir à le taper au démarrage du serveur) ## RSA ## # création du certificat de l'autorité de certification # la clé (4096 plutôt que 2048) openssl genrsa -out rsa_ca.key 4096 # création du certificat x509 # renseigner les rubriques openssl req -new -x509 -sha256 -days 730 -key rsa_ca.key -out rsa_ca.crt # vérifier openssl x509 -in rsa_ca.crt -text -noout
Code:
# certificat serveur # création clé privée openssl genrsa -out rsa_server.key 4096 #Protection clé chown root:ssl-cert rsa_server.key chmod 440 rsa_server.key
Code:
# création demande de signature de certificat # renseigner les rubriques # common name = nom serveur openssl req -new -sha256 -days 730 -key rsa_server.key -out rsa_server.csr # signature openssl x509 -req -sha256 -in rsa_server.csr -CA rsa_ca.crt -CAkey rsa_ca.key \ -CAcreateserial -CAserial rsa_ca.srl -days 730 -out rsa_server.crt # vérifier openssl x509 -in rsa_server.crt -text -noout
Code:
## ECDSA # création CA ECDSA # création du certificat de l'autorité de certification # la clé openssl ecparam -name secp384r1 -genkey -out ec_ca.key # création du certificat x509 # renseigner les rubriques openssl req -new -x509 -sha256 -days 730 -key ec_ca.key -out ec_ca.crt # vérifier openssl x509 -in ec_ca.crt -text -noout
Code:
# certificat serveur # création clé privée openssl ecparam -name secp384r1 -genkey -out ec_server.key # création demande de signature de certificat # renseigner les rubriques # common name = nom du serveur openssl req -new -sha256 -days 730 -key ec_server.key -out ec_server.csr
Code:
# signature openssl x509 -req -sha256 -in ec_server.csr -CA ec_ca.crt -CAkey ec_ca.key \ -CAcreateserial -CAserial ec_ca.srl -days 730 -out ec_server.crt # vérifier openssl x509 -in ec_server.crt -text -noout
Mais des sociétés génèrent pour vous des certificats gracieusement et surtout gratuitement :
http://www.cacert.org/
http://www.startssl.com/?app=1
La mise en place par exemple sur Apache :
Code:
<VirtualHost _default_:443> ServerAdmin [email protected] DocumentRoot /var/www SSLCertificateFile /etc/ssl/private/vivageek.com.crt SSLCertificateChainFile /etc/ssl/private/vivageek.com.chain SSLCertificateKeyFile /etc/ssl/private/vivgeek.com.key SSLEngine on SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1 SSLCompression off SSLHonorCipherOrder on # SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA- AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256- SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM- SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4- SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128- GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA SSLCipherSuite ALL:!aNULL:!eNULL:!LOW:!EXP:!RC4:!3DES:+HIGH:+MEDIUM Header set Strict-Transport-Security "max-age=2678400" ... </VirtualHost>
Explication :
- cipher = algorithme de (dé)chiffrement
- ServerAdmin [email protected] le nom de l'admin du serveur
- DocumentRoot /var/www on est root sur le serveur
- /etc/ssl/private/vivageek.com.crt l'endroit où est déposer la clé privé
- Protocoles de transport : SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2
En effet, ce que l'on chiffre, on devra nécessairement le déchiffrer afin que le serveur comprenne les données envoyé sinon notre visiteur sera à la porte du serveur en attente. On privilégiait toujours les versions TLS les plus récentes. On remarque que la clé privée est dans le serveur, en effet c'est bizarre qu'elle reste dans le coffre-fort, mais cela permet d'avoir une sécurité de plus.
Les attaques peuvent à partir des navigateurs être une source de compromission surtout si vous vous promeniez avec la clé privée. C'est pour cela qu'elle est toujours conservée dans le serveur.
Conclusion
Ce nouveau type de communication risque fort de devenir un standard usuel et surtout obligatoire dans le futur web. Pour cela, il est utile d'essayer de mieux le connaître et d'apprivoiser ces termes techniques. Comme on peut le voir il est aisé d'installer un protocole SSL sur Easyphp, WAMP, … en local.
Je vais vous aider regardez tapez sur windows :
Tapez Cmd
Dans l'invite de commande :
Code:
openssl req -config "C:\Program Files (x86)\EasyPHP-DevServer-14.1VC11\binaries\apache\conf\openssl.cnf" -new -out site.csr
Vous aurez alors :
Enter PEM pass phrase : tapez le mot de passe que vous voulez en enter.
Votre Pays : https://www.digicert.com/ssl-certifi...ntry-codes.htm
Continuez à renseigner jusqu'à la fin puis tapez :
Code:
openssl rsa -in privkey.pem -out site.key openssl x509 -in site.csr -out site.cert -req -signkey site.key -days 365 openssl x509 -in site.cert -out site.der.crt -outform "DER 9"
S'il le faut renseigner le PEM choisi tantôt, vous êtes l'heureux possesseur d'un certificat SSL auto signé en local. Regardez sur votre bureau, il devrait avoir apparu avec un icône de certificat.
La communication veut devenir plus sécurisée, cela ne veut pas dire qu'elle l'est et attention à ne pas avoir un sentiment de sécurité qui vous feraient perdre toute méfiance.
En effet, beaucoup de techniques permettent de contourner SSL/TLS et il faut être à l'écoute des attaques mais aussi des solutions apportées.
Merci de m'avoir lu, à bientôt.
