Vers un In­ter­net plus sûr avec TLS 1.3

L’IETF a en­fin don­né le feu vert au pro­to­cole TLS 1.3, amé­lio­rant ain­si la sé­cu­ri­té et la ra­pi­di­té de connexion. Tout en ren­dant la sur­veillance plus dif­fi­cile pour les at­ta­quants.

L'Informaticien - - SOMMAIRE - THIER­RY THAUREAUX

Le pro­to­cole TLS 1.3 ap­prou­vé par l’IETF

L’In­ter­net En­gi­nee­ring Task Force ( IETF), l’or­ga­nisme d’éla­bo­ra­tion des stan­dards d’In­ter­net, vient d’ap­prou­ver la norme de sé­cu­ri­té TLS 1.3. Un chan­ge­ment de ver­sion, même mi­neur, est ra­re­ment ano­din lors­qu’il concerne un pro­to­cole de sé­cu­ri­té. Bien que beau­coup l’ap­pellent en­core SSL, le pro­to­cole du HTTPS est de­puis quelques temps dé­jà TLS. Comme son pré­dé­ces­seur SSL ( Se­cure So­ckets Layer), TLS ( Trans­port Layer Se­cu­ri­ty) est un pro­to­cole de sé­cu­ri­sa­tion des échanges sur In­ter­net. Il fonc­tionne sui­vant le mo­dèle client- ser­veur et per­met de sa­tis­faire à di­vers ob­jec­tifs de sé­cu­ri­té, dont l’au­then­ti­fi­ca­tion du ser­veur, la confi­den­tia­li­té des don­nées échan­gées via le cryp­tage de ses­sion, l’in­té­gri­té de ces don­nées et, op­tion­nel­le­ment, l’au­then­ti­fi­ca­tion du client – même si dans la réa­li­té celle- ci est sou­vent as­su­rée par le ser­veur. Des pro­to­coles de sé­cu­ri­sa­tion des échanges sont très lar­ge­ment uti­li­sés sur In­ter­net, leur mise en oeuvre étant fa­ci­li­tée par le fait que les pro­to­coles de la couche Ap­pli­ca­tion ( comme le HTTP) n’ont pas à être pro­fon­dé­ment mo­di­fiés pour uti­li­ser une connexion sécurisée. Néan­moins, ils ne sont im­plé­men­tés qu’au- des­sus des pre­miers ( SSL ou TLS). Le pro­to­cole HTTP sé­cu­ri­sé ( HTTPS) est par exemple une simple com­bi­nai­son du HTTP avec une couche de chif­fre­ment comme le SSL ou le TLS, mais le SSL ( v2 ou v3) est mis à l’in­dex de­puis 2014 à cause de nom­breuses failles de sé­cu­ri­té qui ont mon­tré ses fai­blesses. Le TLS est un élé­ment fon­da­men­tal de la sé­cu­ri­sa­tion des connexions in­ter­net via HTTPS.

Des chan­ge­ments en pro­fon­deur

L’un des prin­ci­paux chan­ge­ments opé­rés par TLS 1.3 est l’aban­don des al­go­rithmes de chif­fre­ment et de ha­chage ob­so­lètes, tels que MD5 et SHA- 224, pour des al­ter­na­tives plus sé­cu­ri­sées comme ChaC­ha20, Po­ly1305, Ed25519, x448 et x25519. TLS 1.3 sup­prime ain­si toutes les pri­mi­tives et les fonc­tion­na­li­tés qui ont contri­bué à une confi­gu­ra­tion faible et per­mis les vul­né­ra­bi­li­tés cou­rantes telles que Crime, Drown, Lu­cky 13, Poo­dle, Sloth, Vau­de­nay et bien d’autres. Des fonc­tion­na­li­tés sup­plé­men­taires ont, d’un autre cô­té, été ajou­tées pour amé­lio­rer la sé­cu­ri­té et la ro­bus­tesse du pro­to­cole. Cette ver­sion offre en ef­fet une pro­tec­tion contre les at­taques de type « down­grade » par les­quelles un at­ta­quant in­cite un ser­veur à

uti­li­ser une an­cienne ver­sion du pro­to­cole ayant des vul­né­ra­bi­li­tés connues. Par­mi les principale­s nou­veau­tés, on peut en­core ci­ter des fonc­tion­na­li­tés telles que TLS False Start et Ze­ro Round Trip Time ( 0- RTT) qui sont cen­sées ré­duire le temps de connexion à des hôtes avec les­quels le client a dé­jà com­mu­ni­qué. Elles per­mettent donc d’avoir une ex­pé­rience web plus ra­pide et plus fluide pour les sites web que vous vi­si­tez ré­gu­liè­re­ment. Les amé­lio­ra­tions en termes de sé­cu­ri­té et de ra­pi­di­té de connexion ap­por­tées par TLS 1.3 pour­raient se ré­su­mer à l’éli­mi­na­tion des étapes de prise de contact in­utiles et à l’uti­li­sa­tion for­cée de nou­velles mé­thodes de chif­fre­ment plus so­lides. La ver­sion ap­prou­vée est en fait la 28e du nom ( draft 28) pro­po­sée à l’is­sue de quatre ans de dis­cus­sion entre les membres de l’IETF. Cette nou­velle ver­sion est des­ti­née à de­ve­nir le mo­dèle stan­dard en ma­tière de sé­cu­ri­sa­tion des connexions in­ter­net, of­frant de plus l’avan­tage de les ac­cé­lé­rer du fait de la sim­pli­fi­ca­tion des né­go­cia­tions. Le HTTPS est ap­pa­ru en 1995 dans Nets­cape Na­vi­ga­tor, ré­pon­dant à un be­soin cru­cial à l’époque au vu no­tam­ment de l’es­sor du com­merce en ligne, alors nais­sant. Le HTTPS uti­li­sait ini­tia­le­ment le pro­to­cole SSL qui s’in­ter­cale entre les pro­to­coles TCP et HTTP afin de les sé­cu­ri­ser. Le SSL a bien évo­lué de­puis, al­lant jus­qu’à chan­ger de nom pour de­ve­nir TLS. Le SSL se dé­cline donc en six ver­sions : SSLv2, SSLv3, TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3. Cette nou­velle ver­sion ar­rive dix ans après TLS 1.2 et cinq ans après les ré­vé­la­tions d’Ed­ward Snow­den.

Ac­cé­lé­ra­tion et sé­cu­ri­sa­tion des connexions

TLS 1.3 amé­liore la vi­tesse de com­mu­ni­ca­tion en ac­cé­lé­rant la né­go­cia­tion grâce à la ré­duc­tion des al­ler- re­tour entre le client et le ser­veur. Il ren­force la sé­cu­ri­té en désac­ti­vant les vieux pro­to­coles et en in­cluant de nou­veaux al­go­rithmes. Les amé­lio­ra­tions en termes de sé­cu­ri­té et de ra­pi­di­té de connexion ap­por­tées par TLS 1.3 sont in­ter­dé­pen­dantes : plus sûr car plus ra­pide et plus ra­pide car plus sé­cu­ri­sé. Pour mieux com­prendre le fonc­tion­ne­ment de cette re­la­tion bi­di­rec­tion­nelle, il faut d’abord rap­pe­ler le fonc­tion­ne­ment d’une connexion TLS 1.2. La connexion ini­tiale en TLS 1.2 passe par un dia­logue entre un ser­veur et un client sur le type de cryp­tage à uti­li­ser conjoin­te­ment. Une fois qu’ils se sont mis d’ac­cord, ils com­mencent à par­ta­ger les clés de chif­fre­ment. TLS 1.3 éli­mine cette dis­cus­sion sur le type de cryp­tage à uti­li­ser. La connexion ini­tiale est une simple dé­cla­ra­tion du client spé­ci­fiant ce à quoi il veut ac­cé­der. Le ser­veur four­nit une clé de chif­fre­ment et le client une clé de ses­sion, et c’est tout ; la com­mu­ni­ca­tion peut dé­mar­rer. Le ser­veur four­nis­sant au­to­ma­ti­que­ment une clé, les clients ne sont pas en me­sure de le trom­per en le for­çant à uti­li­ser des al­go­rithmes de cryp­tage ob­so­lètes. Cette pratique est connue sous le nom d’at­taque de ré­tro­gra­da­tion. TLS 1.3 force donc l’uti­li­sa­tion d’un nou­veau cryp­tage et l’éli­mi­na­tion, en sus, des al­ler- re­tour de de­mandes de né­go­cia­tions ini­tiales in­utiles ( voir fi­gures). Les na­vi­ga­teurs sont do­tés de TLS 1.2 de­puis plu­sieurs an­nées. Ce­pen­dant, le parc mon­dial n’est mal­heu­reu­se­ment pas consti­tué que de na­vi­ga­teurs ré­cents. Du coup, TLS 1.0 reste très sou­vent ac­ti­vé sur nombre de ser­veurs. Mal­gré leur fai­blesse – et donc leur dan­ge­ro­si­té –, SSLv2 et v3 ont en­core des « adeptes » im­pru­dents et le re­trait de TLS 1.0 conti­nue la­bo­rieu­se­ment après l’es­sor tar­dif, mais ra­pide, de TLS 1.1 et 1.2 alors que TLS 1.3 dé­barque. Les sites les plus à la pointe ac­ceptent TLS 1.2 et 1.1 mais re­fusent d’ores et dé­jà TLS 1.0. La plu­part des ser­veurs ac­ceptent in­dif­fé­rem­ment TLS 1.0 à 1.3 et seuls les sites ( très) à la traîne traitent même des connexions SSLv3, à leurs ( grands) risques et pé­rils. Ce dé­cou­page en trois groupes

de confi­gu­ra­tion cor­res­pond gros­so mo­do à ce que pro­pose Mo­zilla sur Se­cu­ri­ty/ Ser­ver Side TLS : mo­derne, in­ter­mé­diaire et « vieillot » , ou, si vous pré­fé­rez la clas­si­fi­ca­tion de l’ANSSI, R3, R3− et R3−−. Il pa­raît évident que tous les ser­veurs ne peuvent pos­sé­der la même confi­gu­ra­tion SSL/ TLS. Les sites orien­tés B2B ont cer­tai­ne­ment plus de chances d’être consul­tés via des vieux na­vi­ga­teurs et peuvent to­lé­rer TLS 1.0. En re­vanche, un site pour le­quel la confi­den­tia­li­té et la sé­cu­ri­té sont pri­mor­diales ou uti­lisent des fonc­tion­na­li­tés CSS ou Flex­box ré­centes re­fu­se­ra, au contraire, TLS 1.0 voire 1.1. Aux na­vi­ga­teurs clients de s’y adap­ter, si­non tant pis. La re­fonte d’un site est la par­faite oc­ca­sion pour re­voir une confi­gu­ra­tion TLS. Si un site est pré­vu pour au mi­ni­mum IE 11, par exemple, et offre un af­fi­chage très dé­gra­dé avec d’an­ciennes ver­sions, la confi­gu­ra­tion de TLS of­fri­ra une so­lu­tion simple et ra­di­cale. Il faut juste bien ré­flé­chir aux consé­quences : vou­lez- vous ou non préserver l’ac­cès via de vieux na­vi­ga­teurs et les risques in­hé­rents en ma­tière de sé­cu­ri­té son­tils to­lé­rables dans votre contexte par­ti­cu­lier ?

Né­go­cia­tion entre client et ser­veur

Client et ser­veur web doivent né­go­cier cer­tains élé­ments lors de l’éta­blis­se­ment d’une liai­son sécurisée TLS. Ils doivent s’as­su­rer qu’ils dis­posent d’al­go­rithmes en com­mun en vue de si­gner, d’échan­ger des clés et de chif­frer. La ver­sion du pro­to­cole SSL/ TLS à uti­li­ser est le tout pre­mier point sur le­quel ils doivent né­ces­sai­re­ment s’ac­cor­der, car le reste de l’éta­blis­se­ment de la liai­son sécurisée – le hand­shake ou poi­gnée de mains – va­rie se­lon la ver­sion. Ce sont prin­ci­pa­le­ment des ini­tia­li­sa­tions, des trans­mis­sions d’aléas et des cal­culs de sommes de contrôle ( check­sums) qui dif­fèrent. Avec TLS 1.3, un al­ler- re­tour est sup­pri­mé lors de l’éta­blis­se­ment de la connexion. Des an­ti­ci­pa­tions ont été réa­li­sées afin de ré­duire les échanges au mi­ni­mum. Le client conserve la main après le « Fi­ni­shed » . Il peut donc trans­mettre une re­quête HTTP GET dans la fou­lée, ré­dui­sant ain­si l’échange com­plet à un seul al­ler- re­tour ( 1 RTT). De ce­ci dé­coule un gain consé­quent lorsque la la­tence est im­por­tante, lorsque le client passe par un ré­seau de com­mu­ni­ca­tion mo­bile ou lorsque le client et le ser­veur sont très éloi­gnés, par exemple. Le mé­ca­nisme de re­prise de ses­sion a lui aus­si été com­plè­te­ment re­ma­nié et ren­du plus ra­pide. TLS 1.3 a la par­ti­cu­la­ri­té d’être la pre­mière ver­sion à lar­ge­ment s’af­fran­chir des re­com­man­da­tions du NIST ( Na­tio­nal Ins­ti­tute of Stan­dards and Tech­no­lo­gy) et, de ce fait, d’une éven­tuelle in­fluence de la NSA qui fait tout pour af­fai­blir les sys­tèmes cryp­to­gra­phiques – en­core mer­ci « Ed­ward » . Ce­la s’est tra­duit par l’adop­tion d’al­go­rithmes dé­ri­vés des tra­vaux d’un cer­tain Da­niel J. Bern­stein : ChaC­ha20, EdDSA, x25519 et quelques autres. Bien qu’il soit tou­jours pos­sible d’uti­li­ser des al­go­rithmes de cryp­to­gra­phie à base de courbes el­lip­tiques de type NIST, ECDSA et AES avec TLS 1.3, il existe dé­sor­mais une al­ter­na­tive

pour cha­cun d’eux. Un grand coup de ba­lai a été don­né dans les vieilles suites cryp­to­gra­phiques. Le mé­ca­nisme d’échange de clé le plus sim­pliste ne peut plus être uti­li­sé – ce­lui chif­frant le se­cret par­ta­gé avec la clé RSA pu­blique du ser­veur qui n’of­frait pas de confi­den­tia­li­té per­sis­tante. Le mode CBC et les vieux al­go­rithmes de chif­fre­ment tels que Triple DES dis­pa­raissent eux aus­si. C’est cette éli­mi­na­tion de tous les élé­ments les moins ro­bustes qui rend TLS 1.3 sûr et qui, de plus, sim­pli­fie gran­de­ment sa confi­gu­ra­tion. Le seul point sen­sible est la pos­si­bi­li­té de faire du 0- RTT. En ef­fet, TLS 1.3 uti­lise la re­prise 0- RTT per­met­tant à deux ma­chines ayant pré­cé­dem­ment éta­bli une né­go­cia­tion TLS 1.3 de sto­cker des in­for­ma­tions de connexion sur l’autre par­ti­ci­pant et d’uti­li­ser d’an­ciennes clés pour les connexions fu­tures. Un at­ta­quant ac­cé­dant à des in­for­ma­tions de re­prise 0- RTT peut usur­per une connexion. Néan­moins, ce­la im­plique l’ac­cès phy­sique à une ma­chine, ce qui heu­reu­se­ment com­plique for­te­ment l’ex­ploi­ta­tion de cette faille. Sé­lec­tion­née par défaut, cette fonc­tion­na­li­té peut être désac­ti­vée par l’ad­mi­nis­tra­teur.

La fin de l’im­pru­dence ?

Ce n’est pas to­ta­le­ment par ha­sard – ni par né­gli­gence – qu’il existe en­core un aus­si grand nombre de ser­veurs confi­gu­rés avec une ré­tro­com­pa­ti­bi­li­té bien trop gé­né­reuse uti­li­sant des suites cryp­to­gra­phiques plus que dé­pas­sées. Plu­sieurs rai­sons peuvent en être la cause. D’abord, la confi­gu­ra­tion SSL/ TLS n’a pas tou­jours été clai­re­ment do­cu­men­tée. De fait, une fois la connexion confi­gu­rée, les ad­mi­nis­tra­teurs sont ten­tés de ne plus y tou­cher. Et ce­la peut du­rer plu­sieurs an­nées. Cet état de fait était ag­gra­vé par l’exis­tence de cer­ti­fi­cats va­lables quatre ou même cinq ans. Il existe pour­tant des ou­tils forts pra­tiques tels que

SSL Ser­ver Test ( https:// www. ssl­labs. com/ ssl­test/) de SSL Labs, ou le re­dou­table CryptC­heck d’Ae­ris ( https:// tls. imi­rhil. fr) per­met­tant de tes­ter ces confi­gu­ra­tions et de pro­po­ser des amé­lio­ra­tions, ou en­core le gé­né­ra­teur de confi­gu­ra­tion de Mo­zilla pour sim­pli­fier la confi­gu­ra­tion d’un site. Ceux- ci sont mal­heu­reu­se­ment en­core trop sou­vent mé­con­nus. La meilleure règle à suivre est sans doute de n’uti­li­ser que deux ou trois confi­gu­ra­tions TLS types, la « mo­derne » et « l’in­ter­mé­diaire » de Mo­zilla ( R3 et R3- se­lon l’Anssi), par exemple. Le lan­ce­ment de TLS 1.3 se fait dans un contexte très dif­fé­rent de ce­lui de la ver­sion pré­cé­dente TLS 1.2. TLS 1.3 a pour vo­ca­tion af­fi­chée d’ac­com­pa­gner le pas­sage au « tout HTTPS » afin de lut­ter contre le pi­ra­tage et la col­lecte mas­sive d’in­for­ma­tions sur le Net. Cette ver­sion est plé­bis­ci­tée par les ac­teurs de pre­mier plan des ré­seaux : édi­teurs de na­vi­ga­teurs, opé­ra­teurs de CDN — Content De­li­ve­ry Net­work— et consorts qui ont par­ti­ci­pé en pro­dui­sant le code né­ces­saire pour tes­ter les ver­sions pré­li­mi­naires. In­utile donc de se faire du souci quant à une adop­tion ra­pide de TLS 1.3. Ce­la n’em­pêche qu’il fau­dra de longues an­nées avant que TLS 1.3 soit la ver­sion la plus ré­pan­due sur l’en­semble des ser­veurs web. L’un des freins les plus im­por­tants est la dif­fu­sion en­core trop dis­crète d’OpenSSL 1.1.1 dis­po­nible seule­ment de­puis le dé­but 2017. Il est ce­pen­dant pos­sible et même conseillé de s’ins­pi­rer de TLS 1.3 pour mieux confi­gu­rer TLS 1.2, c’est- à- dire de désac­ti­ver les ré­ponses aux connexions uti­li­sant des suites cryp­to­gra­phiques telles que SSLv3 ou TLS 1.0 et al­ler en plus vers des types de cryp­to­gra­phie ba­sés sur les courbes el­lip­tiques, cer­ti­fi­cats y com­pris. ❍

Le SSL Ser­ver Test ( https:// www. ssl­labs. com/ ssl­test/) de SSL Labs per­met de tes­ter la confi­gu­ra­tion SSL/ TCL d’un ser­veur web et de pro­po­ser des amé­lio­ra­tions.

Le gé­né­ra­teur de confi­gu­ra­tion de Mo­zilla ( https:// mo­zilla. gi­thub. io/ ser­ver- side- tls/ ssl- config­ge­ne­ra­tor/) est très pratique pour gé­né­rer ra­pi­de­ment un fi­chier de confi­gu­ra­tion TLS.

Pour vé­ri­fier si TLS 1.3 est ac­ti­vé dans Fi­re­fox et éven­tuel­le­ment l’ac­ti­ver si ce n’est pas le cas, ta­pez about: config dans la barre d’adresses.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.