Transport Layer Security

Seguritat de la capa de transport (en inglés: Transport Layer Security, TLS) i el seu antecessor Secure Sockets Layer (SSL; en espanyol capa de ports segurs) són protocols criptográficos, que proporcionen comunicacions segures per una ret, comunament Internet. El protocol TLS és el successor de SSL (1995), introduït en 1999 en una versió millorada de SSL 3.0 (que al principi es va cridar SSL 3.1). La versió actual és TLS 1.3 (a partir de 2018). Les versions de SSL estan desactualizades i es consideren insegures.

S'usen certificats X.509, i per lo tant criptografia asimètrica per a autenticar a la contraparte en qui s'estan comunicant, i per a intercanviar una clau simètrica. Esta sessió és després usada per a sifrar el fluix de senyes entre les parts. Açò permet la confidencialitat del mensage, còdics d'autenticació de mensages per a integritat i com un producte lateral, autenticació del mensage. Vàries versions del protocol estan en aplicacions àmpliament utilisades com navegació web, correu electrònic, fax per Internet, mensageria instantànea i veu-sobre-IP (VoIP). Una propietat important en este context és forward secrecy, per a que la clau de curta vida de la sessió no puga ser descoberta a partir de la clau asimètrica de llarc determini.

• TLS és un protocol d'Internet Engineering Task Force (IETF), definit per primera volta en 1999, que va ser actualisat en el RFC 5246 (agost de 2008) i en RFC 6176 (març de 2011). Es basa en les especificacions prèvies de SSL (1994, 1995, 1996) desenrollades per Netscape Communications per a agregar el protocol HTTPS al seu navegador Netscape Navigator. La seua última versió, TLS 1.3, va ser definida en agost de 2018.

Descripció

SSL proporciona autenticació i privacitat de l'informació entre extrems sobre Internet per mig de l'us de criptografia. Habitualment, solament el servidor és autenticado (és dir, es garantisa la seua identitat) mentres que el client es manté sense autenticar. SSL implica una série de fases bàsiques:

• Negociar entre les parts l'algoritme que s'usarà en la comunicació
• Intercanvie de claus públiques i autenticació basada en certificats digitals.
• Sifrat del tràfic basat en sifrat simètric. Durant la primera fase, el client i el servidor negocien qué algoritmes criptográficos es van a usar. Les implementacions actuals proporcionen les següents opcions:
• Per a criptografia de clau pública: RSA, Diffie-Hellman, DSA (Digital Signature Algorithm) o Fortezza.

• Per a sifrat simètric: RC2, RC4, IDEA (International Data Encryption Algorithm), DONES (Data Encryption Standard), Triple DONES i AES (Advanced Encryption Standard).
• En funcions #: MD5 o de la família SHA.

Història i desenroll

Protocol	Publicació
SSL 1.0	style="N/A" |
SSL 2.0	1995
SSL 3.0	1996
TLS 1.0	1999
TLS 1.1	2006
TLS 1.2	2008
TLS 1.3	2018

API de Secure Network Programming

Els primers esforços d'investigació cap a la seguritat de la capa de transport varen incloure l'interfaç de programació d'aplicacions (API, per la seua sigla en anglés) de Secure Network Programming (SNP), la que en 1993 va explorar la possibilitat de tindre una API de capa de transport segura similar als sockets Berkeley, per a facilitar la retroadaptación de les aplicacions de ret preexistentes en mides de seguritat.

SSL 3.0

El protocol SSL va ser desenrollat originalment per Netscape. La versió 1.0 mai es va entregar públicament; la versió 2.0 es va presentar en febrer de 1995 pero "contenia una cantitat de falles de seguritat que al final varen dur al disseny de la versió SSL 3.0". Dita versió, presentada en 1996, va anar un redisseny complet del protocol produït per Paul Kocher, qui va treballar en els ingeniers de Netscape Phil Karlton i Alan Freier. Les versions més noves de SSL/TLS estan basades en SSL 3.0. El borrador de 1996 de SSL 3.0 va ser publicat per l'IETF com l'històric RFC 6101. En octubre de 2014, es va detectar una nova vulnerabilitat sobre el protocol SSL en la seua versió 3.0, la Vulnerabilitat de Poodle.

TLS 1.0

• TLS 1.0 va ser definit en el RFC 2246 en giner de 1999 i és una actualisació de SSL versió 3.0. Com diu el RFC, "les diferències entre este protocol i SSL 3.0 no són dramàtiques, pero són suficientment significatives com per a impedir l'interoperabilidad entre TLS 1.0 i SSL 3.0". TLS 1.0 inclou una forma en la qual'implementació pot conectar-se en SSL 3.0, debilitant la seguritat.

TLS 1.1

• TLS 1.1 va ser definit en el RFC 4346 en abril de 2006. És una actualisació de TLS 1.0. Les diferències més significatives inclouen:
• Agrega protecció contra atacs de CBC.
  • el vector d'inicialización (IV) implícit va ser reemplaçat per un IV explícit.
  • Canvi en el maneig dels errors de farcidura.
• Soport per al registre de paràmetros d'IANA.

TLS 1.2

• TLS 1.2 va ser definit originalment en el RFC 5246 en agost del 2008. Es basa en una especificació posterior de TLS 1.1. Les majors diferències són:
• la combinació MD5-SHA-1 en la funció pseudoaleatoria (PRF) va ser reemplaçada per SHA-256, en l'opció d'usar les PRF especificades en la cipher-suite.
• la combinació MD5-SHA-1 en el mensage terminat va ser reemplaçada per SHA-256, sense l'opció d'usar algoritmes de # específics per a la cipher-suite. No obstant, el tamany del *# en el mensage terminat és truncat a 96 bits.
• la combinació MD5-SHA-1 en l'element digitalment firmat va ser reemplaçada per un *# simple negociat durant el handshake, que per defecte és SHA-1.
• Millores en l'habilitat de clients i servidors per a especificar qué algoritmes de *# i de firma van a acceptar.
• Expansió del soport de sifres de sifrat autenticades, usades majorment per a modo Galois/Counter (GCM) i modo CCM del sifrat en Advanced Encryption Standard (AES).
• Es varen agregar definició d'Extensions de TLS i de Ciphersuites d'AES.

• TLS 1.2 va ser despuix redefinit en el RFC 6176 de març de 2011 redactant el seu retrocompatibilidad en SSL i TLS per a que dites sessions jamai negocien l'us de SSL versió 2.0.

TLS 1.3

• TLS 1.3 va ser definit en el RFC 8446 en agost de 2018. Està basat en l'anterior especificació TLS 1.2. Les principals diferències en TLS 1.2 inclouen:
• Un modo 0-RTT
• Retir de l'hora GMT.
• Fusiona soport d'ECC del RFC 4492 pero sense curves explícites.
• Retira el camp de llongitut innecessària de l'entrada d'AD a sifres AEAD.
• Canviar el nom de {Client, Servidor} KeyExchange a {Client, Servidor} KeyShare
• Afig un HelloRetryRequest explícita per a rebujar el del client
• Handshake revisat a fi de proporcionar el modo 1-RTT.
• Retir de grups DHE personalisats.
• Eliminat el soport per a la compressió.
• Eliminat el soport per a l'intercanvi de claus RSA estàtica i DH.
• Eliminat el soport per a sistemes de sifrat no AEAD.

Funcionament

El protocol SSL intercanvia registres; opcionalmente, cada registre pot ser comprimit, sifrat i empaquetat en un còdic d'autenticació del mensage (MAC). Cada registre té un camp de content_type que especifica el protocol de nivell superior que s'està usant. Quan s'inicia la conexió, el nivell de registre encapsula un atre protocol, el protocol handshake (o protocol d'acort), que té el content_type 22. El client envia i rep vàries estructures handshake:

• Envia un mensage ClientHello especificant una llista de conjunt de sifrats, métodos de compressió i la versió del protocol SSL més alta permesa. Este també envia bytes aleatoris que seran usats més vesprada (cridats Challenge de Client o Repte). Ademés pot incloure l'identificador de la sessió.
• Despuix, rep un registre ServerHello, en el que el servidor elegix els paràmetros de conexió a partir de les opcions oferides en anterioritat pel client.

• Quan els paràmetros de la conexió són coneguts, client i servidor intercanvien certificats (depenent de les claus públiques de sifrat seleccionades). Estos certificats són actualment X.509, pero hi ha també un borrador especificant l'us de certificats basats en OpenPGP.
• Client i servidor negocien una clau secreta (simètrica) comuna cridada master secret, possiblement usant el resultat d'un intercanvi Diffie-Hellman, o simplement sifrant una clau secreta en una clau pública que és dessifrada en la clau privada de cada u. Totes les senyes de claus restants són derivats a partir d'este master secret (i els valors aleatoris generats en el client i el servidor), que són passats a través una funció pseudoaleatoria cuidadosadament elegida.

• TLS/SSL posseïxen una varietat de mides de seguritat:
• Numerant tots els registres i usant el número de seqüència en el MAC.

• Usant un resum de mensage millorat en una clau (de manera que solament en dita clau es puga comprovar el MAC). Açò s'especifica en el RFC 2104).
• Protecció contra varis atacs coneguts (incloent atacs man-in-the-middle), com els que impliquen un degradat del protocol a versions prèvies (per tant, menys segures), o conjunts de sifrats més dèbils.
• El mensage que finalisa el protocol handshake (Finished) envia un *# de totes les senyes intercanviades i vists per abdós parts.
• La funció pseudo aleatòria dividix les senyes d'entrada en 2 mitats i les processa en algoritmes *# diferents (MD5 i SHA), despuix realisa sobre ells una operació XOR. D'esta forma es protegix a sí mateixa de l'eventualitat de que algun d'estos algoritmes es revelen vulnerables en el futur.

Intercanvi de claus

Ans que un client i el servidor poden escomençar a intercanviar informació protegida per TLS, deuen intercanviar en forma segura o acordar una clau de sifrat i una clau per a usar quan se sifren les senyes (vore Sifrat). Entre els métodos utilisats per a l'intercanvi/acorde de claus són: les claus públiques i privades generades en RSA (denotat TLS_RSA en el protocol de handshake TLS), Diffie-Hellman (cridat TLS_DH), Diffie-Hellman efímer (denotat TLS_DHE), Diffie-Hellman de Curva Elíptica (denotat TLS_ECDH), Diffie-Hellman de Curva Elíptica efímer (TLS_ECDHE), Diffie-Hellman anònim (TLS_DH_anon), i PSK (TLS_PSK).

El método d'acort de claus TLS_DH_anon no verifica el servidor o l'usuari i per lo tant rara volta s'utilisa posat que és vulnerable a un atac de suplantació d'identitat. Solament TLS_DHE i TLS_ECDHE proporcionen secret-perfecte-cap a-avant. Els certificats de clau pública que s'utilisen durant l'intercanvi/acorde també varien en el tamany de les claus de sifrat públiques/privades utilisades durant l'intercanvi i, per tant, en la solidea de la seguritat que proveïxen. En juliol de 2013, Google va anunciar que deixaria d'utilisar claus públiques 1024 bits i canviaria a claus de 2048 bits per a aumentar la seguritat del sifrat TLS que proporciona als seus usuaris.

Autenticació i Intercanvi/acorde de claus

Algoritme	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Estatus
style="Parcial" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |		Definit per a TLS 1.2 en RFCs
style="Parcial" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |
style="Inclosa" |
style="Parcial" |	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |
style="Inclosa" |
style="Parcial" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |
style="Inclosa" |
style="Parcial" |	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |
style="Inclosa" |
style="No" |	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |
style="No" |	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |
style="Inclosa" |	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |		Propost en borradors RFC

Sifrat

Vore també: Sifrat per blocs

Seguritat del sifrat contra atacs coneguts

Sifrat			Versió del Protocol						Estat
Tipo	Algoritme	Fortalea nominal (bits)	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3>
Sifrat per blocs	AES GCM	256, 128	style="N/A" |	style="N/A" |	style="N/A" |	style="N/A" |	style="Sí" |	style="Sí" |	Definit per a TLS 1.2 en RFCs
	AES CCM		style="N/A" |	style="N/A" |	style="N/A" |	style="N/A" |	style="Sí" |	style="Sí" |
	AES CBC		style="N/A" |	style="N/A" |	style="pendent" |	style="pendent" |	style="pendent" |	style="N/A" |
	Camellia GCM	256, 128	style="N/A" |	style="N/A" |	style="N/A" |	style="N/A" |	style="Sí" |	style="N/A" |
	Camellia CBC		style="N/A" |	style="N/A" |	style="pendent" |	style="pendent" |	style="pendent" |	style="N/A" |
	ÀRIA GCM	256, 128	style="N/A" |	style="N/A" |	style="N/A" |	style="N/A" |	style="Sí" |	style="N/A" |
	ÀRIA CBC		style="N/A" |	style="N/A" |	style="pendent" |	style="pendent" |	style="pendent" |	style="N/A" |
	SEED CBC	128	style="N/A" |	style="N/A" |	style="pendent" |	style="pendent" |	style="pendent" |	style="N/A" |
	3DONES EDE CBC	112	style="No" |	style="No" |	style="No" |	style="No" |	style="No" |	style="N/A" |
	GOST 28147-89 CNT	256	style="N/A" |	style="N/A" |	style="No" |	style="No" |	style="No" |	style="N/A" |	Definit en IETF RFC 4357
	IDEA CBC	128	style="No" |	style="No" |	style="No" |	style="No" |	style="N/A" |	style="N/A" |	Retirat de TLS 1.2
	DONES CBC	56	style="No" |	style="No" |	style="No" |	style="No" |	style="N/A" |	style="N/A" |
		40	style="No" |	style="No" |	style="No" |	style="N/A" |	style="N/A" |	style="N/A" |	Prohibides en TLS 1.1 i posteriors
	RC2 CBC	40	style="No" |	style="No" |	style="No" |	style="N/A" |	style="N/A" |	style="N/A" |
Cifrador de fluix	ChaCha20+Poly1305	256	style="N/A" |	style="N/A" |	style="N/A" |	style="N/A" |	style="Sí" |	style="Sí" |	Definit per a TLS 1.2 en RFCs
	RC4	128	style="No" |	style="No" |	style="No" |	style="No" |	style="No" |	style="N/A" |	Prohibit per a totes les versions de TLS en RFC 7465
		40	style="No" |	style="No" |	style="No" |	style="N/A" |	style="N/A" |	style="N/A" |
Cap	Nul	–	style="N/A" |	style="No" |	style="No" |	style="No" |	style="No" |	style="N/A" |	Definit per a TLS 1.2 en els RFCs

Notes

Integritat de senyes

S'utilisa còdic d'autenticació de mensage (MAC, per message authentication code en anglés) per a assegurar l'integritat de les senyes. HMAC s'usa per al modo CBC de sifrat de blocs i sifrat de streams. AEAD és usat per al sifrat autenticado tals com els modos GCM i CCM.

Integritat de Senyes

Algoritme	SSL 2.0	SSL 3.0	TLS 1.0	TLS 1.1	TLS 1.2	TLS 1.3	Estatus
HMAC-MD5	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí" |		Definit per a TLS 1.2 en RFCs
HMAC-SHA1	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |	style="Sí"
HMAC-SHA256/384	style="No" |	style="No" |	style="No" |	style="No" |	style="Sí" |
AEAD	style="No" |	style="No" |	style="No" |	style="No" |	style="Sí" |
GOST 28147-89 IMIT	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |		Propost en borradors de RFC
GOST R 34.11-94	style="No" |	style="No" |	style="Sí" |	style="Sí" |	style="Sí" |

Aplicacions i adopció

SSL s'eixecuta en una capa entre els protocols d'aplicació com HTTP, SMTP, NNTP i sobre el protocol de transport TCP, que forma part de la família de protocols TCP/IP. Pot proporcionar seguritat a qualsevol protocol que use conexions de confiança (tal com TCP).

Llocs web

Un dels usos més importants és junt a HTTP per a formar HTTPS. HTTPS és usat per a assegurar pàgines World Wide Web per a aplicacions de comerç electrònic, utilisant certificats de clau pública per a verificar l'identitat dels extrems.

Soport de protocol de llocs web

Versió d'el Protocol	Soport en Llocs Web	Seguritat
SSL 2.0	16.6% (-2.8%)	style="No" |
SSL 3.0	60.6% (-37.4%)	style="No" |
TLS 1.0	99.5% (±0.2%)	style="pendent" |
TLS 1.1	45.4% (+3.4%)	style="pendent" |
TLS 1.2	48.1% (+3.8%)	style="pendent" |

Notes

Navegadors

Tots els navegadors importants soporten TLS:

Soport de TLS en navegadors

Navegador	Plataforma	TLS 1.0	TLS 1.1	TLS 1.2
Chrome 0–22	Linux, Mac VOS X, Windows (XP, Vista, 7, 8).	style="Sí" |	style="No" |	style="No" |
Chrome 22–29	Linux, Mac VOS X, Windows (XP, Vista, 7, 8)	style="Sí" |	style="Sí" |	style="No" |
Chrome 30-	Linux, Mac VOS X, Windows (XP, Vista, 7, 8)	style="Sí" |	style="Sí" |	style="Sí" |
Firefox 2–	Linux, Mac VOS X, Windows (XP, Vista, 7, 8	style="Sí" |	style="No" |	style="No" |
Firefox 27-	Linux, Mac VOS X, Windows (XP, Vista, 7, 8)	style="Sí" |	style="Sí" |	style="Sí" |
IE 1–7	Mac VOS X, Windows (XP, Vista, 7).	style="Sí" |	style="No" |	style="No" |
IE 8	Windows (XP, Vista)	style="Sí" |	style="No" |	style="No" |
IE 8–9	Windows 7	style="Sí" |	style="Parcial" |	style="Parcial" |
IE 9	Windows Vista	style="Sí" |	style="No" |	style="No" |
IE 10	Windows (7, 8)	style="Sí" |	style="Parcial" |	style="Parcial" |
IE 11	Windows (7, 8.1)	style="Sí" |	style="Sí" |	style="Sí" |
Opera 10–	Linux, Mac VOS X, Windows	style="Sí" |	style="Parcial" |	style="Parcial" |
Safari 5–6	Mac VOS X, Windows (XP, Vista, 7)	style="Sí" |	style="No" |	style="No" |
Safari 7	Mac VOS X 10.9	style="Sí" |	style="Sí" |	style="Sí" |
Mobile Safari/UIWebView	iOS 5.0+	style="Sí" |	style="Sí" |	style="Sí" |

Notes

Biblioteques

SSL i TLS han segut implementats àmpliament en varis proyectes de software obert i lliure. Els programadors poden usar les llibreries PolarSSL, CyaSSL, OpenSSL, MatrixSSL, NSS o GnuTLS per a tindre funcionalitat SSL/TLS.

• Microsoft Windows inclou una implementació de SSL i TLS com a part del seu paquet Secure Channel.
• VOS X inclou una implementació de SSL i TLS com a part del seu paquet Secure Transport.
• Els programadors de Delphi poden usar una llibreria anomenada Indy.
• OpenSSL és una implementació lliure. Té una llicència BSD en algunes extensions.
• GnuTLS és una implementació lliure, en llicència LGPL.
• Zodiac TLS/SSL: és una implementació per a Smalltalk en llicencia MIT.
• cryptlib és llibreria criptográfica potable de software obert (que inclou una implementació de SSL/TLS).
• JSSE: una implementació Java inclosa en el Java Runtime Environment que soporta TLS 1.1 i 1.2 des de Java 7, encara que està per defecte deshabilitada per al client i habilitada en el servidor.
• MatrixSSL: una implementació en llicència dual.

• Network Security Services (NSS): és una llibreria open source validada per a FIPS 140.
• PolarSSL és una implementació SSL/TLS molt chicoteta per a dispositius embebidos que està dissenyada per a us fàcil.
• CyaSSL és una llibreria SSL/TLS embebida en fort foc en velocitat i tamany. Un ensaig presentat en la conferència ACM 2012 de seguritat de computadors i comunicacions va mostrar que moltes aplicacions utilisaven estes llibreries incorrectament, duent a vulnerabilitat. Els autors feyen notar que "la causa principal de la majoria d'estes vulnerabilitat és el terrible disseny de les APIs per a les llibreries subjacents. En lloc d'expressar propietats de seguritat alt nivell per a túnels de ret tals com a confidencialitat i autenticació, estes API exponen detalls de baix nivell del protocol SSL als desenrolladors d'aplicacions. Com a conseqüència, els desenrolladors freqüentment usen les API de SSL incorrectament, malinterpretando i malentender els possibles paràmetros, opcions, efectes colaterals i valors de tornada".

Atres usos

Una atra aplicació en creixent us de TLS és SMTP. TLS és també el método estàndar per a protegir la senyalisació d'aplicacions en Session Initiation Protocol (SIP). TLS es pot utilisar per a proveir autenticació i sifrat a la senyalisació associada en VoIP i atres aplicacions basades en SIP. Encara que un número creixent de productes clients i servidors poden proporcionar SSL de forma nativa, molts encara no ho permeten. En estos casos, un usuari podria voler usar una aplicació SSL independent com Stunnel per a proporcionar sifrat. No obstant, l'Internet Engineering Task Force va recomanar en 1997 que els protocols d'aplicació oferiren una forma d'actualisar a TLS a partir d'una conexió sense sifrat (plaintext), en lloc d'usar un port diferent per a sifrar les comunicacions – açò evitaria l'us d'envoltura (wrappers) com Stunnel. SSL també pot ser usat per a tunelizar una ret completa i crear una ret privada virtual (VPN), com en el cas d'OpenVPN.

Seguritat

SSL 2.0

SSL 2.0 té una varietat de falles:

• Claus criptográficas idèntiques s'utilisen per a l'autenticació de mensages i el sifrat.
• SSL 2.0 té una construcció MAC dèbil que utilisa la funció *# MD5 en un prefix secret, per lo que és vulnerable als atacs d'extensió de llongitut.
• SSL 2.0 no té cap tipo de protecció per al handshake, és dir, un atac man-in-the-middle que es rebaixe a este protocol pot passar desapercebut.
• SSL 2.0 utilisa el tancament de la conexió TCP per a indicar el final de les senyes. Açò significa que els atacs de truncació són possibles: l'atacant simplement forja un TCP FI, deixant el receptor inconscient d'un fi illegítim de mensage de senyes (SSL 3.0 soluciona este problema en tindre una alerta de tancament explícita).
• SSL 2.0 assumix un sol servici i un certificat de domini fix, que choca en una funció estàndar de hosting virtual en els servidors Web. Açò significa que la majoria dels llocs web estan pràcticament afectats per l'us de SSL. SSL 2.0 està desactivat per defecte, a partir de: Internet Explorer 7, Mozilla Firefox 2, Opera 9.5, i Safari. En acabant de que s'envia un "ClientHello" TLS, si Mozilla Firefox comprova que el servidor no pot completar el handshake, intentarà tornar a caure a l'utilisació de SSL 3.0 en un SSL 3.0 "ClientHello" en format SSL 2.0 per a maximizar la provabilitat d'èxit del handshake en els servidors més antics. Permetre SSL 2.0 (i sistemes de sifrat dèbils de 40 i 56 bits), ha segut completament eliminat d'Opera des de la versió 10

SSL 3.0

SSL 3.0 va millorar SSL 2.0 per mig de l'adició de sifrat SHA-1 i soport per a autenticació de certificats. Des del punt de vista de seguritat, SSL 3.0 deuria considerar-se menys desijable que TLS 1.0. Les suites de sifrat de SSL 3.0 tenen un procés de derivació de claus dèbils, la mitat de la clau mestra que s'establix és totalment depenent de la funció *# MD5, que no és resistent als chocs i, per lo tant, no és considerat segur. Baix TLS 1.0, la clau mestra que s'establix depén tant MD5 i SHA-1 per lo que el seu procés de derivació no està actualment considerat dèbil. És per esta raó que les implementacions SSL 3.0 no poden ser validats baix FIPS 140-2.

Hi ha alguns atacs contra l'implementació en lloc del propi protocol: En les implementacions anteriors, algunes entitats emissores no varen establir explícitament basicConstraintsCA=False per als nodos full. Com a resultat, estos nodos full podien firmar certificats pirates. Ademés, alguns programes de (incloent IE6 i Konqueror) no va comprovar este camp per a res. Açò pot ser explotat en atacs man-in-the-middle a totes les possibles conexions SSL. Algunes implementacions (incloent versions anteriors de la API de sifrat de Microsoft, Network Security Services i GnuTLS) deixen de llegir els caràcters que seguixen al caràcter nul en el camp del nom del certificat, lo que pot ser explotat per a enganyar al client en la llectura del certificat com si fora originat en elloc autèntic. (Per eixemple, PayPal. com

TLS

• TLS té una varietat de mides de seguritat:
• Protecció contra una degradació del protocol a una versió anterior (menys segura) o un conjunt de sifrat més dèbil.
• Numeració dels registres d'aplicació posteriors en un número de seqüència i l'us d'este número de seqüència en els còdics d'autenticació de mensages (MAC).
• Usant un resum de mensage millorat en una clau (per lo que només una clau-sostenedor pot comprovar el MAC). La construcció HMAC utilisat per la majoria de les suites de sifrat TLS s'especifica en el RFC 2104 (SSL 3.0 utilisa un MAC basat en *# diferent).
• El mensage que finalisa el protocol d'enllaç ("Finalisar") envia un *# de tots els mensages intercanviats handshake vists per abdós parts.
• La funció pseudoaleatoria dividix les senyes d'entrada en un mig i processa cada u en un algoritme de *# diferent (MD5 i SHA-1), després els fa OR exclusiu junts per a crear el MAC. Açò proporciona protecció inclús si un d'estos algoritmes resulta ser vulnerable.

Atacs contra SSL/TLS

Els atacs més significatius es mencionen més avall:

Atac de renegociación

Una vulnerabilitat del procediment en el quala renegociación va ser descobert en agost de 2009, que pot conduir a atacs d'injecció de text pla contra SSL 3.0 i totes les versions actuals de TLS. Per eixemple, permet a un atacant que pot seqüestrar una conexió https per a empalmar les seues pròpies peticions en l'inici de la conversació que el client té en el servidor web. L'atacant no pot realment dessifrar la comunicació client-servidor, per lo que és diferent d'un típic atac man-in-the-middle. Una solució a curt determini és que els servidors d'Internet deixen de permetre la renegociación, que normalment no requerirà atres canvis a menos que s'utilise l'autenticació de certificats de client. Per a corregir la vulnerabilitat, una extensió de l'indicació de renegociación va ser proposta per a TLS. Es requerirà que el client i el servidor incloguen i verifiquen informació sobre els handshake anteriors en qualsevol renegociación de handshake. Esta extensió s'ha convertit en una norma proposta i se li ha assignat el número de RFC 5746. El RFC ha segut implementat per vàries biblioteques.

Atacs de reversión de versions

Hi ha modificacions als protocols originals, com False Start (aprovada i habilitada per Google Chrome) o Snap Start, en les que s'ha reportat que han introduït llimitacions als atacs de reversión de versions per a TLS o per a permetre que les modificacions de la llista de conjunt de sifrat enviada pel client al servidor (un atacant pot ser capaç d'influir en la selecció de la suite de sifrat en un intent de rebaixar l'intensitat de joc de sifrat, ya siga per a usar un algoritme de sifrat simètric més dèbil o d'un intercanvi de clau més dèbil). S'ha demostrat en la conferència sobre seguritat informàtica i de comunicacions de l'Association for Computing Machinery (ACM) que l'extensió False Start està en risc baix certes circumstàncies, lo que podria permetre a un atacant recuperar les claus de sifrat en llínea i accedir a les senyes sifrades.

Atac BEAST

El 23 de setembre de 2011, els investigadors Thai Duong i Juliano Rizzo varen demostrar una “prova de concepte“ anomenada BEAST ("Browser Exploit Against SSL/TLS") usant un applet Java per a violar restriccions de polítiques de mateix orige, per una vulnerabilitat de CBC àmpliament coneguda de TLS 1.0. Exploits pràctics d'esta vulnerabilitat no es coneixien, la qual va ser descoberta originalment per Phillip Rogaway en 2002.

Mozilla va actualisar les versions de desenroll de les seues llibreries NSS per a mitigar atacs de tipo BEAST. NSS és utilisat per Mozilla Firefox i per Google Chrome per a la seua implementació de SSL. Alguns servidors web que tenen una implementació quebrada de l'especificació SSL pot ser que deixen de funcionar com a resultat d'açò.

Microsoft va emetre el bolletí de seguritat MS12-006 el 12 de giner de 2012, que va corregir la vulnerabilitat BEAST en canviar la forma en que el component de Windows Secure Channel (SChannel) transmet els paquets sifrats. Per la seua banda, Apple va habilitar per defecte la protecció contra BEAST en la versió VOS X 10.9 Mavericks.

L'atac BEAST també es pot previndre eliminant tots els sifrats CBC de la llista de sifrats permesos, deixant solament el sifrat RC4, que és àmpliament soportat per la majoria dels llocs web. Els usuaris de Windows 7 i de Windows Server 2008 R2 poden permetre l'us de TLS 1.1 i 1.2, pero esta contramedida fallarà si no és soportat també per l'atre extrem de la conexió, i caurà a TLS 1.0.

Atacs CRIME i BREACH

Artícul principal → CRIME.

Els autors de l'atac BEAST també són els creadors de l'atac CRIME, que usa compressió de senyes per a endevinar. Quan s'utilisa per a recuperar el contingut de la cookie d'autenticació secreta, permet a un atacant realisar un seqüestre de sessió en una sessió web autenticada.

Atacs de farcidura

Les versions anteriors de TLS eren vulnerables front al atac de farcidura d'oràcul descobert en 2002. Una nova variant, cridada Atac Tretze en sòrt, va ser publicada en 2013. Fins a febrer de 2013, els implementadores de TLS estaven encara treballant en el desenroll de solucions per a la protecció contra esta forma d'atac. Una solució definitiva va ser llançada com l'extensió Encrypt-then-MAC per a TLS llançat com RFC 7366.

Atac POODLE

Artícul principal → Ataque POODLE.

El 14 d'octubre de 2014, investigadors de Google varen publicar una vulnerabilitat en el disseny de SSL 3.0, lo que fa que el modo CBC d'operació en SSL 3.0 siga vulnerable a l'atac de farcidura ([4]). Ells varen cridar a este atac POODLE (en anglés, Padding Oracle On Downgraded Legacy Encryption o Farcidura d'oràcul en Degradació a Sifrat Obsolet). En promig, els atacants solament necessiten fer 256 peticions SSL 3.0 per a revelar un byte de mensage sifrat.

Encara que esta vulnerabilitat solament existix en SSL 3.0 i la majoria dels clients i servidors admet TLS 1.0 i superiors, tots els principals navegadors rebaixen voluntàriament a SSL 3.0 si els handshake en les noves versions de TLS fallen a menos que proporcionen l'opció per a un usuari o administrador per a deshabilitar SSL 3.0 i l'usuari o l'administrador ho faça. Per lo tant, l'home-en-el-mig primer deu portar a terme un atac de rollback i després aprofitar esta vulnerabilitat.

En general, la degradació de la seguritat elegant pel be de la interoperabilidad és difícil portar a terme d'una manera que no puga ser explotada. Est és un repte especialment en els dominis a on la fragmentació és alta.

Ataque RC4

A pesar d'atacs existents sobre RC4 que ho trenquen, les suites de sifrat basades en RC4 en SSL i TLS varen ser considerades segurs en un moment per la forma en que el sistema de sifrat s'utilisava en estos protocols derrotava als atacs que trencaven RC4, fins que nous atacs divulgats en març de 2013 permetien que RC4 en TLS fora quebrat completament. En 2011 es recomanava usar la suite RC4 com una solució alternativa per a l'atac BEAST. En 2013 una vulnerabilitat va ser descoberta en RC4 sugerint que no era una bona solució per a BEAST. Un cas d'un atac va ser propost per Alfardan, Bernstein, Paterson, Poettering i Schuldt que utilisava nous biaix estadístics descoberts en la taula de clau RC4 per a recuperar parts del text en clar en un gran número de sifrats TLS. Un atac de biaix de doble byte en RC4 en TLS i SSL que requerix 13 × 220 sifrats per a trencar RC4 es va donar a conéixer el 8 de juliol de 2013, i va ser descrit com "viable" en la presentació d'acompanyament en el 22ndo Simpòsium USENIX de Seguritat el 15 d'agost de 2013.

No obstant, molts navegadors moderns han segut dissenyats per a derrotar els atacs BEAST (llevat Safari per a Mac VOS X 10.7 o versions anteriors, per a iOS 6 o anterior, i per a Windows; vore navegadors). Com a resultat, RC4 ya no és la millor opció per a TLS 1.0. Els sistemes de sifrat CBC que es varen vore afectats per l'atac BEAST en el passat s'estan convertint en una opció més popular per a la protecció.

Microsoft recomana deshabilitar RC4 quan siga possible.

Atac de truncació

Un atac de truncació TLS bloqueja les peticions de desconexió del conte de la víctima per a que l'usuari sense saber-ho, permaneixca conectat a un servici web. Quan s'envia la solicitut de fin de sessió, l'atacant injecta un mensage TCP FI no sifrat (no hi ha més senyes del remitent) per a tancar la conexió. El servidor, per tant, no rep la solicitut de tancament de sessió i no es dona conte de la terminació anormal.

Publicat en juliol de 2013, l'atac provoca servicis web com Gmail i Hotmail que mostren una pàgina que informa a l'usuari de que han eixit correctament del servici, a l'hora que garantisa que el navegador de l'usuari manté l'autorisació en el servici, lo que permet a un atacant tindre l'accés per a prendre el control del conte que ha iniciat sessió en l'usuari. L'atac no es basa en l'instalació de malware en l'ordenador de la víctima; els atacants solament necessiten posar-se entre la víctima i el servidor web (per eixemple, per mig de la creació d'un punt d'accés inalàmbric rebel). Esta vulnerabilitat també requerix accés a la computadora de la víctima.

Fallo Heartbleed

Artícul principal → Heartbleed.

El fallo Heartbleed és una greu vulnerabilitat en la popular llibreria de software criptográfica OpenSSL, que afecta a les versions 1.0.1 a 1.0.1f. Esta debilitat permet el robo de l'informació protegida, en condicions normals, pel sifrat SSL / TLS que s'utilisa per a assegurar les càrregues de senyes. SSL / TLS proporciona seguritat de les comunicacions i la privacitat a través d'Internet per a aplicacions com a web, correu electrònic, mensageria instantànea (IM) i algunes rets privades virtuals (VPN).

El fallo Heartbleed permet a qualsevol persona en Internet llegir la memòria dels sistemes protegits per les versions vulnerables del software OpenSSL. Açò compromet les claus secretes utilisades per a identificar els proveïdors de servicis i per a sifrar el tràfic, els noms i les contrasenyes dels usuaris i el contingut real. Açò permet als atacants espiar les comunicacions, furtar senyes directament dels servicis i dels usuaris i suplantar servicis i als usuaris.

Estudi de llocs web

A decembre de 2014, Trustworthy Internet Movement estima que la proporció de llocs web que són vulnerable a atacs TLS.

Estudi de les vulnerabilitats de TLS dels llocs web més populars

Atacs	Seguritat
	Insegur		Depén	Segur	Un atre
Ataque de Renegociación	style="N/A" |	style="No" |	style="Parcial" |	style="Sí" |	5.1% (−0.3%) sense soport
Ataque RC4	style="No" |	style="No" |	style="Parcial" |	style="Sí" |	style="No disponible" |
Atac BEAST (mitigat en el costat del client en navegadors moderns)	style="No disponible" |	style="No" |	style="No disponible" |	style="No disponible" |	style="No disponible" |
Atac CRIME	style="No disponible" |	style="No" |	style="No disponible" |	style="No disponible" |	style="No disponible" |
Heartbleed	style="No disponible" |	style="No" |	style="No disponible" |	style="No disponible" |	style="No disponible" |
Atac d'injecció ChangeCipherSpec	style="No disponible" |	style="No" |	style="Parcial" |	style="Sí" |	1.0% (+0.1%) desconegut
POODLE contra TLS (POODLE Original contra SSL 3.0 no està inclós)	style="No disponible" |	style="No" |	style="No disponible" |	style="Sí" |	1.6% desconegut

Forward secrecy

Artícul principal → Perfect forward secrecy.

Forward secrecy és una propietat dels sistemes criptográficos que garantisa que una clau de sessió derivada d'un conjunt de claus públiques i privades no es voran compromeses si una de les claus privades es veu compromesa en el futur. Sense forward secrecy, si la clau privada del servidor fora coneguda, no només es voran compromeses totes les sessions sifrades-TLS futures per mig d'eixe certificat del servidor, sino també les sessions anteriors que ho utilisaven (sempre per supost que estes sessions passades anaren interceptades i almagasenades en el moment de la transmissió). Una implementació de TLS pot proporcionar forward secrecy en exigir l'us d'intercanvie de claus Diffie-Hellman efímeres per a establir claus de sessió, i algunes implementacions TLS notables ho fan exclusivament: per eixemple, Gmail i atres servicis de Google que utilisen HTTPS OpenSSL. No obstant, molts clients i servidors que soporten TLS (inclosos els navegadors i servidors web) no estan configurats per a aplicar eixes restriccions. En la pràctica, a menos que un servici web utilise Diffie-Hellman per a implementar forward secrecy, tot el tràfic web sifrat cap a i des d'eixe servici pot ser dessifrat per un tercer si obté la clau mestra del servidor (privat); per eixemple, per mig d'una orde judicial.

Inclús quan s'implementa l'intercanvi de claus Diffie-Hellman, els mecanismes de gestió de sessió en el servidor poden afectar el forward secrecy. L'us de tiquets de sessió TLS (una extensió TLS) fa que la sessió es dega protegir per AES128-CBC-SHA256 independentment de qualsevol atre paràmetro TLS negociats, incloent als conjunts de sifrat de forward secrecy, i les claus dels tiquets de sessió de llarga duració TLS estropegen l'intent d'implementar forward secrecy.

Des de finals de 2011, Google ha proporcionat forward secrecy en TLS per omissió per als usuaris del seu servici de Gmail, junt en Google Docs i busca sifrada, entre atres servicis. Des de novembre de 2013, Twitter ha proporcionat forward secrecy en TLS per als usuaris del seu servici. A decembre de 2014, el 20,0% dels llocs web habilitats per a TLS estan configurats per a utilisar conjunts de sifrat que proporcionen forward secrecy als navegadors web.

Evitar Triple-DONES CBC

Alguns experts recomanen evitar Triple-DONES CBC. Degut a que RC4 i Triple-DONES són els últims sifrats soportats en les biblioteques SSL/TLS de Windows XP, fa que siga difícil soportar SSL per a programes que utilisen esta biblioteca en Windows XP. Per eixemple en el cas d'Internet Explorer per a Windows XP.

Fer front als atacs MITM

Artícul principal → Ataque Man-in-the-middle.

Fixació de Certificats

Una forma de detectar i bloquejar molts tipos d'atacs MITM és "fixar el certificat", a voltes cridat "fixació SSL".

Un client que fa fixació de certificat agrega un pas adicional per al protocol SSL o protocol TLS habitual: Despuix d'obtindre el certificat del servidor en la forma estàndar, el client comprova el certificat del servidor en les senyes de confiança per a validació. Normalment les senyes de validació de confiança s'inclou en l'aplicació, en la forma d'una còpia de confiança de dit certificat, o un *# de confiança o chafada digital del certificat o la clau pública del certificat. Per eixemple, el Chromium i Google Chrome inclouen senyes de validació per al certificat *. google. com que detecta certificats fraudulents en 2011. Des de llavors, Mozilla ha introduït fixació de certificats públics en el seu navegador Firefox.

En atres sistemes que el client espera que la primera volta que obtinga el certificat d'un servidor és de confiança i l'almagasena; durant les sessions posteriors en eixe servidor, el client comprova el certificat del servidor contra el certificat almagasenat per a protegir-se dels atacs MITM posteriors.

Proyecte Perspectives

El Proyecte Perspectives opera notaris de ret que els clients poden usar per a detectar si el certificat d'un lloc ha canviat. Per la seua naturalea, els atacs man-in-the-middle coloquen a l'atacant entre el destí i un sol objectiu específic. Com a tal, Perspectives advertirien a l'objectiu de que el certificat entregat al navegador web no coincidix en el certificat vist des d'atres perspectives - les perspectives d'atres usuaris en diferents moments i llocs. L'us de notaris de ret des d'una multitut de perspectives fa possible que un objectiu detecte un atac inclús si un certificat sembla ser completament vàlit.

Detalls del Protocol

El protocol TLS intercanvia registres- els que encapsulan les senyes que s'intercanvien en un format específic (vore més avall). Cada registre pot ser comprimit, sifrat i empaquetat en un còdic de MAC (Còdic d'Autenticació del Mensage), tot depenent de l'estat de la conexió. Cada registre té un camp de tipo de contingut que designa el tipo de senyes encapsulados, un camp de llongitut i un camp de versió TLS. Les senyes encapsulados poden ser mensages de control o de procediment de la pròpia TLS, o simplement les senyes de les aplicacions que necessiten ser transferits per TLS. Les especificacions (suite de sifrat, claus, etc.) necessaris per a l'intercanvi de senyes de l'aplicació per TLS, s'han acordat en el "handshake TLS" entre el client que solicita les senyes i el servidor que respon a les solicituts. Per tant, el protocol definix tant l'estructura de càrregues útils transferits en TLS i el procediment per a establir i supervisar la transferència.

Handshake TLS

Quan s'inicia la conexió, el registre encapsula un protocol de "control"- el protocol de mensageria de handshake (contingut de tipo 22). Este protocol s'utilisa per a l'intercanvi de tota l'informació requerida per les dos parts per a l'intercanvi de les senyes de les aplicacions reals per TLS. En ell es definixen els mensages de format o que continguen esta informació i l'orde del seu intercanvi. Estos poden variar en funció de les demandes del client i del servidor, és dir, existixen varis procediments possibles per a establir la conexió. Este intercanvi inicial resulta en una conexió exitosa TLS (abdós parts llestes per a transferir senyes de l'aplicació en TLS) o un mensage d'alerta (com s'especifica més alvance).

Handshake bàsic

A continuació, un eixemple simple de conexió, que ilustra un handshake en el que el servidor (pero no el client) és autenticado pel seu certificat:

1. Fase de negociació:
   • Un client envia un mensage ClientHello especificant la versió més alta de protocol TLS que soporta, un número a l'encert, una llista de conjunts de sifrat sugerides i métodos de compressió sugerits. Si el client està intentant realisar un handshake recomençat, pot enviar un ANEU de sessió.
   • El servidor respon en un mensage ServerHello, que conté la versió del protocol elegit, un número aleatori, CipherSuite i método de compressió de les opcions oferides pel client. Per a confirmar o permetre handshake recomençat el servidor pot enviar un ANEU de sessió. La versió del protocol elegit deu ser el més alt que tant el soport de client i servidor. Per eixemple, si el client és compatible en la versió 1.1 i el servidor és compatible en la versió 1.2, la versió 1.1 es deu seleccionar; 1.0 no es deu seleccionar.

1. • El servidor envia el seu mensage de certificat (depenent de la suite de sifrat seleccionat, açò pot ser omés pel servidor).
   • El servidor envia el seu mensage ServerKeyExchange (en funció del conjunt de sifrat seleccionat, açò pot ser omés pel servidor). Este mensage s'envia a tots els conjunts de sifrat DHE i DH_anon.
   • El servidor envia un mensage ServerHelloDone, lo que indica que va terminar en la negociació del handshake.
   • El client respon en un mensage ClientKeyExchange, que pot contindre una PreMasterSecret, la clau pública, o res. (Una volta més, açò depén de la sifra seleccionada.) Esta PreMasterSecret se sifra utilisant la clau pública del certificat del servidor.

1. • El client i el servidor a continuació utilisen els números aleatoris i PreMasterSecret per a calcular un secret comú, cridat el "secret principal" (master secret). Tots els demés senyes clau per a esta conexió es deriva d'este secret principal (i els valors aleatoris generats tant per client i per servidor), que es passen a través d'una funció pseudoaleatoria cuidadosadament dissenyat.
2. El client ara envia un registre ChangeCipherSpec, essencialment dient al servidor, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrada si els paràmetros de sifrat estaven presents en el certificat del servidor)." El ChangeCipherSpec és en sí mateixa un protocol a nivell de registre en el tipo de contingut 20.
   • Per últim, el client envia un mensage autenticado i sifrat de Finished (terminat), que conté un *# i MAC sobre els mensages de handshake anteriors.
   • El servidor intentarà dessifrar el mensage Finished del client i verificar el *# i MAC. Si el dessifrat o verificació falla, el handshake es considera que ha fracassat i la conexió deu ser derribada.

1. Per últim, el servidor envia un ChangeCipherSpec, dient-li al client, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrat, si el sifrat es va negociar)."
   • El servidor envia el seu mensage Finished autenticado i sifrat.
   • El client realisa el mateix dessifrat i verificació.
2. Fase d'aplicació: en este punt, el "handshake" està completat i el protocol d'aplicació està activada, en el tipo de contingut de 23. Els mensages d'aplicació intercanviats entre el client i el servidor també seran autenticados i opcionalmente sifrats exactament igual que en el seu mensage final. De lo contrari, el tipo de contingut contestarà 25 i el client no va serà autenticado.

Handshake TLS autenticado pel client

El següent eixemple complet mostra un client sent autenticado (ademés del servidor com el de més dalt) a través de TLS per mig de certificats intercanviats entre abdós interlocutors.

1. Fase de Negociació:
   • Un client envia un mensage ClientHello especificant la versió més alta de protocol TLS que soporta, un número a l'encert, una llista de conjunts de sifrat sugerits i métodos de compressió.
   • El servidor respon en un mensage ServerHello, que conté la versió elegida del protocol, un número a l'encert, una suite de sifrat i el método de compressió de les opcions oferides pel client. El servidor també pot enviar un identificador de sessió com a part del mensage per a realisar un handshake recomençat.
   • El servidor envia el seu mensage de certificats (depenent de la suite de sifrat seleccionat, açò pot ser omés pel servidor).
   • El servidor envia el seu mensage ServerKeyExchange (en funció del conjunt de sifrat seleccionat, açò pot ser omés pel servidor). Este mensage s'envia a tots els conjunts de sifrat DHE i DH_anon.

1. • El servidor solicita un certificat des del client, de modo que la conexió puga ser mútuament autenticada, utilisant un mensage CertificateRequest.
   • El servidor envia un mensage ServerHelloDone, lo que indica que va terminar en la negociació handshake.
   • El client respon en un mensage de certificat, que conté el certificat del client.
   • El client envia un mensage ClientKeyExchange, que pot contindre un PreMasterSecret, clau pública, o res. (Una volta més, açò depén del sifrat seleccionat.) Esta PreMasterSecret se sifra utilisant la clau pública del certificat del servidor.
   • El client envia un mensage CertificateVerify, que és una firma en els mensages de reconeiximent anteriors utilisant la clau privada del certificat del client. Esta firma pot ser verificada utilisant la clau pública del certificat del client. Açò permet al servidor saber que el client té accés a la clau privada del certificat i per lo tant posseïx el certificat.

1. • El client i el servidor a continuació, utilisen els números aleatoris i PreMasterSecret per a calcular un secret comú, cridat el "secret principal". Tots els demés senyes clau per a esta conexió es deriven d'este secret mestre (i els valors aleatoris client-i generats pel servidor), que es passa a través d'una funció pseudoaleatoria cuidadosadament dissenyada.
2. El client ara envia un registre ChangeCipherSpec, essencialment dient al servidor, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrada si el sifrat es va negociar)." El ChangeCipherSpec és en sí mateixa un protocol a nivell de registre i és tipo 20 i no 22.
   • Per últim, el client envia un mensage sifrat de Finished, que conté un *# i MAC sobre els mensages de handshake anteriors.
   • El servidor intentarà dessifrar el mensage final del client i verificar el *# i MAC. Si el dessifrat o verificació falla, el handshake es considera que ha fracassat i la conexió deu ser derribada.

1. Per últim, el servidor envia un ChangeCipherSpec, dient-li al client, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrada si el sifrat es va negociar)."
   • El servidor envia el seu propi mensage sifrat de Finished.
   • El client realisa el mateix dessifrat i verificació.
2. Fase d'aplicació: en este punt, el "handshake" està completat i el protocol d'aplicació està activat, en el tipo de contingut 23. Els mensages de l'aplicació intercanviats entre el client i el servidor també seran sifrats exactament igual que en el seu mensage Finished.

Handshake recomençat

Les operacions de clau pública (per eixemple, RSA) són relativament costoses en térmens de càlcul computacional. TLS proporciona un accés directe segur en el mecanisme de handshake per a evitar estes operacions: recomençar sessions. Les sessions recomençades s'implementen utilisant els identificadors (IDs) de sessió o tiquets de sessió. Aparte de la ventaja de rendiment, recomençant les sessions també es pot utilisar per a inicie de sessió únic, ya que es garantisa que tant la sessió original, aixina com qualsevol sessions recomençada s'originen des del mateix client. Açò és de particular importància per al FTP sobre el protocol TLS/SSL, ya que de lo contrari podria sofrir d'un atac man-in-the-middle en el que un atacant podria interceptar el contingut de les conexions de senyes secundàries.

IDs de sessió

En un handshake normal complet, el servidor envia un ANEU de sessió com a part del mensage ServerHello. El client associa est ANEU de sessió en la direcció IP del servidor i el port TCP, per a que quan el client es conecte de nou a eixe servidor, pot utilisar el ANEU de sessió per a acurtar el handshake. En el servidor, el ANEU de sessió s'assigna als paràmetros criptográficos negociats anteriorment, específicament el "secret mestre". Abdós parts deuen tindre el mateix "secret mestre" o el handshake recomençat fallarà (açò evita que un espia utilise un ANEU de sessió). Les senyes aleatòries en els mensages ClientHello i ServerHello pràcticament garantisen que les claus de conexió generades seran diferents de la conexió anterior. En les RFC, este tipo de handshake es diu un protocol d'enllaç abreviat. També es descriu en la lliteratura com un reinicie de handshake.

1. Fase de Negociació:

1. • Un client envia un mensage ClientHello especificant la versió més alta de protocol TLS que soporta, un número a l'encert, una llista de conjunts de sifrat sugerits i métodos de compressió. Inclou en el mensage l'ANEU de sessió de la conexió TLS prèvia.
   • El servidor respon en un mensage ServerHello, que conté la versió elegida del protocol, un número a l'encert, una suite de sifrat i el método de compressió de les opcions oferides pel client. Si el servidor reconeix el ANEU de sessió, respon en la mateixa ANEU de sessió. El client usa açò per a reconéixer que s'està portant a terme una sessió recomençada. Si el servidor no reconeix el ANEU de sessió enviat pel client, respon en un valor diferent per a la ANEU de sessió, lo que li diu al client que no es portarà a terme un recomençament de sessió. En este punt, tant el client com el servidor tenen el "secret mestre" i senyes aleatòries per a generar la clau usada per a esta conexió.
2. El servidor envia un ChangeCipherSpec, dient-li al client, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrada si el sifrat es va negociar)."

1. • Per últim, el servidor envia un mensage sifrat de Finished, que conté un *# i MAC sobre els mensages de handshake anteriors.
   • El client realisa el mateix dessifrat i verificació.
2. El client ara envia un registre ChangeCipherSpec, essencialment dient al servidor, "Tot lo que yo et diga d'ara en avant serà autenticado (i sifrada si el sifrat es va negociar)."
   • El client envia el seu propi mensage sifrat de Finished.
   • El servidor intentarà dessifrar el mensage final del client i verificar el *# i MAC.
3. Fase d'aplicació: en este punt, el "handshake" està completat i el protocol d'aplicació està activat, en el tipo de contingut 23. Els mensages de l'aplicació intercanviats entre el client i el servidor també seran sifrats exactament igual que en el seu mensage Finished.

Tiquets de sessió

El RFC 5077 estén TLS a través de l'utilisació de tiquets de sessió, en lloc dels IDs de sessió. Definix una forma de recomençar una sessió TLS sense necessitat d'almagasenar l'estat específic de la sessió en el servidor TLS. En utilisar tiquets de sessió, el servidor TLS almagasena el seu estat específic de la sessió en un tiquet de sessió i envia el tiquet de sessió al client TLS per a ser almagasenat. El client es recomença una sessió TLS per mig de l'enviament del tiquet de sessió al servidor, i el servidor recomença la sessió TLS en l'estat específic de la sessió en el tiquet. El tiquet de sessió està sifrat i autenticada pel servidor, i el servidor verifica la seua validea abans d'utilisar el seu contingut. Una debilitat particular d'este método en OpenSSL és que sempre llimita el sifrat i l'autenticació de seguritat del tiquet de sessió TLS transmés a AES128-CBC-SHA256, no importa qué atres paràmetros TLS siguen negociats per a la sessió actual TLS. Açò significa que l'informació d'estat (el tiquet de sessió TLS) no està tan ben protegit com la sessió TLS mateixa. De particular preocupació és l'almagasenament d'OpenSSL de les claus en un context d'aplicació (SSL_CCH), és dir, que es manté durant la duració de l'aplicació, i no permet el reingrés d'informació dels tiquets de sessió AES128-CBC-SHA256 TLS sense reiniciar el context a nivell d'aplicació OpenSSL (lo que és rar, propens a errors i a sovint requerix intervenció administrativa manual).

Registre TLS

Est és el format general per a tots els registres TLS.

+	Byte +0								Byte +1								Byte +2								Byte +3
Byte 0	Tipo de Contingut
Bytes 1..4	Versió																Llongitut
	(Major)								(Minor)								(bits 15..8)								(bits 7..0)
Bytes 5..(m-1)	Mensage(s) del Protocol
Bytes m..(p-1)	MAC (opcional)
Bytes p..(q-1)	Farcidura (sifrats de bloc solament)

Tipo de Contingut

Este camp identifica el Tipo de Capa de Registre del Protocol contingut en este registre.

Tipos de Contingut

Hex	Dec	Tipo
0x14	20	ChangeCipherSpec
0x15	21	Alerta
0x16	22	Handshake
0x17	23	Aplicació
0x18	24	Heartbeat

Versió

Este camp identifica la versió major i menor de TLS per al mensage contingut. Per a un mensage ClientHello, açò no té per qué ser la versió més alta admesa pel client.

Versions

Versió Major	Versió Menor	Tipo de Versió
3	0	SSL 3.0
3	1	TLS 1.0
3	2	TLS 1.1
3	3	TLS 1.2

Llongitut

La llongitut del mensage del Protocol (s), MAC i Farcidura, que no excedixca de 214 bytes (16 KiB).

Protocol del Mensage

Un o més mensages identificats pel camp Protocol. Tinga en conte que este camp pot ser sifrat depenent de l'estat de la conexió.

MAC i Farcidura

Un còdic d'autenticació de mensage calculat sobre el mensage del Protocol, en el material clau adicional inclós. Tinga en conte que este camp pot ser codificat, o no inclosos en la seua totalitat, depenent de l'estat de la conexió.

No MAC o farcidura poden estar presents al final dels registres TLS abans de tots els algoritmes de sifrat i paràmetros han segut negociats i handshaked i després confirmat per l'enviament d'un registre CipherStateChange (vore més avall) per a la senyalisació d'estos paràmetros tindran efecte en tots els registres adicionals enviats pel mateixa parells.

Protocol de handshake

La majoria dels mensages intercanviats durant la configuració de la sessió TLS es basen en este registre, a menos que un error o advertència es produïxca i necessite ser senyalat per un registre de protocol d'alerta (vore més avall), o el modo de sifrat de la sessió és modificat per un atre récort (vejau el protocol ChangeCipherSpec avall).

+	Byte +0								Byte +1								Byte +2								Byte +3
Byte 0	22
Bytes 1..4	Versió																Llongitut
	(Major)								(Menor)								(bits 15..8)								(bits 7..0)
Bytes 5..8	Tipo de Mensage								Llarc de les senyes del mensage d'handshake
									(bits 23..16)								(bits 15..8)								(bits 7..0)
Bytes 9..(n-1)	Senyes del mensage d'handshake
Bytes n..(n+3)	Tipo de Mensage								Llarc de les senyes del mensage d'handshake
									(bits 23..16)								(bits 15..8)								(bits 7..0)
Bytes (n+4)..	Senyes del mensage d'handshake

Tipo de Mensage

Este camp identifica el tipo de mensage del handshake.

Message Types
Còdic	Descripció
0	HelloRequest
1	ClientHello
2	ServerHello
4	NewSessionTicket
11	Certificate
12	ServerKeyExchange
13	CertificateRequest
14	ServerHelloDone
15	CertificateVerify
16	ClientKeyExchange
20	Finished

Llongitut de senyes de mensages d'handshake

Est és un camp de 3 bytes que indica la llongitut de les senyes d'handshake, no incloent la capçalera. Tinga en conte que varis mensages de handshake es poden combinar dins d'un registre.

Protocol d'alertes

Este registre no deuria enviar-se normalment durant els intercanvis de protocol d'enllaç o d'aplicació normals. No obstant, este mensage pot ser enviat en qualsevol moment durant el handshake i fins al tancament de la sessió. Si açò s'utilisa per a senyalar un error fatal, la sessió es tancarà immediatament despuix d'enviar este registre, per lo que este registre s'utilisa per a donar la raó d'este tancament. Si el nivell d'alerta es marca com una advertència, l'equip remot pot decidir tancar la sessió si decidix que la sessió no és lo suficientment confiable per a les seues necessitats (abans de fer-ho, el remot també pot enviar la seua pròpia senyal).

+	Byte +0								Byte +1								Byte +2								Byte +3
Byte 0	21
Bytes 1..4	Versió																Llarc
	(Major)								(Menor)								0								2
Bytes 5..6	Nivell								Descripció
Bytes 7..(p-1)	MAC (opcional)
Bytes p..(q-1)	Farcidura (solament en sifrat de blocs)

Nivell

Este camp identifica el nivell d'alerta. Si el nivell és fatal, el remitent deu tancar la sessió immediatament. De lo contrari, el destinatari pot decidir terminar la sessió, per mig de l'enviament de la seua pròpia alerta fatal i tancament de la sessió mateixa immediatament despuix d'enviar-ho. L'us de registres d'alerta és opcional, no obstant si no es troba abans del tancament de sessió, la sessió pot recomençar-se automàticament (en les seues handshake).

El tancament normal de la sessió despuix de la terminació de l'aplicació transportada deu ser alertat preferiblement en a lo manco el tipo d'alerta Close notify (en un nivell d'avís senzill) per a evitar que la nova sessió puga ser recomençada. La senyalisació explícita del tancament normal d'una sessió segura abans de tancar de manera efectiva la seua capa de transport és útil per a previndre o detectar els atacs (com els intents de truncar les senyes transportades de forma segura, si és que intrínsecament no té una llongitut predeterminada o duració que el destinatari de les senyes pot esperar).

Tipos de Nivell d'Alerta

Còdic	Tipo de Nivell	Estat de Conexió
1	advertència	la conexió o la seguritat pot ser inestable.
2	fatal	la conexió o la seguritat pot estar compromesa, o un error irrecuperable ha ocorregut.

Descripció

Este camp identifica com tipo d'alerta està sent enviada.

Descripció de tipos d'Alertes

Còdic	Descripció	Tipos del Nivell	Notes
0	Notificació de Tancament	advertència/fatal
10	Mensage Inesperat	fatal
20	Mal registre MAC	fatal	Possiblement una mala implementació de SSL, o la càrrega útil ha segut modificada en i. i. regla FTP d'un firewall en un servidor FTPS.
21	Falla en Dessifrat	fatal	solament TLS, reservat
22	Desbordament de Registre	fatal	solament TLS
30	Falla de Descompressió	fatal
40	Falla de handshake	fatal
41	Sense certificat	advertència/fatal	Solament SSL 3.0, reservat
42	Certificat mal	advertència/fatal
43	Certificat no soportat	advertència/fatal	per ej. el certificat té habilitat sol us com a autenticació de servidor i es presenta com a certificat de client
44	Certificat revocat	advertència/fatal
45	Certificat expirat	advertència/fatal	Revisar certificat del servidor expirat també revisar que algun certificat presentat en la cadena ha expirat
46	Certificat desconegut	advertència/fatal
47	paràmetro illegal	fatal
48	CA (Autoritat de certificació) desconeguda	fatal	solament TLS
49	Accés denegat	fatal	solament TLS – per ej. no s'ha presentat un certificat de client (TLS: mensage de certificat en blanc o SSLv3: alerta de "No Certificat"), pero el servidor està configurat per a requerir un.
50	error de decodificació	fatal	solament TLS
51	error de dessifrat	advertència/fatal	solament TLS
60	Restricció d'exportació	fatal	solament TLS, reservat
70	Versió de Protocol	fatal	solament TLS
71	Seguritat Insuficient	fatal	solament TLS
80	Error Intern	fatal	solament TLS
90	Cancelat per l'Usuari	fatal	solament TLS
100	No renegociación	advertència	solament TLS
110	Extensió No Soportada	advertència	solament TLS
111	Certificat no Obtenible	advertència	solament TLS
112	Nom No Reconegut	advertència/fatal	solament TLS; l'Indicador de nom del servidor del client especifica un host no soportat pel servidor
113	Resposta de Mal Certificat	fatal	solament TLS
114	Valor de *# de Mal Certificat	fatal	solament TLS
115	Identitat PSK desconeguda (usat en TLS-PSK i TLS-SRP)	fatal	solament TLS
120	Sense Protocol d'Aplicació	fatal	solament TLS, el ALPN del client ALPN no conté cap protocol soportat pel servidor.

Protocol ChangeCipherSpec

+	Byte +0								Byte +1								Byte +2								Byte +3
Byte 0	20
Bytes 1..4	Versió																Llarc
	(Major)								(Menor)								0								1
Byte 5	Tipo de Protocol CCS

Tipo de Protocol CCS

Actualment solament 1.

Protocol d'aplicació

+	Byte +0								Byte +1								Byte +2								Byte +3
Byte 0	23
Bytes 1..4	Versió																Llarc
	(Major)								(Menor)								(bits 15..8)								(bits 7..0)
Bytes 5..(m-1)	Senyes d'Aplicació
Bytes m..(p-1)	MAC (opcional)
Bytes p..(q-1)	Farcidura (solament sifrat de blocs)

Llarc

Llarc de les senyes de l'aplicació (excloent l'encapçalat del protocol i incloent el final de MAC i farcidura)

MAC

20 bytes per al HMAC basat en SHA-1, 16 bytes per al HMAC basat en MD5.

Farcidura

Llarc variable; l'últim byte conté ellarc de la farcidura.

Soport per a servidors virtuals per nom

Des del punt de vista del protocol d'aplicacions, TLS pertany a una capa baixa, encara que el model TCP/IP és molt gros per a mostrar-ho. Açò significa que el handshake és usualment (llevat en el cas STARTTLS) portat a terme ans que el protocol d'aplicació puga començar. La funcionalitat de servidor virtual basat en noms és proveïda per la capa d'aplicació, a on tots els servidors virtuals estajats en una mateixa màquina compartixen el mateix certificat. Açò és un problema, ya que el servidor deu seleccionar i manar el certificat immediatament despuix del mensage de ClientHello. Est és un gran problema en els ambients d'estage, ya que implica que tots els clients en un mateix servidor deuen compartir el certificat o es deu utilisar una IP distinta per a cada u d'ells. Hi ha dos formes conegudes d'evitar açò, proveïdes per X.509:

• Si tots els servidors virtuals pertanyen al mateix domini, es pot utilisar un certificat comodí. Ademés de que podria ser un problema la selecció àmplia d'host ame, no hi ha acort en cóm emparellar certificats wildcard. S'apliquen regles diferents depenent del protocol d'aplicació o del software usat.
• Agregar cada host virtual en l'extensió subjectAltName. El problema major d'açò és que el certificat necessita ser remés cada volta que s'agrega un nou servidor. En orden a proveir el nom del servidor, la RFC 4366 Transport Layer Security (TLS) Extensions permeten al client incloure una extensió d'Indicació de nom de servidor (Server Name Indication o SNI) en el mensage estés ClientHello. Esta extensió immediatament li dona pistes al servidor respecte de quin nom és al que el client es vol conectar, per lo que el servidor pot seleccionar el certificat apropiat per a enviar al client.

Estàndarts

TLS 1.0

Les extensions a TLS 1.0 inclouen:

• RFC 2595: “Using TLS with IMAP, POP3 and ACAP”. Especifica una extensió als servicis IMAP, POP3 i ACAP que permeten a client i servidor usar seguritat en la capa de transport per a entregar comunicacions privades i autenticades sobre Internet.
• RFC 2712: "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". Les famílies de sifrats de 40-bit definides en este memo apareixen només per a propòsits de documentació del fet de que eixes famílies de còdics de sifrat han segut ya assignades.
• RFC 2817: "Upgrading to TLS Within HTTP/1.1", explica cóm usar el mecanisme Upgrade en HTTP/1.1 per a iniciar TLS sobre una conexió TCP existent. Açò permet al tràfic HTTP insegur i segur compartir el mateix port conegut (en este cas, http: en el 80 en lloc d'https: en el 443).
• RFC 2818: "HTTP Over TLS", diferencia tràfic segur de tràfic insegur per mig de l'us d'un 'port de servidor' diferent.

• RFC 3207: “SMTP Service Extension for Secure SMTP over Transport Layer Security”. Especifca una extensió al servici SMTP que permeten a client i servidor SMTP usar seguritat en la capa de transport per a entregar comunicacions privades i autenticades sobre Internet.
• RFC 3268: "AES Ciphersuites for TLS". Afig la família de sifrat AES als sifrats simètrics prèviament existents.
• RFC 3546: "Transport Layer Security (TLS) Extensions", afig un mecanisme per a negociar extensions de protocols durant la inicialización de sessió i definix algunes extensions.
• RFC 3749: “Transport Layer Security Protocol Compression Methods”, especifica el marc per als métodos de compressió i per al método DEFLATE.
• RFC 3943: “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”.
• RFC 4132: “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4162: “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”.
• RFC 4217: “Securing FTP with TLS”.

• RFC 4279: "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", afig tres conjunts de noves famílies de sifrats per a que el protocol TLS permeta l'autenticació basada en claus prèviament compartides.

TLS 1.1

Les extensions a TLS 1.1 inclouen:

• RFC 4347: “Datagram Transport Layer Security” especifica una variant de TLS que funciona sobre protocols de datagrama (tals com UDP).
• RFC 4366: “Transport Layer Security (TLS) Extensions” descriu tant un set d'extensions específiques i un mecanisme d'extensions genèriques.
• RFC 4492: “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”.
• RFC 4507: “Transport Layer Security (TLS) Session Resumption without Server-Side State”.
• RFC 4680: “TLS Handshake Message for Supplemental Data”.
• RFC 4681: “TLS User Mapping Extension”.
• RFC 4785: “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”.
• RFC 5054: “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”. Definix les cihpersuites TLS-SRP.
• RFC 5081: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, obsoleta despuix del RFC 6091.

TLS 1.2

La versió actual aprovada de TLS és la 1.2, la que s'especifica en:

• RFC 5246: “The Transport Layer Security (TLS) Protocol Version 1.2”. L'estàndart actual reemplaça a les versions més antigues, les que són considerades obsoletes:
• RFC 2246: “The TLS Protocol Version 1.0”.
• RFC 4346: “The Transport Layer Security (TLS) Protocol Version 1.1”. aixina com el mai estandardisat SSL 3.0:
• RFC 6101: “The Secure Sockets Layer (SSL) Protocol Version 3.0”. Uns atres RFC posteriors varen estendre TLS. Les extensions a TLS 1.2 inclouen:
• RFC 5746: “Transport Layer Security (TLS) Renegotiation Indication Extension”.
• RFC 5878: “Transport Layer Security (TLS) Authorization Extensions”.
• RFC 6091: “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication“.
• RFC 6176: “Prohibiting Secure Sockets Layer (SSL) Version 2.0”.
• RFC 6209: “Addition of the ÀRIA Cipher Suites to Transport Layer Security (TLS)”.

TLS 1.3

• RFC 8446,en inglés: The Transport Layer Security (TLS) Protocol Version 1.3.

Encapsulación

Les encapsulación de TLS inclouen:

• RFC 5216: "The EAP-TLS Authentication Protocol"

Vore també

• Datagram Transport Layer Security
• HTTPS
• X.509
• Wireless Transport Layer Security
• Heartbleed
• Network Security Services] (NSS)

Bibliografia

• Wagner, David i Bruce Schneier, «Analysis of the SSL 3.0 Protocol», The Second USENIX Workshop on Electronic Commerce Proceedings, USENIX Press, November 1996, pp. 29-40.

Enllaços externs

• Centre d'informació de SSL
• [5] (en anglés)
• generació de CSR
• [6]
• [7]
• [8] Instructius d'instalació de Certificats SSL ordenats per plataforma
• configuració de SSL
• Guia d'Instalació de SSL
• [9]
• Preguntes freqüents de Certificats SSL