SSL VPN 5.6.4 Issue - Unknown cipher error

[seadave]

Thought I would pass this along.  Today we upgraded from 5.4.5 to 5.6.4.  We have two 500Ds.  So earlier this week, we restored our 5.4.5 config from production to our standby unit.  We then followed the upgrade matrix to get it to 5.6.4.

After cleaning up App Control policies and some of the other changes from 5.4.x to 5.6.x, we determined it was ready to go.  Earlier we had pushed out a new ProxySSL cert to our clients via GPO as the old 5.4.5 one was SHA1 and was no longer supported in 5.6.x.

This AM I swapped the cables and all looked fine.  Registered it in our FAZ and logs were flowing.  Watched for unnecessary blocks and all looked good.  With one exception.  Connection attempts to our SSLVPN were failing with an "Unknown cipher error".  I assumed the cert was corrupted somehow so I rekeyed my cert with Digicert (that took an agonizingly long time to finish for some reason), and then loaded the new cert.  The problem persisted.  Both Qualys (https://www.ssllabs.com/ssltest/index.html) and Digicert (https://www.digicert.com/help/) were not able to scan the connection.  These links are invaluable when testing such things.

So I decided to dig into CLI before swapping back to my other Gate.  Here are my SSL settings (show full):

config vpn ssl settings set reqclientcert disable set tlsv1-0 disable set tlsv1-1 enable set tlsv1-2 enable unset banned-cipher set ssl-big-buffer disable set ssl-insert-empty-fragment enable set https-redirect enable [style="background-color: #ffff00;"]set ssl-client-renegotiation enable[/style] set force-two-factor-auth disable set servercert "SSLVPN-070618" [style="background-color: #ffff00;"]set algorithm medium[/style] set idle-timeout 7200 set auth-timeout 28800 set login-attempt-limit 2 set login-block-time 60 set login-timeout 30 set dtls-hello-timeout 10 set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1" set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1" set dns-suffix "company.local" set dns-server1 10.31.251.10 set dns-server2 10.31.252.10 set wins-server1 0.0.0.0 set wins-server2 0.0.0.0 set ipv6-dns-server1 :: set ipv6-dns-server2 :: set ipv6-wins-server1 :: set ipv6-wins-server2 :: set route-source-interface disable set url-obscuration enable set http-compression disable set http-only-cookie enable set port 443 set port-precedence enable set auto-tunnel-static-route enable set header-x-forwarded-for add set source-interface "port9" set source-address "all" set source-address-negate disable set source-address6 "all" set source-address6-negate disable set default-portal "SSL_VPN_TS" config authentication-rule edit 8 set groups "SSL_VPN_FULL" set portal "SSL_VPN_FULL" set realm '' set client-cert disable set cipher high set auth any next edit 10 set groups "SSL_VPN_SAS" set portal "SSL_VPN_SAS" set realm '' set client-cert disable set cipher high set auth any next edit 9 set groups "SSL_VPN_TS" set portal "SSL_VPN_TS" set realm '' set client-cert disable set cipher high set auth any next end set dtls-tunnel enable set check-referer enable set http-request-header-timeout 20 set http-request-body-timeout 30 set unsafe-legacy-renegotiation disable end

We traced the issue to one of the two highlighted settings.  The defaults were:

set ssl-client-renegotiation disable set algorithm high

For some reason, with these settings the session would not allow a handshake.  In testing I changed to this:

set ssl-client-renegotiation enable set algorithm low

Once I did that, the sessions started working again.  So I decided I didn't want "set algorithm low" and changed it back to the default (unset algorithm), but it again broke all incoming connections.

So I modified it to set alogrithm medium and it is again working.

I will open a ticket with the TAC to see what the issue was.

I hope this saves someone else some time.

[emnoc]

So what's connecting to the SSLVPN ( forticlient or portal )?

Ken

[seadave]

Neither. Client wouldn’t connect and page wouldn’t load until I made changes as indicated. Will see what TAC says. Not sure if it was something carried over from 5.4 config or a default in 5.6. One other odd behavior, if I changed ssl vpn cert to Fortinet _Factory, portal page would load untrusted due to host name mismatch, but using my Digicert cert would only give cipher error until I modified ssl vpn global settings as indicated.

[seadave]

To be clear we were testing both FC 5.6 and portal.

[emnoc]

but using my Digicert cert would only give cipher error until I modified ssl vpn global settings as indicated

That doesn't make sense, but what type of cert ( SAN *wildcard STD ), keysize ?

[seadave]

Correct, it doesn't make sense.  We'll see what TAC says.  Cert was/is an ECC256p cert, Fortigate generated CSR, cert generated by Digicert.  Digicert CA cert is loaded so not a trust signing issues.  One of those commands impacted how that cert was presented to client connections.  I've had this issue before on a prior firmware release.  I tried to use an ECC cert for the Admin interface and that wasn't supported for some reason.

I wish I had tried the CLI modification before re-signing the cert with a new CSR.  But the end result was that had no impact on resolution.  The resolution was changing the two commands mentioned above.

Here is another symptom to ponder.  When using the default settings of those two commands, neither the Qualys or Digicert verification signers could negotiate a session to verify the cert.  They would immediately respond with connection refused or unable to negotiate a connection, with both the old and new cert.  

After that failed with the updated cert, I realized it had to be a FortiOS issue.  That is when I changed renegotiation to enabled and algorithm to medium.  The minute I did that, both scanners were able to confirm proper cert operation.

[AtiT]

Hi,

can you scan the device with NMAP to see what ciphers are used for ssl? nmap -sV -p <port> --script ssl-enum-ciphers <host>

see: https://nmap.org/nsedoc/scripts/ssl-enum-ciphers.html

Maybe it will show something ...maybe.

[seadave]

I used Qualys for a quick scan.  Obscured specific ID values.

Subject x.x.com Fingerprint SHA256: xxxxxxxxxxxxxxxxxxxxxxxxxxxx Pin SHA256: xxxxxxxxxxxxxxxxxxxxxxxxxx Common names x.x.com Alternative names x.x.com Serial Number xxxxxxxxxxxxxxxxxxxxxxxxxxxx Valid from Fri, 06 Jul 2018 00:00:00 UTC Valid until Fri, 05 Oct 2018 12:00:00 UTC (expires in 2 months and 25 days) Key EC 256 bits Weak key (Debian) No Issuer DigiCert ECC Secure Server CA AIA: http://cacerts.digicert.c...tECCSecureServerCA.crt Signature algorithm SHA256withECDSA Extended Validation No Certificate Transparency Yes (certificate) OCSP Must Staple No Revocation information CRL, OCSP CRL: [link]http://crl3.digicert.com/ssca-ecc-g1.crl[/link] OCSP: [link]http://ocsp.digicert.com[/link] Revocation status Good (not revoked) DNS CAA No (more info) Trusted Yes Mozilla Apple Android Java Windows

Additional Certificates (if supplied) Certificates provided 3 (3100 bytes) Chain issues Contains anchor #2 Subject DigiCert ECC Secure Server CA Fingerprint SHA256: 458446ba75d932e914f23c2b57b7d192eddbc2181d958e1181ad5251747a1ee8 Pin SHA256: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw= Valid until Wed, 08 Mar 2023 12:00:00 UTC (expires in 4 years and 7 months) Key EC 384 bits Issuer DigiCert Global Root CA Signature algorithm SHA384withRSA #3 Subject DigiCert Global Root CA In trust store Fingerprint SHA256: 4348a0e9444c78cb265e058d5e8944b4d84f9662bd26db257f8934a443c70161 Pin SHA256: r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E= Valid until Mon, 10 Nov 2031 00:00:00 UTC (expires in 13 years and 4 months) Key RSA 2048 bits (e 65537) Issuer DigiCert Global Root CA Self-signed Signature algorithm SHA1withRSA Weak, but no impact on root certificate

Show Certification Paths Certification Paths Click here to expand

Configuration

Protocols TLS 1.3 No TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 No SSL 3 No SSL 2 No For TLS 1.3 tests, we currently support draft version 23.

Cipher Suites # TLS 1.2 (suites in server-preferred order) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (0xc0af) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CCM (0xc0ad) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc073) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) ECDH secp256r1 (eq. 3072 bits RSA) FS 256 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (0xc0ae) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_128_CCM (0xc0ac) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc072) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) ECDH secp256r1 (eq. 3072 bits RSA) FS 128 TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK 112 # TLS 1.1 (suites in server-preferred order)

Handshake Simulation Android 4.4.2 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Android 5.0.0 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDH secp256r1 FS Android 6.0 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDH secp256r1 FS Android 7.0 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS BingPreview Jan 2015 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Chrome 49 / XP SP3 Server sent fatal alert: handshake_failure Chrome 65 / Win 7 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Firefox 31.3.0 ESR / Win 7 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ECDH secp256r1 FS Firefox 47 / Win 7 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 ECDH secp256r1 FS Firefox 49 / XP SP3 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Firefox 59 / Win 7 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Googlebot Feb 2018 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS IE 11 / Win 7 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS IE 11 / Win 8.1 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS IE 11 / Win Phone 8.1 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS IE 11 / Win Phone 8.1 Update R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS IE 11 / Win 10 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Edge 15 / Win 10 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Edge 13 / Win Phone 10 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Java 8u161 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS OpenSSL 1.0.1l R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS OpenSSL 1.0.2e R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Safari 6 / iOS 6.0.1 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS Safari 7 / iOS 7.1 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS Safari 7 / OS X 10.9 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS Safari 8 / iOS 8.4 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS Safari 8 / OS X 10.10 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS Safari 9 / iOS 9 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Safari 9 / OS X 10.11 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Safari 10 / iOS 10 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Safari 10 / OS X 10.12 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Apple ATS 9 / iOS 9 R EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS Yahoo Slurp Jan 2015 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS YandexBot Jan 2015 EC 256 (SHA256) TLS 1.2 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS # Not simulated clients (Protocol mismatch) Click here to expand

(1) Clients that do not support Forward Secrecy (FS) are excluded when determining support for it. (2) No support for virtual SSL hosting (SNI). Connects to the default site if the server uses SNI. (3) Only first connection attempt simulated. Browsers sometimes retry with a lower protocol version. (R) Denotes a reference browser or client, with which we expect better effective security. (All) We use defaults, but some platforms do not use their best protocols and features (e.g., Java 6 & 7, older IE). (All) Certificate trust is not checked in handshake simulation, we only perform TLS handshake.

Protocol Details DROWN No, server keys and hostname not seen elsewhere with SSLv2 Secure Renegotiation Supported Secure Client-Initiated Renegotiation Yes Insecure Client-Initiated Renegotiation No BEAST attack Mitigated server-side (more info) POODLE (SSLv3) No, SSL 3 not supported (more info) POODLE (TLS) No (more info) Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported (more info) SSL/TLS compression No RC4 No Heartbeat (extension) No Heartbleed (vulnerability) No (more info) Ticketbleed (vulnerability) No (more info) OpenSSL CCS vuln. (CVE-2014-0224) No (more info) OpenSSL Padding Oracle vuln. (CVE-2016-2107) No (more info) ROBOT (vulnerability) No (more info) Forward Secrecy Yes (with most browsers) ROBUST (more info) ALPN No NPN No Session resumption (caching) No (IDs assigned but not accepted) Session resumption (tickets) Yes OCSP stapling No Strict Transport Security (HSTS) Yes TOO SHORT (less than 180 days) max-age=28800 HSTS Preloading Not in: Chrome Edge Firefox IE Public Key Pinning (HPKP) No (more info) Public Key Pinning Report-Only No Public Key Pinning (Static) No (more info) Long handshake intolerance No TLS extension intolerance No TLS version intolerance No Incorrect SNI alerts No Uses common DH primes No, DHE suites not supported DH public server param (Ys) reuse No, DHE suites not supported ECDH public server param reuse No Supported Named Groups secp256r1 SSL 2 handshake compatibility No

HTTP Requests 1 [link]https://x.x.com/[/link] (HTTP/1.1 200 OK)

Miscellaneous Test date Mon, 09 Jul 2018 18:16:42 UTC Test duration 36.559 seconds HTTP status code 200 HTTP server signature xxxxxxxx-xxxxx

[emnoc]

It's a ECC  certificate, are you 100% sure it's supported for SSLVPN ? if you search here in this site a thread a few months back brought up the same issue.

ken

[seadave]

I had an ECC cert issue for the Admin interface on an older 5.4 release.  As mentioned it is now working with ECC, but I had to modify those two ssl vpn global settings to get it to do so.  TAC is researching and I'll post results when found.