Skip to main content
journeyman
New Member
October 20, 2014
Question

mitigating the poodle SSLv3 vulnerability

  • October 20, 2014
  • 4 replies
  • 11513 views
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)?

    4 replies

    hnmr
    New Member
    October 21, 2014

    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
    New Member
    December 3, 2014

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

    carlitos05
    New Member
    September 23, 2015

    you can test if sslv3 is disabled by :

     

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

     

    emnoc
    New Member
    September 23, 2015

    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