Nicholas Giordano

Ultimamente mi sono imbattuto, utilizzando un server gestito tramite Plesk, nel seguente messaggio d’errore: “ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY”. Stiamo parlando ovviamente di un messaggio dovuto a qualcosa di non funzionante riguardante i certificati SSL/TSL, la cosa buffa è che però il suddetto messaggio non appariva su tutti i browser che andavano a visitare i domini e che i certificati installati sul suddetto dominio risultavano pienamente validi. La problematica si verificava infatti solamente quando vecchi browser o sistemi con una vecchia versione di Android andavano a navigare verso gli indirizzi in questione. Come tutti i server gestiti dalle recenti versioni di Plesk, le pagine web vengono “servite” utilizzando nginx come reverse proxy per Apache il che garantisce una quantità di migliorie sotto il punto di vista della gestione dei traffici anche più elevati e buoni margini di operabilità dei servizi offerti dalla nostra macchina in una vastità molto ampia di scenari d’utilizzo. Proprio per questa cosa ho pensato che potesse essere nginx il problema paradossalmente parlando. Infatti una volta disattivato ed utilizzando il solo Apache la problematica è totalmente rientrata. E’ però una valida soluzione uccidere un servizio che ci aiuta in così tanti modi? Ovviamente no, motivo per cui mi sono messo a cercare una soluzione diversa! Consideriamo ovviamente che una dinamica del genere la vediamo affliggere i nostri domini solo nel caso in cui li abbiamo su un server personale, vps o dedicato che sia e che assolutamente mai si verifica se utilizziamo hosting gestito da una qualsiasi compagnia che si rispetti, se vediamo quindi comparire il messaggio d’errore su un nostro piano hosting il problema è probabilmente dovuto ad altro (SPDY o Chiper).

Qual’è quindi la soluzione al mio problema se non voglio (giustamente) disattivare il reverse proxy? Semplice! Fornire ad nginx opportune direttive che gli permettano di rispondere correttamente anche a sistemi un po “vecchi” ed “inadeguati” che vanno a dialogare con lui.

Le direttive da dare ad nginx sono le seguenti, ed andranno date per ogni dominio di cui è reverse proxy

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
ssl_prefer_server_ciphers on

In questo modo anche i browser più vecchi riusciranno a verificare l’autinticità del certificato SSL/TSL facendo accedere l’utente finale alle reali pagine di destinazione.

Perchè preoccuparci di una cosa del genere però? Magari abbiamo il nostro dominio sul nostro sistema gestito tramite plesk e mai abbiamo notato una cosa del genere e i nostri siti sempre hanno funzionato in maniera opportuna. Ebbene, il problema è proprio qui. Tutto funziona correttamente, il problema non si nota fino a quanto un tuo cliente non raggiunge un dominio al quale il suo dispositivo dice che per “ragioni di sicurezza” non può accedere, e questa ovviamente è una cosa che vogliamo scongiurare a tutti i costi 😉