Una vulnerabilidad crítica ha sacudido la confianza en SSL.com, una Autoridad Certificadora (CA) reconocida por todos los principales navegadores. El fallo, reportado públicamente y ya reconocido por la entidad afectada, permitía obtener certificados válidos sin demostrar control real del dominio objetivo, con potenciales consecuencias graves para la seguridad web a nivel global.
|
etiquetas: ssl , valicación , certificados , grave fallo , dominio , ca , vulnerabilidad 
Ya veremos cuánto crece la CRL de ssl.com.
Yo propondría por ejemplo que para desactivar las alertas tuvieras que conectar el teléfono a un PC y usar algún comando desde ahí. Algo que no pudiera hacer un usuario fácilmente siguiendo las instrucciones de un estafador.
Y para instalar CAs puedes usar una solución MDM (las hay open source, como FleetDM).
Yo tengo un dominio "normal" y uso IPs internas, eso si se puede hacer
También tenemos un autofirmado (y el CA instalado para evitar los errores) pero solo para PCs, los móviles no los tocamos
Lo idea seria no depender de nada centralizado.
Siempre hará falta un tercero que certifique que eres quien dices ser. Y que tendrá los mecanismos para que certifiques que eres quien dices ser.
Pero si que es verdad que es mas complicado que usar a un "avalista" centralizado. Todo llegara de momento.
Creo que se puede ver en etherscan.io/contractsVerified?filter=audit
columna 'Audit'
Cual es el procedimiento para eso ?
El certificado no "verifica el dominio". Esa verificación se hace como condición previa para obtener el certificado, que básicamente es una clave pública firmada digitalmente que se usará para asegurar la comunicación
Que aporta sobre un certificado correctamente firmado?
La estructura actual permite que cada navegador y/o cada entidad elija cuáles de esas entidades (Root CAs) son confiables.
Por ejemplo, es de esperar que un gobierno de un país elija no aceptar certificados firmados por entidades de certificación que sospechan de estar comprometidas por naciones rivales.
La estructura actual permite que cada navegador y/o cada entidad elija cuáles de esas entidades (Root CAs) son confiables.
No sirve. El 99,999% de los usuarios se queda con los predeterminados del navegador.
Si no, ¿qué otro método se te ocurre?
Es un meme pero la block chain va hacia esa dirección.
Si no se te ocurre, ¿ no se te ha ocurrido pensar que a lo mejor no lo hay ?
espero que se acabe solucionando con nueva tecnología.
No, no es cuestión de tecnología. Hay muchas cosas que no se pueden solucionar con mejor tecnología. Es ciencia, no magia.
"Pero eso es imposible". Aja, has oido hablar del bitcoin y los mineros? Ves los paralelismos?
No digo que esta vaya a ser la solucion. Pero como puedes ver, con el tiempo salen ideas que a nadie se le hubiera ocurrido antes. El bitcoin es de hecho unos de los mejores ejemplos en ese sentido. Nadie se podia imaginar que pudiera haber una moneda digital descentralizada.
A ver como lo haces.
Ánimo, solo hay millones y millones de ellos en activo.
Esos usuarios podriamos llamarlos "validadores" y lo harian a cambio de una comision.
Ah, ya te entiendo. Unos cuantos usuarios.
Es el método que hay ahora.
Aja, has oido hablar del bitcoin y los mineros? Ves los paralelismos?
No.
No creo que los haya.
Bueno, lejanamente todo se parece a todo.
Eh? Comprobar unos CNAME DNS RECORDS y luego poner tu firma se hace en menos de un segundo. En serio esto es un argumento?
Que ademas no habria que traspasar todos de golpe en un dia. Solo conforme vayan expirando sus certificados actuales. Madre mia el nivel.
Ah, ya te entiendo. Unos cuantos usuarios.
Es el método que hay ahora
Estariamos hablando de MILLONES de usuarios.
Y con una barrera de entrada cero. Tu mismo… » ver todo el comentario
Hay dos filosofias para resolver ese problema:
- Proof of work.
- Proof of stake.
En todo caso lo que estas planteando es un metodo alternativo para comprobar la.legitimidad del solicitante del certificado, nada más
Saber a quien poner la firma y a quien no creo que requiere más tiempo.
A lo mejor es que no entiendes el proceso o el objetivo que pretenden los certificados.
Entiendo. No sabes de criptomonedas ni lo que es el minado entonces.
No. No entiendes nada. Te imaginas cosas.
Es desagradable tener que tratar con personas con esa actitud, como comprenderás.
En mal momento decidí comentar sobre tu mensaje para aportar algo positivo.
Para qué serviria eso???
Sabes para que sirve la firma de la clave pública (certificado)??
Eso no serviria para nada.
Si te vas a las cadenas de confianza tienes PGP mas antiguo que la lecne, si no se uso en la web fué por algo
Entiendo que la idea vendria de que un usuario recibiria la peticion, validaria el dominio y si esta todo guay lo meteria en la blockchain firmado. Los usuarios harian estas validaciones a cambio de una comision.
Lo estoy simplificando mucho. Pero basicamente es la misma idea que se hace con el bitcoin/criptomonedas y el minado.
Eso que "es lo de menos" es justo lo que ha fallado
Ese es el problema, que ni a ti ni a nadie parece ocurrírsele una solución.
La blockchain es una buena forma de publicar cosas y que quede registro... pero no creo que sea factible para publicar una clave pública sin que nadie se haga pasar por ti.
Que sugieres para verificar las claves públicas ?
Me imagino que la solución vendrá relacionado con la blockchain.
Puede fallar por hackeo (como este caso) o por corrupcion.
No falla por "hackeo", no es el caso. Falla porque no han hecho las verificaciones pertinentes, dejándoselas a un sistema programado mal hecho.
Y aun a nadie se le ha ocurrido un sistema mejor.
Llamalo "punto unico de fallo" si prefieres.
Y aun a nadie se le ha ocurrido un sistema mejor.
Lo cual no quiere decir que no exista un sistema mejor. Ese es precisamente mi punto.
- Actuan con delay. Hasta que eso sea descubierto, he podido romper el HTTPS por un buen tiempo.
- Si la entidad certificadora es lo suficientemente grande, te vas a cargar bastante trozos de internet a corto plazo (imaginate si tu banco usa esa entidad... uh).
No basta con obtener un certificado falso, tienes que colocar la clave privada y el certificado en el sitio web.