¿Por qué no se usa RFC4255 (SSHFP) para https?

13

Hace algunas horas tuve esta idea, pero, por supuesto, ya existe e incluso hay un RFC ... .
¿Por qué no publicamos la huella digital para el certificado SSL / TLS a través de DNS? Necesitamos DNSSEC para asegurarnos de que la respuesta sea legítima y debemos asegurarnos de que los servidores de nombres estén en un entorno seguro, pero además no veo ningún problema que SSL / TLS no tenga.

Este cambio movería la autoridad para proteger todo nuestro tráfico cifrado de las autoridades de certificación (CA) a los servidores de nombres DNS. Esto podría ser un problema porque en ese caso, todos los proveedores de DNS (que tienen DNSSEC) deberían convertirse en entornos de muy alta seguridad, como lo son ahora las CA. ¿Pero no deberían ser todos los servidores de nombres ya esto? La mayoría de los sitios web usan http simple para tráfico sensible y la mayoría de las personas no se darían cuenta si no hay un candado al iniciar sesión en Google. Yo diría que ya tienen una gran responsabilidad.

Si no confiamos en los servidores de nombres del dominio, podríamos incluir huellas dactilares en los servidores raíz, pero no estoy seguro de cuánta carga adicional sería.

Otro problema es que DNSSEC aún no está implementado ampliamente. Pero el motivo de mi pregunta es porque el IETF está considerando la posibilidad de admitir el cifrado en http / 2.0 sin requerir la verificación del certificado "para que sea más fácil de implementar".

En mi opinión, la seguridad debe hacerse correctamente o no debe hacerse. No le dé a la gente una falsa sensación de seguridad. Pero si vamos a cambiar los protocolos de todos modos (actualizar todos los servidores web), podríamos implementar DNSSEC y hacerlo de la manera correcta (autenticada).

Los problemas / cambios en breve:

  • necesitamos confiar en los servidores de nombres (¿raíz?) en lugar de una tonelada de CAs;
  • necesitamos agregar un tipo de registro dns o extender el uso del registro sshfp; y
  • necesitamos apoyar a dnssec más ampliamente.

¿Me estoy perdiendo algo? ¿Por qué estamos pagando un alto precio por los certificados SSL / TLS cuando todo lo que tenemos que hacer es publicar la huella digital del certificado en un canal autenticado?

El punto de cifrado no autenticado en http 2.0 es fomentar la habilitación sin tener que modificar ninguna otra configuración. Estoy en contra de esto porque es innecesariamente lento (otro viaje de ida y vuelta para el intercambio de claves, que es especialmente malo en el extranjero o con cualquier pérdida de paquetes) y casi no agrega seguridad. Incluso podría proporcionar una falsa sensación de seguridad. En el lado bueno, confunde el tráfico.

Esta propuesta de uso de DNS hace que sea un poco más complicado implementar el cifrado en los servidores web, pero lo hace (al menos casi) tan seguro como el SSL / TLS normal y al mismo tiempo mantiene una disponibilidad generalizada del cifrado muy alta (no creo que Mantendré los precios ridículamente altos de un servidor de nombres habilitado para sshfp / httpfp / tlsfp como hacen con los certificados). El cifrado no autenticado aún puede ser un último recurso cuando todas las demás opciones (certificado firmado, certificado almacenado, huella digital publicada de manera segura) no están disponibles (aunque no se deben mostrar al usuario porque proporciona una sensación de seguridad completamente falsa), pero No estoy seguro de que valga la pena la desaceleración.

Si no es posible usar los servidores raíz para esto, también podríamos usar los servidores de nombres del dominio como "entornos razonablemente seguros" (candado normal) y usar un certificado firmado por CA para EV (barra verde). Luego, dígales a las personas que busquen la barra verde cuando hagan banca en línea. Los servidores de nombres ya tienen una gran responsabilidad, por lo que podría ser lo suficientemente seguro, incluso si no podemos esperar que sean tan seguros como un CA. Al menos sería un sistema mucho más flexible; Estoy restringido a mi dominio y un subdominio para cualquier certificado a un precio razonable (y el subdominio ya está ocupado por "www.").

Mi pregunta nuevamente en breve: ¿Hay alguna razón por la que no usamos un sistema similar a SSHFP para https, si DNSSEC estaba ampliamente disponible?

    
pregunta Luc 27.08.2013 - 21:00
fuente

3 respuestas

16

Hay un RFC para eso . Es parte de lo que DNSSEC debe hacer.

Ahora no tenga demasiadas esperanzas sobre el "dólar superior" o la reducción de los mismos. La necesidad de "certificar" de alguna manera las claves públicas con respecto a los nombres de los servidores no se elimina mágicamente al cambiar a DNSSEC. La función "CA" se acaba de mover y los costos asociados todavía están allí. Se puede predecir que si los registradores deben asumir estos costos, entonces sus precios subirán. Tarde o temprano, alguien tendrá que pagar por ello, y tengo la firme sospecha de que será el propietario del servidor SSL.

Filosóficamente , no está claro si la fusión de la estructura de certificación (la PKI) y la estructura de nombres (el DNS) es una buena idea. La fusión simplificaría las comunicaciones entre DNS y PKI cuando se trata del caso específico de emisión de certificados vinculados a nombres de host; pero también significa que las dos responsabilidades se entrelazan. Se necesita una dosis sustancial de ilusiones para creer que quien sea un buen registrador también sería un buen CA; los dos tipos de actividades son vagamente similares, pero no idénticos.

Además, se supone que los certificados tienen un alcance más allá de los servidores HTTPS; deben ser utilizables en contextos que no tienen relación alguna con el DNS y los nombres de host, por ejemplo al firmar software (aplicación, controladores ...).

Económicamente , no cambiaría mucho. Entre las CA comerciales, la más utilizada es VeriSign, también conocida como Symantec. Cambiar a DNSSEC significa que la autoridad de certificación definitiva ya no será VeriSign, pero quienquiera que administre la mayor parte del DNS raíz, es decir, ... VeriSign. Ahora ESO sería un cambio, ¿no?

Políticamente , habría problemas con el "estado CA". Muchas de las docenas de CA en las que el sistema Windows confía de forma predeterminada son "CA de vanidad" patrocinadas o incluso operadas por varios gobiernos. Los mismos gobiernos no tienen intención de operar infraestructuras relacionadas con el DNS que requieren mucho más ancho de banda y disponibilidad; y les molesta que sus certificados de precioouuusss se conviertan en "ciudadanos de segunda clase".

Por seguridad , esto no es un problema. Los eventos de certificados falsos son muy raros; nos enteramos de uno de estos casos por año . La mayor parte de los fraudes y phishing relacionados con Internet y otros ataques no se basan en engañar a las CA existentes. En otras palabras, el sistema de CA actual funciona . No arregles lo que no está roto. Sí, el sistema de CA parece frágil y propenso a fallas, pero a pesar de mucha publicidad sobre las infracciones ocasionales, el hecho es que sobrevive.

Resumen: los estándares están listos, se publican los RFC, se escribe el software. Ahora todo lo que falta es una razón para cambiar de un mundo "comercial CA X.509" a un mundo "registrador comercial DNSSEC". Es difícil ver qué bien haría en realidad.

    
respondido por el Thomas Pornin 27.08.2013 - 21:44
fuente
6

El CERT RR ha sido desaprobado. La propuesta actual para poner material de clave pública en DNS se llama DANE. Han definido un tipo de registro TLSA que es documentos en RFC 6698 . Esto permite que un administrador de dominio haga valer un certificado específico o una CA para un servicio en particular.

    
respondido por el Richard Salts 28.08.2013 - 07:12
fuente
3

Sí existe, se llama DANE - enlace (el CERT RFC no ha tenido ninguna tracción, No sé por qué).

Para generar los registros puedes usar esto:

enlace

Este complemento de Firefox puede validarlos:

enlace

desafortunadamente no está completo.

El equipo de patrulla de certificados tiene un complemento actualizado:

enlace

pero la dosis tampoco parece funcionar :(

Parece que no hay ningún otro soporte para otros navegadores, chrome tiene soporte escrito pero no publicado, consulte esta publicación del blog (Si TLSA es importante para usted, ¿puede enviarle un correo electrónico a Adam?):

enlace

Tenga en cuenta que TLSA no solo le permite validar un certificado, sino que también le permite al propietario del sitio afirmar que el certificado utilizado en su sitio solo estará firmado por una CA en particular, lo que de alguna manera ayuda a poner el pícaro / hackeado Problemas de CA para descansar.

Recuerde que cualquier CA (o una filial de una CA, o una subsidiaria de una CA, etc.) puede firmar un certificado para cualquier dominio . ¡Para que el ecosistema de CA esté seguro, cada CA debe estar seguro!

    
respondido por el JasperWallace 09.09.2013 - 18:04
fuente

Lea otras preguntas en las etiquetas