¿Por qué las autoridades de certificados raíz pueden emitir certificados para cualquier dominio?

5

¿Por qué se permite que las autoridades de los certificados emitan certificados en los navegadores para cualquier nombre de dominio?

¿Eso no implica que una autoridad de certificado raíz de alto pirateo pueda emitir certificados falsos de confianza en los que confíe cualquier navegador? Esto no es muy seguro desde la perspectiva del usuario final.

¿No sería más seguro que usted designe qué autoridades de certificado raíz están permitidas & ¿Se puede confiar en firmar certificados para sus registros de nombre de dominio, por ejemplo, a través de DNS SEC? Ejemplos similares de DNS también son registros SPF de correo en los que usted dice qué servidores de correo pueden enviar correos desde su dominio.

¿Por qué está diseñado para confiar en que todas las CA raíz emitan certificados para cualquier nombre de dominio?

    
pregunta Christian 22.01.2016 - 22:37
fuente

3 respuestas

6
  

¿Por qué está diseñado para confiar en que todas las CA raíz emitan certificados para cualquier nombre de dominio?

Esto tiene razones históricas y quizás razones para promover la competencia. Al principio tenías solo unos pocos CA raíz con precios muy altos. Ahora los precios están bajos porque todos los CA pueden emitir un certificado para cualquiera. Si cada CA solo pudiera firmar certificados para una parte específica de Internet, esta competencia no sería posible.

El diseño inicial tan inseguro que tiene en varias partes de los protocolos de Internet y generalmente se soluciona agregando seguridad opcional, es decir, fijación de certificados, política de seguridad de contenido contra scripts entre sitios, etc. Por supuesto, todo esto es simplemente Seguridad opcional agregada y por lo tanto rara vez se utiliza. El pensamiento general es que funciona sin tener que preocuparse.

  

¿No sería más seguro que usted designe qué autoridades de certificado raíz están permitidas & ¿Se puede confiar en firmar certificados para sus registros de nombre de dominio, por ejemplo, a través de DNS SEC?

Hay ideas para usarlo y en el área de seguridad del correo DANE está ganando poco a poco seguidores y hay también propuestas para almacenar SSH u otras claves y certificados (o huellas digitales) en DNS. El problema principal es que primero se necesita tener DNSSec disponible en todas partes antes de poder confiar en DNSSec para entregar todos estos certificados. Pero por ahora solo una pequeña parte de Internet está protegida por DNSSec. Además, muchos resolvedores de DNS no tratan con DNSSec en absoluto o no lo hacen correctamente y, en el nivel de la aplicación, por lo general, tampoco tiene acceso al estado de protección de una respuesta de DNS.

  

Los ejemplos de DNS similares también son registros SPF de correo en los que usted dice qué servidores de correo pueden enviar correo desde su dominio.

Los registros SPF o DKIM no se consideran tan importantes para la seguridad y, por lo tanto, la entrega de estos registros con DNS simple sin protección se considera aceptable. Este no sería el caso de los certificados en los que necesitaría una respuesta en la que pueda confiar plenamente.

    
respondido por el Steffen Ullrich 23.01.2016 - 07:25
fuente
4

Confiar en DNSSEC equivaldría esencialmente a transferir nuestra confianza de las CA a los registradores (por ejemplo, empresas como GoDaddy), los TLD (por ejemplo, VeriSign) y la raíz (por ejemplo, la ICANN). No estoy seguro de que podamos confiar en estas entidades más de lo que podemos confiar en las CA. Consulte la publicación del blog de Moxie Marlinspike para una gran reseña sobre este tema: enlace

    
respondido por el mti2935 22.01.2016 - 23:07
fuente
0

Has golpeado en uno de los problemas fundamentales con los certificados. Son una forma de autenticación, pero son deficientes en la autorización. Sé quién eres, pero ¿qué puedes firmar? ¿Y tú y yo estamos de acuerdo en las definiciones de todos modos?

Con el tiempo, varios bits se han pirateado en X.509. Los bits representan si puede firmar código, cifrar sobre TLS, etc. Pero no hay noción de "alcance". No es como "soy un CA, pero solo puedo firmar certificados para el dominio example.com". Incluso entonces, hay diferencias de implementación y de interpretación.

Uno de los grandes problemas es que X.509 confunde la autenticación y la autorización. El conjunto de operaciones que uno puede hacer (firmar datos, cifrar datos, emitir certificados, revocar certificados, etc.) está mal definido. Las posibles restricciones (siempre, nunca, a veces, con aprobación, etc.) no están definidas. El alcance de las operaciones (limitado a un dominio, un subdominio, etc.) está mal definido.

Es un sistema de 20 a 30 años de edad que se parece a su edad. Pero no hay una solución fácil.

    
respondido por el Paco Hope 24.01.2016 - 22:59
fuente

Lea otras preguntas en las etiquetas