15 Crittografia

Panoramica

Zabbix supporta comunicazioni crittografate tra i componenti Zabbix utilizzando il protocollo Transport Layer Security (TLS) v.1.2 e 1.3 (a seconda della libreria crittografica). Sono supportate la crittografia basata su certificati e quella basata su chiavi precondivise.

La crittografia può essere configurata per le connessioni:

• Tra Zabbix server, Zabbix proxy, Zabbix agent, Zabbix web service, le utility zabbix_sender e zabbix_get
• Al database Zabbix da Zabbix frontend e server/proxy
• Tra Zabbix frontend e Zabbix server

La crittografia è facoltativa e configurabile per i singoli componenti:

• Alcuni proxy e agent possono essere configurati per utilizzare la crittografia basata su certificati con il server, mentre altri possono usare la crittografia basata su chiavi precondivise, e altri ancora possono continuare con comunicazioni non crittografate (come in precedenza).
• Il server (proxy) può utilizzare configurazioni di crittografia diverse per host differenti.

I programmi daemon di Zabbix utilizzano un'unica porta di ascolto per le connessioni in ingresso crittografate e non crittografate. L'aggiunta della crittografia non richiede l'apertura di nuove porte nei firewall.

Limitazioni

• Le chiavi private sono memorizzate in testo semplice in file leggibili dai componenti di Zabbix durante l'avvio.
• Le chiavi precondivise vengono inserite nel frontend di Zabbix e memorizzate nel database di Zabbix in testo semplice.
• La crittografia integrata non protegge le comunicazioni tra il web server che esegue il frontend di Zabbix e il browser web dell'utente.
• Attualmente ogni connessione crittografata viene aperta con un handshake TLS completo; non sono implementati né il caching delle sessioni né i ticket.
• L'aggiunta della crittografia aumenta il tempo necessario per i controlli degli item e le azioni, a seconda della latenza di rete:
  • Ad esempio, se il ritardo dei pacchetti è di 100 ms, l'apertura di una connessione TCP e l'invio di una richiesta non crittografata richiedono circa 200 ms. Con la crittografia vengono aggiunti circa 1000 ms per stabilire la connessione TLS.
  • Potrebbe essere necessario aumentare i timeout, altrimenti alcuni item e azioni che eseguono script remoti sugli agent potrebbero funzionare con connessioni non crittografate, ma fallire per timeout con quelle crittografate.
• La crittografia non è supportata da network discovery. I controlli di Zabbix agent eseguiti dal network discovery non saranno crittografati e, se Zabbix agent è configurato per rifiutare le connessioni non crittografate, tali controlli non avranno successo.

Compilazione di Zabbix con supporto alla crittografia

Per supportare la crittografia, Zabbix deve essere compilato e collegato con una delle librerie crittografiche supportate:

• GnuTLS - dalla versione 3.1.18
• OpenSSL - versioni 1.0.1, 1.0.2, 1.1.0, 1.1.1, 3.0.x
• LibreSSL - testato con le versioni 2.7.4, 2.8.2:
  • LibreSSL 2.6.x non è supportato
  • LibreSSL è supportato come sostituto compatibile di OpenSSL; le nuove funzioni API specifiche di LibreSSL tls_*() non vengono utilizzate. I componenti di Zabbix compilati con LibreSSL non saranno in grado di usare PSK, potranno essere usati solo i certificati.

La libreria viene selezionata specificando la rispettiva opzione nello script "configure":

• --with-gnutls[=DIR]
• --with-openssl[=DIR] (usato anche per LibreSSL)

Ad esempio, per configurare i sorgenti per server e agent con OpenSSL puoi usare qualcosa come:

./configure --enable-server --enable-agent --with-mysql --enable-ipv6 --with-net-snmp --with-libcurl --with-libxml2 --with-openssl

Diversi componenti di Zabbix possono essere compilati con librerie crittografiche diverse (ad esempio un server con OpenSSL, un agent con GnuTLS).

Gestione della cifratura delle connessioni

Le connessioni in Zabbix possono utilizzare:

• nessuna cifratura (predefinita)
• cifratura basata su certificati RSA
• cifratura basata su PSK

Esistono due parametri importanti utilizzati per specificare la cifratura tra i componenti di Zabbix:

• TLSConnect - specifica quale cifratura utilizzare per le connessioni in uscita (non cifrate, PSK o certificato)
• TLSAccept - specifica quali tipi di connessioni sono consentiti per le connessioni in ingresso (non cifrate, PSK o certificato). È possibile specificare uno o più valori.

TLSConnect viene utilizzato nei file di configurazione di Zabbix proxy (in modalità attiva, specifica solo le connessioni verso server) e di Zabbix agent (per i controlli attivi). In Zabbix frontend l'equivalente di TLSConnect è il campo Connessioni verso host nella scheda Raccolta dati → Host → <some host> → Cifratura e il campo Connessioni verso proxy nella scheda Amministrazione → Proxy → <some proxy> → Cifratura. Se il tipo di cifratura configurato per la connessione fallisce, non verranno provati altri tipi di cifratura.

TLSAccept viene utilizzato nei file di configurazione di Zabbix proxy (in modalità passiva, specifica solo le connessioni da server) e di Zabbix agent (per i controlli passivi). In Zabbix frontend l'equivalente di TLSAccept è il campo Connessioni da host nella scheda Raccolta dati → Host → <some host> → Cifratura e il campo Connessioni da proxy nella scheda Amministrazione → Proxy → <some proxy> → Cifratura.

Normalmente si configura un solo tipo di cifratura per le connessioni in ingresso. Tuttavia, potrebbe essere necessario cambiare il tipo di cifratura, ad esempio da non cifrata a basata su certificato, con un tempo di inattività minimo e la possibilità di rollback. Per ottenere questo risultato:

• Impostare TLSAccept=unencrypted,cert nel file di configurazione di agent e riavviare Zabbix agent
• Testare la connessione con zabbix_get verso agent utilizzando un certificato. Se funziona, è possibile riconfigurare la cifratura per quell'agent in Zabbix frontend nella scheda Raccolta dati → Host → <some host> → Cifratura impostando Connessioni verso host su "Certificato".
• Quando la cache di configurazione di server viene aggiornata (e la configurazione di proxy viene aggiornata se l'host è monitorato da proxy), allora le connessioni verso quell'agent saranno cifrate
• Se tutto funziona come previsto, è possibile impostare TLSAccept=cert nel file di configurazione di agent e riavviare Zabbix agent. Ora agent accetterà solo connessioni cifrate basate su certificato. Le connessioni non cifrate e quelle basate su PSK verranno rifiutate.

In modo simile funziona su server e proxy. Se in Zabbix frontend nella configurazione dell'host Connessioni da host è impostato su "Certificato", allora saranno accettate dall'agent solo connessioni cifrate basate su certificato (controlli attivi) e zabbix_sender (item trapper).

Molto probabilmente si configureranno le connessioni in ingresso e in uscita per utilizzare lo stesso tipo di cifratura oppure nessuna cifratura. Tuttavia, tecnicamente è possibile configurarle in modo asimmetrico, ad esempio cifratura basata su certificato per le connessioni in ingresso e basata su PSK per quelle in uscita.

La configurazione della cifratura per ciascun host viene visualizzata in Zabbix frontend, in Raccolta dati → Host nella colonna Cifratura agent. Ad esempio:

Esempio	Connessioni verso host	Connessioni consentite da host	Connessioni rifiutate da host
	Non cifrate	Non cifrate	Cifrate, basate su certificato e basate su PSK
	Cifrate, basate su certificato	Cifrate, basate su certificato	Non cifrate e cifrate basate su PSK
	Cifrate, basate su PSK	Cifrate, basate su PSK	Non cifrate e cifrate basate su certificato
	Cifrate, basate su PSK	Non cifrate e cifrate basate su PSK	Cifrate basate su certificato
	Cifrate, basate su certificato	Non cifrate, oppure cifrate basate su PSK o su certificato	-

zabbix_get e zabbix_sender con crittografia

Vedere le pagine man di zabbix_get e zabbix_sender per informazioni sul loro utilizzo con la crittografia.

Ciphersuite

Per impostazione predefinita, le ciphersuite vengono configurate internamente durante l'avvio di Zabbix.

Sono supportate anche ciphersuite configurate dall'utente per GnuTLS e OpenSSL. Gli utenti possono configurare le ciphersuite in base alle proprie policy di sicurezza. L'uso di questa funzionalità è facoltativo (le ciphersuite predefinite integrate continuano comunque a funzionare).

Per le librerie crittografiche compilate con le impostazioni predefinite, le regole integrate di Zabbix in genere producono le seguenti ciphersuite (in ordine di priorità dalla più alta alla più bassa):

Ciphersuite configurate dall'utente

I criteri integrati di selezione delle ciphersuite possono essere sovrascritti con ciphersuite configurate dall'utente.

I criteri integrati di selezione delle ciphersuite possono essere sovrascritti utilizzando i seguenti parametri:

Per sovrascrivere la selezione delle ciphersuite nelle utility zabbix_get e zabbix_sender, utilizzare i parametri della riga di comando:

• --tls-cipher13
• --tls-cipher

I nuovi parametri sono facoltativi. Se un parametro non è specificato, viene utilizzato il valore predefinito interno. Se un parametro è definito, non può essere vuoto.

Se l'impostazione di un valore TLSCipher* nella libreria crittografica non riesce, allora server, proxy o agent non si avvieranno e verrà registrato un errore.

È importante comprendere quando ciascun parametro è applicabile.

Connessioni in uscita

Il caso più semplice è quello delle connessioni in uscita:

• Per le connessioni in uscita con certificato, utilizzare TLSCipherCert13 o TLSCipherCert
• Per le connessioni in uscita con PSK, utilizzare TLSCipherPSK13 o TLSCipherPSK
• Nel caso delle utility zabbix_get e zabbix_sender, è possibile usare i parametri della riga di comando --tls-cipher13 o --tls-cipher (la crittografia è specificata in modo univoco con il parametro --tls-connect)

Connessioni in ingresso

La situazione è un po' più complicata con le connessioni in ingresso, perché le regole sono specifiche per i componenti e per la configurazione.

Per Zabbix agent:

Per Zabbix server e proxy:

Nelle due tabelle sopra è possibile osservare un certo schema:

• TLSCipherAll e TLSCipherAll13 possono essere specificati solo se viene usato un elenco combinato di suite di cifratura basate su certificato e su PSK. Ci sono due casi in cui questo avviene: server (proxy) con un certificato configurato (le suite di cifratura PSK sono sempre configurate su server e proxy se la libreria crittografica supporta PSK), agent configurato per accettare connessioni in ingresso sia basate su certificato sia su PSK
• negli altri casi sono sufficienti TLSCipherCert* e/o TLSCipherPSK*

Le tabelle seguenti mostrano i valori predefiniti integrati di TLSCipher*. Possono essere un buon punto di partenza per i propri valori personalizzati.

¹ I valori predefiniti sono diversi per le versioni OpenSSL meno recenti (1.0.1, 1.0.2, 1.1.0), per LibreSSL e se OpenSSL è compilato senza supporto PSK.

Esempi di suite di cifratura configurate dall'utente

Vedere di seguito i seguenti esempi di suite di cifratura configurate dall'utente:

• Test delle stringhe dei cifrari e autorizzazione delle sole suite di cifratura PFS
• Passaggio da AES128 ad AES256

Test delle stringhe di cifratura e autorizzazione delle sole suite di cifratura PFS

Per vedere quali suite di cifratura sono state selezionate, è necessario impostare 'DebugLevel=4' nel file di configurazione oppure usare l'opzione -vv per zabbix_sender.

Potrebbe essere necessario fare alcune prove con i parametri TLSCipher* prima di ottenere le suite di cifratura desiderate. Riavviare Zabbix server, proxy o agent più volte solo per modificare i parametri TLSCipher* è scomodo. Opzioni più pratiche sono usare zabbix_sender o il comando openssl. Mostriamo entrambe.

1. Uso di zabbix_sender.

Creiamo un file di configurazione di test, ad esempio /home/zabbix/test.conf, con la sintassi di un file zabbix_agentd.conf:

  Hostname=nonexisting
  ServerActive=nonexisting

  TLSConnect=cert
  TLSCAFile=/home/zabbix/ca.crt
  TLSCertFile=/home/zabbix/agent.crt
  TLSKeyFile=/home/zabbix/agent.key
  TLSPSKIdentity=nonexisting
  TLSPSKFile=/home/zabbix/agent.psk

Per questo esempio sono necessari certificati CA e agent validi e una PSK. Adattare i percorsi e i nomi dei file dei certificati e della PSK al proprio ambiente.

Se non si usano certificati, ma solo PSK, è possibile creare un file di test più semplice:

  Hostname=nonexisting
  ServerActive=nonexisting

  TLSConnect=psk
  TLSPSKIdentity=nonexisting
  TLSPSKFile=/home/zabbix/agentd.psk

Le suite di cifratura selezionate possono essere visualizzate eseguendo zabbix_sender (esempio compilato con OpenSSL 1.1.d):

  $ zabbix_sender -vv -c /home/zabbix/test.conf -k nonexisting_item -o 1 2>&1 | grep ciphersuites
  zabbix_sender [41271]: DEBUG: zbx_tls_init_child() certificate ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA
  zabbix_sender [41271]: DEBUG: zbx_tls_init_child() PSK ciphersuites: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA
  zabbix_sender [41271]: DEBUG: zbx_tls_init_child() certificate and PSK ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA

Qui si vedono le suite di cifratura selezionate per impostazione predefinita. Questi valori predefiniti sono scelti per garantire l'interoperabilità con gli agent Zabbix in esecuzione su sistemi con versioni OpenSSL meno recenti (a partire dalla 1.0.1).

Con sistemi più recenti è possibile scegliere di rafforzare la sicurezza consentendo solo alcune suite di cifratura, ad esempio solo quelle con PFS (Perfect Forward Secrecy). Proviamo a consentire solo suite di cifratura con PFS usando i parametri TLSCipher*.

Aggiungere due righe al file di configurazione test.conf:

  TLSCipherCert=EECDH+aRSA+AES128
  TLSCipherPSK=kECDHEPSK+AES128

ed eseguire di nuovo il test:

  $ zabbix_sender -vv -c /home/zabbix/test.conf -k nonexisting_item -o 1 2>&1 | grep ciphersuites            
  zabbix_sender [42892]: DEBUG: zbx_tls_init_child() certificate ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA        
  zabbix_sender [42892]: DEBUG: zbx_tls_init_child() PSK ciphersuites: TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA        
  zabbix_sender [42892]: DEBUG: zbx_tls_init_child() certificate and PSK ciphersuites: TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-CCM8 AES128-CCM AES128-SHA256 AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA PSK-AES128-GCM-SHA256 PSK-AES128-CCM8 PSK-AES128-CCM PSK-AES128-CBC-SHA256 PSK-AES128-CBC-SHA        

Gli elenchi "certificate ciphersuites" e "PSK ciphersuites" sono cambiati

• sono più brevi di prima e contengono solo suite di cifratura TLS 1.3 e suite di cifratura TLS 1.2 ECDHE-*, come previsto.

2. TLSCipherAll e TLSCipherAll13 non possono essere testati con zabbix_sender; non influiscono sul valore "certificate and PSK ciphersuites" mostrato nell'esempio sopra. Per regolare TLSCipherAll e TLSCipherAll13 è necessario fare prove con l'agent, il proxy o il server.

Quindi, per consentire solo suite di cifratura PFS potrebbe essere necessario aggiungere fino a tre parametri

  TLSCipherCert=EECDH+aRSA+AES128
  TLSCipherPSK=kECDHEPSK+AES128
  TLSCipherAll=EECDH+aRSA+AES128:kECDHEPSK+AES128

a zabbix_agentd.conf, zabbix_proxy.conf e zabbix_server_conf se ognuno di essi ha un certificato configurato e l'agent ha anche una PSK.

Se l'ambiente Zabbix usa solo cifratura basata su PSK e non certificati, allora ne basta solo uno:

  TLSCipherPSK=kECDHEPSK+AES128

Ora che è chiaro come funziona, è possibile testare la selezione delle suite di cifratura anche al di fuori di Zabbix, con il comando openssl. Proviamo tutti e tre i valori del parametro TLSCipher*:

  $ openssl ciphers EECDH+aRSA+AES128 | sed 's/:/ /g'
  TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA
  $ openssl ciphers kECDHEPSK+AES128 | sed 's/:/ /g'
  TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA
  $ openssl ciphers EECDH+aRSA+AES128:kECDHEPSK+AES128 | sed 's/:/ /g'
  TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-PSK-AES128-CBC-SHA256 ECDHE-PSK-AES128-CBC-SHA

Si potrebbe preferire openssl ciphers con l'opzione -V per un output più dettagliato:

  $ openssl ciphers -V EECDH+aRSA+AES128:kECDHEPSK+AES128
            0x13,0x02 - TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
            0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
            0x13,0x01 - TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD
            0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
            0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
            0xC0,0x13 - ECDHE-RSA-AES128-SHA    TLSv1 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
            0xC0,0x37 - ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA256
            0xC0,0x35 - ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1

In modo analogo, è possibile testare le stringhe di priorità per GnuTLS:

  $ gnutls-cli -l --priority=NONE:+VERS-TLS1.2:+ECDHE-RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
  Cipher suites for NONE:+VERS-TLS1.2:+ECDHE-RSA:+AES-128-GCM:+AES-128-CBC:+AEAD:+SHA256:+CURVE-ALL:+COMP-NULL:+SIGN-ALL:+CTYPE-X.509
  TLS_ECDHE_RSA_AES_128_GCM_SHA256                        0xc0, 0x2f      TLS1.2
  TLS_ECDHE_RSA_AES_128_CBC_SHA256                        0xc0, 0x27      TLS1.2

  Protocols: VERS-TLS1.2
  Ciphers: AES-128-GCM, AES-128-CBC
  MACs: AEAD, SHA256
  Key Exchange Algorithms: ECDHE-RSA
  Groups: GROUP-SECP256R1, GROUP-SECP384R1, GROUP-SECP521R1, GROUP-X25519, GROUP-X448, GROUP-FFDHE2048, GROUP-FFDHE3072, GROUP-FFDHE4096, GROUP-FFDHE6144, GROUP-FFDHE8192
  PK-signatures: SIGN-RSA-SHA256, SIGN-RSA-PSS-SHA256, SIGN-RSA-PSS-RSAE-SHA256, SIGN-ECDSA-SHA256, SIGN-ECDSA-SECP256R1-SHA256, SIGN-EdDSA-Ed25519, SIGN-RSA-SHA384, SIGN-RSA-PSS-SHA384, SIGN-RSA-PSS-RSAE-SHA384, SIGN-ECDSA-SHA384, SIGN-ECDSA-SECP384R1-SHA384, SIGN-EdDSA-Ed448, SIGN-RSA-SHA512, SIGN-RSA-PSS-SHA512, SIGN-RSA-PSS-RSAE-SHA512, SIGN-ECDSA-SHA512, SIGN-ECDSA-SECP521R1-SHA512, SIGN-RSA-SHA1, SIGN-ECDSA-SHA1

Passaggio da AES128 ad AES256

Zabbix utilizza AES128 come valore predefinito integrato per i dati. Supponiamo che si stiano utilizzando certificati e che si voglia passare ad AES256, su OpenSSL 1.1.1.

Questo può essere ottenuto aggiungendo i rispettivi parametri in zabbix_server.conf:

  TLSCAFile=/home/zabbix/ca.crt
  TLSCertFile=/home/zabbix/server.crt
  TLSKeyFile=/home/zabbix/server.key
  TLSCipherCert13=TLS_AES_256_GCM_SHA384
  TLSCipherCert=EECDH+aRSA+AES256:-SHA1:-SHA384
  TLSCipherPSK13=TLS_CHACHA20_POLY1305_SHA256
  TLSCipherPSK=kECDHEPSK+AES256:-SHA1
  TLSCipherAll13=TLS_AES_256_GCM_SHA384
  TLSCipherAll=EECDH+aRSA+AES256:-SHA1:-SHA384

E in zabbix_agentd.conf:

  TLSConnect=cert
  TLSAccept=cert
  TLSCAFile=/home/zabbix/ca.crt
  TLSCertFile=/home/zabbix/agent.crt
  TLSKeyFile=/home/zabbix/agent.key
  TLSCipherCert13=TLS_AES_256_GCM_SHA384
  TLSCipherCert=EECDH+aRSA+AES256:-SHA1:-SHA384