UD2.

Certificats digitals i signatura digital

Objectius
Objectius

o Conèixer en què consisteix la infraestructura de clau pública (PKI)

o Comprendre com funciona la criptografia de clau pública o asimètrica
o Entendre com funciona la signatura digital i les seves aplicacions
o Identificar els serveis que ens ofereixen els certificats digitals i la signatura digital
o Conèixer el funcionament bàsic de SSL/TLS i HTTPS
o Aplicar bones pràctiques en l'ús de la navegació segura amb SSL/TLS

Continguts
1. Criptografia de clau pública
2. Infraestructura de clau pública (PKI)2.1. Certificats digitals2.2. Signatura digital
3. Protocols segurs: SSL/TLS i HTTPS
4. Vulnerabilitats i atacs a SSL/TLS/HTTPS
5. Bones pràctiques en l' ús d' HTTPS

1. Criptografia de clau pública

A la unitat didàctica 2 vam veure com la criptografia és una eina utilitzada des de fa
molts segles. Els espartans feien servir un rudimentari mètode conegut com l' escítala i
l'imperi romà feia servir el conegut mètode Cèsar de desplaçament o substitució. Ara
per ara ambdós mètodes són trivials de desxifrar per qualsevol iniciat en aquests temes.

Però és des del segle passat on ocorren els majors avenços en aquest camp, fins al punt
que podem dir que hi ha hagut un abans i un després passant a denominar-se
criptografia clàssica i moderna. Fins i tot hi ha fets històrics que van afectar grans
esdeveniments de la història moderna, com aconseguir que la segona guerra mundial
acabés dos any abans del previst salvant la vida de milions de persones (segons
estimacions d'experts) gràcies al treball de Sir Alan Turing (considerat el pare de la
informàtica) i el seu equip a la mansió anglesa de Bletchley Park, trencant els codi de
la màquina de xifrat Enigma i Lorenz usades pels nazis en la guerra.

En el següent breu vídeo del projecte Criptored pots veure aquesta distinció:

1
https://youtu.be/a3VYWMneK90

A mitjans dels anys 70, la criptografia de clau pública, també coneguda com de clau
asimètrica ve a complementar la criptografia tradicional de xifrat simètric i algunes de
les seves debilitats. Es coneix amb aquest nom perquè la clau de xifrat és diferent a la de
desxifrat de manera que el que es fa una clau, es desfà amb l'altra.

Cada participant en una comunicació - ja sigui una persona o un sistema informàtic com
un servidor web - utilitza un parell de claus:

o Clau pública: es pot lliurar o compartir amb qualsevol persona, ja que no és secreta.
Fins i tot es pot publicar en pàgines personals.
o Clau privada: el propietari l' ha de guardar a bon recapte ja que no s' ha de compartir
amb ningú i com el seu nom indica, és per a ús privat del seu posseïdor.

La seguretat del sistema es basa per tant en la seguretat de la clau privada i en què és
computacionalment "impossible", obtenir la clau privada d'una persona o servei
coneixent la seva pública. Quan es parla de computacionalment impossible, volem dir
que amb la potència actual dels ordinadors, es podria invertir desenes o cents d'anys - en
funció de la fortalesa de l'algoritme i de la longitud de les claus - en poder descobrir la
clau privada.

El parell de claus es generen mitjançant propietats matemàtiques dels nombres cosins

molt grans. Aquesta parella de claus només es pot generar una vegada, de manera que es
pot assumir que no és possible que dues persones hagin obtingut casualment la mateixa
parella de claus.

Per xifrar un destinatari, el remitent xifra el missatge amb clau pública del destinatari de
manera que només el destinatari pot desxifrar amb la seva privada, ja que és l'únic que
la posseeix. D' aquesta manera s' assoleix la confidencialitat de l' enviament del
missatge, ja que ningú llevat del destinatari pot desxifrar-lo.

Els sistemes de clau pública també permeten garantir l'autenticació i el no repudi

mitjançant la signatura digital. En xifrar un document amb la nostra clau privada,
qualsevol pot desxifrar-lo amb la nostra pública. Lògicament, aquest procés no té sentit
per a la confidencialitat ja que qualsevol pot veure el seu contingut, però serveix per
demostrar l'autoria d'un document, ja que només el posseïdor de la clau privada, pot
haver-lo signat.

El següent vídeo mostra d'una forma més visual com funcionen els sistemes de xifra
asimètrica:

https://youtu.be/On1clzor4x4

2
Quin sistema és millor, el de clau simètrica o el de clau pública?

El següent breu vídeo de Criptored, compara els sistemes de xifra simètrica i asimètrica,
concloent que tots dos es complementen i tenen les seves aplicacions concretes d'ús.
Actualment s'utilitza en molts escenaris la combinació de tots dos, denominada
criptografia híbrida, i que fem servir a diari al nostre navegador amb el protocol
HTTPS quan ens connectem al banc, a xarxes socials o a llegir el correu electrònic via
web: https://youtu.be/0qfOVm-dtcQ

2. Infraestructura de clau pública (PKI)

Hem vist en el punt anterior, que la criptografia de clau pública ens proporciona
autenticació, confidencialitat, integritat i no repudi, necessaris avui dia per garantir
una bona seguretat en la informació. Com hem vist, això s' aconsegueix amb un sistema
de claus públiques i privades que combinant-los adequadament ens proporcionen els
serveis esmentats anteriorment.

Però el principal problema que sorgeix és la confiança. Com puc garantir que la clau
pública d'un usuari és seva i no és la d'un impostor? Qualsevol pot generar un parell de
claus i pretendre ser una altra persona. Aquí és on entren en joc les autoritats de
certificació (AC o CA, de l'anglès Certification Authority), que assumeixen la
responsabilitat d'autenticar la identitat d'aquesta clau pública i que apareixerà en un
document electrònic anomenat certificat digital.

Tot aquest conjunt de certificats, firmes digitals, autoritats de certificació i els processos
que hi intervenen, formen part del que es coneix com a infraestructura de clau
pública que passem a definir a continuació.

Infraestructura de clau pública

Per infraestructura de clau pública o PKI (Public Key Infraestructure) s'entén el conjunt
d'eines maquinari, programari, processos i procediments legals que permeten crear,
gestionar, emmagatzemar, distribuir i revocar certificats digitals.

Aquest terme inclou per tant les autoritats de certificació i la resta d' elements que
participen com els certificats digitals o els algorismes de clau pública i signatura digital
en comunicacions i transaccions electròniques.

Cal indicar també que per usar la signatura digital i els algoritmes de clau pública, no és
necessària la PKI, com s'ha pogut veure en les pràctiques del punt anterior.

Una infraestructura de clau pública consta de:

o Autoritats de Certificació (CAs) que porten la gestió dels certificats

3
 o Autoritats de Registre (RAs), que autoritzen l'associació entre una clau pública i el
titular d'un certificat
o Parts utilitzadores, que verifiquen certificats i signatures
o Repositoris (Directeris), que emmagatzemen i distribueixen certificats i estats dels
mateixos
o Titulars de Certificats, que són les entitats finals, usuaris o subscriptors dels certificats
i per tant a qui pertanyen
o Autoritat d' Un certificat

La següent il·lustració mostra aquests components i la seva relació:

2.1. Certificats digitals

Un element important a la PKI són els certificats digitals, documents electrònics

emesos per autoritats de certificació (en endavant AC) que garanteixen la identitat d'un
usuari o servei electrònic com una pàgina web.

Bàsicament un certificat digital és una clau pública d'un usuari o servei, signada
digitalment amb la clau privada d'una AC en la qual confiem, garantint que aquesta clau
pública és de qui diu ser. Per exemple, en el cas del DNI electrònic, l'AC de la Policia
Nacional signa digitalment la clau pública del certificat ciutadà que està introduït en el
xip del seu DNI.

4
Un certificat digital per tant és un document digital mitjançant el qual un tercer
confiable (una autoritat de certificació) garanteix la vinculació entre la identitat d'un
subjecte o entitat i la seva clau pública. Existeixen variats formats per a certificats
digitals, els més comunament emprats es regeixen per l' estàndard UIT-T X.509.

Els certificats digitals es fan servir majorment per:

o Signatura digital de programari o documents

o Xifrar missatges

Els certificats poden ser de diversos tipus segons el seu ús:

o Personals
o Servidor
o Programari
o Entitat de certificació

Els certificats també es poden classificar en funció del nivell de verificació que es fa en
concedir-los per part de l' AC:

o Classe 1: correspon als certificats més fàcils d' obtenir i involucren poques verificacions
de les dades que hi figuren: només el nom i l' adreça de correu electrònic del titular.
o Classe 2: s' emeten per a persones i per a servidors o dispositius i es realitza una major
verificació de la identitat que a classe 1. Els certificats per a persones de classe 2
resulten adequats per a les firmes digitals, el xifrat i el control d' accés electrònic en
transaccions en les quals la prova d' identitat basada en informació de la base de
dades de validació és suficient. Els certificats de dispositiu o servidor de classe 2
resulten adequats per a l' autenticació de servidors, la integritat de missatges,
programari i el xifrat.
o Classe 3: s' emeten a persones, organitzacions, servidors, dispositius i administradors
d' AC i autoritats de certificats arrel. Els certificats individuals de classe 3 resulten
adequats per a les firmes digitals, el xifrat i el control d' accés en transaccions on s'
assegura la prova d' identitat. Els certificats de servidor de classe 3 resulten adequats
per a l' autenticació de servidor; la integritat de missatges, programari i xifrat. Donen
un major nivell de confiança perquè exigeixen un procés de verificació presencial.

Un altre tipus de classificació dels certificats en funció de la validació que es fa per a l'
organització que ho demana és:

o Domain Validated (DV): tenen el nivell més baix de verificació perquè només es
comprova que el domini pertany al sol·licitant. La confirmació per part de l'AC es fa
enviant un email al correu que figura en la informació de la base de dades whois del
domini registrat o bé enviant un arxiu de verificació que el sol·licitant col·loca al lloc
web perquè l'AC comprovi que li pertany aquest domini.

5
 o Organization Validated (OV): tenen un nivell més alt de confiança perquè a més de
comprovar el domini, verifiquen la identitat de l'organització a la qual pertany el
domini. El nom de l'organització també apareixerà en el certificat, donant confiança
afegida que tant el lloc web com la companyia són de confiança. Solen ser utilitzats per
empreses, governs i altres entitats que volen proporcionar una capa addicional de
confiança per als seus visitants.
o Extended Validation (EV): són els més segurs i confiables i alhora els més cars perquè
requereixen un procés de validació molt més complex per part de l'AC i la sol·licitud de
molta documentació a l'organització sol·licitant. A més de mostrar el nom de
l'organització en el certificat, també apareixerà en color verd a la barra d'adreces, al
costat del candau. Tots els bancs haurien de fer servir certificats d'aquest tipus, tot i
que malauradament molts no ho fan, com és el cas del BBVA o Banc Santander per
citar alguns exemples.

Certificat de BBVA amb validació OV únicament i certificat Bankia amb validació estesa i per
tant, de major confiança

Els certificats poden anar en diversos suports com per exemple:

o Fitxer en disc dur, disquette o USB

o Targetes smartcard (com el DNI-e)
o targetes criptogràfiques
o token USB

6
Un certificat digital conté informació com:

o Número de versió
o Número de sèrie
o Nom de l'emissor (AC)
o Nom del subjecte
o Període de validesa
o Clau pública del subjecte
o Mètode de verificació de la signatura
o Signatura digital del certificat per part de l' AC
o Extensions de certificat

En la següent figura es poden comprovar la informació que conté un certificat digital

d'un servidor web segur (HTTPS) d'un banc:

Aquesta informació es pot obtenir usant qualsevol navegador. Per exemple a Firefox,
polsant Control + i (o bé Eines, Informació de la pàgina), pestanya Seguretat, botó veure
certificat. També es pot fer al candau de la barra d' adreces. Des de Chrome es pot fer
fent clic al candau de la barra d'adreces i després seleccionar Connexió, Dades del
certificat. La següent imatge mostra la mateixa informació des de Chrome:

7
Els certificats digitals es poden trobar en diversos estats:

o Emès: es troba en vigència i per tant és vàlid.

o Expirat: ha finalitzat el seu període de validesa i cal renovar-lo.
o Revocat: és un certificat que no és vàlid i ha estat inclòs en una llista de revocació
(CRL) perquè la clau privada s'ha vist compromesa o hi ha hagut canvis en les dades
associades al certificat
o Suspès: és una revocació temporal per les mateixes raons que el revocat, però és una
situació reversible.

Passos per obtenir un certificat

Com a persones físiques o bé, per muntar un servidor web segur, podem sol·licitar un
certificat a una AC seguint els següents passos:

1. El sol·licitant (persona física o una empresa) realitza una sol·licitud (CSR, Certificate
Signing Request) enviant les seves dades a l'autoritat certificadora.

8
 2. L'Autoritat de Certificació verifica la identitat del sol·licitant d'un certificat abans de la
seva expedició, de forma presencial habitualment.
3. En expedir el certificat, l' AC el signa amb la seva clau privada, garantint la seva
validesa.
4. L'AC envia al sol·licitant el certificat.
5. Els certificats solen ser per a persones físiques o per a servidors (p.ex. https).

En algun moment del procés, cal generar el parell de claus (privada i pública)
associades al sol·licitant. Hi ha dues opcions, sent la segona la més recomanable i
usada:

1. Mètode 1: l'autoritat en crear el certificat crea un parell de claus:Clau privada:

continguda en el propi certificat digital - Ni l'usuari ni la CA han de proporcionar el
certificat a altres - La CA no es queda amb còpia del certificat - Si es perd, se n'ha de
demanar un de nouClave pública: guardada per la CA i proporcionada a tothom qui la
sol·liciti

2. Mètode 2: per evitar que la CA pugui tenir la clau privada el sol·licitant pot generar
una petició de certificat (CSR) des del seu ordinador, que enviarà a l'autoritat
certificadora, i així no li envia la seva clau privada, que sempre la tindrà ell al seu
ordinador

Procés de validació i verificació d' un certificat

Els passos que se segueixen quan un part vol validar el certificat que li envia l'altra part,
com per exemple un navegador web quan es connecta a una pàgina web segura:

1. Aconseguir el certificat de l' altra part.

2. Verificar la validesa del certificat: - Dins del període de validesa - Certificat no revocat -
Signatura electrònica de l'ACn

3. Verificar la signatura digital del resum o hash del missatge amb la clau pública de l'
emissor.

4. El receptor ha d'estar en possessió de la clau pública de l'AC (instal·lada al seu

navegador, per exemple), amb la qual cosa podrà comprovar la signatura electrònica
de l'AC del certificat.

Autoritat de Certificació

9
L'AC és una entitat fiable i reconeguda regionalment o mundialment, encarregada de
garantir de forma unívoca i segura la identitat associada a una clau pública. Realitza les
següents tasques:

o Rep i processa peticions de certificats (CSR) dels usuaris finals.

o Consulta amb una Autoritat de Registre per determinar si accepta o refusa la petició de
certificat
o Emet el certificat
o Gestiona Llistes de Revocació de Certificats (CRLs)
o Renova certificats
o Proporciona: - Serveis de backup i arxiu segur de claus de xifrat - Infraestructura de
seguretat per a la confiança, polítiques d'operació segura i informació d'auditoria.

Algunes de les principals autoritats certificadores són:

o Internacionals: Verisign, GlobalSign, Thawte Certification, Comodo, etc

o A Espanya: FNMT, ACCV (GVA), Edicom, etc.

Qualsevol pot crear la seva pròpia AC amb el programari adequat (per exemple
Openssl). El problema és generar reputació i confiança per la resta per ser inclòs en els
repositoris d'AC, com les que venen de sèrie al nostre navegador.

Es poden consultar les AC del nostre ordinador, depenent del programari que utilitzem.
Per exemple al navegador Firefox es poden consultar des de menú Preferències,
Avançat, Certificats, botó Veure certificats, pestanya Autoritats:

10
Des de Chrome, podem fer-ho des de menú Configuració, Mostrar opcions avançades,
botó Administrar certificats, pestanya Entitats Emissores:

2.2. Signatura digital

La signatura digital es fa servir per autenticar l'origen de les dades i assegurar la

integritat del missatge. La seva finalitat no és proporcionar confidencialitat ja que no s'
utilitza per xifrar els documents complets si no un resum del missatge amb una funció
hash, d' aquesta manera les entitats poden assegurar l' origen de les dades.

Aquest tipus de signatura electrònica està sent adoptada progressivament com una
signatura amb validesa jurídica. Per exemple, la signatura digital de la declaració de la
renda presentada telemàticament per Internet, es realitza mitjançant aquest sistema.

Com ja es va estudiar a la unitat didàctica 2, la funció hash és un algoritme matemàtic

que permet calcular un valor resum (message digest) de les dades a ser signats
digitalment. No és reversible, és a dir, no és possible, a partir del valor resum, calcular
les dades originals. Alguns exemples d'algoritmes de hash són SHA, MD4, MD5, etc.

La signatura digital proporciona doncs els serveis següents:

o Autenticitat
o Integritat
o No repudi

11
Funcionament de la signatura digital

La signatura digital d' un document és el resultat de realitzar el següent procés:

1. Aplicar una funció hash, al seu contingut generant així un resum irreversible.
2. Aplicar l 'algoritme de firma (com RSA o DSA i en el qual s'empra la clau privada) al
resum, generant així la firma digital.

El destinatari, en rebre el missatge:

1. Calcula de nou el resum mitjançant la mateixa funció hash.

2. Desxifra la firma utilitzant la clau pública de l' emissor i aplicant el mateix algoritme de
signatura.
3. Si ambdós resums coincideixen, la signatura és vàlida

En la següent figura, s'il·lustra el procés de la signatura digital:

Aplicacions de la signatura digital

Com ja s'ha citat, actualment la firma digital és un reemplaçament de la firma

manuscrita fins al punt que té completa validesa legal. Algunes de les aplicacions més
destacables de la firma digital són:

o Missatges amb autenticitat assegurada o Diners electrònics

o Missatges sense possibilitat de repudi o Notificacions judicials electròniques
o Contractes comercials electrònics o Vot electrònic

12
 o Factura Electrònica o Decrets executius (govern)
o Desmaterialització de documents o Crèdits de seguretat social
o Transaccions comercials electròniques o Contractació pública
o Invitació electrònica o Segellament de temps

3. Protocols segurs: SSL/TLS i HTTPS

SSL (Secure Sockets Layer) i TLS (Transport Layer Security) són una sèrie de
protocols que permeten donar seguretat als protocols de capa d'aplicació que no la
posseeixen de forma nativa, protegint d'aquesta manera serveis com les aplicacions web,
el correu electrònic, la transferència d'arxius o la veu sobre IP.

D'aquesta manera, protocols com HTTP, SMTP/POP3 o FTP passen a denominar-se

HTTPS, SMTPS, POP3S o FTPS quan fan servir SSL/TLS per sota. SSL/TLS ofereix
xifrat híbrid en combinar algoritmes de clau pública amb algoritmes de clau simètrica.
La clau simètrica es fa servir per xifrar les comunicacions entre ambdós extrems, i per
intercanviar-se aquesta clau de sessió, es fa servir la criptografia de clau pública.

Com ja es va comentar anteriorment a la unitat, el xifrat simètric és molt més ràpid i

necessita menor càrrega computacional que el xifrat asimètric. Tanmateix aquest últim
és ideal per assegurar la integritat i l' autenticació de les dades, així com per a l'
intercanvi segur de claus.

SSL és el protocol més antic i va ser desenvolupat per Netscape a mitjans dels 90. En
aquest protocol han anat basant-se les següents versions que han anat millorant fallades
de seguretat fins a arribar al protocol TLS, que és una versió millorada del seu
antecessor SSL.

TLS actualment va per la versió 1.3 i és el protocol que es recomana usar en navegador i
servidors web, a causa de les fallades de seguretat de SSL que han anat publicant-se
recentment. SSL va arribar fins a la versió 3 i es desaconsella el seu ús per les raons
exposades anteriorment.

Ambdós protocols han estat fonamentals per a l'auge del comerç electrònic, les compres
segures i l'administració telemàtica en proporcionar seguretat en aquests serveis en
utilitzar una xarxa de transport insegura com és Internet.

En el següent vídeo d'Intypedia, pots veure una introducció al protocol SSL/TLS així
com el seu funcionament: https://youtu.be/pOeWmStBOYY

13
4. Vulnerabilitats i atacs a SSL/TLS/HTTPS

Tot i que la família de protocols SSL/TLS es van concebre per proporcionar

confidencialitat, autenticitat, integritat i no repudi a les transaccions electròniques
realitzades per Internet, no els deslliura de tenir fallades i debilitats que han anat
descobrint-se al llarg del temps, com passa amb qualsevol tecnologia.

El protocol SSL es va desenvolupar a mitjans dels 90 i des d'aleshores la capacitat de

còmput dels ordinadors ha augmentat exponencialment, permetent trobar debilitats en
els protocols criptogràfics. Actualment i a causa de les vulnerabilitats aparegudes, es
desaconsella usar SSL al navegador, i es recomana l' ús sempre de l' última versió de
TLS.

A continuació comentem per sobre, evitant excessius tecnicismes, algunes de les

vulnerabilitats més destacables i que desaconsellen l'ús de SSL en totes les seves
versions i de TLS en algunes d'elles, forçant que usem a ser possible l'última versió,
TLS 1.2.

BEAST

Browser Exploit Against SSL/TLS, més conegut per les seves sigles BEAST, és un
atac que vulnera els protocols SSL i TLS 1.0 (no així a TLS 1.1 i TLS 1.2) de manera
que permet desxifrar el trànsit d'una sessió. Aquesta vulnerabilitat va ser descoberta pel
2011 per dos investigadors de seguretat: Thai Duong i Juliano Rizzo.

L'impacte d'aquesta vulnerabilitat és important perquè és el primer atac a SSL/TLS que

permet desxifrar el trànsit. Per a això és necessari que l'atacant insereixi codi en
llenguatge Javascript (és un llenguatge que s'executa al navegador) al navegador de la
víctima, de manera que enviï un text conegut per l'atacant pel canal SSL xifrat. L'atacant
ha de poder capturar el missatge xifrat (per exemple amb un atac MITM) i encara que
no conegui la clau de xifrat, mitjançant tècniques de criptoanàlisi, l'atac li permet
desxifrar altres dades de la sessió com per exemple les cookies.

En robar una cookie de sessió, l'atacant pot colar-se en la sessió que té la víctima oberta
contra l'aplicació web. Les cookies són petits fragments d'informació que en la majoria
de les aplicacions web serveixen per identificar l'usuari un cop s'ha autenticat en
l'aplicació web: això evita que l'usuari hagi d'escriure l'usuari i la contrasenya en cada
clic o petició web a la mateixa aplicació.

14
Microsoft va reconèixer que totes les versions de Windows, des d'XP fins a Windows
7, són vulnerables a atacs BEAST.

Heartbleed

Heartbleed és una vulnerabilitat d 'OpenSSL que va ser descoberta per enginyers de

Google i l'empresa Codenomicon l'abril del 2014. OpenSSL és un paquet de programari
lliure que implementa els protocols SSL/TLS i és àmpliament usat a tot el món. És una
fallada que afecta els servidors web que utilitzen OpenSSL de manera que l'usuari final
poc pot fer si el programari dels servidors no és actualitzat.

Mitjançant aquesta vulnerabilitat, un atacant podria llegir la memòria d'un servidor o un

client, permetent-li aconseguir les claus privades d'un servidor i per tant poder desxifrar
els missatges. Pel que sembla alguns atacants han estat aprofitant aquesta fallada des de
fa almenys cinc mesos abans que fos descobert i publicat.

Hi ha eines online com Lastpass o Filippo i plugins de navegadors com Chromebleed

que permeten comprovar si un servidor al qual ens connectem és vulnerable.

Per a més detalls de la vulnerabilitat, es pot consultar el següent article d' Hispasec:

OpenSSL afectada per una vulnerabilitat apodada Heartbleed

Logo de la vulnerabilitat Heartbleed

Poodle
15
L'atac POODLE (Padding Oracle On Downgraded Legacy Encryption) és una fallada
de seguretat que per tenir èxit necessita fer un atac previ MITM i forçar a baixar la
versió de SSL/TLS a la SSL 3.0, el que es coneix com a degradació o downgrade.
Aquesta fallada de seguretat va ser descoberta per enginyers de Google l'octubre de
2014 i afecta SSL 3.0 en usar sistemes de xifrat per bloc (CBC).

Bàsicament l'atac consisteix en una iteració on es va descobrint byte a byte mitjançant la

comprovació dels 256 possibles valors d'un byte, fins que es pot obtenir una dada crítica
de la connexió com la cookie de sessió.

Una possible solució és desactivar completament l' ús de SSL 3.0 a la banda del client i
el servidor. El problema és que servidors web antics no admeten TLS 1.0 i superiors. La
solució recomanada pels experts és usar l'extensió TLS_FALLBACK_SCSV tant en
navegador com en el servidor, que impedeix que es pugui degradar la connexió fent
servir una versió vella de SSL.

Com sempre la millor solució és tenir els sistemes actualitzats i usar sempre l'última
versió disponible del nostre navegador favorit.

Per a més detalls de la vulnerabilitat, es pot consultar el següent enllaç:

POODLE, així és l'atac que deixa obsolet SSLv3

FREAK

La vulnerabilitat FREAK (Factoring RSA Export Keys) va ser descoberta el març del
2015 per un grup d'investigadors coneguts com a SmackTLS. Aquesta vulnerabilitat és
deguda al altri que molts servidors web utilitzen algoritmes de xifrat molt febles, amb
longitud de claus de xifrat més curtes i que van ser qualificats com a EXPORT.

La raó d'ells és que als anys 90, el govern dels Estats Units considerava tota tecnologia
de xifrat pròpia restringida per a la seva exportació, en la mateixa categoria que
l'equipament militar. El raonament que s'oferia era la possibilitat que els algoritmes de
xifrat caiguessin en mans enemigues i aquests disposessin així d'una eina que entorpiria
la feina de les agències d'intel·ligència. Més tard, l'any 2000, amb la modificació de les
lleis d'exportació dels Estats Units, els venedors van ser capaços d'incloure sistemes de
xifrat de 128 bits més segurs en els seus productes i van ser capaços de distribuir-los a
tot el món.

16
El problema és que la majoria dels servidors actuals seguien suportant aquests xifrats
febles i era possible per a un atacant amb un atac MITM, forçar a usar un d'aquests
xifrats febles i aconseguir obtenir la clau de la sessió.

És possible comprovar si un servidor web és vulnerables amb el següent comandament

en una consola GNU/Linux:

openssl s_client -connect domini:443 -cipher EXPORT

Per exemple, en el moment de publicar la vulnerabilitat, les adreces web de GVA

appweb.edu.gva.es o itaca.edu.gva.es eren vulnerables a FREAK

En el següent enllaç es poden consultar més detalls de la vulnerabilitat:

FREAK, una vulnerabilitat en les connexions TLS/SSL de més de 10 anys

Altres vulnerabilitats: SSLStrip i Web MITM

Hi ha una altra vulnerabilitats, com l'atac SSLStrip que enganya l'usuari creient que
està fent servir una connexió segura o els atacs MITM on l'atacant envia un certificat
fals per poder desxifrar les comunicacions. Aquestes tècniques es poden evitar amb una
bona formació i conscienciació per part de l'usuari, que no hauria de continuar navegant
per una web on el navegador ens mostri una alerta de seguretat o ens mostri un candau
sense estar usant.

Imatge que mostra la típica alerta del navegador IE quan el certificat no s'ha pogut validar,
perquè

poden estar fent-nos un atac MITM amb un certificat fals

17
Imatge que mostra la barra de direccions després de patir un atac SSLStrip. Obseŕvese que
hay un candado

però la connexió no és HTTPS

En el següent vídeo d'Intypedia es mostren algunes d'aquestes vulnerabilitats aquí

comentades: https://youtu.be/pSVNnShpCOM

Domain Fronting

Tot i que no podem classificar-lo com una vulnerabilitat o un atac a SSL/TLS, el

domain fronting és una tècnica utlitzada des de fa algun temps per evadir la censura
d'alguns països o les polítiques de seguretat d'algunes organitzacions, que deneguen
l'accés web a determinats dominis per qüestions polítiques o de control parental
(eròtiques, violència, hacking, terrorisme, etc).

Aquesta tècnica s'aprofita d'una funcionalitat existent en la negociació SSL/TLS entre el

client i el servidor, i que es denomina SNI (Server Name Indication). SNI és una
extensió de TLS que permet al client indicar que host per nom vol connectar, abans de

18
completar el handshake. D'aquesta manera, un servidor o frontal web (d'aquí el nom de
domain fronting) pot utilitzar múltiples certificats SSL/TLS en una mateixa adreça IP i
número de port i d'aquesta manera permetre múltiples llocs segurs (HTTPS) o que
qualsevol altre servei sobre TLS pugui ser servit en una mateixa IP sense que tots
comparteixin el mateix certificat.

D'altra banda, des de la versió 3 de X.509 v3 s'introdueix el camp que permet que un
certificat serveixi per a més d'un domini i l'ús de comodins mentre el nom comú i camps
de l'espai. Però pot ser poc pràctic o fins i tot impossible, a causa de la falta d'una llista
completa de tots els noms per endavant. A més aquests certificats comodí s'han de
tornar a emetre cada vegada que la llista de dominis canviï.

Aquesta tècnica és usada per aplicacions com Tor (en el seu plugin meek), Signal per a
Android, Lantern o Psiphon. Bàsicament consisteix a utilitzar diferents noms de hosts
(fqdn) en diferents capes. Per exemple, a nivell de negociació TLS, la petició es fa a
www.google.com, però dins de la capa HTTP xifrada per TLS, a l'encapçalat Host de la
petició HTTP, es demana un nom diferent, que d'una altra manera seria denegat per la
política de seguretat de l'organització. En la següent figura s'intenta il·lustrar la tècnica:

El client sol·licita una petició DNS a allowed.example, domini autoritzat per la xarxa
a la qual està connectat el client. D'aquesta manera tampoc s'aixequen alarmes a través
de DNS. A continuació, un cop resolta la consulta DNS, el client negocia el handshake
TLS usant com a SNI allowed.com. Però un cop establerta la sessió TLS, a la capa
HTTP interna i xifrada per la capa TLS, es demana el host forbidden.example, que
seria denegat per la xarxa en condicions normals.

Òbviament, forbidden.example és allotjat per allowed.example, en un servei de cloud o

de CDN tipus Google App Engine, Amazon EC2 o Azure. També se'l pot muntar un
mateix, no cal contractar un hosting en aquests proveïdors.

Com a exemple real, per demostrar això, podem fer servir Google fent una petició del
seu certificat en cloud.google.com. Si des d'una consola GNU/Linux amb openssl
instal·lat executem el següent comandament:

echo | openssl s_client -connect cloud.google.com:443

2>/dev/null | openssl x509 -text | grep -A1 "Alternative
Name"

Podrem veure per consola l'enorme llistat de dominis que aquest certificat suporta i
entre ells trobem *.appengine.google.com, que és el frontal de les aplicacions de GAE
(Google App Engine). Això vol dir que podem contractar un servidor amb una APP que
respongui a denegado.appengine.google.com i ocultar-lo dins d'una petició externa a

19
cloud.google.com, cosa que als ulls de l'administrador de la xarxa, semblaria un simple
accés a la web de Google Cloud.

La forma de denegar aquesta tècnica no és fàcil. O es denega, per citar exemples, a

Google, Amazon o Azure la qual cosa no és viable per a moltes organitzacions (no així
per a la Xina, on està censurat Google) o s'implanta DPI trencant l'HTTPS en totes les
peticions dels clients per desxifrar i inspeccionar el que s'està fent a la capa HTTP (una
cosa costosa de realitzar i implantar i no sempre possible).

4.1. Algunes notícies relacionades amb vulnerabilitats i atacs a

SSL/TLS
Per si fos poc amb les vulnerabilitats exposades a la secció anterior i que poden ser
solucionades usant sistemes actualitzats i desconfiant de connexions insegures o sense,
hi ha hagut molts incidents de seguretat relacionats amb les autoritats de certificació, bé
per una mala gestió a l' hora de concedir certificats, o bé per haver estat atacades i
compromeses les seves claus privades. Es destaquen a continuació algunes d' elles:

Certificat fals de Windows Live pot permetre atacs Man In The Middle

Es detecta un altre certificat fals de Google

DigiNotar: La tercera revocació massiva en 10 anys

Malware i certificats digitals

Què ha passat amb el certificat d'Adobe?

Nous certificats fraudulents per a google.com i altres dominis

Nous certificats fraudulents per a dominis de Google

I per finalitzar, destacar aquest article publicat per l'investigador de seguretat Sergio de
los Santos, on s'explica d'una forma molt amena els problemes associats amb l'ús de
certificats digitals:

Converses sobre certificats digitals

5. Bones pràctiques en l'ús d'HTTPS

20
En aquest punt intentarem recopilar de forma breu les pràctiques més recomanables a
l'hora d'utilitzar aplicacions segures amb SSL/TLS i poder identificar quan som víctimes
d'un atac que pugui vulnerar la confidencialitat de les nostres dades.

Citem a continuació les recomanacions més destacables:

o Alertes de certificat no vàlid: rebutjar la connexió si el navegador mostra una alerta

indicant que el certificat no és vàlid. Això pot ser a causa d'un atac de falsificació de
certificat però moltes vegades aquesta causa és degut al al seu que no el servidor web
utilitza un certificat autofirmat o bé signat per una AC que no està instal·lada al nostre
navegador. Això de vegades passa fins i tot amb pàgines de l'administració com la
seguretat social o de la Generalitat valenciana, els certificats de la qual no venien
instal·lats de sèrie en la majoria de navegadors fa anys i en aquests casos és
convenient acceptar els certificats però sempre amb molta cura i estant segur del que
es fa (davant el dubte és millor no acceptar-ho). En les següents imatges es mostren
els avisos que mostren alguns navegadors davant d'aquest problema:

21
o Forçar l'ús d'HTTPS sempre que sigui possible: És millor que intentem connectar
directament als llocs web a través de https (escrivint-lo manualment a la barra
d'adreces) per evitar atacs del tipus SSLStrip. Molts navegadors per defecte intenten
accedir a la versió https dels llocs web, però també dos del plugin HTTPS-Everywhere,
que força a connectar sempre que sigui possible per HTTPS en comptes de per HTTP
sense necessitat que haguem d'escriure https a ñla barra d'adreces. Una altra opció és
usar NoScript, que inclou la mateixa funcionalitat, a més de definir llistes negres i
blanques de llocs on forcem sempre l'ús o no de https, així com el bloqueig de
seqüències de comandaments JavaScript, applets Java o objectes Flash potencialment
danyosos.

22
 Logo d' HTTPS Everywhere

o No fiar-se del "candadito": atacs com el SSLStrip han deixat en evidència la

recomanació que es fa moltes vegades d'observar si apareix un candau al costat de la
barra d'adreces per verificar que estem fent servir una connexió segur. Això no és
suficient i cal verificar que el protocol que estem fent servir és https i fins i tot no està
de més verificar l'autenticitat del certificat mostrant-ne els detalls des de la finestra
d'informació de seguretat que mostren molts navegadors en fer clic al candau i que ja
es va comentar al punt 2 de la unitat.

o Activar la validació OCSP: OCSP és un protocol que permet validar en línia els
certificats de les organitzacions. Tots els navegadors permeten habilitar aquesta
comprovació i a més rebutjar la connexió si el servidor OCSP no està disponible (el que
de vegades passa per un atac intencionat). A Firefox es fa des de Preferències,
Avançat, Certificats, Consultar els servidors responedors OCSP per confirmar la validesa
actual dels certificats. Una altra manera de fer-ho és des d'about:config a la barra de
direccions, i activant els valors security. OCSP.enable i security. OCSP.require. A
Chrome han decidit eliminar aquesta opció per temes de rendiment i disponibilitat
dels servidors de les AC. Google ha decidit incloure tots els certificats revocats de sèrie
al seu navegador per la qual cosa és molt important tenir aquest navegador sempre
actualitzat.

o Utilitzar Certificate Pinning: aquesta tècnica consisteix a "fixar" o "unir" (to pin) un
certificat a un domini permanentment, de manera que encara que patim un atac amb
un certificat fals però signat per una AC, el sistema detectarà que hi ha hagut un canvi
de certificat i mostrarà un avís i/o no permetrà la connexió. Sense aquesta tècnica, el
nostre navegador permetria la connexió sense mostrar cap alerta, en ser una AC vàlida
tot i haver canviat el certificat. Eines per realitzar això són Certificate Patrol o EMET
(una potent eina de seguretat de Microsoft) tot i que hi ha navegadors que realitzen el
Certificate Pinning de sèrie amb els seus propis dominis, com fa Chrome amb els seus
dominis de Google, per evitar atacs MITM amb certificats falsos. Alguns navegadors
també incloïen suport per a Public Key Pinning Extension for HTTP (HPKP), que és un
encapçalat que els servidors web poden enviar perquè els navegadors fixin la clau
pública d'un domini a un determinat valor, evitant d'aquesta manera els MITM amb
certificats falsos. Aquest sistema ja està obsolet a causa de molts problemes que
generava i està deixant de ser suportat pels navegadors moderns i està sent
reemplaçat per Certificate Transparency.
o Certificate Transparency: és un framework dissenyat per protegir i
monitoritzar l'emissió incorrecta de certificats. Els certificats recent emesos
es registren per ser supervisats. D'aquesta manera, les autoritats de
certificació (AC) poden estar subjectes a un escrutini i supervisió públics

23
 molt més grans. Els certificats potencialment maliciosos, com els que
infringeixen els requisits bàsics de CA/B Forum, es poden detectar i revocar
molt més ràpidament. Els fabricants de navegadors estan autoritzats a
prendre decisions més informades respecte a les AC problemàtiques de les
quals poden decidir desconfiar. Els servidors web envien l'encapçalat
Expect-CT mitjançant el qual informen i fan complir els requisits de
transparència de certificats, per evitar que l'ús de certificats emesos
incorrectament per a aquest lloc passi desapercebut. Per la seva banda, els
certificats legítims dels llocs web que fan servir aquest framework, han de
registrar els seus certificats en un registre públic (CT log). En aquell moment
un timestamp anomenat SCT (Signed Timestamp) és generat i retornat al
lloc web i que serveix com a prova que el certificat ha estat registrat. Els
servidors web han d'enviar aquests SCT's als clients TLS per al navegador.
Poden ser tramesos d' una de les formes següents: mitjançant extensions
x509 en el certificat, mitjançant extensions en el handshake TLS o bé
mitjançant OCSP.

Conclusions
En aquest tema hem après a:

o Identificar els serveis que ens ofereixen els certificats digitals i la signatura digital
o Usar la criptografia de clau pública i la signatura digital
o Comprendre el funcionament bàsic de SSL/TLS i HTTPS
o Detectar si un servidor segur o el nostre navegador és vulnerable a alguna fallada de
seguretat SSL/TLS
o Aplicar mesures de seguretat per detectar i identificar atacs SSL/TLS

24