Certificados SSL… ¿gratuitos?
Esta semana estuve trabajando sobre una noticia interesante en el mundo de la seguridad. Para ello, me gustaría que todos sepan de qué hablamos cuando hablamos de HTTPS, y lo haré muy brevemente:
Un sitio que posee https (la URL empieza con https://www.) envía y recibe la información entre el servidor y el usuario de forma cifrada. Esto ofrece seguridad para ataques de intercepción de contenidos. Para usar el protocolo https, es necesario contar con un certificado digital SSL. Ese certificado digital tiene que estar firmado por una entidad certificadora (CA).
Los navegadores poseen un listado de entidades certificadoras que son aceptadas por el mismo. Si un certificado esta firmado por una entidad certificadora no válida, el usuario debe aceptar “correr el riesgo” de visitar de todas formas la página. De esta forma, uno puede levantar sitios web con cifrado sin necesidad de adquirir un certificado con una CA válida para los navegadores.
Si no entendieron la explicación anterior, paren y lean algo más sobre Hypertext Transfer Protocol Secure. Caso contrario, sigan.
Sobre el protocolo HTTPS siempre existió un estilo de mito. Con el crecimiento de los ataques de Phishing, hace tiempo que bancos, entidades financieras y sobre todo profesionales en seguridad transmiten a los usuarios la importancia de chequear la existencia del HTTPS en un sitio web para ver “si es seguro”.
La realidad es que este es un consejo válido en un contexto en que los atacantes y phishers no acostumbraban instalar certificados en sus servidores, pero no era un consejo eterno, y se creó un falso consejo o mito en los usuarios: si un sitio tiene HTTPS, es seguro.
Lamentablemente esto no es así. HTTPS, como ya se explicó, garantiza la utilización de certificados para que la información entre cliente y servidor viaje cifrada. Es decir, garantiza confidencialidad en la transmisión de los datos. Pero no garantiza que esos datos no están viajando cifrados a un atacante o phisher.
Encima, me entero la semana pasada por noticias en medio digitales, que Internet Explorer aceptará certificados digitales gratuitos. Para ser más claros: con muy poco esfuerzo (unos cuantos clics) y sin necesidad de abonar un centavo, un atacante puede sacar un certificado SSL y utilizarlo para levantar sitios maliciosos con HTTPS. Es cierto que esto es algo que podían hacer con anterioridad, pero pagando. Y este era sin duda un impedimento importante a la hora de llevar a cabo un ataque de Phishing.
En el Blog de Laboratorio de ESET Latinoamérica, escribí el post “Cazando mitos: HTTPS” donde extiendo un poco más sobre esta idea, que finalmente resumo así:
- “Al acceder a un sitio que posea un formulario donde se ingresa información personal, debe verificarse que el mismo utilice el protocolo HTTPS”… VERDADERO
- “Un sitio donde se ingresa información confidencial que no posee HTTPS no es seguro”…VERDADERO
- “Utilizando el protocolo HTTPS, la información es cifrada”… VERDADERO
- “Siempre que un sitio posea HTTPS será seguro”… FALSO
Por otro lado, unos días más tarde hicimos un video demostrando qué fácil es realizar un ataque de Phishing utilizando un sitio con el protocolo HTTPS. Este es el video educativo:
Por último, me queda una duda importante que quería compartir aquí en el blog, y que en parte quizás ustedes puedan aportar más luz al asunto.
La pregunta es: ¿por qué aceptar entidades certificadoras que otorgan certificados SSL gratuitos? La pregunta simplificada es ¿por qué los navegadores decidieron aceptar estos certificados?
Digo, porque uno que estudió el protocolo HTTPS entendía que el hecho de que los certificados se debían abonar (incluso a veces con costos realmente accesibles), era en parte una legitimidad para los sitios que lo utilizaban, entendiendo que realmente la información que se traficaba justificaba adquirir un certificado. Siguiendo esta lógica, la respuesta es: a los navegadores les interesa la usabilidad, y no la seguridad.
Sin embargo, por otro lado, se puede pensar de otra forma. Como ya se explicó, si un atacante quiere hacer un sitio falso con HTTPS, ya podía hacerlo abonando costos bajos de dinero. Entonces, el hecho de que ahora lo pueda hacer de forma gratuita no cambia un riesgo que ya existía. Además, el hecho de pensar en la usabilidad no significa no importar la seguridad, y la realidad es que si un usuario entiende qué es HTTPS, esto no representa un problema de seguridad. ¿Me explico? Por si no quedó claro, el potencial problema de seguridad que se abre con los certificados gratuitos es tal, justamente por la existencia de un mito, y de personas que erróneamente creen que con ver el protocolo es suficiente para estar tranquilo. Pero los navegadores, ¿tienen que preocuparse de la gente que tiene un concepto equivocado? Cualquier persona que entienda qué es y para qué está HTTPS, sabrá que hay otras medidas de protección para ver si un sitio es o no seguro.
En fin, tiendo a inclinarme por esta última alternativa luego de haber pasado un par de días ubicado en la primera.
Ustedes, Si llegaron hasta acá… ¿qué piensan? 
A mi me parece EXCELENTE lo de que se empiecen a aceptar certificados gratuitos, de hecho deberían aceptar certificados auto-firmados.
perdón, le di al botón “enviar comentario” antes de tiempo XD (mas mal tino que otra cosa):
continuo…
Me parece genial esto, pero también se le debería aclarar al usuario muchas cosas, los niveles de seguridad.
El problema que yo veo con los certificados es que el SSL requiere un certificado “firmado” por alguien que cobra, en mi opinión deberíamos tener esto separado, por un lado el SSL y por el otro el certificado en sí.
¿por qué?, por que a muchos solo nos interesa ofrecerle a nuestros clientes la seguridad de que su información y contraseñas están seguros, al menos en el tráfico.
por otro lado, a mi no me importa ni me molestaría adquirir un certificado que certifique que el sitio ES MIO, que yo EXISTO, que mi empresa EXISTE, pero lo que mas me interesaría yo creo es la antigüedad, que entre mas tiempo lleve yo con mi página mas “valida” sea como página real. Los Phisers no usan webs por más de unos cuantos meses, y aveces semanas.
Hay muchas muchas cosas alrededor de esto, yo en lo personal realicé un experimento, haciendo un pequeño “virus” que instalaba mi CA en las PC’s víctimas, y cambiaba sus DNS. Esto me permitió redirigir el tráfico de http://www.banco-x.com a mi servidor y como mi CA estaba registrado en la víctica tener SSL con el dominio ORIGINAL del banco.
Yo soy de México y no veo nada que me impida instalar este pequeño Virus en ciber cafés e incluso en empresas.
Saludos
Seba, a mí me parece mucho más acertada tu opinión del último párrafo, donde en realidad, que haya certificados gratuitos firmados por CAs ya incluidas en los browsers, no cambia absolutamente nada. Lo otro me parece pecar de inocente, sabiendo la plata que se mueve alrededor de este tema (ver algunos informes de la gente de Hispasec), creer que sólo por pagar un certificado a una CA estás imponiendo una barrera a los “ladris” de internet.
Me parece que SSL es técnicamente muy bueno, los browsers lo implementan relativamente bien, lástima que para hacer las cosas más cómodas al usuario siempre hay que pagar en cuanto a seguridad; y ya sabemos que la capa 8 es la más débil.
Por otra parte, a mí me parece muy bueno que haya CAs que generen certificados de sitios en forma gratuita y que además estén incluidos por defecto en los browsers; más viendo lo “molesto” que se puso Firefox (por poner un ejemplo) cuando entramos a un sitio con SSL donde no coinciden todos los chequeos del certificado del mismo. Esto lo obligaba a uno a pedir que importen el certificado del CA “propio”.
Se me ocurre que la solución puede estar por la de “niveles” o “categorías” de certificados, donde los certificados de entidades financieras tengan el nivel máximo de importancia, y los de un, por ejemplo, webmail, menos criticidad. De esa manera, el browser podría “reforzar” visualmente/operativamente en mayor o menor medida el comportamiento con el usuario. Esto mejoraría el estado actual de los certificados que uno tiene en el browser, donde hoy los certificados están en una “bolsa de gatos”.
En fin, son ideas… Sería bueno agregar algo de todo esto en SSL (v4.x?), que contemple no sólo lo técnico, sino toda la cadena de uso, desde que se emite un certificado de un CA, hasta que se generan certificados de sitios, usuarios, y cómo se vincula todo esto con los browsers, servidores de correo, etc.
Mis 2 ctvs.
¡Saludos!
PD: Fijate que pifiaste en “confidencialidad en la transmición de los datos.”, es “transmisión”.
Hola Marcelo,
Gracias por el comentario! Un par de cosas:
1. Para seguir fomentando la duda, pensá que aunque es factible para un atacante sacar un certificado SSL pago para su sitio falso, no es “tan fácil” que lo hagan por más plata que se mueva. Esto es debido a que utilizan cientos de dominios que duran unos pocos días y luego son dados de baja, por lo que no tendrían que pagar un certificado sino muchos.
2. El error de ortografía fue arreglado. Gracias.
Saludos.
Que tal. Pues yo creo que, además de los certificados, deberían crear el dominio “.bnk”, exclusivo para instituciones bancarias. Con esto nos evitaríamos bastantes problemas.
Digo, si hay .edu, ¿por qué no .bnk?
Creo yo.
Saludos.
pero ¿cuantas instituciones bancarias hay? ¿como las autentificarias que realmente son instituciones bancarias? y finalmente ¿y si alguien se hace de un .bnk?
@Hsilamot: pues habría menos que .com, seguro. Para autentificarlas, pues habrá métodos, así como los hay para otorgar los .gob, .gov y .edu
Por tanto, no sería tan fácil hacerse de un .bnk
Vamos, que métodos para hacerlo con seguridad y fiabilidad, de haberlos, haylos.
Un saludo
si, pero la verdad, queramoslo o no los profesionales del phiseo son eso: profesionales, ya se las ingeniarian.
de cualquier forma ya hay alternativas “seguras” como son el .cc (que se supone es dificil de comprar) además de que en mi país (méxico) los bancos les encanta confundirnos mas a la gente, por ejemplo, Banamex (donde yo estuve) mucho tiempo fue asi:
acceso: http://www.banamex.com
login: http://www.banamex.com.mx/bancanet
login nuevo: boveda.banamex.com.mx
manejo: bovedabanamex.com/ETCETC
manejo: banamexporinternet.com/ETCETC
manejo actual: boveda.banamex.com.mx
afortunadamente hasta despues de años por fin todo lo centralizaron en un solo dominio, pero muchos bancos hacen eso, se crean casi un dominio por cada directorio que tienen, de hecho, dejame decirte que el dominio actual http://www.banamex.com.mx perteneció a un phiser durante dos o tres años antes de que banamex se lo quitara.
hablando en términos de seguridad esto no es algo que sea culpa de los bancos o el usuario, es culpa de ambos, si el usuario es cuidadoso, es difícil que exista un ataque, si el banco es cuidadoso es también difícil, sin embargo, una omisión por cualquiera de los dos nos pone en riesgo.
mi conclusión es que esto no es una lucha de un solo lado, necesitamos atacar a los phisers desde el lado del banco hasta el lado del cliente =)