EL NUE­VO ROS­TRO DEL CER­TI­FI­CA­DO SSL

Co­mo Ar­ya en Ga­me of Th­ro­nes, el SSL se ha rein­ven­ta­do con gran in­ge­nio, as­tu­cia y la ca­pa­ci­dad pa­ra pro­te­ger a los usua­rios de vul­ne­ra­bi­li­da­des con su nue­vo al­go­rit­mo crip­to­grá­fi­co de cur­va elíp­ti­ca (ECC) 10 000 ve­ces más di­fí­cil de des­ci­frar.

IT Now Guatemala - - EDITORIAL - Fa­bián Cal­de­rón

Co­mo Ar­ya en Ga­me of Th­ro­nes, el SSL se ha rein­ven­ta­do con gran in­ge­nio, as­tu­cia y la ca­pa­ci­dad pa­ra pro­te­ger a los usua­rios de vul­ne­ra­bi­li­da­des con su nue­vo al­go­rit­mo crip­to­grá­fi­co de cur­va elíp­ti­ca (ECC) 10 000

Ar­ya Stark que­ría con­ver­tir­se en “na­die” por lo que se unió al “Dios de los mil ros­tros” don­de cam­bia­ría de ca­ra pa­ra po­der ven­gar­se de quié­nes es­ta­ban en su lis­ta, una si­tua­ción si­mi­lar pa­só con los cer­ti­fi­ca­dos SSL que cam­bió su ros­tro, pe­ro en lu­gar de ven­gar­se lo hi­zo pa­ra brin­dar ma­yor pro­tec­ción a los ci­ber­nau­tas.

Más sa­bien­do que el trá­fi­co SSL (Se­cu­re Soc­ket La­yer por sus si­glas en in­glés) re­pre­sen­ta en la ac­tua­li­dad en­tre un 30% y un 40% de las co­mu­ni­ca­cio­nes que co­rren por In­ter­net, lle­gan­do a al­can­zar el 70% en al­gu­nas re­des. Su cre­ci­mien­to es in­clu­so, más rá­pi­do que el trá­fi­co glo­bal IP, ya que son ca­da vez más los si­tios que em­plean cla­ves SSL de 4096 bits y uni­da­des de ci­fra­do Dif­fie-hell­man, que ha­cen uso in­ten­si­vo de los re­cur­sos de compu­tación.

Jai­ro Pantoja, ex­per­to en cer­ti­fi­ca­dos SSL de Sy­man­tec, ex­pli­có que con es­ta nue­va ca­ra exis­ten los Cer­ti­fi­ca­dos SSL EV (Ex­ten­ded Va­li­da­tion EV) en los que se au­men­tan la ta­sa de con­ver­sión y re­du­cen la ta­sa de aban­dono en los si­tios web y mues­tra una ba­rra ver­de en el si­tio del clien­te jun­to con un can­da­do (cer­ti­fi­ca­do di­gi­tal), el cual pro­vee se­gu­ri­dad al usua­rio que es­tá in­gre­san­do a un si­tio web se­gu­ro.

Lo bueno de es­ta ca­ra es que cons­ta con un nue­vo al­go­rit­mo de crip­to­gra­fía de cur­va elíp­ti­ca (ECC) 10 000 ve­ces más di­fí­cil de des­ci­frar que las cla­ves RSA, es­to sig­ni­fi­ca que una cla­ve ECC de 256 bits ofre­ce el mis­mo ni­vel de se­gu­ri­dad que una cla­ve RSA de 3 072 bits.

Su sis­te­ma es en­tre 7% y un 10 % más rá­pi­do y ne­ce­si­ta me­nos po­ten­cia de pro­ce­sa­mien­to.

“Por ejem­plo, un clien­te nues­tro lo­gró re­du­cir los tiem­pos de res­pues­ta en un 7% y al mis­mo tiem­po, uti­li­zar un 46 % me­nos de re­cur­sos de CPU, lo que po­si­bi­li­tó un ma­yor nú­me­ro de co­ne­xio­nes si­mul­tá­neas a su si­tio web”, ar­gu­men­tó Pantoja.

Tra­di­cio­nal­men­te el cer­ti­fi­ca­do SSL es co­no­ci­do pa­ra brin­dar se­gu­ri­dad al vi­si­tan­te web por me­dio de ci­fra­dos con al­go­rit­mos ma­te­má­ti­cos y un sis­te­ma de cla­ves que só­lo son iden­ti­fi­ca­dos en­tre la per­so­na que na­ve­ga y el ser­vi­dor. Al te­ner un cer­ti­fi­ca­do SSL con­fia­ble, la in­for­ma­ción que se ten­ga en el si­tio web es­ta­rá en­crip­ta­da, en ese mo­men­to po­de­mos ase­gu­rar que na­die pue­de leer su con­te­ni­do.

Un cer­ti­fi­ca­do SSL re­gu­lar im­ple­men­ta el mo­de­lo pre­fe­ri­do de se­gu­ri­dad en la web don­de ma­ne­ja cla­ves di­gi­ta­les que pro­te­gen la in­te­gri­dad de sus da­tos al mo­men­to de en­viar y re­ci­bir. Los

El ob­je­ti­vo del SSL es que la co­mu­ni­ca­ción en­tre el usua­rio fi­nal y el si­tio web es­te ci­fra­da de pun­to a pun­to. Pe­ro, el trá­fi­co ci­fra­do aho­ra con­lle­va ame­na­zas.

ser­vi­do­res que co­rren SSL crean una vía con un ci­fra­do úni­co pa­ra las se­sio­nes pri­va­das a tra­vés que In­ter­net, la cla­ve pú­bli­ca del ser­vi­dor es­tá al al­can­ce de cual­quier per­so­na, es por eso que uti­li­zan una cla­ve pú­bli­ca y una cla­ve pri­va­da: la pú­bli­ca es pa­ra ci­frar la in­for­ma­ción, la cla­ve pri­va­da pa­ra des­ci­frar­la.

Por ello, hay de­ta­lle al cual de­ben es­tar aten­tos los que uti­li­zan es­te cer­ti­fi­ca­do, ya que a par­tir del 1 de oc­tu­bre de 2016, se­gún Sy­man­tec, de­ja­rán de emi­tir­se los cer­ti­fi­ca­dos SSL pú­bli­cos pa­ra las di­rec­cio­nes IP re­ser­va­das y nom­bres de ser­vi­do­res in­ter­nos.

Por eso se re­co­mien­da crear una je­rar­quía de SSL pri­va­da pa­ra los ser­vi­do­res in­ter­nos, re­du­cir los ries­gos, erro­res y cos­tos aso­cia­dos a las au­to­ri­da­des de au­ten­ti­ca­ción au­to­fir­ma­das.

La nue­va ca­ra ya es­tá, ¿có­mo la eje­cu­to?

Alain Ka­rioty, vi­ce­pre­si­den­te de ven­tas de A10 Net­works pa­ra La­ti­noa­mé­ri­ca, co­men­tó que no so­lo hay que em­plear­lo sino tam­bién cui­dar­lo.

“Des­de siem­pre se ha con­si­de­ra­do que el tra­fi­co SSL o TLS, sig­ni­fi­ca­ba trá­fi­co se­gu­ro. Sin em­bar­go, con el au­men­to del trá­fi­co ci­fra­do en las re­des, las de­fen­sas de se­gu­ri­dad tra­di­cio­na­les co­mo fi­re­walls, IPS, DLP, an­ti­vi­rus, an­ti­malwa­re, pro­tec­ción con­tra ame­na­zas per­sis­ten­tes avan­za­das, se han vuel­to in­efi­cien­tes”, ex­pre­só Ka­rioty.

El he­cho que pue­dan pa­re­cer in­su­fi­cien­tes, va por­que no tie­nen la ca­pa­ci­dad de des­ci­frar es­te trá­fi­co, por lo tan­to, es­te cir­cu­la sin po­der es­tar ana­li­za­do. Los ata­can­tes se han da­do cuen­ta de ello y aho­ra, rea­li­zan sus ata­ques en trá­fi­co ci­fra­do.

La com­pa­ñía de so­lu­cio­nes SSL, Di­gicert re­co­mien­da se­guir es­tos pa­sos:

1-Co­piar los ar­chi­vos de cer­ti­fi­ca­do pa­ra su ser­vi­dor: Des­car­gue su in­ter­me­dio y su cer­ti­fi­ca­do, los ar­chi­vos del clien­te, y lue­go co­pie­los en el di­rec­to­rio de su ser­vi­dor en el que se man­ten­drá el cer­ti­fi­ca­do y la cla­ve de los ar­chi­vos. So­lo de­be ha­cer­los le­gi­bles en el root.

2-Bus­que el ar­chi­vo de con­fi­gu­ra­ción pa­ra edi­tar: En es­te ca­so pue­dee uti­li­zar Apa­che, cpa­nel, Ex­chan­ge o Mi­cro­soft In­ter­net In­for­ma­tion Ser­vi­ces (IIS). La ubi­ca­ción y el nom­bre de es­te ar­chi­vo pue­de va­riar de un ser­vi­dor a otro, es­pe­cial­men­te si us­ted uti­li­za una in­ter­faz es­pe­cial pa­ra ad­mi­nis­trar la con­fi­gu­ra­ción del ser­vi­dor.

3- Iden­ti­fi­car el blo­que de <Vir­tua­lhost>: una vez que lo ha­ya he­cho po­drá ver en qué si­tio de la web desea ac­ti­vi­dad SSL. Si ne­ce­si­ta que su si­tio sea ac­ce­si­ble tan­to a tra­vés de co­ne­xión se­gu­ra (https) y no se­gu­ros (HTTP), se ne­ce­si­ta un ser­vi­dor vir­tual pa­ra ca­da ti­po de co­ne­xión. Si só­lo ne­ce­si­ta su si­tio web pa­ra ac­ce­der de for­ma se­gu­ra, configurar el host vir­tual exis­ten­te pa­ra SSL co­mo se des­cri­be en el pa­so 4.

4-Configurar el blo­que <Vir­tua­lhost> pa­ra el si­tio con SSL: Es­te es un ejem­plo de la con­fi­gu­ra­ción de un host vir­tual pa­ra SSL. Las par­tes en ne­gri­ta son las par­tes que hay que aña­dir pa­ra la con­fi­gu­ra­ción de SSL:

5- Pon­ga a prue­ba su con­fi­gu­ra­ción an­tes de re­ini­ciar: Siem­pre es me­jor pa­ra ver los erro­res en sus ar­chi­vos de con­fi­gu­ra­ción erro­res an­tes de

re­ini­ciar.

Al rea­li­zar es­tos pa­sos, sa­be­mos que pue­de exis­tir una in­te­gra­ción con los si­tios web. Pa­ra ello se de­be sa­ber que el ob­je­ti­vo de SSL es ha­cer que la co­mu­ni­ca­ción en­tre el usua­rio fi­nal y el si­tio web es­te ci­fra­da de pun­to a pun­to. Pe­ro, el trá­fi­co ci­fra­do aho­ra con­lle­va ame­na­zas.

Por eso cuan­do es­ta­mos co­nec­ta­dos a una red wifi pú­bli­ca, el trá­fi­co no tie­ne el ni­vel de con­fi­den­cia­li­dad que pen­sa­mos. Así las co­sas, un ata­can­te po­dría es­tar vi­gi­lan­do red wifi no se­gu­ra y ob­te­nien­do to­da la in­for­ma­ción del usua­rio.

Los nue­vos enemi­gos…

Co­mo Ar­ya Stark, quien tam­bién te­nía co­mo enemi­go a “La ni­ña aban­do­na­da” y es­te le cau­só da­ño, el SSL tie­ne unos cuan­tos enemi­gos con los cua­les de­be lu­char.

El ci­fra­do es una so­lu­ción ade­cua­da pa­ra ata­car di­ver­sos ti­pos de vul­ne­ra­bi­li­da­des, tan­to téc­ni­cas co­mo la ma­la con­fi­gu­ra­ción de me­di­das y con­tro­les de se­gu­ri­dad a ni­vel pe­ri­me­tral, ade­más de las vul­ne­ra­bi­li­da­des de los usua­rios fi­na­les al ma­ni­pu­lar in­for­ma­ción con­fi­den­cial de for­ma erró­nea, así co­mo en­viar un co­rreo con in­for­ma­ción con­fi­den­cial a un bu­zón per­so­nal. El ci­fra­do, pro­te­ge tan­to la con­fi­den­cia­li­dad co­mo la in­te­gri­dad de la in­for­ma­ción.

Se­gún Ka­rioty de A10 Net­works, des­de que se em­pie­zan a ver ata­ques en trá­fi­co ci­fra­do, los ci­ber­de­lin­cuen­tes ya no se mo­les­tan en bus­car vul­ne­ra­bi­li­da­des de Día Ce­ro.

“Al pa­sar por tú­ne­les ci­fra­dos sin ser ana­li­za­dos por las me­di­das de se­gu­ri­dad, in­fec­tar un usua­rio o to­mar el con­trol de un sis­te­ma de for­ma re­mo­ta se ha con­ver­ti­do en una ta­rea muy sen­ci­lla, in­clu­so con ata­ques co­no­ci­dos”, ma­ni­fes­tó el ex­per­to.

Uno de los ata­ques más fre­cuen­tes es el spear phis­hing con su téc­ni­ca de lle­gar al co­rreo elec­tró­ni­co, apa­ren­te­men­te de una fuen­te de con­fian­za, pe­ro en vez de eso, lle­va al inad­ver­ti­do des­ti­na­ta­rio a un si­tio web fal­so lleno de malwa­re. Y cla­ro, la co­ne­xión a es­te si­tio se ha­ce me­dian­te HTTPS (tra­fi­co ci­fra­do) y se es­tá con­vir­tien­do en la prin­ci­pal ame­na­za con la que ac­tual­men­te vi­ve el SSL.

Pa­ra pro­te­ger los da­tos mu­chas or­ga­ni­za­cio­nes han ini­cia­do su tran­si­ción a Perfect For­ward Se­crecy (PFS) prin­ci­pal­men­te por dos ra­zo­nes, la pri­me­ra que ase­gu­ra si una cla­ve SSL es com­pro­me­ti­da, los cri­mi­na­les no po­drían des­ci­frar los da­tos.

Ca­da se­sión SSL es ci­fra­da con una cla­ve úni­ca, por lo que los asal­tan­tes ten­drían que cra­quear ca­da se­sión in­di­vi­dual; una ta­rea ca­si im­po­si­ble.

De igual ma­ne­ra, es­ta he­rra­mien­ta mi­ti­ga mu­chos ti­pos de vul­ne­ra­bi­li­da­des SSL. Por ejem­plo, con el fa­mo­so agu­je­ro de se­gu­ri­dad Heart­bleed, si una cla­ve pri­va­da SSL es­tu­vie­se com­pro­me­ti­da, los hac­kers no po­drían mo­ni­to­ri­zar ni des­ci­frar las co­mu­ni­ca­cio­nes (ci­fra­do úni­co).

La se­gu­ri­dad del ci­fra­do en si de­pen­de de va­rios fac­to­res y lo me­jor es uti­li­zar al­gún ser­vi­cio gra­tui­to en in­ter­net pa­ra va­li­dar que el si­tio es se­gu­ro.

Pa­ra Eli Fask­ha, pre­si­den­te de So­lu­cio­nes Se­gu­ras, par­te de los erro­res que co­me­ten las com­pa­ñías es con­fiar en una so­la tec­no­lo­gía pa­ra la se­gu­ri­dad de sus sis­te­mas.

HTTPS/SSL/TLS so­la­men­te pro­te­ge los da­tos en trán­si­to, pe­ro mu­chos pien­sas que im­ple­men­tan­do un cer­ti­fi­ca­do di­gi­tal ya es­tán se­gu­ros sus ser­vi­do­res.

“Hay que pen­sar en ci­fra­do de los da­tos en re­po­so, de sis­te­mas de pro­tec­ción de con­te­ni­do web, y otros ele­men­tos muy im­por­tan­tes que tra­ba­jan en con­jun­to pa­ra ase­gu­rar los sis­te­mas de una em­pre­sa”, afir­mó.

¿Us­ted es­tá co­me­tien­do es­te error? ¿Sa­be de la nue­va ca­ra de los cer­ti­fi­ca­dos SSL? Qui­zás su res­pues­ta a am­bas pre­gun­tas sea no. De­be­ría co­no­cer­lo, si no, po­dría es­tar po­nien­do en pe­li­gro a to­dos usua­rios.

Newspapers in Spanish

Newspapers from Guatemala

© PressReader. All rights reserved.