Portada
mis comunidades
otras secciones
#4:
#3 Pero en el caso de los certificados da igual que se software libre o no, simplemente con que la entidad certificadora envíe una copia de la clave privada al gobierno, es más que suficiente para interceptar las comunicaciones ssl del servidor deseado.
Es por eso, que la única forma real de garantizar que nadie tiene una copia de la clave privada de tu certificado para ssl es generando un certificado autofirmado, eso si, con la problemática que conlleva, ya que el cliente recibirá un aviso en el navegador conforme ese certificado no ha sido generado por ninguna entidad certificadora reconocida.
Es por eso, que la única forma real de garantizar que nadie tiene una copia de la clave privada de tu certificado para ssl es generando un certificado autofirmado, eso si, con la problemática que conlleva, ya que el cliente recibirá un aviso en el navegador conforme ese certificado no ha sido generado por ninguna entidad certificadora reconocida.
#2:
Y me llamaban loco cuando decía que me fiaba más de un certificado generado por mi que uno proporcionado por una entidad certificadora.
#3:
Está claro que lo hacen. Hacen muchas cosas peores que esa (véase SITEL), ¿Cómo no iban a hacer eso que es tremandamente más fácil?
Es por eso que los sistemas abiertos y el software libre son cada vez más importantes. La posibilidad de auditar cómo funciona algo que usas es lo único que te garantiza la no manipulación.
Es por eso que los sistemas abiertos y el software libre son cada vez más importantes. La posibilidad de auditar cómo funciona algo que usas es lo único que te garantiza la no manipulación.
#7:
#4 De ahí que en mi comentario haya puesto "sistemas abiertos y software libre", y no sólo software libre.
Efectivamente, en el caso de los certificados, lo que hace falta es que puedas ser tú mismo quien se autofirme el certificado. Obviamente, si tienes que pasar por una autoridad certificadora, y no hay forma de que te asegures de que ellos no se quedan una copia de tu clave privada, el sistema no es abierto. Hay partes del sistema que no puedes auditar y de las que te tienes que fiar. Y en esas es, precisamente, donde seguro que los gobiernos están metiendo la mano.
Efectivamente, en el caso de los certificados, lo que hace falta es que puedas ser tú mismo quien se autofirme el certificado. Obviamente, si tienes que pasar por una autoridad certificadora, y no hay forma de que te asegures de que ellos no se quedan una copia de tu clave privada, el sistema no es abierto. Hay partes del sistema que no puedes auditar y de las que te tienes que fiar. Y en esas es, precisamente, donde seguro que los gobiernos están metiendo la mano.
Comentarios
Y me llamaban loco cuando decía que me fiaba más de un certificado generado por mi que uno proporcionado por una entidad certificadora.
#2 Si, a mi también me trataron de loco:
dnie-britanico-hackeado-12-minutos#c-10
#21 En ese comentario estabas equivocado. Las tarjetas como los DNIes generan sus propias claves privada/publica en su interior y mandan al gobierno la clave pública y no al reves. Eso es la teoría claro, yo tampoco tengo muy claro si no mandarán también la clave privada por "motivos de seguridad".
#22 En el caso de IZENPE (la CA de la CAV) se puede decir que también funciona así pero te envian una SmartCard con la clave privada y estas tarjetas se supone que generan su propia clave privada y que esta no es legible por un lector, luego no deberían poder hacerse con ella a no ser que hayan modificado la estructura interna de la propia tarjeta.
#24 Sigue siendo un caso bastante similar, puesto que el hardware (el propio DNIe) lo obtienes sin saber como funciona.
En relación al voto de elzo en #28, me refiero a que te dan el generador de claves y no puedes aportarlas tu ni saber como se han generado en detalle. Pero gracias por votar y no argumentar nada
Está claro que lo hacen. Hacen muchas cosas peores que esa (véase SITEL), ¿Cómo no iban a hacer eso que es tremandamente más fácil?
Es por eso que los sistemas abiertos y el software libre son cada vez más importantes. La posibilidad de auditar cómo funciona algo que usas es lo único que te garantiza la no manipulación.
#3 Pero en el caso de los certificados da igual que se software libre o no, simplemente con que la entidad certificadora envíe una copia de la clave privada al gobierno, es más que suficiente para interceptar las comunicaciones ssl del servidor deseado.
Es por eso, que la única forma real de garantizar que nadie tiene una copia de la clave privada de tu certificado para ssl es generando un certificado autofirmado, eso si, con la problemática que conlleva, ya que el cliente recibirá un aviso en el navegador conforme ese certificado no ha sido generado por ninguna entidad certificadora reconocida.
#4 Las entidades certificadoras tienen la clave PRIVADA??????????????????????
Para que?????????????
Pues es q eso es un fallo de seguridad tremendo, nadie mas que tu tiene que tener tu clave privada, por eso se llama privada....
Imagino que no sera asi, imagino que lo que ocurrira es que esas certificadoras permitiran a los estados cambiar la clave publica por una suya y hacer ataques man-in-the-middle
#5 Explicándolo así muy por encima las CA tienen su clave privada, que es la raíz con la que se generan los certificados SSL. Si los gobiernos tienen acceso a la raíz del CA en cuestión, los certificados generados por ellos podrían ser vulnerables.
Yo entiendo lo siguiente: Google (por decir algo) le pide su certificado normal a Verisign y si un usuario cualquiera se conecta por https la conexión es segura. Ahora bien, aquí llegan los servicios secretos chinos y le dicen a la Oficina de Correos de Hong Kong (una certificadora como Verisign) fírmame esta clave privada como si yo fuera Google, a lo que la Oficina de correos accede. Los servicios secretos chinos entonces instalan una cajita en el ISP (la cajita es hardware, pero bien podría introducirse en una actualización de firmware) por la que pasa el tráfico. Cuando la cajita está apagada las conexiones seguras se establecen con google y el certificado de google se verifica que ha sido firmado por Verisign. Cuando se enciende, al iniciar la comunicación segura, la cajita intercepta todo el tráfico seguro a google, y cuando el usuario intenta comprobar el certificado que recibe es el que ha firmado la oficina de correos de HK no el de Verisign, no obstante el certificado es válido y el usuario piensa que está seguro cuando hay un "hombre en el medio". Obviamente como dice #6 si el gobierno tiene directamente la clave privada de una CA puede hacer lo que quiera.
#12 Pero eso tal como yo lo veo no sería principalmente problema de la CA, más bien de los navegadores y de los usuarios porque tú en cualquier momento puedes eliminar una CA de tu navegador si no confias en ella.
#16 Te envía tu clave pública firmada por su (la de la CA) clave privada de modo que un usuario sabe que eres quien dice ser y que encriptando con esa clave pública sólo tú que tienes la clave privada vas a poder desencriptar.
#13 Si lo llevas al extremo no te fías de nadie, claro está: borras todas las CA, aceptas los certificados de los servidores como excepción y rezas para que no haya un "man in the middle"
#6: la clave privada de la autoridad certificadora sólo sirve para falsificar certificados. Poseer esta clave no permite descifrar la comunicación pero sí hacer un ataque tipo "man in the middle", o sea hacerse pasar por el servidor real con un intermediario. Teniendo la clave de CUALQUIER autoridad certificadora válida, el navegador no dará ningún aviso si te ponen un servidor falso que reciba el tráfico y lo reenvíe.
#32 Exacto, lo que hacen es generar un certificado falso para que la comunicación no provoque error alguno de certificados.
De esta forma:
[PC_Víctima] [ESPÍAS] [SERVICIO_SUPLANTADO]
Así, tú navegador sólo sabe que estás conectando con un sitio que es quien dice ser (gracias al certificado falso), pero que no es el servicio que tú crees que es. La comunicación viaja cifrada entre tu ordenador y el de los "espías", que a su vez, reenvían la información con el servicio final, devolviéndose la respuesta por el canal ssl seguro totalmente falsificado.
Cualquier persona puede hacer un Man-In-The-Middle a servicios como Gmail usando Ettercap en una red wifi abierta, sacándose así usuarios y contraseñas. Aquí un ejemplo:
El problema es que este procedimiento como se aprecia en el vídeo, genera avisos de certificados no conocidos, y para alguien avispado que no acepte todo mensaje de error, la suplantación salta a la vista y no tendría éxito.
Lo que nos traemos entre manos es usar un certificado FALSIFICADO por las propias CA para que el navegador no avise, y acabes siendo víctima de un perfecto MITM.
#32 Poseer esta clave no permite descifrar la comunicación pero sí hacer un ataque tipo "man in the middle", o sea hacerse pasar por el servidor real con un intermediario.
Hacerse pasar por alguien es suplantación, nada que ver con el man-in-the-middle.
#38 Nada que ver tampoco: El mitm suplanta a los dos, a uno con respecto al otro y viceversa.
#38 No, nada que ver. Precisamente se basa en suplantación, pero no tiene nada que ver.
Madre mía...
#40 Madre mía
- Conexión auténtica: A habla con B. esquema: A-----B
- Conexión con suplantación: X se hace pasar por A
esquema: X-----B
- Conexión con man-in-the-middle. X está en el medio
esquema: A-----X-----B
Los requisitos son distintos. Aunque B no usara autentificación segura, es necesario poder controlar todas sus conexiones para poder hacer man-in-the-middle. Esto es posible cuando las conexiones deben pasar obligatoriamente por un proxy concreto (universidad, empresas).
Pero incluso en ese caso, no podrá suplantar a los "notarios de la red", que permitirían detectar el ataque.
https://www.networknotary.org/
#41 Pero vamos a ver, no te das cuenta de que me das la razón... ¿doblemente?
En este caso el MITM es una doble suplantación de identidad, que permite ponerse en medio de una conexión sin que ninguna de ambas partes se den cuenta.
De tú esquema de suplantación.
Suplantación 1: (A ----- X)
Suplantación 2: (X ----- B)
MITM
(A ----- X ) + (X ----- B)
Ambas partes legítimas, A y B, creen estar hablando entre ellas, cuando realmente están hablando con un nodo maligno X, que está espiando todas las comunicaciones a la vez que las reenvía para pasar desapercibido.
Este tipo de MITM tiene mucho que ver con la suplantación de identidad, obviamente.
#5 Las tienen porque en muchos casos los certificados no sólo firman, sino que además (en este caso) cifran. El problema es que si lo que estás cifrando es, por ejemplo, el correo electrónico del curro y te pasara algo a tí y a tu tarjeta (piensa en un accidente de avión), la empresa debería ser capaz de recuperar tus correos (bueno, ésta es un área un poco gris, no sé hasta que punto puedes hacerlo, pero la empresa quiere asegurarse la capacidad técnica de hacerlo).
Por supuesto, para evitar abusos, las CAs medianamente serias tiene un sistema por el cual, para recuperar tu clave privada, necesitas tener un mínimo de administradores presentes (en plan, 4 de 5), para evitar que un administrador con malas intenciones abuse el sistema. Sin embargo, en cualquier caso, todo ésto puede ser robusto* tecnológicamente, pero no deja de ser un sistema gestionado por seres humanos, que si algo nos dice la historia, son falibles a más no poder.
* Robusto, que no infalible, ojo... cada vez se tarda menos en romper claves, y no me extrañaría que hubiera ya maneras de romper claves de 1024 en un tiempo razonable.
#4 De ahí que en mi comentario haya puesto "sistemas abiertos y software libre", y no sólo software libre.
Efectivamente, en el caso de los certificados, lo que hace falta es que puedas ser tú mismo quien se autofirme el certificado. Obviamente, si tienes que pasar por una autoridad certificadora, y no hay forma de que te asegures de que ellos no se quedan una copia de tu clave privada, el sistema no es abierto. Hay partes del sistema que no puedes auditar y de las que te tienes que fiar. Y en esas es, precisamente, donde seguro que los gobiernos están metiendo la mano.
#7: el problema de los certificados autofirmados es que al no tener manera de validarlos, cualquiera puede interceptar el tráfico y reenviarlo sin que el usuario tenga forma de darse cuenta.
La autoridad certificadora es como el "notario" que certifica que una firma no es falsa.
#4 ¿Desde cuando una CA genera o tiene acceso a las claves privadas de los usuarios? Una CA lo que hace es firmar con su clave privada la clave pública de un usuario junto a información de ese usuario para decir de alguna manera : este tio es quien dice ser y yo doy fe. Vamos que es una especie de notario en el mundo digital.
Vamos que decir que una CA puede descifrar comunicaciones basadas en criptografía asimétrica es una burrada como una casa.
#10 No se como funcionará en tu caso, pero con las entidades certificadoras que he trabajado, me piden los datos de la empresa, nombre de servidor, etc. Luego hacen sus propias averiguaciones para saber si realmente somos quien decimos ser, te llaman por teléfono (buscando ellos la información de la empresa) y finalmente te envían el certificado.
#14 Pues eso, una CA se encarga de validar que eres quien dices ser y en base a eso te hace un certificado que contiene entre otras cosas tu clave pública (y no la privada como han dicho por ahí arriba).
#15 Solo con la clave privada puedes descifrar los mensajes generados con la clave pública.
La entidad certificadora te envía un certificado que contiene ambas claves, la pública y la privada.
#16 Perdona pero eso no tiene ningún sentido, si la CA te envia tu clave privada ya no te sirve para nada porque otra entidad ya es capaz de desencriptar los mensajes que van dirigidos a ti. Te copio de wikipedia:
"El mecanismo habitual de solicitud de un certificado de servidor web a una CA consiste en que la entidad solicitante, utilizando ciertas funciones del software de servidor web, completa ciertos datos identificativos (entre los que se incluye el localizador URL del servidor) y genera una pareja de claves pública/privada. Con esa información el software de servidor compone un fichero que contiene una petición CSR (Certificate Signing Request) en formato PKCS#10 que contiene la clave pública y que se hace llegar a la CA elegida. Esta, tras verificar por sí o mediante los servicios de una RA (Registration Authority, Autoridad de Registro) la información de identificación aportada y la realización del pago, envía el certificado firmado al solicitante, que lo instala en el servidor web con la misma herramienta con la que generó la petición CSR.
En este contexto, PKCS corresponde a un conjunto de especificaciones que son estándares de facto denominadas Public-Key Cryptography Standards."
#17 Tienes razón, y en la mayoría de los casos funciona así, pero por desgracia, algunos que trabajamos para la admin pública dependemos de nuestra propia entidad y son ellos los que nos envían los certificados.
#17 Conitnuación del comentario #22:
Y otra cosa que se me olvidaba, dejando un poco de lado el tema de los certificados para servidor, ¿te has fijado que ocurre con los certificados personales?
Tanto FNMT como Catcert (no he tenido ocasión de probar otros) te envían el certificado completo, con clave pública y privada.
Y cómo hacen? porque la autoridad certificadora nunca tiene acceso a la clave privada. Bueno, al menos no si la clave se genera como debería.
Es cierto que algunas autoridades ofrecen al usuario la posibilidad de darles todo el trabajo hecho, o sea que les generan el par de claves y les firman la clave privada. Pero si el administrador del sitio está preocupado por la seguridad no tiene más que buscar en internet las instrucciones de cómo usar openssl para generar el par de claves, generar el requerimiento de firma y enviarlo a la autoridad certificadora.
#4: la autoridad certificadora no tiene por qué tener acceso a la clave privada. Ellos lo único que firman es la "fingerprint" de la clave privada. Para eso se genera el archivo .csr que es el "Certificate Signing Request".
Si se hace de esta forma la autoridad certificadora no tiene ningún dato que no se pueda obtener de todas formas analizando el tráfico.
Dios que guapo, la peña no tiene idea de como funciona el modelo de cifrado/criptografia/clave asimetrica pero habla sin pudor alguno y corrige a quien lo esta diciendo bien
.
Para que no impere la tonteria pondre mi granito de arena diciendo como funciona el modelo. Describamos el escenario:
Alice quiere enviarle un mensaje a Bob y no quiere que nadie mas pueda leerlo y ademas que Bob sepa que el mensaje efectivamente lo envia Alice. Cada uno de ellos tiene una clave privada, LA CUAL SOLO TIENEN ELLOS y una clave publica, la cual puede ver todo el mundo. Para su cometido, Alice dispara el siguiente mecanismo (a grandes rasgos, no entrare en el formato exacto de estos mensajes):
- Alice le pide a una CA la clave publica de Bob.
- La CA le devuelve a Alice la clave publica de Bob.
- Alice coge su mensaje y lo cifra usando su clave privada y luego lo vuelve a cifrar usando la clave publica de Bob.
- Le envia el mensaje a Bob.
- Bob recibe el mensaje.
- Bob le pide a una CA la clave publica de Alice.
- La CA le devuelve a Bob, la clave publica de Alice.
- Bob descifra el mensaje usando su clave privada (ha deshecho el cifrado con su clave publica) y luego descifra de nuevo usando la clave publica de Alice (ha deshecho el cifrado con la clave privada de Alice) y ya puede leer el mensaje (el cual solo conoce Bruce Schneier por cierto).
En todo este proceso la CA SOLO TIENE CLAVES PUBLICAS. Otra cosa es que la CA haya dado su clave privada a Juan o Pepe, en cuyo caso Juan o Pepe podran enviar mensajes haciendose pasar por la CA, pero en ningun caso en el modelo la CA tiene que tener la clave privada, si te la piden te la estan metiendo doblada.
Y para que esta explicacion no se convierta en mas ruido voy a dejar simplemente este enlace. http://www.cs.rutgers.edu/~tdnguyen/classes/cs671/presentations/Arvind-NEWDIRS.pdf
#23 Ese es otro escenario posible que para ser efectivo tendría que complementarse haciendo que el servidor DNS dirigiera al usuario al servidor falso, una vez ahí se crearía una conexión segura con los falsificadores gracias al certificado y por ejemplo el usuario daría sus credenciales del banco con total tranquilidad, ya que el navegador cree que todo es normal y en realidad estás conectado a un servidor en Uzbekistán.
#29 ¿el último paso no debería ser comprobar la firma en lugar de desencriptar? es decir Bob ya puede leer el mensaje, pero no sabe si se lo ha enviado Alice hasta que comprueba con la clave pública de ella que el mensaje ha sido firmado con la clave privada de Alice.
#35 O tener controladas las comunicaciones a nivel ISP para redirigir el tráfico a su antojo. O entrar en la red wifi que use la víctima... seguro que hay muchas posibilidades.
No sé si conocéis esta utilidad online para testar la calidad de la configuración SSL de cualquier servidor:
https://www.ssllabs.com/ssldb/analyze.html
Está muy bien documentada y parece fiable, si bien yo no soy un experto y desconozco el grado de validez de los resultados.
Con todo y a partir del listado de 100 entidades certificadoras confiables para IExplorer que aparece linkado en el artículo de EFF he extraido las españolas y las he pasado por el test, he aquí los resultados:
Ministerio del Interior
http://www.mir.es No Pasa | Grado F0
Fábrica Nacional de Moneda y Timbre (FNMT)
http://www.cert.fnmt.es No Pasa | Grado F0
Government of Spain (CAV), Izenpe S.A.
http://www.izenpe.com No pasa | Grado F0
Agencia Catalana de Certificacio (CATCert)
http://www.catcert.cat No pasa | F0
Autoritat de Certificació de la Comunitat Valenciana (ACCV)
http://www.accv.es No Pasa | Grado F0
Agencia Notarial de Certificación (ANCERT)
http://www.ancert.com No pasa | Grado F0
Red Abogacía
http://www.redabogacia.org No Pasa | Grado F0
Colegio de Registradores Mercantiles
http://www.registradores.org/ Pasa | Grado B73
Internet Publishing Services s.l. (ipsCA)
http://www.ips.es/ No permite Análisis
Autoridad de Certificacion Firmaprofesional
http://www.firmaprofesional.com/ Pasa | Grado A85
Camerfirma
http://www.camerfirma.com/ Pasa | Grado C59
EDICOM
http://acedicom.edicomgroup.com No pasa | Grado F0
Tela marinera, de las web del gobierno, para empezar, ni una pasa el test.Vamos que si en su propia casa de herrero están así.. como para confiarse.
Tal y como yo lo tenía entendido (corregidme por favor) cuando contratas a una CA para que firme tu certificado sólo es necesario enviarle una solicitud de firma de tu clave privada, no la clave privada en sí. Es decir, yo creo mi certificado en mi servidor y pido (normalmente pagando) a la CA que me lo firme.
Por lo que he entendido (y probablemente me he perdido algo), lo que está pasando es que la mayoría de navegadores tienen por defecto muchas CA en la lista de emisoras de confianza.
Pongamos que una de estas CA no es buena haciendo su trabajo y "Malvados SA" pide que le firme un certificado a nombre de "meneame.net". Entonces "Malvados SA" pueden hacer un ataque "man in the middle" de manera que cuando yo visite una web segura de "meneame.net" en realidad esté visitando la web de "Malvados SA" pero el navegador no me dirá "este certificado no es de meneame" porque yo tendré en la lista de certificados de confianza a una CA mala.
¿Quien controla la lista de CA de confianza por defecto en los navegadores?
Por otro lado, si un gobierno del que no te fias está en la lista de emisoras de certificados de confianza de tu navegador, tienes un problema gordo porque puede emitir certificados a nombre de quien sea y usarlos como quiera, no?
(Que alguien me corrija, que no estoy muy seguro de lo que digo)
¿Alguien tiene alguna duda al respecto?
No soy un experto, pero creo que os estáis haciendo unas pajas mentales con la clave privada de pelotas. Es mucho más fácil que eso.
El gobierno de EEUU llama a la puerta de un CA, le planta el maletín de billetes y la amenaza de ir a por ellos si no colaboran, les piden que firmen un certificado FALSO que afirme que el origen de la conexión es [Empresa_X] y ya está. Una vez instalado, existen dos servidores que supuestamente son identificados como de la [Empresa_X], uno real, y otro falso.
Con eso ya pueden hacer un Man-In-The-Middle completo y entre otras cosas, acceder a tus credenciales y a todo lo que navegue por la red.
En resumidas cuentas...
Herramientas -> Opciones -> Avanzado -> Ver Certificados -> Autoridades -> A revisar esa lista eliminando a cualquier sospechoso.
Es lo máximo que podemos hacer.
La fundacion para el software libre o lo que sea no podria crear una entidad para ser una CA? Poco a poco los navegadores tendrian que tragar y fiarse de ella...
Hace 10 años EEUU no permitía usar criptografía con más de 64 bits (si mal no recuerdo). Al cabo de unos años, incremento la cifra, y luego la volvió a incrementar hasta no poner límite.
Es decir, que a medida que podían ir descifrando los mensajes, lo aumentaban.
jejej solo certificados ssl y toda tu vida , ademas de controlarla , la dirigen donde quieren ..
Noticia seria que no lo hicieran...
EDIT: No he dicho nada.
#8: ¿Qué es lo que está mal? Los nombres de los protocolos son SSL y TLS. Creo que está bien dicho en el titular.
Edito: Vale, pues nada