Autoridad de certificación
Entidad que emite certificados digitales

En criptografía , una autoridad de certificación ( CA ) es una entidad que almacena, firma y emite certificados digitales . Un certificado digital certifica la propiedad de una clave pública por parte del sujeto nombrado del certificado. Esto permite que otros (partes confiadas) confíen en las firmas o en las afirmaciones realizadas sobre la clave privada que corresponde a la clave pública certificada. Una CA actúa como un tercero de confianza, en el que confían tanto el sujeto (propietario) del certificado como la parte que confía en el certificado. [1] El formato de estos certificados está especificado por el estándar X.509 o EMV .

Un uso particularmente común de las autoridades de certificación es firmar certificados utilizados en HTTPS , el protocolo de navegación segura para la World Wide Web. Otro uso común es la emisión de tarjetas de identidad por parte de los gobiernos nacionales para su uso en la firma electrónica de documentos. [2]

Descripción general

Los certificados de confianza se pueden utilizar para crear conexiones seguras a un servidor a través de Internet. Un certificado es esencial para eludir a una parte maliciosa que se encuentra en la ruta a un servidor de destino que actúa como si fuera el objetivo. Este escenario se conoce comúnmente como un ataque de intermediario . El cliente utiliza el certificado de CA para autenticar la firma de CA en el certificado del servidor, como parte de las autorizaciones antes de iniciar una conexión segura. [3] Por lo general, el software cliente (por ejemplo, los navegadores) incluye un conjunto de certificados de CA confiables. Esto tiene sentido, ya que muchos usuarios necesitan confiar en su software cliente. Un cliente malicioso o comprometido puede omitir cualquier control de seguridad y aún así engañar a sus usuarios para que crean lo contrario.

Los clientes de una CA son supervisores de servidores que solicitan un certificado que sus servidores otorgarán a los usuarios. Las CA comerciales cobran dinero por emitir certificados, y sus clientes esperan que el certificado de la CA esté contenido en la mayoría de los navegadores web, de modo que las conexiones seguras a los servidores certificados funcionen de manera eficiente desde el primer momento. La cantidad de navegadores de Internet, otros dispositivos y aplicaciones que confían en una autoridad de certificación en particular se conoce como ubicuidad. Mozilla , que es una empresa sin fines de lucro, emite varios certificados de CA comerciales con sus productos. [4] Si bien Mozilla desarrolló su propia política, el CA/Browser Forum desarrolló pautas similares para la confianza de las CA. Un solo certificado de CA puede compartirse entre varias CA o sus revendedores . Un certificado de CA raíz puede ser la base para emitir varios certificados de CA intermedios con diferentes requisitos de validación.

Además de las CA comerciales, algunas organizaciones sin fines de lucro emiten certificados digitales de confianza pública sin cargo, por ejemplo, Let's Encrypt . Algunas grandes empresas de computación en la nube y alojamiento web también son CA de confianza pública y emiten certificados para servicios alojados en su infraestructura, por ejemplo, IBM Cloud , Amazon Web Services , Cloudflare y Google Cloud Platform .

Las grandes organizaciones o los organismos gubernamentales pueden tener sus propias PKI ( infraestructura de clave pública ), cada una de las cuales contiene sus propias CA. Cualquier sitio que utilice certificados autofirmados actúa como su propia CA.

Los bancos comerciales que emiten tarjetas de pago EMV están regidos por la Autoridad de Certificación EMV, [5] esquemas de pago que enrutan las transacciones de pago iniciadas en Terminales de Punto de Venta ( POS ) a un Banco Emisor de Tarjetas para transferir los fondos desde la cuenta bancaria del titular de la tarjeta a la cuenta bancaria del receptor del pago. Cada tarjeta de pago presenta junto con sus datos de tarjeta también el Certificado de Emisor de Tarjeta al POS. El Certificado de Emisor está firmado por el Certificado de CA EMV. El POS recupera la clave pública de la CA EMV de su almacenamiento, valida el Certificado de Emisor y la autenticidad de la tarjeta de pago antes de enviar la solicitud de pago al esquema de pago.

Los navegadores y otros tipos de clientes suelen permitir a los usuarios añadir o eliminar certificados de CA a voluntad. Si bien los certificados de servidor suelen durar un período relativamente corto, los certificados de CA se extienden aún más, [6] por lo que, para los servidores visitados repetidamente, es menos propenso a errores importar y confiar en el certificado emitido por la CA, en lugar de confirmar una exención de seguridad cada vez que se renueva el certificado del servidor.

Con menor frecuencia, se utilizan certificados confiables para cifrar o firmar mensajes. Las CA también proporcionan certificados de usuario final, que se pueden utilizar con S/MIME . Sin embargo, el cifrado implica la clave pública del receptor y, dado que los autores y los receptores de mensajes cifrados, aparentemente, se conocen entre sí, la utilidad de un tercero confiable se limita a la verificación de la firma de los mensajes enviados a listas de correo públicas.

Proveedores

En todo el mundo, el negocio de las autoridades de certificación está fragmentado y los proveedores nacionales o regionales dominan su mercado local. Esto se debe a que muchos usos de los certificados digitales, como las firmas digitales legalmente vinculantes, están vinculados a leyes, regulaciones y esquemas de acreditación locales para las autoridades de certificación.

Sin embargo, el mercado de certificados de servidor TLS/SSL de confianza global está en manos de un pequeño número de empresas multinacionales. Este mercado tiene importantes barreras de entrada debido a los requisitos técnicos. [7] Si bien no es un requisito legal, los nuevos proveedores pueden optar por someterse a auditorías de seguridad anuales (como WebTrust [8] para las autoridades de certificación en América del Norte y ETSI en Europa [9] ) para que un navegador web o un sistema operativo los incluya como raíz de confianza.

Al 24 de agosto de 2020 [actualizar], 147 certificados raíz, que representan a 52 organizaciones, son confiables en el navegador web Mozilla Firefox , [10] 168 certificados raíz, que representan a 60 organizaciones, son confiables para macOS , [11] y 255 certificados raíz, que representan a 101 organizaciones, son confiables para Microsoft Windows . [12] A partir de Android 4.2 (Jelly Bean), Android actualmente contiene más de 100 CA que se actualizan con cada versión. [13]

El 18 de noviembre de 2014, un grupo de empresas y organizaciones sin fines de lucro, entre las que se incluyen Electronic Frontier Foundation , Mozilla, Cisco y Akamai, anunciaron Let's Encrypt , una autoridad de certificación sin fines de lucro que proporciona certificados X.509 validados por dominio gratuitos, así como software para permitir la instalación y el mantenimiento de certificados. [14] Let's Encrypt es operado por el recientemente formado Internet Security Research Group , una organización sin fines de lucro de California reconocida como exenta de impuestos a nivel federal. [15]

Según Netcraft , el estándar de la industria para monitorear certificados TLS activos, en mayo de 2015, "Aunque el ecosistema global [TLS] es competitivo, está dominado por un puñado de CA importantes: tres autoridades de certificación (Symantec, Comodo, GoDaddy) representan tres cuartas partes de todos los certificados [TLS] emitidos en servidores web públicos. El primer puesto lo ha ocupado Symantec (o VeriSign antes de que Symantec lo comprara) desde que comenzó [nuestra] encuesta, y actualmente representa poco menos de un tercio de todos los certificados. Para ilustrar el efecto de las diferentes metodologías, entre el millón de sitios más activos, Symantec emitió el 44% de los certificados válidos y confiables en uso, significativamente más que su participación de mercado general". [16]

En 2020, según la empresa de encuestas independiente Netcraft , "DigiCert es la autoridad de certificación de alta seguridad más grande del mundo, con el 60% del mercado de certificados de validación extendida y el 96% de los certificados validados por organizaciones a nivel mundial. [17]

A partir de julio de 2024, [actualizar]la empresa de encuestas W3Techs, que recopila estadísticas sobre el uso de la autoridad de certificación entre los 10 millones de sitios web principales de Alexa y el millón de sitios web principales de Tranco, enumera las seis autoridades más grandes por participación de uso absoluto como se muestra a continuación. [18]

RangoEditorUsoCuota de mercado
1Vamos a encriptar52,5%56,3%
2GlobalSign13,1%14,0%
3Identidad de confianza11,6%12,4%
4Sectigo (Comodo Ciberseguridad)6,8%7,3%
5Grupo DigiCert5.0%5,3%
6Grupo GoDaddy4,2%4,4%

Normas de validación

Las CA comerciales que emiten la mayor parte de los certificados para servidores HTTPS suelen utilizar una técnica denominada " validación de dominio " para autenticar al destinatario del certificado. Las técnicas utilizadas para la validación de dominio varían entre las CA, pero en general las técnicas de validación de dominio tienen como objetivo demostrar que el solicitante del certificado controla un nombre de dominio determinado , no información sobre la identidad del solicitante.

Muchas autoridades de certificación también ofrecen certificados de validación extendida (EV) como una alternativa más rigurosa a los certificados validados por dominio. La validación extendida tiene como objetivo verificar no solo el control de un nombre de dominio, sino también la información de identidad adicional que se incluirá en el certificado. Algunos navegadores muestran esta información de identidad adicional en un cuadro verde en la barra de URL. Una limitación de EV como solución a las debilidades de la validación de dominio es que los atacantes aún podrían obtener un certificado validado por dominio para el dominio víctima y desplegarlo durante un ataque; si eso ocurriera, la diferencia observable para el usuario víctima sería la ausencia de una barra verde con el nombre de la empresa. Hay algunas dudas sobre si los usuarios reconocerían esta ausencia como indicativa de que se está produciendo un ataque: una prueba realizada con Internet Explorer 7 en 2009 mostró que los usuarios no notaron la ausencia de las advertencias EV de IE7, sin embargo, el navegador actual de Microsoft, Edge , muestra una diferencia significativamente mayor entre los certificados EV y los validados por dominio, ya que los certificados validados por dominio tienen un candado hueco y gris.

Debilidades de validación

La validación de dominios sufre ciertas limitaciones estructurales de seguridad. En particular, siempre es vulnerable a ataques que permiten a un adversario observar las sondas de validación de dominios que envían las CA. Estos pueden incluir ataques contra los protocolos DNS, TCP o BGP (que carecen de las protecciones criptográficas de TLS/SSL) o la vulneración de enrutadores. Estos ataques son posibles tanto en la red cercana a una CA como cerca del propio dominio de la víctima.

Una de las técnicas de validación de dominios más comunes implica el envío de un correo electrónico que contiene un token de autenticación o un enlace a una dirección de correo electrónico que probablemente sea responsable administrativamente del dominio. Esta podría ser la dirección de correo electrónico de contacto técnico que aparece en la entrada WHOIS del dominio o un correo electrónico administrativo como admin@ , administrator@ , webmaster@ , hostmaster@ o postmaster@ del dominio. [19] [20] Algunas autoridades de certificación pueden aceptar la confirmación utilizando root@ , [ cita requerida ] info@ o support@ en el dominio. [21] La teoría detrás de la validación de dominios es que solo el propietario legítimo de un dominio podría leer los correos electrónicos enviados a estas direcciones administrativas.

Las implementaciones de validación de dominios han sido a veces una fuente de vulnerabilidades de seguridad. En un caso, los investigadores de seguridad demostraron que los atacantes podían obtener certificados para sitios de correo web porque una CA estaba dispuesta a utilizar una dirección de correo electrónico como [email protected] para domain.com, pero no todos los sistemas de correo web habían reservado el nombre de usuario "ssladmin" para evitar que los atacantes lo registraran. [22]

Antes de 2011, no existía una lista estándar de direcciones de correo electrónico que pudieran utilizarse para la validación de dominios, por lo que no estaba claro para los administradores de correo electrónico qué direcciones debían reservarse. La primera versión de los Requisitos básicos del CA/Browser Forum , adoptada en noviembre de 2011, especificaba una lista de dichas direcciones. Esto permitía a los servidores de correo reservar esas direcciones para uso administrativo, aunque estas precauciones aún no son universales. En enero de 2015, un finlandés registró el nombre de usuario "hostmaster" en la versión finlandesa de Microsoft Live y pudo obtener un certificado validado por dominio para live.fi, a pesar de no ser el propietario del nombre de dominio. [23]

Expedición de un certificado

El procedimiento para obtener un certificado de clave pública

Una CA emite certificados digitales que contienen una clave pública y la identidad del propietario. La clave privada correspondiente no se pone a disposición del público, sino que el usuario final que generó el par de claves la mantiene en secreto. El certificado es también una confirmación o validación por parte de la CA de que la clave pública contenida en el certificado pertenece a la persona, organización, servidor u otra entidad indicada en el certificado. La obligación de una CA en tales esquemas es verificar las credenciales de un solicitante, de modo que los usuarios y las partes que confían puedan confiar en la información contenida en el certificado emitido. Las CA utilizan una variedad de estándares y pruebas para hacerlo. En esencia, la autoridad de certificación es responsable de decir "sí, esta persona es quien dice ser, y nosotros, la CA, certificamos eso". [24]

Si el usuario confía en la CA y puede verificar su firma, entonces también puede asumir que una determinada clave pública pertenece efectivamente a quien está identificado en el certificado. [25]

Ejemplo

La criptografía de clave pública se puede utilizar para cifrar datos comunicados entre dos partes. Esto suele ocurrir cuando un usuario inicia sesión en cualquier sitio que implemente el protocolo HTTP Secure . En este ejemplo, supongamos que el usuario inicia sesión en la página de inicio de su banco www.bank.example para realizar operaciones bancarias en línea. Cuando el usuario abre la página de inicio www.bank.example, recibe una clave pública junto con todos los datos que muestra su navegador web. La clave pública se puede utilizar para cifrar datos del cliente al servidor, pero el procedimiento seguro es utilizarla en un protocolo que determine una clave de cifrado simétrica compartida temporal; los mensajes en un protocolo de intercambio de claves de este tipo se pueden cifrar con la clave pública del banco de tal manera que solo el servidor del banco tenga la clave privada para leerlos. [26]

El resto de la comunicación se realiza utilizando la nueva clave simétrica (desechable), de modo que cuando el usuario introduce información en la página del banco y la envía (envía la información de vuelta al banco), los datos que el usuario ha introducido en la página quedan cifrados en su navegador web. Por lo tanto, incluso si alguien puede acceder a los datos (cifrados) que el usuario comunicó a www.bank.example, dicho espía no puede leerlos ni descifrarlos.

Este mecanismo sólo es seguro si el usuario puede estar seguro de que es el banco lo que ve en su navegador web. Si el usuario escribe www.bank.example, pero su comunicación es interceptada y un sitio web falso (que simula ser el sitio web del banco) envía la información de la página de vuelta al navegador del usuario, la página web falsa puede enviar una clave pública falsa al usuario (para la cual el sitio falso posee una clave privada correspondiente). El usuario completará el formulario con sus datos personales y enviará la página. La página web falsa obtendrá entonces acceso a los datos del usuario.

Esto es lo que pretende evitar el mecanismo de la autoridad de certificación. Una autoridad de certificación (CA) es una organización que almacena claves públicas y sus propietarios, y cada parte en una comunicación confía en esta organización (y conoce su clave pública). Cuando el navegador web del usuario recibe la clave pública de www.bank.example también recibe una firma digital de la clave (con algo más de información, en un llamado certificado X.509 ). El navegador ya posee la clave pública de la CA y, en consecuencia, puede verificar la firma, confiar en el certificado y la clave pública que contiene: dado que www.bank.example utiliza una clave pública que certifica la autoridad de certificación, un www.bank.example falso solo puede utilizar la misma clave pública. Dado que el www.bank.example falso no conoce la clave privada correspondiente, no puede crear la firma necesaria para verificar su autenticidad. [27]

Seguridad

Es difícil asegurar la exactitud de la correspondencia entre los datos y la entidad cuando los datos se presentan a la CA (quizás a través de una red electrónica) y cuando también se presentan las credenciales de la persona/empresa/programa que solicita un certificado. Por eso, las CA comerciales suelen utilizar una combinación de técnicas de autenticación que incluyen el aprovechamiento de las oficinas gubernamentales, la infraestructura de pago, las bases de datos y servicios de terceros y la heurística personalizada. En algunos sistemas empresariales, se pueden utilizar formas locales de autenticación, como Kerberos, para obtener un certificado que, a su vez, puede ser utilizado por terceros externos que confían en él. En algunos casos, se exige a los notarios que conozcan personalmente a la parte cuya firma se va a certificar; se trata de un estándar más alto que el que alcanzan muchas CA. Según el esquema de la Asociación Estadounidense de Abogados sobre la Gestión de Transacciones en Línea, los puntos principales de los estatutos federales y estatales de los EE. UU. promulgados con respecto a las firmas digitales han sido "prevenir una regulación local conflictiva y excesivamente onerosa y establecer que los escritos electrónicos satisfacen los requisitos tradicionales asociados con los documentos en papel". Además, el estatuto de firma electrónica de los EE. UU. y el código UETA sugerido [28] ayudan a garantizar que:

  1. No se podrá negar efecto legal, validez o exigibilidad a una firma, contrato u otro registro relacionado con dicha transacción únicamente porque esté en forma electrónica; y
  2. No se podrá negar efecto jurídico, validez o ejecutabilidad a un contrato relativo a dicha transacción únicamente porque en su formación se haya utilizado una firma electrónica o un registro electrónico.

A pesar de las medidas de seguridad adoptadas para verificar correctamente la identidad de personas y empresas, existe el riesgo de que una única CA emita un certificado falso a un impostor. También es posible registrar personas y empresas con el mismo nombre o nombres muy similares, lo que puede dar lugar a confusión. Para minimizar este peligro, la iniciativa de transparencia de certificados propone auditar todos los certificados en un registro público infalsificable, lo que podría ayudar a prevenir el phishing . [29] [30]

En implementaciones a gran escala, es posible que Alice no esté familiarizada con la autoridad de certificación de Bob (quizás cada uno tenga un servidor CA diferente), por lo que el certificado de Bob también puede incluir la clave pública de su CA firmada por una CA 2 diferente , que presumiblemente Alice puede reconocer. Este proceso generalmente conduce a una jerarquía o malla de CA y certificados de CA.

Revocación de certificado

Un certificado puede ser revocado antes de su vencimiento, lo que indica que ya no es válido. Sin la revocación, un atacante podría explotar un certificado comprometido o emitido incorrectamente hasta su vencimiento. [31] Por lo tanto, la revocación es una parte importante de una infraestructura de clave pública . [32] La revocación la realiza la CA emisora, que produce una declaración de revocación autenticada criptográficamente . [33]

Para distribuir información de revocación a los clientes, la puntualidad del descubrimiento de la revocación (y, por lo tanto, la ventana para que un atacante explote un certificado comprometido) se compensa con el uso de recursos en la consulta de estados de revocación y las preocupaciones de privacidad. [34] Si la información de revocación no está disponible (ya sea debido a un accidente o un ataque), los clientes deben decidir si fallan de manera total y tratan un certificado como si estuviera revocado (y así degradan la disponibilidad ) o fallan de manera suave y lo tratan como si no estuviera revocado (y permiten a los atacantes eludir la revocación). [35]

Debido al costo de las comprobaciones de revocación y al impacto en la disponibilidad de servicios remotos potencialmente poco fiables, los navegadores web limitan las comprobaciones de revocación que realizan y, cuando lo hacen, fallan de manera suave. [36] Las listas de revocación de certificados consumen demasiado ancho de banda para su uso rutinario, y el Protocolo de estado de certificados en línea presenta problemas de latencia de conexión y privacidad. Se han propuesto otros esquemas, pero aún no se han implementado con éxito, para permitir la comprobación de fallas de manera estricta. [32]

Organizaciones industriales

  • Consejo de Seguridad de Autoridades de Certificación (CASC): en febrero de 2013, se fundó el CASC como una organización de defensa de la industria dedicada a abordar cuestiones de la industria y educar al público sobre seguridad en Internet. Los miembros fundadores son las siete autoridades de certificación más importantes. [37] [38]
  • Foro de estándares comunes de seguridad informática (CCSF): en 2009, se fundó el CCSF para promover estándares industriales que protejan a los usuarios finales. El director ejecutivo de Comodo Group, Melih Abdulhayoğlu, es considerado el fundador del CCSF. [39]
  • CA/Browser Forum : en 2005 se formó un nuevo consorcio de autoridades de certificación y proveedores de navegadores web para promover los estándares de la industria y los requisitos básicos para la seguridad en Internet. El director ejecutivo de Comodo Group, Melih Abdulhayoğlu, organizó la primera reunión y se lo considera el fundador del CA/Browser Forum. [40] [41]

Requisitos básicos

El CA/Browser Forum publica los Requisitos básicos, [42] una lista de políticas y requisitos técnicos que deben seguir las CA. Estos son un requisito para la inclusión en los almacenes de certificados de Firefox [43] y Safari. [44]

Compromiso de CA

Si la CA puede ser subvertida, entonces se pierde la seguridad de todo el sistema, subvirtiendo potencialmente todas las entidades que confían en la CA comprometida.

Por ejemplo, supongamos que un atacante, Eve, consigue que una CA le emita un certificado que dice representar a Alice. Es decir, el certificado declararía públicamente que representa a Alice y podría incluir otra información sobre Alice. Parte de la información sobre Alice, como el nombre de su empleador, podría ser verdadera, lo que aumentaría la credibilidad del certificado. Eve, sin embargo, tendría la importantísima clave privada asociada al certificado. Eve podría entonces utilizar el certificado para enviar un correo electrónico firmado digitalmente a Bob, engañándolo para que crea que el correo electrónico es de Alice. Bob podría incluso responder con un correo electrónico cifrado, creyendo que solo Alice podría leerlo, cuando Eve en realidad es capaz de descifrarlo utilizando la clave privada.

Un caso notable de subversión de CA como éste ocurrió en 2001, cuando la autoridad de certificación VeriSign emitió dos certificados a una persona que decía representar a Microsoft. Los certificados tienen el nombre "Microsoft Corporation", por lo que podrían usarse para engañar a alguien y hacerle creer que las actualizaciones del software de Microsoft provenían de Microsoft cuando en realidad no era así. El fraude se detectó a principios de 2001. Microsoft y VeriSign tomaron medidas para limitar el impacto del problema. [45] [46]

En 2008, el distribuidor de Comodo, Certstar, vendió un certificado para mozilla.com a Eddy Nigg, quien no tenía autoridad para representar a Mozilla. [47]

En 2011, se obtuvieron certificados fraudulentos de Comodo y DigiNotar , [48] [49] supuestamente por parte de piratas informáticos iraníes. Hay pruebas de que los certificados fraudulentos de DigiNotar se utilizaron en un ataque de intermediario en Irán. [50]

En 2012, se supo que Trustwave emitió un certificado raíz subordinado que se utilizó para la gestión transparente del tráfico (man-in-the-middle) que efectivamente permitía a una empresa rastrear el tráfico de red interna SSL utilizando el certificado subordinado. [51]

En 2012, el malware Flame (también conocido como SkyWiper) contenía módulos que tenían una colisión MD5 con un certificado válido emitido por un certificado de licencia de Microsoft Terminal Server que utilizaba el algoritmo hash MD5 roto. De esta forma, los autores pudieron llevar a cabo un ataque de colisión con el hash que figuraba en el certificado. [52] [53]

En 2015, una autoridad de certificación china llamada MCS Holdings y afiliada al registro de dominios central de China emitió certificados no autorizados para dominios de Google. [54] [55] Por lo tanto, Google eliminó tanto MCS como la autoridad de certificación raíz de Chrome y revocó los certificados. [56]

Almacenamiento de claves

Un atacante que roba las claves privadas de una autoridad de certificación puede falsificar certificados como si fueran CA, sin necesidad de acceso continuo a los sistemas de la CA. Por lo tanto, el robo de claves es uno de los principales riesgos contra los que se defienden las autoridades de certificación. Las CA de confianza pública casi siempre almacenan sus claves en un módulo de seguridad de hardware (HSM), que les permite firmar certificados con una clave, pero generalmente impiden la extracción de esa clave con controles físicos y de software. Las CA suelen tomar la precaución adicional de mantener la clave para sus certificados raíz de largo plazo en un HSM que se mantiene fuera de línea , excepto cuando es necesario para firmar certificados intermedios de vida más corta. Los certificados intermedios, almacenados en un HSM en línea, pueden realizar el trabajo diario de firmar certificados de entidad final y mantener actualizada la información de revocación.

Las CA a veces utilizan una ceremonia de clave al generar claves de firma, con el fin de garantizar que las claves no sean alteradas ni copiadas.

Debilidad en la implementación del esquema de terceros de confianza

La debilidad crítica en la forma en que se implementa el esquema X.509 actual es que cualquier CA en la que confíe una parte en particular puede emitir certificados para cualquier dominio que elija. Dichos certificados serán aceptados como válidos por la parte que confía, ya sean legítimos y autorizados o no. [57] Esta es una deficiencia grave, dado que la tecnología más común que emplea X.509 y terceros confiables es el protocolo HTTPS. Como todos los navegadores web principales se distribuyen a sus usuarios finales preconfigurados con una lista de CA confiables que se cuentan por docenas, esto significa que cualquiera de estas CA confiables preaprobadas puede emitir un certificado válido para cualquier dominio. [58] La respuesta de la industria a esto ha sido moderada. [59] Dado que el contenido de la lista de CA confiables preconfigurada de un navegador está determinado independientemente por la parte que distribuye o hace que se instale la aplicación del navegador, realmente no hay nada que las propias CA puedan hacer.

Esta cuestión es el impulso que impulsa el desarrollo del protocolo de autenticación de entidades con nombre (DANE) basado en DNS . Si se adopta junto con las extensiones de seguridad del sistema de nombres de dominio (DNSSEC), DANE reducirá en gran medida, si no elimina, el papel de terceros de confianza en la infraestructura de clave pública (PKI) de un dominio.

Véase también

Referencias

  1. ^ Chien, Hung-Yu (19 de agosto de 2021). "Certificados de clave pública dinámica con secreto hacia adelante". Electrónica . 10 (16): 2009. doi : 10.3390/electronics10162009 . ISSN  2079-9292.
  2. ^ "¿Qué es una autoridad de certificación (CA)?".
  3. ^ Villanueva, John Carl. "Cómo funcionan los certificados digitales: descripción general". www.jscape.com . Consultado el 5 de septiembre de 2021 .
  4. ^ "Lista de certificados CA incluidos en Mozilla — Mozilla". Mozilla.org. Archivado desde el original el 4 de agosto de 2013. Consultado el 11 de junio de 2014 .
  5. ^ "EMV CA". Autoridad de certificación EMV a nivel mundial. 2 de octubre de 2010. Consultado el 17 de febrero de 2019 .
  6. ^ Zakir Durumeric; James Kasten; Michael Bailey; J. Alex Halderman (12 de septiembre de 2013). "Análisis del ecosistema de certificados HTTPS" (PDF) . Conferencia de medición de Internet . SIGCOMM . Archivado (PDF) del original el 22 de diciembre de 2013 . Consultado el 20 de diciembre de 2013 .
  7. ^ "¿Qué es un certificado SSL?". Archivado desde el original el 2015-11-03 . Consultado el 2022-03-19 .
  8. ^ "webtrust". webtrust. Archivado desde el original el 18 de agosto de 2013. Consultado el 2 de marzo de 2013 .
  9. ^ Kirk Hall (abril de 2013). «Estándares y reglamentaciones de la industria aplicables a las autoridades de certificación» (PDF) . Trend Micro. Archivado (PDF) del original el 4 de marzo de 2016. Consultado el 11 de junio de 2014 .
  10. ^ "CA:IncludedCAs - MozillaWiki". wiki.mozilla.org . Archivado desde el original el 25 de marzo de 2017 . Consultado el 18 de marzo de 2017 .
  11. ^ "Lista de certificados raíz de confianza disponibles en macOS High Sierra". Soporte técnico de Apple . Consultado el 24 de agosto de 2020 .
  12. ^ "Lista de certificados CA incluidos en Microsoft". ccadb-public.secure.force.com . Consultado el 24 de agosto de 2020 .
  13. ^ "Seguridad con HTTPS y SSL". developer.android.com . Archivado desde el original el 8 de julio de 2017. Consultado el 9 de junio de 2017 .
  14. ^ "Let's Encrypt: Delivering SSL/TLS Everywhere" (Nota de prensa). Let's Encrypt. Archivado desde el original el 18 de noviembre de 2014. Consultado el 20 de noviembre de 2014 .
  15. ^ "Acerca de". Let's Encrypt. Archivado desde el original el 10 de junio de 2015. Consultado el 7 de junio de 2015 .
  16. ^ "Conteo de certificados SSL - Netcraft". news.netcraft.com . 13 de mayo de 2015. Archivado desde el original el 16 de mayo de 2015.
  17. ^ "DigiCert: la autoridad de certificación de alta seguridad más grande del mundo | Netcraft". trends.netcraft.com .
  18. ^ "Estadísticas de uso de autoridades de certificación SSL para sitios web, agosto de 2024 - W3Techs". w3techs.com .
  19. ^ "Requisitos básicos para la emisión y gestión de certificados de confianza pública, v.1.2.3" (PDF) . Archivado (PDF) desde el original el 23 de marzo de 2015 . Consultado el 20 de marzo de 2015 .
  20. ^ "CA/Prácticas prohibidas o problemáticas - MozillaWiki". wiki.mozilla.org . Archivado desde el original el 21 de julio de 2017 . Consultado el 6 de julio de 2017 .
  21. ^ "Preguntas frecuentes sobre SSL - Preguntas frecuentes - Rapid SSL" www.rapidssl.com . Archivado desde el original el 6 de febrero de 2015.
  22. ^ Zusman, Mike (2009). No se presentan cargos penales: piratería informática de PKI (PDF) . DEF CON 17. Las Vegas. Archivado (PDF) desde el original el 15 de abril de 2013.
  23. ^ "Un finlandés creó esta sencilla cuenta de correo electrónico y recibió el certificado de seguridad de Microsoft". tivi.fi . Archivado desde el original el 8 de agosto de 2015.
  24. ^ "Responsabilidades de la autoridad de certificación". Archivado desde el original el 12 de febrero de 2015. Consultado el 12 de febrero de 2015 .
  25. ^ "Red Mundial". 17 de enero de 2000.
  26. ^ Criptografía aplicada y seguridad de redes: Segunda conferencia internacional, ACNS 2004, Yellow Mountain, China, 8-11 de junio de 2004. Actas. Springer. Junio ​​de 2004. ISBN 9783540222170.
  27. ^ Guía rápida para administrar los ciclos de vida de los certificados. Realtimepublishers.com. 2006. ISBN 9781931491594.
  28. ^ "Firmas y registros electrónicos" (PDF) . Archivado (PDF) desde el original el 4 de marzo de 2016 . Consultado el 28 de agosto de 2014 .
  29. ^ "Transparencia de los certificados". Archivado desde el original el 1 de noviembre de 2013. Consultado el 3 de noviembre de 2013 .
  30. ^ Laurie, Ben; Langley, Adam; Kasper, Emilia (junio de 2013). Transparencia en los certificados. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6962 . ISSN  2070-1721. RFC 6962. Experimental. |- |6963 |Mejores prácticas actuales | P. Saint-Andre (mayo de 2013). Un espacio de nombres de recursos uniformes (URN) para ejemplos. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6963 . ISSN  2070-1721. RFC 6963.|Actualiza RFC 1930. |- |6979 |Informativo | T. Pornin (agosto de 2013). Uso determinista del algoritmo de firma digital (DSA) y del algoritmo de firma digital de curva elíptica (ECDSA). Presentación independiente. doi : 10.17487/RFC6979 . ISSN  2070-1721. RFC 6979.| |- |6980 |Estándar propuesto | F. Gont (agosto de 2013). Implicancias de seguridad de la fragmentación de IPv6 con detección de vecinos de IPv6. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6980 . ISSN  2070-1721. RFC 6980.|Actualiza RFC 3971 y 4861. |- |6996 |Mejores prácticas actuales | J. Mitchell (julio de 2013). Reserva de sistemas autónomos (AS) para uso privado. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6996 . ISSN  2070-1721. BCP 6. RFC 6996.|Actualiza RFC 1930. |}
  31. ^ Smith, Dickinson y Seamons 2020, pág. 1.
  32. ^ ab Sheffer, Saint-Andre & Fossati 2022, 7.5. Revocación del Certificado.
  33. ^ Chung y otros. 2018, pág. 3.
  34. ^ Smith, Dickinson y Seamons 2020, pág. 10.
  35. ^ Larisch y otros. 2017, pág. 542.
  36. ^ Smith, Dickinson y Seamons 2020, pág. 1-2.
  37. ^ "Se formó un consejo de poder de múltiples proveedores para abordar cuestiones relacionadas con los certificados digitales". Network World . 14 de febrero de 2013. Archivado desde el original el 28 de julio de 2013.
  38. ^ "Las principales autoridades de certificación se unen en nombre de la seguridad SSL". Dark Reading . 14 de febrero de 2013. Archivado desde el original el 10 de abril de 2013.
  39. ^ "Fundador del foro CA/Browser". Archivado desde el original el 23 de agosto de 2014. Consultado el 23 de agosto de 2014 .
  40. ^ "Foro CA/Browser". Archivado desde el original el 12 de mayo de 2013. Consultado el 23 de abril de 2013 .
  41. ^ Wilson, Wilson. "CA/Browser Forum History" (PDF) . DigiCert. Archivado (PDF) del original el 2013-05-12 . Consultado el 2013-04-23 .
  42. ^ "Baseline Requirements". Foro CAB. 4 de septiembre de 2013. Archivado desde el original el 7 de enero de 2014. Consultado el 14 de abril de 2017 .
  43. ^ "Política de la tienda raíz de Mozilla". Mozilla. Archivado desde el original el 15 de abril de 2017. Consultado el 14 de abril de 2017 .
  44. ^ "Programa de certificados raíz de Apple". Apple. Archivado desde el original el 20 de marzo de 2017. Consultado el 14 de abril de 2017 .
  45. ^ "CA-2001-04". Cert.org. 31 de diciembre de 2001. Archivado desde el original el 2 de noviembre de 2013. Consultado el 11 de junio de 2014 .
  46. ^ Microsoft, Inc. (21 de febrero de 2007). «Boletín de seguridad de Microsoft MS01-017: Los certificados digitales erróneos emitidos por VeriSign plantean un riesgo de suplantación de identidad». Archivado desde el original el 26 de octubre de 2011. Consultado el 9 de noviembre de 2011 .
  47. ^ Seltzer, Larry. "Proveedor de certificados SSL vende certificado CSSL de Mozilla.com a un tipo". eWeek . Consultado el 5 de diciembre de 2021 .
  48. ^ Bright, Peter (28 de marzo de 2011). «Un hacker iraní independiente se atribuye la responsabilidad del ataque a Comodo». Ars Technica. Archivado desde el original el 29 de agosto de 2011. Consultado el 1 de septiembre de 2011 .
  49. ^ Bright, Peter (30 de agosto de 2011). «Otro certificado fraudulento plantea las mismas viejas preguntas sobre las autoridades de certificación». Ars Technica. Archivado desde el original el 12 de septiembre de 2011. Consultado el 1 de septiembre de 2011 .
  50. ^ Leyden, John (6 de septiembre de 2011). «Dentro de la 'Operación Tulipán Negro': análisis del hackeo de DigiNotar». The Register . Archivado desde el original el 3 de julio de 2017.
  51. ^ "Trustwave emitió un certificado de intermediario". The H Security . 2012-02-07. Archivado desde el original el 2012-03-13 . Consultado el 2012-03-14 .
  52. ^ "Explicación del ataque de colisión del malware Flame | Blog de MSRC | Centro de respuesta de seguridad de Microsoft". msrc.microsoft.com . Consultado el 13 de octubre de 2023 .
  53. ^ Goodin, Dan (7 de junio de 2012). "Un gran avance en el campo de las criptomonedas demuestra que Flame fue diseñado por científicos de talla mundial". Ars Technica . Consultado el 13 de octubre de 2023 .
  54. ^ Fisher, Dennis (23 de marzo de 2015). "CA vinculada a un registrador chino emitió certificados de Google no autorizados". ThreatPost . Consultado el 27 de septiembre de 2023 .
  55. ^ Langley, Adam (23 de marzo de 2015). «Mantenimiento de la seguridad de los certificados digitales». Blog de seguridad de Google . Consultado el 27 de septiembre de 2023 .
  56. ^ Lowenthal, Tom (31 de marzo de 2015). "El CNNIC de China emite certificados falsos en una grave violación de la confianza en las criptomonedas". Comité para la Protección de los Periodistas . Consultado el 13 de octubre de 2023 .
  57. ^ Osborne, Charlie. "Symantec despide a su personal por emitir certificados de Google no autorizados - ZDNet". ZDNet . Archivado desde el original el 2 de octubre de 2016.
  58. ^ "Se descubren certificados digitales de Google no autorizados". linkedin.com . 12 de agosto de 2014.
  59. ^ "Tras la emisión no autorizada de certificados por parte de la CA NIC india, ¿pueden las CA gubernamentales seguir siendo consideradas "terceros de confianza"?". casecurity.org . 24 de julio de 2014. Archivado desde el original el 3 de octubre de 2016.

Obras citadas

  • Chung, Taejoong; Lok, Jay; Chandrasekaran, Balakrishnan; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Rula, John; Sullivan, Nick; Wilson, Christo (2018). "¿Está la Web preparada para el imprescindible OCSP?" (PDF) . Actas de la Conferencia de medición de Internet de 2018. págs. 105–118. doi :10.1145/3278532.3278543. ISBN . 9781450356190. Número de identificación del sujeto  53223350.
  • Larisch, James; Choffnes, David; Levin, Dave; Maggs, Bruce M.; Mislove, Alan; Wilson, Christo (2017). "CRLite: un sistema escalable para enviar todas las revocaciones de TLS a todos los navegadores". Simposio IEEE sobre seguridad y privacidad de 2017 (SP) . págs. 539–556. doi : 10.1109/sp.2017.17 . ISBN . 978-1-5090-5533-3. Número de identificación del sujeto  3926509.
  • Sheffer, Yaron; Saint-Andre, Pierre; Fossati, Thomas (noviembre de 2022). Recomendaciones para el uso seguro de la seguridad de la capa de transporte (TLS) y la seguridad de la capa de transporte de datagramas (DTLS). doi : 10.17487/RFC9325 . RFC 9325.
  • Smith, Trevor; Dickinson, Luke; Seamons, Kent (2020). "Let's Revoke: Scalable Global Certificate Revocation". Actas del Simposio sobre seguridad de redes y sistemas distribuidos de 2020. doi : 10.14722 /ndss.2020.24084 . ISBN . 978-1-891562-61-7.S2CID211268930  .​
  • ¿Qué tan seguro es el protocolo HTTPS hoy en día? ¿Con qué frecuencia lo atacan?, Electronic Frontier Foundation (25 de octubre de 2011)
Obtenido de "https://es.wikipedia.org/w/index.php?title=Autoridad_de_certificación&oldid=1249277004"