Bueno ya no mando mas de esto, acá esta la solución para cada navegador :P
https://zmap.io/sslv3/browsers.html El 16 de octubre de 2014, 20:04, Fernando Giraldo Montoya < fercho...@gmail.com> escribió: > lo último que leí al respecto, muy bueno > http://www.genbeta.com/seguridad/poodle-asi-es-el-ataque-que-deja-por-fin-obsoleto-a-sslv3 > > El 16 de octubre de 2014, 19:54, Jose Luis C. <jlc...@riseup.net> > escribió: > > Resulta que mi Firefox 32 era vulnerable. Hay que instalar la extensión >> SSL Version Control y configurarla para que Firefox trabaje con otra. >> >> Saludos. >> >> El 16/10/14 a las #4, Oscar Fabian escribió: >> >> testing... >>> >>> El 16 de octubre de 2014, 17:26, Jhosman Lizarazo - Ubuntu Colombia < >>> jhos...@ubuntu.com> escribió: >>> >>> En el sitio web de RedHat encontré un script para que veamos si somos >>>> vulnerables o no (aplica sobre todo a servidores, no tanto al usuario >>>> final, pero puede pasar) >>>> >>>> Copiar y pegar en un documento.sh >>>> >>>> #!/bin/bash >>>> ret=$(echo Q | timeout 5 openssl s_client -connect >>>> "${1-`hostname`}:${2-443}" -ssl3 2> /dev/null) >>>> if echo "${ret}" | grep -q 'Protocol.*SSLv3'; then >>>> if echo "${ret}" | grep -q 'Cipher.*0000'; then >>>> echo "SSLv3 disabled" >>>> else >>>> echo "SSLv3 enabled" >>>> fi >>>> else >>>> echo "SSL disabled or other error" >>>> fi >>>> >>>> >>>> Guardar y dar permisos de ejecución, luego correr el script y ver los >>>> resultados, si el SSLv3 está habilitado se debe actuar. >>>> >>>> El 16 de octubre de 2014, 16:58, Oscar Fabian<ofp.pri...@gmail.com> >>>> escribió: >>>> >>>> ham se publico esta mañana en facebook link oficial de la falla >>>>> https://www.openssl.org/~bodo/ssl-poodle.pdf >>>>> >>>>> interesante que se esta diciendo que la falla mata a SSL v3 y piden >>>>> >>>> migrar >>>> >>>>> a TLS >>>>> >>>>> El 16 de octubre de 2014, 16:51, Jhosman Lizarazo - Ubuntu Colombia < >>>>> jhos...@ubuntu.com> escribió: >>>>> >>>>> La vulnerabilidad CANICHE es una debilidad en la versión 3 del >>>>>> >>>>> protocolo >>>> >>>>> SSL que permite a un atacante en un contexto-man-in-the-middle de >>>>>> >>>>> descifrar >>>>> >>>>>> el contenido de texto sin formato de un mensaje cifrado SSLv3. >>>>>> >>>>>> Mas información en: >>>>>> >>>>>> http://people.canonical.com/~ubuntu-security/cve/2014/CVE- >>>> 2014-3566.html >>>> >>>>> >>>>>> *¿Quién está afectado por esta vulnerabilidad? * >>>>>> Esta vulnerabilidad afecta a cada pieza de software que puede ser >>>>>> coaccionado para comunicarse con SSLv3. Esto significa que cualquier >>>>>> software que implementa un mecanismo de reserva que incluye soporte >>>>>> >>>>> SSLv3 >>>> >>>>> es vulnerable y puede ser explotado.Algunas piezas comunes de software >>>>>> >>>>> que >>>>> >>>>>> pueden ser afectados son los navegadores web, servidores web, >>>>>> >>>>> servidores >>>> >>>>> VPN, servidores de correo, etc- >>>>>> >>>>>> *¿Cómo funciona?* >>>>>> >>>>>> En resumen, la vulnerabilidad existe CANICHE porque el protocolo SSLv3 >>>>>> >>>>> no >>>> >>>>> comprueba adecuadamente los bytes de relleno que se envían con mensajes >>>>>> cifrados.Puesto que éstos no pueden ser verificados por la parte >>>>>> >>>>> receptora, >>>>> >>>>>> un atacante puede sustituir a estos y pasarlos al destino previsto. >>>>>> >>>>> Cuando >>>>> >>>>>> se hace de una manera específica, la carga útil modificada >>>>>> >>>>> potencialmente >>>> >>>>> será aceptado por el receptor sin queja. >>>>>> >>>>>> Un promedio de una vez de cada 256 solicitudes será aceptado en el >>>>>> >>>>> destino, >>>>> >>>>>> lo que permite al atacante descifrar un solo byte. Esto se puede >>>>>> >>>>> repetir >>>> >>>>> fácilmente con el fin de descifrar progresivamente bytes adicionales. >>>>>> Cualquier atacante capaz de forzar repetidamente un participante para >>>>>> volver a enviar los datos mediante este protocolo puede romper el >>>>>> >>>>> cifrado >>>> >>>>> en un lapso muy corto de tiempo. >>>>>> >>>>>> *¿Cómo puedo protegerme?* >>>>>> >>>>>> Deberían tomarse medidas para asegurarse de que usted no es vulnerable >>>>>> >>>>> en >>>> >>>>> sus papeles como un cliente y un servidor. Desde encriptación >>>>>> >>>>> normalmente >>>> >>>>> se negocia entre clientes y servidores, es un tema que involucra a >>>>>> >>>>> ambas >>>> >>>>> partes.Los servidores y los clientes deben deben tomar medidas para >>>>>> desactivar el soporte SSLv3 completamente. >>>>>> >>>>>> Muchas aplicaciones utilizan mejor encriptación por defecto, pero >>>>>> implementan soporte SSLv3 como una opción de reserva. Esto se debe >>>>>> desactivar, como un usuario malicioso puede forzar la comunicación >>>>>> >>>>> SSLv3 >>>> >>>>> si >>>>> >>>>>> ambos participantes lo permiten como un método aceptable. >>>>>> >>>>>> *Cómo proteger aplicaciones comunes* >>>>>> >>>>>> A continuación, vamos a cubrir cómo deshabilitar SSLv3 en algunas >>>>>> aplicaciones de servidor comunes. Tenga cuidado al evaluar sus >>>>>> >>>>> servidores >>>> >>>>> para proteger a los servicios adicionales que pueden confiar en el >>>>>> >>>>> cifrado >>>>> >>>>>> SSL / TCP. >>>>>> >>>>>> Debido a la vulnerabilidad CANICHE no representa un problema de >>>>>> >>>>> aplicación >>>>> >>>>>> y es un problema inherente con todo el protocolo, no hay ninguna >>>>>> >>>>> solución y >>>>> >>>>>> la única solución fiable es no usarlo. >>>>>> Nginx servidor Web >>>>>> >>>>>> Para desactivar SSLv3 en el servidor web Nginx, puede utilizar el >>>>>> ssl_protocols Directiva. Esto se encuentra en los server o http >>>>>> bloques >>>>>> >>>>> en >>>>> >>>>>> su configuración. >>>>>> >>>>>> Por ejemplo, en Ubuntu, puede agregar esta a nivel mundial para >>>>>> /etc/nginx/nginx.conf interior del http bloque, o para cada server >>>>>> >>>>> bloque >>>> >>>>> en el /etc/nginx/sites-enabled directorio. >>>>>> >>>>>> sudo nano /etc/nginx/nginx.conf >>>>>> >>>>>> *Para desactivar SSLv3, su ssl_protocols directiva debe establecerse >>>>>> >>>>> así:* >>>>> >>>>>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2; >>>>>> >>>>>> Debe reiniciar el servidor después de haber hecho la modificación >>>>>> >>>>> anterior: >>>>> >>>>>> sudo service nginx restart >>>>>> >>>>>> *Apache Web Server* >>>>>> >>>>>> Para desactivar SSLv3 en el servidor web Apache, usted tendrá que >>>>>> >>>>> ajustar >>>> >>>>> el SSLProtocol directiva proporcionada por el mod_ssl módulo. >>>>>> >>>>>> Esta directiva se puede establecer en el nivel de servidor o en una >>>>>> configuración de host virtual. Dependiendo de la configuración de su >>>>>> distribución de Apache, la configuración SSL se puede situar en un >>>>>> >>>>> archivo >>>>> >>>>>> independiente que proviene. >>>>>> >>>>>> En Ubuntu, la especificación a nivel de servidor para los servidores >>>>>> se >>>>>> puede ajustar mediante la edición del >>>>>> >>>>> /etc/apache2/mods-available/ssl.conf >>>>> >>>>>> archivo. Si mod_ssl está habilitada, un enlace simbólico se conectará >>>>>> >>>>> este >>>>> >>>>>> archivo al mods-enabled subdirectorio: >>>>>> >>>>>> sudo nano /etc/apache2/mods-available/ssl.conf >>>>>> >>>>>> *En CentOS*, puede puede ajustar esto en el archivo de configuración >>>>>> >>>>> SSL >>>> >>>>> se >>>>> >>>>>> encuentra aquí (si SSL está habilitado): >>>>>> >>>>>> sudo nano /etc/httpd/conf.d/ssl.conf >>>>>> >>>>>> En el interior se encuentra el SSLProtocol Directiva. Si esto no está >>>>>> disponible, lo crea. Modifique esto para eliminar explícitamente el >>>>>> >>>>> apoyo a >>>>> >>>>>> SSLv3: >>>>>> >>>>>> SSLProtocol all -SSLv3 -SSLv2 >>>>>> >>>>>> Guarde y cierre el archivo. Reinicie el servicio para permitir los >>>>>> >>>>> cambios. >>>>> >>>>>> En Ubuntu, puede escribir: >>>>>> >>>>>> sudo service apache2 restart >>>>>> >>>>>> En CentOS, esto sería: >>>>>> >>>>>> sudo service httpd restart >>>>>> >>>>>> *HAProxy equilibrador de carga* >>>>>> >>>>>> Para desactivar SSLv3 en un equilibrador de carga HAProxy, tendrá que >>>>>> >>>>> abrir >>>>> >>>>>> el haproxy.cfg archivo. >>>>>> >>>>>> Esta se encuentra en /etc/haproxy/haproxy.cfg : >>>>>> >>>>>> sudo nano /etc/haproxy/haproxy.cfg >>>>>> >>>>>> En la configuración de su extremo delantero, si ha habilitado SSL, tu >>>>>> >>>>> bind >>>>> >>>>>> Directiva especificará la dirección IP pública y el puerto. Si está >>>>>> utilizando SSL, tendrá que añadir no-sslv3 hasta el final de esta >>>>>> >>>>> línea: >>>> >>>>> frontend name bind public_ip :443 ssl crt /path/to/certs no-sslv3 >>>>>> >>>>>> Guarde y cierre el archivo. >>>>>> >>>>>> Tendrá que reiniciar el servicio para aplicar los cambios: >>>>>> >>>>>> sudo service haproxy restart >>>>>> >>>>>> *OpenVPN servidor VPN* >>>>>> >>>>>> Las versiones recientes de OpenVPN en realidad no permiten SSLv3. El >>>>>> servicio no es vulnerable a este problema específico, por lo que no >>>>>> >>>>> tendrá >>>>> >>>>>> que ajustar su configuración. >>>>>> >>>>>> Ver este post en los foros de OpenVPN para más información . >>>>>> Postfix SMTP del servidor https://forums.openvpn.net/topic17268.html >>>>>> >>>>>> Si la configuración de Postfix está configurado para requerir el >>>>>> >>>>> cifrado, >>>> >>>>> se utilizará una directiva llamada smtpd_tls_mandatory_protocols . >>>>>> >>>>>> Usted puede encontrar esto en el archivo principal de configuración de >>>>>> Postfix: >>>>>> >>>>>> sudo nano /etc/postfix/main.cf >>>>>> >>>>>> Para un servidor Postfix configurado para utilizar cifrado en todo >>>>>> >>>>> momento, >>>>> >>>>>> puede asegurarse de que SSLv3 y SSLv2 no son aceptadas por el >>>>>> establecimiento de este parámetro. Si no forzar el cifrado, usted no >>>>>> >>>>> tiene >>>>> >>>>>> que hacer nada: >>>>>> >>>>>> smtpd_tls_mandatory_protocols=!SSLv2, !SSLv3 >>>>>> >>>>>> Guarde la configuración. Reinicie el servicio para implementar los >>>>>> >>>>> cambios: >>>>> >>>>>> sudo service postfix restart >>>>>> >>>>>> *Dovecot IMAP y POP3 Servidor* >>>>>> >>>>>> Para desactivar SSLv3 en un servidor Dovecot, usted tendrá que ajustar >>>>>> directiva llamados ssl_protocols . Dependiendo de sus métodos de >>>>>> distribución de envasado, las configuraciones SSL se pueden mantener >>>>>> en >>>>>> >>>>> un >>>>> >>>>>> archivo de configuración alternativa. >>>>>> >>>>>> Para la mayoría de las distribuciones, puede ajustar esta directiva >>>>>> mediante la apertura de este archivo: >>>>>> >>>>>> sudo nano /etc/dovecot/conf.d/10-ssl.conf >>>>>> >>>>>> En el interior, establecer el ssl_protocols directiva para >>>>>> deshabilitar >>>>>> SSLv2 y SSLv3: >>>>>> >>>>>> ssl_protocols = !SSLv3 !SSLv2 >>>>>> >>>>>> Guarde y cierre el archivo. >>>>>> >>>>>> Reinicie el servicio con el fin de aplicar los cambios: >>>>>> >>>>>> sudo service dovecot restart >>>>>> >>>>>> *Medidas adicionales* >>>>>> >>>>>> Junto con las aplicaciones del lado del servidor, también debe >>>>>> >>>>> actualizar >>>> >>>>> las aplicaciones cliente. >>>>>> >>>>>> En particular, los navegadores web pueden ser vulnerables a este >>>>>> >>>>> problema a >>>>> >>>>>> causa de su negociación del protocolo de bajada. Asegúrese de que sus >>>>>> navegadores no permiten SSLv3 como un método de cifrado aceptable. >>>>>> Esto >>>>>> puede ser ajustable en la configuración o mediante la instalación de >>>>>> un >>>>>> plugin o extensión adicional. >>>>>> Conclusión >>>>>> >>>>>> Debido al amplio apoyo SSLv3, incluso cuando el cifrado fuerte está >>>>>> habilitada, esta vulnerabilidad es de gran alcance y peligroso. Usted >>>>>> tendrá que tomar medidas para protegerse a sí mismo tanto como un >>>>>> consumidor y el proveedor de los recursos que utilizan cifrado SSL. >>>>>> >>>>>> Asegúrese de revisar todos sus servicios de redes accesibles que >>>>>> pueden >>>>>> aprovechar SSL / TLS en cualquier forma. A menudo, estas aplicaciones >>>>>> requieren instrucciones explícitas para desactivar por completo las >>>>>> >>>>> formas >>>>> >>>>>> más débiles de cifrado como SSLv3. >>>>>> >>>>>> -- >>>>>> Cordialmente. >>>>>> >>>>>> >>>>>> >>>>>> Jhosman Lizarazo >>>>>> https://launchpad.net/~jhosman >>>>>> -- >>>>>> Al escribir recuerde observar la etiqueta (normas) de esta lista: >>>>>> http://goo.gl/Pu0ke >>>>>> Para cambiar su inscripción, vaya a "Cambio de opciones" en >>>>>> http://goo.gl/Nevnx >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> .---. .----------- Cordialmente. >>>>> / \ __ / ------ #Oscar Fabian Prieto Gonzalez >>>>> / / \( )/ ----- #Tecnico en Sistemas >>>>> ////// ' \/ ` --- #GNU/user >>>>> //// / // : : --- #www.ofprieto.blogspot.com >>>>> // / / /` '-- >>>>> // //..\\ >>>>> =============UU====UU==== >>>>> '//||\\` >>>>> ''`` >>>>> -- >>>>> Al escribir recuerde observar la etiqueta (normas) de esta lista: >>>>> http://goo.gl/Pu0ke >>>>> Para cambiar su inscripción, vaya a "Cambio de opciones" en >>>>> http://goo.gl/Nevnx >>>>> >>>>> >>>> >>>> -- >>>> Cordialmente. >>>> >>>> >>>> >>>> Jhosman Lizarazo >>>> https://launchpad.net/~jhosman >>>> -- >>>> Al escribir recuerde observar la etiqueta (normas) de esta lista: >>>> http://goo.gl/Pu0ke >>>> Para cambiar su inscripción, vaya a "Cambio de opciones" en >>>> http://goo.gl/Nevnx >>>> >>>> >>> >>> >> >> -- >> Al escribir recuerde observar la etiqueta (normas) de esta lista: >> http://goo.gl/Pu0ke >> Para cambiar su inscripción, vaya a "Cambio de opciones" en >> http://goo.gl/Nevnx >> > > > > -- > > > Twitter: @Fercho_Giraldo @Medellinlibre > *GNU/LINUX USER # 553303* > There is a difference between knowing the path and walking the path > -- Twitter: @Fercho_Giraldo @Medellinlibre *GNU/LINUX USER # 553303* There is a difference between knowing the path and walking the path -- Al escribir recuerde observar la etiqueta (normas) de esta lista: http://goo.gl/Pu0ke Para cambiar su inscripción, vaya a "Cambio de opciones" en http://goo.gl/Nevnx
