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 <
[email protected]> 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<[email protected]>
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 <
[email protected]> 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
