Need to block SSL version 3

There's different places where SSLv3 can be turned on / off on the Fortigate. The biggest one is in the gui: 

config system global 
    set strong-crypto enable 
end 

But there's some other places as well, all references are on the fortiguard page here: http://www.fortiguard.com...POODLE--Vulnerability/

Hello,

You maybe want to disable it for vpn access as well:

config vpn ssl settings     set sslv3 disable

I disabled sslv3 for SSL VPN and now FortiClient will not connect.  If I enable it FortiClient connects without a problem.

How do I force FortiClient to not use sslv3?

Thanks!

This is how I have it configured, but FortiClient does not connect.  Is there a way to force FortiClient to use TLS?

Change_Me # get vpn ssl set

sslvpn-enable       : enable 

sslv3               : disable 

tlsv1-0             : enable 

tlsv1-1             : enable 

tlsv1-2             : enable 

I have the identical settings for SSL VPN on the FortiGate except for DNS server IPs of course.

I'm using FortiClient 5.2.3.0633.  I can't figure out how to force this version to negotiate TLS 1.x.

Here's the output from an SSLVPN debug I ran yesterday while attempting to VPN in.

2015-03-16 19:46:34 [3957:root]SSL state:before/accept initialization (172.16.5.82)

2015-03-16 19:46:34 [3957:root]SSL state:SSLv2/v3 read client hello A:(null)(172.16.5.82)

2015-03-16 19:46:34 [3957:root]SSL_accept failed, 1:unknown protocol

2015-03-16 19:46:34 [3957:root]Destroy sconn 0x3106a600, connSize=0.

I had a similar problem resolved as follows in the windows client stations: 1) have identified that access the link https: // <ip-address>: 10443 was not operating in Internet Explorer. But the test in Firefox worked; 2) Once checked in the advanced settings for Internet Explorer and activated the option to use TLS 1.2; 3) Performed the test again in connection with the SSLVPN client and started to work. Hope this helps.

I never seen any problems with disabling sslv3. Here's  my cfg;

SOC60D (root) # show vpn ssl settings config vpn ssl settings     set sslv3 disable     set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"     set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1"     set port 10443     set source-interface "wifi"     set source-address "all"     set source-address6 "all"     set default-portal "default" end

To test it's quite simple;

You 1^st need to ensure that tls1v is enabled on that port. I would use a unix curl like program available on linux, macosx or most other  unixes

curl  –k -3  https://1.1.1.1:10443

curl -k -2   https://1.1.1.1:10443

curl -k -1  https://1.1.1.1:10443

Then you can test with the client. Alternatively, you can test with the “curl” above or via a tlsv1.x  only enabled browser the choice is up to you. But if you can hit the portal at tls1.x and  if the fortiClient can’t than it always the lack the enabling of tls in the client.

BTW I'm  using 5.2.3.370 on MACOSX and it's strong and good;

20150317 21:17:18.959 [sslvpn:INFO] unknown:0 [xml config]: GET /remote/fortisslvpn_xml ... (received 668 bytes): HTTP/1.1 200 OK Date: Tue, 17 Mar 2015 20:17:09 GMT Set-Cookie: SVPNCOOKIE=CRkqc6/CvXoOJqh/wUoYtODK4RjBXJ5E2E1pYZ9dxwt8g3OhaqgfCRR3PdirJe6P%0aGR2joncgMQL2B3evrYDLyFFxjq284KeOtpAKPTWJV+2jtCpMz1y31js4ab+dTs5Q%0aMHPGy0OCPgo/mS9PlYsDJZJGziSJepz5BAClrux5DgE=%0a; path=/; secure; httponly Transfer-Encoding: chunked Content-Type: text/xml X-Frame-Options: SAMEORIGIN <?xml version='1.0' encoding='utf-8'?><sslvpn-tunnel ver='1'><fos platform='FWF60D' major='5' minor='02' patch='2' build='0642' branch='642' /><client-config save-password='off' keep-alive='off' auto-connect='off' /><ipv4></ipv4><idle-timeout val='300' /><auth-timeout val='28800' /></sslvpn-tunnel> ---- 20150317 21:17:18.965 [sslvpn:INFO] unknown:0 dns suffix: 20150317 21:17:18.969 [sslvpn:INFO] unknown:0 epctrl ping server: 20150317 21:17:18.972 [sslvpn:DEBG] unknown:0 PPP 20150317 21:17:18.975 [sslvpn:INFO] unknown:0 begin io loop 20150317 21:17:18.978 [sslvpn:INFO] unknown:0 launch ssl read thread 20150317 21:17:18.981 [sslvpn:INFO] unknown:0 launch tty read thread 20150317 21:17:18.981 [sslvpn:INFO] unknown:0 ssl read thread started 20150317 21:17:18.983 [sslvpn:INFO] unknown:0 main thread waiting for threads termination 20150317 21:17:18.983 [sslvpn:INFO] unknown:0 ssl write thread started 20150317 21:17:18.983 [sslvpn:INFO] unknown:0 tty read thread started 20150317 21:17:18.987 [sslvpn:INFO] unknown:0 tty write thread started 20150317 21:17:18.987 [sslvpn:DEBG] unknown:0 begin to write to ssl 20150317 21:17:19.030 [sslvpn:INFO] unknown:0 got peer's ip address 20150317 21:17:19.987 [sslvpn:INFO] unknown:0 ppp interface is up 20150317 21:17:19.996 [sslvpn:INFO] unknown:0 Current dns 0: 10.10.80.1 20150317 21:17:21.005 [sslvpn:INFO] unknown:0 try to get ppp's ip address 10.212.134.1 20150317 21:17:21.011 [sslvpn:INFO] unknown:0 No split tunnel is specified 20150317 21:17:21.019 [sslvpn:INFO] unknown:0 no dns configured on fgt, keep current dns, ret = 0 20150317 21:17:21.029 [sslvpn:INFO] unknown:0 ppp address: 10.212.134.1 20150317 21:17:21.036 [sslvpn:INFO] unknown:0 sending sslvpn up message to vpn controller. ping server is  allow_save_password:0 allow_keep_alive:0 allow_auto_connect:0  

And to add;

SSL neg should always take the higher version if the client is enabled. So TLSv1.2 over v1.1 over sslv3 , and please don’t use  sslv2. You can use the following debug

diag debug app sslvpnd -1

And monitor the connection output;

[17121:root:43]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

Ken

I've made a little progress...

I enabled tlsv1.0 and was able to connect.  When I disable it I cannot connect.

Change_Me # get vpn ssl settings sslvpn-enable       : enable sslv3               : disable tlsv1-0             : enable tlsv1-1             : enable tlsv1-2             : enable

Delete the other 2 that you don't  require and retest.

TLS1vX was include in the  5 code train , so  I believe tlv1.0 should be okay unless you have some type of CVE to reference

Just test using a browser or curl after and before starting the  forticlient. You should really diag debug the application sslvpnd and I betcha your forticlient is always selecting the higher proposal regardless. If your running the latest 5.2.X forticlient, it should always support tls1.2 as  the 1st pickings from my own testing with macos and window.  I can't speak of linux.

I would be careful with disabling the other proposal if you have any older forticlient installed.

ken

Thank you for your assistance!  I don't have a CVE specific to CBC weakness, but I've read about it on several forums, for example http://crypto.stackexchan...cbc-in-ssl-be-attacked

Here's the output from an SSLVPN debug I ran a couple days ago while attempting to VPN in with both sslv3 and tls1.0 disabled in the FortiGate SSL VPN settings.  So only TLS1.1 and TLS1.2 are enabled.  Should it matter that I am using a Windows XP computer to test with?   2015-03-16 19:46:34 [3957:root]SSL state:before/accept initialization (172.16.5.82) 2015-03-16 19:46:34 [3957:root]SSL state:SSLv2/v3 read client hello A:(null)(172.16.5.82) 2015-03-16 19:46:34 [3957:root]SSL_accept failed, 1:unknown protocol 2015-03-16 19:46:34 [3957:root]Destroy sconn 0x3106a600, connSize=0.