¿Por qué debo pagar un certificado SSL?
Para la mayoría de los usos, no hay una buena razón para pagarlos.
Vea la parte inferior para obtener un resumen de las excepciones.
Retrocedamos un paso y expliquemos qué hacen los certificados y cómo.
Lo que comúnmente se llaman "certificados" consisten en dos piezas vinculadas:
- El certificado propiamente dicho , que contiene una clave pública y alguna identificación (como un nombre de dominio).
- La clave privada , que permite al titular (y solo al titular) firmar digitalmente los mensajes de tal manera que puedan verificarse utilizando el certificado anterior.
Si desea un certificado para yourdomain.com
, usted:
- Cree un par de claves privado / público y mantenga la parte privada, bueno, privada.
- Solicite a un tercero confiable ("CrediCorp") que cree un certificado
yourdomain.com
con su clave pública.
- Demuestra de alguna manera a CrediCorp que controlas
yourdomain.com
.
- Coloque la clave privada y el certificado obtenido en su servidor y configure el servidor web para usarlos.
Luego, si Alice visita yourdomain.com
, su navegador obtiene el certificado de su servidor web, junto con un mensaje firmado por su clave privada. Luego su navegador verifica tres cosas:
- Que el mensaje firmado puede ser verificado por su certificado (demostrando que ha sido firmado por la clave privada correspondiente que solo
yourdomain.com
debería tener).
- Que el dominio del certificado es el dominio que el navegador está intentando visitar (
yourdomain.com
).
- Que el certificado es de CrediCorp.
La combinación de estas tres cosas le garantiza a Alice con quien realmente está hablando yourdomain.com
, y no a algún impostor ... Siempre que Alice confíe en CrediCorp .
(También sigue un poco de baile de cripto vudú para convertir esta autenticidad en confidencialidad).
¿ Cómo confía Alice en CrediCorp?
Ese es el verdadero meollo aquí. En resumen, en algún momento CrediCorp dijo "Hey, vamos a hacer certificados". Después de hacer un gran esfuerzo siguiendo muchas reglas , lograron convencer a algunas personas de que CrediCorp es, de hecho, confiable, y solo emitirán certificados correctamente.
En particular, lograron convencer a los creadores de, por ejemplo, Firefox. Como resultado, CrediCorp se incluye en la lista A de Firefox, y Firefox confía en sus certificados de manera predeterminada. Así que, realmente, Alice confía en Firefox, Firefox confía en CrediCorp y CrediCorp confiaba en usted (después de verificar) cuando afirmó que controlaba yourdomain.com
. Es casi como una cadena .
Pero Firefox no solo confía en CrediCorp para emitir certificados yourdomain.com
, sino que confía en los certificados de CrediCorp para cualquier dominio. Y Firefox también confía en ShabbyCorp, para cualquier dominio.
Esto tiene consecuencias. Si alguien logra convencer a ShabbyCorp de que controla yourdomain.com
(porque ShabbyCorp no es muy exhaustivo), puede obtener un certificado de ShabbyCorp yourdomain.com
con la clave privada correspondiente. Y con ese certificado podrían hacerse pasar por su servidor web. Después de todo, ¡tienen un certificado (clave más) para el yourdomain.com
que Firefox confía!
CrediCorp y ShabbyCorp son lo que se llama autoridades de certificación , CA para abreviar. En el mundo real, ComodoSSL y Let's Encrypt son ejemplos de AC. Pero hay muchos más de ellos; Al momento de escribir este artículo, Firefox confía en 154 AC .
Whoa Pero, ¿cómo responde eso a mi pregunta?
Estoy ehm, llegando a eso ...
Aquí está la cosa. La mecánica que describí anteriormente se aplica a todos los certificados. Si tiene un certificado correcto y confiable para su sitio web, funcionará. No hay nada especial sobre los certificados de la marca A versus los certificados de la marca B; todos están sujetos a los mismos requisitos de CA y las mismas matemáticas de cifrado.
E incluso si te gusta más CrediCorp, porque sabes que suenan mucho más confiables, usarlos realmente no te ayudará. Si un atacante puede convencer a ShabbyCorp para que le dé un certificado para su sitio, el atacante puede usar ese certificado para hacerse pasar por su sitio, independientemente de dónde haya obtenido el suyo.
Mientras Firefox confíe en ShabbyCorp, los visitantes no verán la diferencia. (Sí, los visitantes podrían extraer el certificado y buscar allí, ver quién lo emitió. ¿Pero quién lo hace?) En lo que respecta a falsificar certificados, esto hace que todo el sistema sea tan débil como el más de 150 AC más débiles. Por qué sí, eso da miedo, y es probablemente la mayor crítica que la gente tiene de todo este esquema. Aún así, es con lo que estamos atrapados.
El punto es que si no confías en una CA para dar certificados "buenos", obtener tus certificados en otro lugar no te ayuda mucho.
Gotcha, todo está igualmente condenado. ¿Sin advertencias?
Weeeelllll ...
Comencemos por matar el punto que hice en la última sección. Hoy en día es posible bloquear su dominio solo para las CA de su elección utilizando DNS-CAA . Supongamos que confía en Comodo y no confía en otras CA, es posible solicitar a todas las CA que no sean Comodo que no emitan certificados para su dominio. En teoria. (Debido a que DNS-CAA no es verificado por los navegadores, solo mediante la emisión de CA. Por lo tanto, una CA comprometida podría ignorar esta protección).
Si está dispuesto a pasar por ese problema, entonces la pregunta es: ¿es que Let's Encrypt es realmente menos confiable? O menos seguro? La confiabilidad es difícil, ¿cómo cuantificas eso? Todo lo que puedo decir es que, en mi opinión, Let's Encrypt no es menos confiable que otras AC. En cuanto a la seguridad de sus validaciones, son muy similares a lo que hacen las AC comerciales (de todos modos, para los certificados DV). Ver también esta pregunta .
Por lo que vale: la red StackExchange, de la que forma parte este sitio, actualmente utiliza certificados Let's Encrypt. La mayoría de la gente nunca se daría cuenta de esto, y si lo hicieran, dudo sinceramente si significaría mucho para ellos.
Para que un certificado sea significativo, los proveedores de software deben confiar en la CA emisora ; de lo contrario, el certificado no sirve para nada. Usé Firefox como ejemplo, pero realmente quieres que la CA sea confiable por al menos las versiones actuales y algo más antiguas de Firefox, Chrome, Windows, Mac OS X, iOS y Android. Y las docenas de jugadores más pequeños. Todas estas entidades confían en las CA que vale la pena considerar (que incluyen ComodoSSL y Let's Encrypt).
Si una CA se comporta mal o se revela que no es confiable, se eliminará de las varias tiendas de confianza lo suficientemente rápido como para arruinar el día de los propietarios de certificados. Dos ejemplos notables que conozco son DigiNotar y StartCom / WoSign (revisa los artículos, ¡proporcionan ideas interesantes en la dinámica de confianza!). Entonces, si cree que Let's Encrypt se arruinará, o se caerá por alguna otra razón, no usarlos evitará que quede atrapado en esa caída en particular.
Los certificados emplean algo de magia matemática criptográfica ; la pregunta es ¿ qué magia matemática criptográfica ? ¿Qué pasa si es magia débil? Esto es realmente una preocupación real, y las AC también han demostrado que se esfuerzan en actualizar esto. Afortunadamente, los proveedores de navegadores han recogido la holgura al establecer mínimos aquí para que los certificados sean aceptados. Por ejemplo, los certificados que usan RSA-1024 o SHA-1 ahora son rechazados por la mayoría de los navegadores, por lo que cualquier certificado que funcione en la práctica no usa estas primitivas criptográficas obsoletas. El resultado es que es bastante difícil para cualquier CA (incluimos Let's Encrypt) decepcionar más en esta parte.
Antes, más o menos dije que todos los certificados se crean de la misma manera. Mentí, no lo son. En particular, lo que discutí hasta ahora son " certificados de dominio validado (DV)", que es lo que usa la gran mayoría de los sitios web. Proporcionan una medida de certeza de que su navegador realmente está hablando con el dominio que muestra en la barra de URL. También hay certificados de "Validación de organización (OV)" y " Validación extendida (EV)", que requieren verificaciones mucho más elaboradas de las AC. En particular, solo debería poder obtener un certificado EV para somebank.com
/ SomeBank Inc., si realmente puede demostrar que es SomeBank, Inc.
Los certificados EV son mucho más costosos de obtener (estadio: cientos de EUR / USD por año), y pueden ser recompensados con una barra de URL verde o un candado en el navegador, tal vez mostrando "SomeBank, Inc." también. A diferencia de los certificados DV, también ofrecen una idea de a quién podría pertenecer realmente el sitio web. Lo bueno es que pueden parecer más legítimos. La decepción es que los usuarios rara vez les prestan atención, por lo que su efectividad es limitada.
Un atacante con un certificado DV falsificado aún puede hacerse pasar por el sitio, solo sin la pista visual adicional que puede ofrecer un certificado EV, y los usuarios generalmente no notan la distinción. Por el contrario, es posible obtener un certificado EV engañoso para facilitar el phishing. Como resultado, tanto Chrome como Firefox dejarán de lado sus gestos visuales a los certificados EV, y algunas personas creen que desaparecerán por completo.
Si eres un banco, probablemente aún quieras un certificado EV por ahora. De lo contrario, no tanto. Pero si lo hace necesario EV, Cifrar Vamos no es para ti, ya que simplemente no ofrecen certificados EV.
Los certificados solo son válidos por tiempo limitado . Los certificados de una CA comercial típica tienden a ser válidos por un año, pero he visto algo de tres meses a tres años. Los certificados Let's Encrypt son válidos por 90 días , lo cual es un poco corto de ese rango, por lo que deberá renovarlos con frecuencia. Para los usuarios de Let's Encrypt, esto generalmente se automatiza para que los certificados se reemplacen cada 60 días.
Ser capaz de automatizar la renovación con un software ampliamente disponible es en realidad más agradable que la anual. Oh, mierda, ¿mi certificado expiró? ¿Cuál es mi inicio de sesión en la CA? ¿Cómo funciona esto de nuevo? ritual que la mayoría de los sitios pequeños parecen terminar en las AC comerciales.
Antes, lo llamaba aterrador que hay tantas AC que todos debemos confiar. Sin embargo, tener muchas AC también es una ventaja, en el sentido de que eliminar una de nuestras tiendas de confianza tiene un impacto limitado en los usuarios. En particular, expulsar una sola CA solo afectará los certificados emitidos por esa CA. Si todos terminan usando una sola CA (que algunas personas temen que suceda con Let's Encrypt ), concentramos toda nuestra confianza allí y perdemos las ventajas de esa fragmentación.
Y finalmente, hay otros beneficios que una CA paga podría ofrecer, como soporte comercial o una garantía SSL de un millón de dólares . Tengo poca fe en ambos aspectos, pero son cosas que Let's Encrypt no ofrece.
Me duele la cabeza ... Creo que tenía una pregunta.
¡Usa lo que te hace sentir cómodo! Para los certificados DV, hay poco que realmente diferencie a las distintas AC. Utilizo Let's Encrypt tanto de forma profesional como privada, y estoy contento con eso.
Realmente solo veo cuatro posibles razones para evitar Let's Encrypt:
- Si necesita certificados EV (u OV).
- Si no puede o no desea automatizar la renovación del certificado y tres meses de validez del certificado es demasiado corto para usted.
- Si no confía en Let's Encrypt (pero asegúrese de considerar otras medidas como DNS-CAA también, y probablemente debería incluir en la lista negra Let's Encrypt en su navegador también).
- Si cree que Let's Encrypt se suspenderá o se eliminará de los navegadores por algún motivo.
Si ninguno de ellos se aplica a usted, no dude en no pagar sus certificados.