Get best of the week

Une introduction à TLS pour Patrik Patrick (Partie 1)

Comme vous le savez peut-être déjà, voici Patrick. Il est une étoile de mer, ce qui signifie qu'il est possible, sans l'insulter, de dire que ses mains poussent d'un endroit. Patrick est également très pratique et oublie immédiatement tout ce dont il n'a pas besoin - mais s'il a besoin de quelque chose, il veut le savoir (parce qu'il en a besoin!). Spoiler: ici Patrick essaie de faire une poignée de main TLS.



Cet article est écrit pour Patrick et des gens comme lui. Elle est née d'une présentation présentée pour la première fois lors de notre formation interne Plesk TechTalk, où des employés sous une forme accessible partagent des informations sur des technologies, des processus et des solutions intéressants. Par conséquent, les images de cet article ressembleront à des diapositives :) L'auteur du texte original du rapport est le responsable du programme Plesk Ruslan Kosolapov .

En règle générale, tout le matériel TLS couvre un petit aspect, mais pas la grande image. Ce n'est pas très pratique et Patrick a mal à la tête. Ici, tout sera différent: bref, applicable «au quotidien» et le plus exhaustivement possible.

Qu'est-ce que TLS et pourquoi est-ce pour Patrick


TLS (Transport Layer Security) est un protocole de protection de la couche transport. Il est nécessaire pour que personne ne puisse "vous écouter" et trouver des informations importantes (le plus souvent des mots de passe, si l'on parle de travailler sur le réseau). Et aussi pour se protéger de la falsification et de la modification du trafic lors de la transmission. C'est dans ces deux choses que réside le but de TLS.

Pour plus de clarté, considérons la négociation TLS comme un appel à Patrick SpongeBob. Pendant un appel, quelqu'un peut écouter la conversation (se tenir à côté de Patrick ou s'allumer au milieu de la ligne), et généralement le Bob l'éponge peut ne pas être à l'autre bout - tous ces problèmes sont pertinents. Et pour les résoudre, Patrick veut utiliser TLS.

En bref, la poignée de main de niveau supérieur ressemble à ceci:

Patrick: Je veux utiliser TLS, les versions de chiffrement sont telles ou telles.
Spongebob: Ok, utilisons des versions chiffrées telles ou telles.

Après cela, SpongeBob envoie le certificat, Patrick le vérifie, dit que tout va bien, la clé de session est terminée (il y en a deux, mais cela n'a pas d'importance). Pourquoi utiliser une clé de session plutôt qu'un cryptage asymétrique - car c'est plus rapide. Après cela, ils commencent à parler une langue incompréhensible pour le déchiffrement. Ainsi, tout est protégé.

Tout semble simple. Comment cela fonctionne sur le matériel n'est pas si important pour nous. Mais si vous commencez à penser - et Patrick commence à penser! - cela soulève la question de savoir comment convenir généralement que nous utiliserons TLS? Après tout, il n'y avait pas de TLS, mais il n'y avait que des protocoles ordinaires - SMTP, HTTP. Comment dire ce qui est nécessaire sur TLS? Et ici, dans notre industrie, tout est comme d'habitude - il y a plusieurs façons!

Au début, ils voulaient utiliser un port spécifique, ce qui impliquerait l'utilisation de TLS dessus. Quels en sont les inconvénients? Et pourquoi alors la méthode explicite (explicite) pour démarrer une session TLS est-elle apparue? Il existe plusieurs raisons:

  1. Vous avez besoin de beaucoup de ports - et les ports sont une chose que vous ne voulez pas dépenser. Parce que plus il y en a, plus il est difficile de configurer le pare-feu.
  2. Le serveur peut ignorer cela - il s'est connecté au port 443, et il n'y a pas de TLS, seulement HTTP sans HTTPS.
  3. Avant l'établissement de la connexion, vous ne pouvez pas savoir si le serveur TLS est pris en charge ou non.

Tout cela a conduit à l'émergence d'une méthode explicite - lorsque nous nous connectons à un port standard, puis mettons à niveau notre session vers TLS. Pour différents services, le protocole a des commandes différentes, par exemple, pour SMTP, il existe une commande distincte au niveau du protocole SMTP - STARTTLS . HTTP a aussi une telle blague, elle s'appelle Upgrade: TLS / 1.0 . Au niveau du protocole, il est plus facile de comprendre si un serveur TLS est pris en charge ou non.

Laissez-nous nous attarder un peu plus sur les différents types de connexions et comment les choses sont avec TLS pour eux.

Se connecter: HTTP


Tout serait facile s'il n'y avait pas, comme toujours, de nuances. Dans le cas de HTTP, les exigences de sécurité croissantes fournissent une évolution constante du processus de travail avec TLS. Au début, il y avait une redirection vers HTTPS, et cela se faisait simplement dans l'en-tête. Cela a laissé une faille pour les vulnérabilités, alors Google a proposé HSTS (HTTP Strict Transport Security). Il s'agit d'un tel en-tête dans la réponse HTTP qui indique au navigateur: «n'oubliez pas que lorsque vous arrivez sur ce domaine, allez directement en HTTPS, même si la personne vous a dit d'aller sur HTTP». Ainsi, il n'y a pas de redirection et tout se passe beaucoup plus sûr. En outre, Google a une autre initiative: vous pouvez laisser une demande afin que votre site soit ajouté à la liste de Google Chrome «Toujours utiliser HTTPS», quelles que soient les rubriques.

Brièvement: HSTS résout la redirection des vulnérabilités HTTP vers HTTPS, donc presque tous les navigateurs prennent en charge HSTS, ce qui est bien.

Connect: exotique (nouvelles versions de HTTP et pas seulement)


En HTTP / 2, les choses vont bien avec TLS: il est toujours utilisé (comme les navigateurs sont maintenant faits). De plus, TLS dans HTTP / 2 doit être récent - c'est-à-dire avoir la version 1.2+.

Très probablement, Google vendra très bientôt l'utilisation répandue de HTTP / 3, maintenant il est adopté par la norme IANA. L'histoire de son apparition et de son développement est assez déroutante; La principale chose à retenir de Patrick:

  • HTTP / 3 est toujours TLS 1.3+.
  • HTTP / 3 est basé sur QUIC - c'est un tel protocole sur UDP, qui, selon Google, est meilleur que TCP. En fait, avant que le nom HTTP / 3 ne soit finalement approuvé, le protocole s'appelait HTTP sur QUIC.

Il existe encore un protocole SCTP intéressant, utilisé principalement dans les télécommunications. Au-dessus, TLS et DTLS sont utilisés (c'est un TLS pour UDP).

En bref: dans 2 ans, QUIC (c'est-à-dire HTTP / 3) sera utilisé partout, mais maintenant il devrait déjà y avoir HTTP / 2 partout, mais en réalité il n'est pas partout.

Se connecter: Mail


De nombreux clients pensent qu'il devrait y avoir TLS sur le 587e port, mais il y a aussi des nuances ici: quelqu'un attend TLS par défaut et quelqu'un attend une demande STARTTLS explicite du client. Pour cette raison, diverses combinaisons de serveur de messagerie et de client de messagerie provoquent parfois des effets indésirables. Par exemple, un client entre dans le port 587, s'attendant à ce qu'il y ait TLS, en même temps, le serveur attend que le client demande explicitement STARTTLS . N'ayant rien reçu, le client revient au port 25. Le résultat est un commutateur silencieux vers une connexion SMTP non sécurisée. Lors des tests et du développement, il convient de se souvenir de ces effets des combinaisons client-serveur. Autodiscaver a différentes options pour spécifier TLS: comment il doit être, ce qui est attendu et ce qu'il faut faire. De nombreux clients de messagerie comprennent ces choses.

Brièvement: avec la prise en charge TLS dans les serveurs de messagerie et les clients de messagerie, tout va bien en général, mais dans des cas particuliers, il peut y avoir des problèmes et les extensions TLS ne sont pas très bien prises en charge.

Se connecter: FTP


On ne peut pas dire grand-chose ici. Le principal problème est SNI (c'est lorsque différents domaines sont sur la même IP). Au niveau FTP, le nom de domaine n'est pas transféré. Dans une version explicite, cela ne peut pas fonctionner, car il n'y a nulle part où l'écrire. Il existe plusieurs options de solution - certaines le proposent, d'autres donc, une solution générale n'a pas encore été adoptée, il n'y a pas de norme.

En bref: il existe une sorte de prise en charge TLS pour FTP (FTPS, SFTP - un analogue de FTP implémenté via SSH), mais certains aspects ne sont pas couverts en raison des limites techniques de FTP lui-même.

Prise de contact TLS


Donc, maintenant nous savons comment initier la communication en utilisant TLS dans différentes connexions, et Patrick a pu communiquer son désir à SpongeBob. Une fois qu'ils ont convenu d'utiliser TLS, la prise de contact TLS est produite. Son résultat devrait être un accord entre le client et le serveur sur la façon dont ils chiffrent tout cela. De plus, le client doit s'assurer que le serveur est bien celui qui est nécessaire. Parfois, le serveur vérifie également le client (mais beaucoup moins souvent).

Chiffres et versions


Comme déjà mentionné, la première étape consiste à choisir quelle version de TLS et quels chiffres seront utilisés pour le chiffrement. Typiquement, le chiffrement ressemble à ceci:



La suite de chiffrement est dans le registre IANA, et dans le protocole TLS sous forme binaire est seulement son ID. Comme vous pouvez le voir sur la figure, voici non seulement (et pas seulement) le chiffrement, mais aussi son mode de fonctionnement et d'autres détails nécessaires à la prise de contact TLS. Patrick n'a pas besoin d'entrer dans les détails. Tout ce qui est important à ce stade est de se rappeler que ces lettres sont bonnes (et les autres sont mauvaises):

  • DHE
  • ECDhe
  • AES128
  • AES256
  • RSA
  • Ecdsa
  • Cbc
  • Gcm
  • SHA256
  • SHA383
  • CHACHA20
  • POLY1308

Image pour se souvenir de bons chiffres:



s'il est difficile de s'en souvenir, il existe de bons services qui peuvent vous en parler, par exemple, un service de Mozilla ssl-config.mozilla.org .



Vous pouvez immédiatement voir où et comment il est pris en charge - c'est ce que les gars de Mozilla essaient de suivre.

Un détail intéressant: le client transfère les chiffres par ordre de priorité en fonction de leurs préférences, mais le serveur est laissé à la décision - il sélectionne le chiffre qui semble être le meilleur dans la liste des clients pris en charge.

Les deux côtés indiquent également la version maximale prise en charge du protocole - dans ce cas, Patrick est plus avancé que SpongeBob.

En fait un certificat


Avec la réponse «Faisons comme ça», le serveur envoie son ou ses certificats - il peut y en avoir beaucoup.

Qu'est-ce qu'un certificat? Il s'agit d'une relation d'information (sujet) - le plus souvent c'est le nom d'un domaine ou d'une organisation - et d'une clé publique (clé publique). Autrement dit, le certificat dit: «Mec, ma clé publique est comme ça. Maintenant, avec son aide, nous nous mettrons d'accord sur les clés de session. » De plus, avec son aide, vous pouvez vérifier la signature des certificats ou autre chose. Autrement dit, il serait possible d'utiliser non pas des certificats, mais des registres où cette relation est indiquée. Et en fait, les pas dans cette direction se poursuivent, car le mécanisme de l'autorité de certification n'est pas très bon, il n'y a tout simplement rien d'autre.

Ainsi, le certificat est la structure de «Sujet: Clé publique» plus la signature de cet ishyuer (l'émetteur en translittération en russe semble affreux, mais le synonyme le plus proche ici n'est pas très proche dans le contexte de l '«émetteur») auquel ce certificat a été délivré. Ishüyer possède également un certificat et la connexion de quelqu'un avec quelque chose. Vous pouvez vérifier l'exactitude du certificat en prenant la clé publique de l'ishyuere et en vérifiant la signature. En conséquence, rien ne peut être truqué ici.

Passons en revue le certificat et voyons quels problèmes il pourrait avoir.



Premièrement, le numéro de série n'implique l'unicité que dans les limites de l'ishyuere, bien que certains logiciels considèrent qu'il est unique dans tout l'univers. Heureusement, le plus souvent, c'est vraiment complètement unique.

Le certificat indique également quels algorithmes sont utilisés pour le chiffrement et la signature: RSA ou ECDSA, c'est-à-dire quelle cryptographie utiliser pour travailler avec cette clé publique. La principale différence entre RSA et ECDSA est que le principe mathématique de ECDSA est basé sur des courbes elliptiques, et RSA est simplement des nombres naturels, il est donc plus lent et d'énormes bits de clés sont utilisés (3-4 mille) pour éviter qu'il ne soit fissuré . Et pour ECDSA, une clé de 300 bits est suffisante et cela fonctionne plus rapidement. Par conséquent, beaucoup passent à ECDSA - la poignée de main elle-même est lourde et je veux la réduire. L'ECDSA peut être demandé lors de la délivrance d'un certificat, et si le prospecteur le soutient, il le fera pour vous. Mais la signature du certificat dépend de la clé privée dont il dispose actuellement, et non de la question de savoir si vous avez demandé ECDSA ou RSA.Par conséquent, les navigateurs peuvent montrer que l'un est dans la signature et l'autre dans la clé publique, et il n'est pas nécessaire d'avoir peur si la signature n'est pas ECDSA.

Comment obtenir un certificat?


En bref - comme ceci:

Patrick dit à l'autorité de certification: J'ai besoin d'un certificat. Cette personne (ou organisation) vérifie si c'est Patrick. Les chèques peuvent être très différents. Bien sûr, Patrick en tant que client peut ne pas avoir de certificat, mais si le serveur n'a pas de certificat, il n'y aura pas de TLS. Il est vérifié si tout est correctement indiqué dans la demande de certificat, si Patrick est réellement propriétaire du sujet pour lequel il demande un certificat. Cela se fait par des centres d'autorité de certification supérieurs - des personnes conditionnelles que tout le monde croit. Pour émettre un certificat, vous devez établir un CSR (demande de signature de certificat, demande de certificat).



C'est aussi une structure, qui est assez difficile à travailler, car il y a peu de services qui vous permettent de tout définir, spécifier, vérifier et tout voir.

Au total, nous générons une paire de clé publique: clé privée, mais nous ne donnons que le public, et masquons le privé. Ensuite, nous générons une demande de signature de certificat et la signons avec notre clé privée. Nous envoyons tout cela à l'autorité de certification et celle-ci démarre la vérification. Cela peut être différent, pour les certificats particulièrement intéressants, il existe des procédures spéciales difficiles, mais nous nous attarderons sur le cas général.

CAA RR



Il y a un tel problème que les gens que tout le monde croit ne sont parfois pas très bons. L'une des raisons pour lesquelles Symantec fait partie de DigiCert est qu'il (Symantec) a émis des certificats sans demander aux propriétaires de domaine. Vous ne pouvez pas faire cela, c'était insultant pour tout le monde, mais surtout pour Symantec lui-même, car vous deviez vendre votre entreprise. Pour rendre le serveur moins dépendant de ces camarades sans scrupules, il existe une chose comme CAA RR - un enregistrement dans DNS, où il indique à qui le propriétaire permet d'émettre des certificats pour son domaine. Cette fonctionnalité est également dans Plesk, elle est peu utilisée jusqu'à présent, à peu près comme DNSSec, mais néanmoins. Toutes les autorités de certification ont accepté de vérifier cette entrée et si elle indique que cette autorité de certification ne peut pas être délivrée, elle indiquera: "vous n'avez pas réussi la validation, c'est écrit dans le CAA RR,que je ne peux pas écrire un certificat pour vous "- et que je ne l'écrirai pas. S'il n'y a pas d'entrée, vous pouvez. Maintenant, Google pousse l'initiative afin que les clients vérifient la conformité du certificat qu'ils ont reçu avec les enregistrements RR CAA. Le débat est toujours en cours.

De plus, CAA RR à partir du moment où nous avons étendu leur prise en charge dans Plesk en indiquant les méthodes de validation (c'est-à-dire, vous pouvez également indiquer ici par quelle méthode vous validez que ce domaine est le vôtre) et l'URI du compte (Uniform Resource Identifier). Populaire auprès des utilisateurs, Plesk Let's Encrypt prend déjà en charge tout cela (bravo!).

Tout cela fonctionne pour tout type de certificat, et puisque nous parlerons des différences plus tard, il est temps de parler plus en détail des types.

Types de certificats


Il y en a trois:

Validation de domaine


Le sujet est un domaine, c'est-à-dire que nous ne le vérifions ici. Auparavant, lorsqu'il n'y avait pas de validateurs automatiques, la validation se faisait principalement par e-mail via le service Whois. Cela a été considéré comme une raison suffisante de croire que vous êtes le propriétaire de ce domaine. Puis ils ont pensé à vérifier via DNS - ils vous ont écrit par e-mail: «et ajoutez tel ou tel enregistrement au DNS». Plus tard, des méthodes automatiques sont apparues (nous parlerons un peu plus loin d'ACME).

Validation de l'organisation


Dans le champ «sujet», en plus du nom de domaine, le nom de l'organisation est également indiqué. Le contrôle consiste à valider si le domaine appartient à cette organisation et si la personne qui est venue pour le certificat y travaille. Comment cela se fait: ils recherchent des organisations sur les registres, appellent, demandent que quelque chose soit fait (le téléphone s'est avéré être correct, la bonne personne a répondu, ce qui signifie que tout va probablement bien).

Validation étendue


Identique à OV, seulement plus frais. Tout est très réglementé ici - un document de 40 pages dans l'esprit de "au paragraphe 5.6.8 devrait être le suivant: ...", etc. Beaucoup de choses sont vérifiées - le pays, le département (si indiqué dans la demande), et parfois une personne spéciale quitte même pour voir avec ses yeux. Quelle est la différence pratique? Presque tous les navigateurs ont cessé de faire la distinction entre OV et DV, ce qui est mauvais, car dans ce cas, le nom de l'organisation n'est pas affiché. En conséquence, personne ne se soucie de créer un domaine aliepxress.ru, de dessiner la même page et de voler des cartes de crédit. Et il sera absolument légitime de créer un tel domaine et d'obtenir un certificat DV dessus.

Exemple avec EV - le nom de l'organisation est visible ici, donc si quelqu'un vole quelque chose, l'utilisateur saura que c'était Valve Corp corporation, et l'enregistrement de la société est un peu plus difficile que le domaine (plus de contrôles).



Cependant, tout va au point où EV cessera d'être différent, sur les appareils mobiles, il n'est plus visible et vous devez appuyer sur un bouton séparé, et dans Safari aussi. Google Chrome tient toujours (UPD - plus maintenant! J'ai dû faire un écran à partir d'IE). L'argumentation de ceux qui ne montrent pas: «si vous êtes inquiet, cliquez et regardez», mais personne ne presse naturellement.

Obtention d'un certificat: automatisation


Parlons maintenant de la réception automatisée des certificats DV. Pour plus de clarté, voyons comment fonctionne notre système Let's Encrypt préféré. Il a généralement une bonne documentation, si quelqu'un est intéressé, et même en russe.

ACMÉ


ACME (Automatic Certificate Management Environment) est un protocole conçu pour automatiser et standardiser le processus d'obtention d'un certificat.

Comment ACME prouve-t-il que vous êtes propriétaire d'un domaine? Vous dites: Je veux un certificat et indiquez le type de validation automatique - par exemple, ACME HTTP-01. Let's Encrypt vous demande de mettre les données dans un fichier, et si vous pouviez mettre les fichiers sur votre domaine (et Let's Encrypt pourrait les récupérer à partir de là via HTTP), vous en êtes probablement le propriétaire. Maintenant, cette approche est critiquée, y compris par Google, car elle ne protège pas contre le phishing. Autrement dit, avec une validation manuelle, le domaine aliepxress.ru est susceptible de susciter des soupçons, mais Let's Encrypt lui-même ne sait pas jusqu'à présent comment (ou il peut, mais mal).

Défi DNS


En plus d'ACME, il existe également un défi DNS. Par exemple, ils vous disent: entrez un enregistrement txt dans votre zone DNS, mettez-y les données. Il existe d'autres moyens, mais pas communs, et l'un a été annulé, car il s'est révélé vulnérable. Ce que nous avons dans Plesk: les certificats génériques (qui ne peuvent être émis que par challenge DNS) ne fonctionnent pas pour beaucoup de gens, car très souvent Plesk ne gère pas les zones DNS du domaine et l'extension Let's Encrypt ne peut pas automatiser la création d'un enregistrement dans la zone DNS .

Encore deux mots sur Let's Encrypt


Un aspect important de l'utilisation des certificats Let's Encrypt est les limites. En cas de doute (ou soupçon qu'ils ont été atteints), il est préférable de suivre le lien: letsencrypt.org/docs/rate-limits

Parfois, ils sont mis à jour. Il y a des limites non évidentes que les gens oublient: le plus souvent, à en juger par les demandes de support, ils sont confrontés à une limite de 100 noms de domaine dans le certificat. Let's Encrypt a également un serveur de transfert et il y a plus de limites, mais ces certificats sont considérés comme non fiables et pour le navigateur, ils sont similaires à l'auto-signature. Dans la pratique, avec une limite de 100 noms, ils nous parviennent rarement (malgré le fait que les sites sur Plesk ont ​​un total de 1 300 000 certificats Let's Encrypt). La médiane, selon nos statistiques, est de 20 noms par certificat. Donc, si quelque chose ne fonctionne pas, regardez - peut-être que la limite est atteinte. Let's Encrypt a un bon rapport d'erreurs, et vous pouvez généralement comprendre ce qui s'est passé.

Et après?


Ainsi, une fois le certificat reçu, le serveur transmet les données de clé de session - c'est ce qui sera utilisé pour le chiffrement. Si le serveur considère qu'il est nécessaire d'authentifier le client (par exemple, l'accès n'est ouvert qu'à un certain cercle de personnes), il peut demander: le client, qui êtes-vous? Et puis le client devra envoyer son certificat. Après avoir reçu le message ServerHelloDone, le client se rend compte qu'il est temps de vérifier les certificats et de travailler avec les clés.

Tout ce dont nous avons parlé, avant que TLS 1.3 passe par un canal ouvert, et tout le monde peut voir toutes ces choses. Il existe plusieurs attaques intéressantes que vous pouvez lire sur vous-même.
Dans la deuxième série de l'article, nous apprendrons comment le client vérifie le certificat.

More articles:


All Articles