mitigating the poodle SSLv3 vulnerability

[journeyman]

Fortinet have released an advisory regarding the poodle vulnerability that documents how to disable SSLv3. The HTTPS gui is fixed with

 config system global  
     set strong-crypto enable  
 end

According to the cli manual this enforces

use strong encryption and only allow strong ciphers (AES, 3DES) and digest (SHA1) for HTTPS/SSH admin access.

My question is twofold: 1. How does this prove or imply that SSLv3 is disabled? 2. Are there any other side effects to making this change (ssh key change or otherwise)?

[hnmr]

we have implemented the fix on some Fortigates and haven't seen any side effects or issues after this. SSH is still working, the access to the GUI and SSL VPN via FortiClient as well. 

[Petras]

Hello, it is possible to filter SSLv3 packets  via Fortigate? 

[carlitos05]

you can test if sslv3 is disabled by :

logging in from a linux-box >  openssl s_client -connect <IP>:443 -ssl3

[emnoc]

Hello, it is possible to filter SSLv3 packets  via Fortigate?

There's a few snort rules that you can use but YMMV , in reality you should disable sslv3 support at the host:services. Within most case it a cfg line ( i.e apache2 ) or a software upgrade and disable via the software. Or if it's linux you can deploy a iptable rules once again YMMV and your success will vary.

If it's a fortigate (service) the only option is to look for a command configuration in the sys global or upgrade the unit fortiOS. You might get away with  running FIPS mode of operation.

Do a search for SSLv3 iptables and/or SNORT and look at what it would take to convert the rules to a fortigate custom IPS sensor and test. I just did a SSLv3 identify and squash project like 3 months ago and we  audit all inbound hosts and disable all services that support SSLv3,  BUT we never did our outbound clients which is probably going to be the big threat. So  the client browser is the weak spot.

So keep us update on what you do & the approach that you take.

ken