Acaba de sorgir la notícia que Apple, Cloudflare, Fastly i Mozilla han col·laborat en la millora del xifratge del mecanisme d’identificació de noms de servidor d’HTTPS a l’IETF 102 Hackathon, tal com indica un tuit de Nick Sullivan de Cloudflare. El tuit va felicitar l’equip mixt dels quatre gegants tecnològics dient “Awesome work” i compartint allà sota enllaços als servidors de treball de esni.examp1e.net i cloudflare-esni.com .
Un treball fantàstic a l’IETF 102 hackathon per part de l’equip encriptat de SNI format per gent de @Cloudflare @ ràpidament @mozilla i @poma . Ara hi ha implementacions a BoringSSL, NSS i picotls.
Els servidors de treball estan actius a https://t.co/sLI9xLRjlK i https://t.co/AoC2SIlJ7N .
- Nick Sullivan (@grittygrease) 15 de juliol de 2018
L'IETF Hackathon és una plataforma que convida els joves desenvolupadors i entusiastes de la tecnologia a unir-se a l'elaboració de solucions per a problemes relacionats amb la tecnologia que enfronta avui l'usuari comú. Els esdeveniments són gratuïts, oberts a tothom i fomenten el treball en equip en lloc de la competició. L’IETF Hackathon d’aquest any es va celebrar a Mont-real el 14thi 15thde juliol. Sembla que l’assoliment més destacat que en va sortir és el xifratge de l’indicació del nom del servidor (TLS) del servidor de seguretat de la capa de transport (TLS), un problema que ha sofert els desenvolupadors durant l’última dècada, un problema que els membres d’Apple, Cloudflare, Fastly , i Mozilla han proposat una solució a.
IETF Hackathon Event. IETF
Hi ha hagut un canvi global clar des del protocol de transferència de text hiper (HTTP) a la capa de transport Seguretat Indicació del nom del servidor Protocol de transferència de text segur (TLS SNI HTTPS) en l’última dècada i mitja. El problema el resultat de l'optimització del sistema TLS SNI HTTPS va ser la capacitat del pirata informàtic d'utilitzar SNI contra el seu propòsit de fer coincidir la transferència de dades per desxifrar-la posteriorment.
Abans del desenvolupament de SNI, era difícil establir connexions segures a diversos servidors virtuals mitjançant el mateix primer handshake de client. Quan una adreça IP va interactuar amb un servidor, els dos van intercanviar 'hellos', el servidor va enviar els seus certificats, l'ordinador va enviar la seva clau de client, els dos van intercanviar ordres 'ChangeCipherSpec' i després es va acabar la interacció a mesura que s'establia una connexió. Pot semblar fàcil de la mateixa manera que s’acaba d’expressar, però el procés va implicar múltiples intercanvis i respostes que fàcilment van aconseguir ser força problemàtics a mesura que augmentava el nombre de servidors amb els quals es comunicava. Si tots els llocs utilitzaven els mateixos certificats, no era un problema, però malauradament rarament era així. Quan diversos llocs enviaven diversos certificats d’anada i tornada, era difícil per al servidor determinar quin certificat buscava l’equip i, a la complexa xarxa d’intercanvis, es feia difícil identificar qui enviava què i quan, acabant així tota l’activitat. amb un missatge d’advertència.
TLS SNI es va introduir al juny del 2003 mitjançant una cimera de l'IETF i el propòsit que va servir, en cert sentit, era crear etiquetes de nom per als equips i serveis implicats a la xarxa d'intercanvi. Això va fer que el procés d’intercanvi hola servidor-client fos molt més senzill, ja que el servidor va poder proporcionar els certificats exactes necessaris i els dos van poder tenir el seu propi intercanvi de converses sense confondre’s sobre qui va dir què. És una mica com tenir noms de contacte per als xats i no confondre’s d’on provenen els missatges, i també poder respondre a cada consulta de manera adequada, proporcionant els documents adequats a l’ordinador que ho necessiti. Aquesta definició de SNI és exactament el que va provocar el major problema amb aquest mètode d’optimització del procés d’intercanvi.
La lluita que moltes empreses van afrontar per canviar a HTTPS va ser l'adaptació de molts certificats al format SNI amb adreces IP individuals per realitzar sol·licituds per a cada certificat. El que TLS va fer per ells va ser simplificar la generació de certificats per respondre a aquestes sol·licituds i el que va fer SNI encara més va ser eliminar la necessitat d’adreces IP de certificats dedicats individualitzats mitjançant el llançament de tot un sistema d’identificació a tota la xarxa d’Internet. El que va venir amb l'actualització del segle va ser el fet que va permetre als pirates informàtics utilitzar els 'noms de contacte' establerts per supervisar i fer ombra de la transferència de dades i extreure la informació que necessiten per desxifrar en una etapa posterior.
Tot i que TLS permetia que les dades s’enviessin d’anada i tornada en un canal xifrat, amb SNI assegurant que arriba a la destinació correcta, aquest últim també proporcionava mitjans perquè els pirates informàtics poguessin controlar l’activitat en línia i fer-la coincidir amb la seva font seguint les sol·licituds DNS, adreces IP i fluxos de dades. Tot i que també s’han implementat polítiques de codificació SNI més estrictes passant informació de DNS a través del canal TLS, queda una petita finestra perquè els pirates informàtics puguin utilitzar-la com a mitjà d’identificació per seguir la informació que els agradaria extreure i aïllar-la. desxifrat. Els servidors complexos que gestionen un major trànsit de dades xifrades TLS utilitzen SNI de text pla per enviar la comunicació als seus servidors i això és el que facilita als pirates informàtics identificar els canals i els fluxos d’informació que volen seguir. Un cop un pirata informàtic pugui extreure la informació SNI de les dades d'interès, pot configurar una reproducció falsa de l'ordre en una connexió TLS independent amb el servidor, enviant la informació SNI robada i recuperant la informació que s’hi va associar. Hi ha hagut diversos intents de resoldre aquest problema SNI en el passat, però la majoria han anat en contra del principi de senzillesa que opera SNI per convertir-lo en un mètode d’identificació convenient per als servidors.
De tornada a la cimera que va treballar per establir aquest mètode, els participants de quatre gegants tecnològics han tornat a la conferència de Mont-real per desenvolupar un xifratge per al TLS SNI, ja que, malgrat l’eficiència més gran del sistema adjacent HTTPS, la seguretat continua sent una preocupació tant com abans.
Per ocultar l'SNI a TLS, s'ha de mantenir un 'Servei Ocult' sota la mostra d'un 'Servei de Fronting' que pugui veure el pirata informàtic. Sense poder observar directament el servei ocult, el pirata informàtic es desviarà amb la disfressa frontal que amaga en text pla sense poder identificar els paràmetres subjacents del servei secret que s’utilitzen per retransmetre les dades xifrades. A mesura que l'observador segueix el rastre del servei de fronting, les dades s'eliminaran del canal observat a mesura que es redirigeixin al seu servei ocult previst, moment en què l'hacker haurà perdut el rastre. Atès que el servidor també estarà exposat al servei de fronting, a mesura que les dades s’obrin cap allà, s’enviarà un segon senyal SNI paral·lel al servei de fronting per redirigir les dades cap al servei ocult i en aquest procés de canvi de direcció, el pirata informàtic es perdrà a la web del servidor. Aquest mecanisme de bitllets dobles es desenvolupa en un bitllet combinat sota el mateix SNI. A mesura que s’envia una peça de dades al servidor, les dades produeixen un re-director cooperant de l’SNI i els dos treballen conjuntament per aconseguir que les dades xifrades TLS arribin a on ha d’anar. Sense poder trencar el servei de fronting aleatori que cobreix les dues pistes SNI, l’hacker no podrà seguir el rastre de les dades, però el servidor encara podrà connectar-les i desxifrar el servei ocult com a ubicació definitiva de les dades. Això permet que els servidors continuïn utilitzant SNI per optimitzar la seva transferència de dades en xifratge TLS, tot garantint que els pirates informàtics no puguin aprofitar el mecanisme SNI.
