SSL/TLS load balancing
In a firewall load balancing virtual server configuration, you can select SSL to load balance only SSL and TLS sessions. The virtual server will load balance SSL and TLS sessions received at the virtual server interface with destination IP address that matches the configured virtual server IP and destination port number that matches the configured virtual server port. Change this port to match the destination port of the sessions to be load balanced.
For SSL load balancing you can also set persistence to SSL session ID. Persistence is achieved by the FortiGate unit sending all sessions with the same SSL session ID to the same real server. When you configure persistence, the FortiGate unit load balances a new session to a real server according to the Load Balance Method. If the session has an SSL session ID, the FortiGate unit sends all subsequent sessions with the same SSL session ID to the same real server.
SSL/TLS offloading
Use SSL offloading to accelerate clients’ SSL or HTTPS connections to real servers by using the FortiGate unit to perform SSL/TLS operations (offloading them from the real servers using the FortiGate unit’s SSL acceleration hardware). FortiGate units can offload most versions of SSL/TLS, including SSL 3.0, TLS 1.0 and TLS 1.2. SSL/TLS offloading is available on FortiGate units that support SSL acceleration.
To configure SSL offloading from the GUI go to Policy & Objects > Virtual Servers. Add a virtual server and set the type to HTTPS or SSL and select the SSL offloading type (Client <-> FortiGate or Full).
Select Client <-> FortiGate to apply hardware accelerated SSL/TLS processing only to the part of the connection between the client and the FortiGate unit. This mode is called half mode SSL offloading. The segment between the FortiGate unit and the server will use clear text communications. This results in best performance, but cannot be used in failover configurations where the failover path does not have an SSL accelerator.
Select Full to apply hardware accelerated SSL processing to both parts of the connection: the segment between client and the FortiGate unit, and the segment between the FortiGate unit and the server. The segment between the FortiGate unit and the server uses encrypted communications, but the handshakes are abbreviated. This is not as efficient as half mode SSL offloading, but still improves performance. As well, full-mode SSL offloading can be used in failover configurations where the failover path does not have an SSL accelerator. If the server is already configured to use SSL, this also enables SSL acceleration without requiring changes to the server’s configuration.
SSL Offloading modes (Half Mode and Full Mode)
Configuring SSL offloading also requires selecting a certificate to use for the SSL offloading sessions. SSL offloading supports key sizes up to 4096. FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive
The following CLI command shows an example half mode HTTPS SSL offloading configuration. In the example the ssl-mode option sets the SSL offload mode to half (which is the default mode).
config firewall vip edit Vserver-ssl-offload set type server-load-balance set server-type https set ldb-method round-robin set extip 172.20.120.30 set extintf wan1 set extport 443
Separate virtual-server client and server TLS version and cipher configuration
set persistence ssl-session-id set ssl-mode half set ssl-certificate my-cert set monitor tcp-mon-1 config realservers edit 1 set ip 10.31.101.30 set port 443
next edit 2 set ip 10.31.101.40 set port 443
end
end
Separate virtual-server client and server TLS version and cipher configuration
In some cases, you may want the to use different versions of SSL or TLS on the client to FortiGate connection than on the FortiGate to server connection. For example, you may want to use the FortiGate to protect a legacy SSL 3.0 or TLS 1.0 server while making sure that client to FortiGate connections must always use the higher level of protection offered by TLS 1.1 or greater. Also, in some cases you might want to protect a server that only has weak ciphers (for example, DES or RC4) while making sure that all connections between the FortiGate and the client use a strong cipher for better protection.
The following options are available when configuring server load balancing for HTTPS sessions configured with the following command:
config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full …
Setting the SSL/TLS versions to use for server and client connections
The ssl-server-min-version, ssl-server-max-version, ssl-min-version and ssl-maxversion configuration options allow the minimum and maximum SSL/TLS versions for the client to FortiGate connection to be independent of the FortiGate to server configuration. By default these options are both set to client and the configured ssl-min-version and ssl-max-version settings are applied to both the client and the server connection.
You can change the ssl-server-min-version and ssl-server-max-version to apply different options to the server connection. The ssl-min-version and ssl-max-version settings are still applied to the client connection. If you set the ssl-server-min-version and ssl-server-max-version to an explicit version then both must be set to an explicit version.
The ssl-server-min-version and ssl-server-max-version options allow you to specify the minimum and maximum SSL/TLS versions the FortiGate will offer to the server (in the record header of the ClientHello) when performing full mode SSL offloading and thus the minimum and maximum SSL/TLS versions the FortiGate accepts from the server (in a ServerHello). If the server responds with a version in its ServerHello Setting the SSL/TLS cipher choices for server and client connections
that is lower than ssl-server-min-version or higher than the ssl-server-max-version then the FortiGate terminates the connection.
Command syntax is:
config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full set ssl-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} set ssl-server-min-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client} set ssl-server-max-version {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2 | client}
Setting the SSL/TLS cipher choices for server and client connections
The ssl-algorithm and ssl-server-algorithm configuration options allow the cipher choice for the FortiGate to server connection to be independent of the client to FortiGate connection. By default, sslserver-algorithm is set to client and the configured ssl-algorithm setting is applied to both the client and the server connection.
You can change the ssl-server-algorithm to apply different options to the server connection. The sslalgorithm setting is still applied to the client connection. The following ssl-server-algorithm options are available:
- high, offer AES or 3DES cypher suites in the ServerHello l medium, use AES, 3DES, or RC4 cypher suites in the ServerHello l low, use AES, 3DES, RC4, or DES cypher suites in the ServerHello l custom, specifiy custom cypher suites using the config ssl-server-cipher-suites and offer these custom cypher suites in the ServerHello.
- client, offer the cypher suites in the ServerHello that are offered in the ClientHello.
Command syntax is:
config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full
set ssl-algorithm {high | medium | low | custom}
set ssl-server-algorithm {high | medium | low | custom | client}
If you set ssl-server-algorithm to custom, the syntax is: config firewall vip edit server-name set type server-load-balance set server-type https set ssl-mode full
set ssl-server-algorithm custom config ssl-server-cipher-suites edit 10 set cipher <cipher-suite>
set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2}
Protection from TLS protocol downgrade attacks
next edit 20 set cipher <cipher-suite>
set versions {ssl-3.0 | tls-1.0 | tls-1.1 | tls-1.2} end
Protection from TLS protocol downgrade attacks
The ssl-client-fallback option, when enabled (the default configuration), performs downgrade attack prevention (RFC 7507).
Command syntax is:
config firewall vip edit server-name set type server-load-balance set server-type https set ssl-client-fallback {disable | enable}
Setting 3072- and 4096-bit Diffie-Hellman values
The ssl-dh-bits option allows you to specify the number of bits of the prime number used in the DiffieHellman exchange for RSA encryption of the SSL connection. Larger prime numbers are associated with greater cryptographic strength. You can set DH values from 768 to 4096 bits.
Command syntax is:
config firewall vip edit server-name set type server-load-balance set server-type https set ssl-dh-bits {768 | 1024 | 1536 | 2048 | 3072 | 4096}
Setting the DH bits to 2048 only provides the equivalent of a symmetric cipher in the range of 112 – 128 bits. This means that if AES 256 is used then the weakest point is the DH of 2048 and a value of at least 3072 should be use if the goal is to have 256 bits of security.
FortiGate models with CP9 processors support 3072 and 4096 DH bit sizes in hardware. All FortiGate models up to and including those with CP8 processors only support offloading DH bit sizes up to 2048 so any sizes larger than that are done in software and thus are relatively resource intensive.
Additional SSL load balancing and SSL offloading options
The following SSL load balancing and SSL offloading options are only available from the CLI:
ssl-client-session-state-max <sessionstates_int>
Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the client and the FortiGate unit.
ssl-client-session-state-timeout <timeout_int>
Additional SSL load balancing and SSL offloading options
Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the client and the FortiGate unit.
ssl-client-session-state-type {both | client | disable | time}
Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the client and the FortiGate unit.
- both: Select to expire SSL session states when either ssl-client-session-state-max or ssl-clientsession-state-timeout is exceeded, regardless of which occurs first. l count: Select to expire SSL session states when ssl-client-session-state-max is exceeded.
- disable: Select to keep no SSL session states.
- time: Select to expire SSL session states when ssl-client-session-state-timeout is exceeded.
ssl-http-location-conversion {enable | disable}
Select to replace http with https in the reply’s Location HTTP header field. For example, in the reply,
Location: http://example.com/ would be converted to Location: https://example.com/ ssl-http-match-host {enable | disable}
Enable (the default) to apply Location conversion to the reply’s HTTP header only if the host name portion of Location matches the request’s Host field, or, if the Host field does not exist, the host name portion of the request’s URI.
If disabled, conversion occurs regardless of whether the host names in the request and the reply match.
For example, if host matching is enabled, and a request contains Host: example.com and the reply contains Location: http://example.cc/, the Location field does not match the host of the original request and the reply’s Location field remains unchanged. If the reply contains Location: http://example.com/, however, then the FortiGate unit detects the matching host name and converts the reply field to Location: https://example.com/.
This option appears only if ssl-http-location-conversion is enable.
ssl-send-empty-frags {enable | disable}
Select to precede the record with empty fragments to protect from attacks on CBC IV. You might disable this option if SSL acceleration will be used with an old or buggy SSL implementation which cannot properly handle empty fragments.
ssl-server-session-state-max <sessionstates_int>
Enter the maximum number of SSL session states to keep for the segment of the SSL connection between the server and the FortiGate unit.
ssl-server-session-state-timeout <timeout_int>
Enter the number of minutes to keep the SSL session states for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.
ssl-server-session-state-type {both | count | disable | time}
Select which method the FortiGate unit should use when deciding to expire SSL sessions for the segment of the SSL connection between the server and the FortiGate unit. This option appears only if ssl-mode is full.
- both: Select to expire SSL session states when either ssl-server-session-state-max or ssl-serversession-state-timeout is exceeded, regardless of which occurs first. l count: Select to expire SSL session states when ssl-server-session-state-max is exceeded.
- disable: Select to keep no SSL session states. l time: Select to expire SSL session states when ssl-server-session-state-timeout is exceeded.
SSL offloading support for Internet Explorer 6
In some cases the Internet Explorer 6 web browser may be able to access real servers. To resolve this issue, disable the ssl-send-empty-frags option:
config firewall vip edit vip_name set type server-load-balance set server-type https set ssl-send-empty-frags disable
end
You can disable this option if SSL acceleration will be used with an old or buggy SSL implementation that cannot properly handle empty fragments.
Selecting the cipher suites available for SSL load balancing
You can use the following command to view the complete list of cipher suites available for SSL offloading:
config firewall vip edit <vip-name> set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 0 set cipher ?
In most configurations the matching cipher suite is automatically selected but you can limit the set of cipher suites that are available for a given SSL offloading configuration. For example, use the following command to limit an SSL load balancing configuration to use the three cipher suites that support ChaCha20 and Poly1305:
config firewall vip edit <vip-name> set type server-load-balance set server-type https set ssl-algorithm custom config ssl-cipher-suites edit 1
set cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256 next edit 2
set cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256 next edit 3
set cipher TLS-DHE-RSA-WITH-CHACHA20-POLY1305-SHA256 end end
Disabling SSL/TLS re-negotiation
The vulnerability CVE-2009-3555 affects all SSL/TLS servers that support re-negotiation. FortiOS when configured for SSL/TLS offloading is operating as a SSL/TLS server. The IETF is working on a TLS protocol change that will fix the problem identified by CVE-2009-3555 while still supporting re-negotiation. Until that protocol change is available, you can use the ssl-client-renegotiation option to disable support for SSL/TLS re-negotiation. The default value of this option is allow, which allows an SSL client to renegotiate. You can change the setting to deny to abort any attempts by an SSL client to renegotiate. If you select deny as soon as a ClientHello message indicating a re-negotiation is received from the client FortiOS terminates the TCP connection.
Since SSL offloading does not support requesting client certificates the only circumstance in which a renegotiation is required is when more than 2^32 bytes of data are exchanged over a single handshake. If you are sure that this volume of traffic will not occur then you can disable re-negotiation and avoid any possibility of the attack described in CVE-2009-3555.
The re-negotiation behavior can be tested using OpenSSL. The OpenSSL s_client application has the feature that the user can request that it do renegotiation by typing “R”. For example, the following shows a successful renegotiation against a FortiGate unit configured with a VIP for 192.168.2.100:443:
$ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003)
depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0
—
Certificate chain
0
s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com
i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com
1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
—
Server certificate
—–BEGIN CERTIFICATE—–
—certificate not shown—
—–END CERTIFICATE—–
subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em ailAddress=support@fortinet.com
issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com
—
No client certificate CA names sent
—
SSL handshake has read 2370 bytes and written 316 bytes —
Disabling SSL/TLS re-negotiation
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE Expansion: NONE SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA Session-ID:
02781E1E368DCCE97A95396FAA82E8F740F5BBA96CF022F6FEC3597B0CC88095
Session-ID-ctx: Master-Key:
A6BBBD8477A2422D56E57C1792A4EA9C86F37D731E67D0A66E5CDB2B5C76650780C0E7F01CFF851EC44661
86F4C48397
Key-Arg : None
Start Time: 1264453027
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
—
GET /main.c HTTP/1.0
R
RENEGOTIATING
depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0 HTTP/1.0 200 ok
Content-type: text/plain
/*
* Copyright (C) 2004-2007 Fortinet */
#include <stdio.h> #include “vsd_ui.h”
int main(int argc, char **argv)
{
return vsd_ui_main(argc, argv);
} closed $
The following is the same test, but this time with the VIP configuration changed to ssl-clientrenegotation deny:
$ openssl s_client -connect 192.168.2.100:443 CONNECTED(00000003)
depth=1 /C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com verify error:num=19:self signed certificate in certificate chain verify return:0
—
Certificate chain
0
s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/emailAdd ress=support@fortinet.com
i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com
1 s:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com i:/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate Authority/CN=support/emailAddress=support@fortinet.com
—
Server certificate
—–BEGIN CERTIFICATE—–
—certificate not shown—
—–END CERTIFICATE—–
subject=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Fortigate/CN=FW80CM3909604325/em ailAddress=support@fortinet.com
issuer=/C=US/ST=California/L=Sunnyvale/O=Fortinet/OU=Certificate
Authority/CN=support/emailAddress=support@fortinet.com
—
No client certificate CA names sent
—
SSL handshake has read 2370 bytes and written 316 bytes
—
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Compression: NONE Expansion: NONE SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA Session-ID:
8253331D266DDE38E4D8A04AFCA9CBDED5B1134932CE1718EED6469C1FBC7474
Session-ID-ctx: Master-Key:
ED05A3EF168AF2D06A486362FE91F1D6CAA55CEFC38A3C36FB8BD74236BF2657D4701B6C1456CEB5BB5EFA
A7619EF12D
Key-Arg : None
Start Time: 1264452957
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
—
GET /main.c HTTP/1.0
R
RENEGOTIATING
19916:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530: Use the following command to check the SSL stats to see that the renegotiations blocked counter is now 1:
diagnose firewall vip virtual-server stats ssl ssl client connections total 0 active 0 max 0
handshakes total 4 active 0 max 0 completed 4 abbreviated 0 session states total 4 active 4 max 4
cipher-suite failures 0
embryonics total 0 active 0 max 0 terminated 0
Disabling SSL/TLS re-negotiation
renegotiations blocked 1
server connections total 0 active 0 max 0
handshakes total 3 active 0 max 0 completed 2 abbreviated 1 session states total 1 active 1 max 1
cipher-suite failures 0
internal error 0 bad handshake length 0 bad change cipher spec length 0 pubkey too big 0 persistence
find 0 found 0 clash 0 addr 0 error 0
If the virtual server debug log is examined (diagnose debug appl vs -1) then at the point the re-negotiation is blocked there is a log:
vs ssl 12 handshake recv ClientHello vs ssl 12 handshake recv 1
(0100005403014b5e056c7f573a563bebe0258c3254bbaff7046a461164f34f94f4f3d019c418000026
00390038003500160013000a00330032002f00050004001500120009001400110008000600030201000
00400230000) vs ssl 12 client renegotiation attempted rejected, abort
vs ssl 12 closing 0 up vs src 12 close 0 in vs src 12 error closing vs dst 14 error closing vs dst 14 closed vs ssl 14 close vs sock 14 free vs src 12 closed vs ssl 12 close vs sock 12 free