Come attivare il supporto SSL su WordPress 2.6.

Logo WordPressWordPress 2.6 include un supporto migliore per visitare la sezione di amministrazione via SSL.

Questa funzione ha bisogno che i cookie di autorizzazione siano inviati esclusivamente attraverso sessioni HTTPS (cifrate).
Per permettere questa possibilità, lasciando la possibilità di visitare il pannello di amministrazione tramite HTTP (in chiaro), WordPress 2.6 passa da un unico cookie ad una impostazione a 3 cookie.

Nelle versioni precedenti WordPress impostava un cookie. Questo cookie era consegnato tramite tutte le pagine del blog sia attraverso connessioni SSL che tramite connessioni in chiaro ed insicure. Era consegnato alla homepage del blog ed alle pagine di amministrazione. Fornire un cookie nelle pagine esterne di WordPress permette di mostrare, ad esempio, i link di logout per l’utente. Per supportare adeguatamente l’SSL, WordPress deve essere in grado di inviare il cookie di autenticazione esclusivamente attraverso sessioni SSL. Se WordPress avesse continuato con un singolo cookie e l’avesse reso più sicuro inviandolo solamente tramite sessioni SSL, quel cookie non avrebbe funzionato in homepage in quanto la maggior parte della gente non visita la propria homepage tramite SSL. Così, WordPress non sarebbe stato in grado di mostrare le informazioni dello stato dell’utente corrente.

Per porre rimedio a questo, WordPress 2.6, separa i cookie di “accesso” e “autenticazione”. Il cookie di accesso è inviato per tutte le pagine del blog attraverso sessioni SSL e non e non può essere usato per accedere alle pagine di amministrazione. Questo cookie indica semplicemente che uno specifico utente è connesso. Il cookie di accesso non può esser usato per effettuare modifiche al blog.

Il cookie di autenticazione, invece, è inviato solo per l’area di amministrazione e può essere usato per effettuare modifiche al blog. Se si effettua il login via HTTPS, il cookie di autenticazione sarà inviato solo per sessioni SSL. Se dunque si effettua il login via HTTPS e poi si visita il pannello di amministrazione tramite HTTP, sarà necessario effettuare un nuovo login per ricevere un cookie di autenticazione non-SSL. Di default, è possibile visitare la pagina di amministrazione sia via HTTP che HTTPS. Se si vuol far si che tutte le sessioni di amministrazione avvengano via HTTPS, è necessario aggiungere la seguente riga al file wp-config.php:

define(’FORCE_SSL_ADMIN’, true);

Questo bloccherà ogni accesso non-SSL al blog. Significa che non sarà mai inviato un cookie di autenticazione in chiaro. Se si vuole far si che i login avvengano via SSL per prevenire che il nome utente e la password vengano inviate in chiaro ma permettere che gli utenti scelgano se usare l’HTTP o l’HTTPS per visitare il pannello di amministrazione, è necessario aggiungere questa riga al file wp-config.php:

define(’FORCE_SSL_LOGIN’, true);

Questo fa si che non tutti i cookie siano inviati via SSL. Gli utenti possono scegliere tra la sicurezza di una sessione HTTPS e la velocità di una sessione HTTP. Se si vuol evitare questa possibilità e forzare l’uso di sessioni HTTPS, bisogna usare FORCE_SSL_ADMIN.

Con questi nuovi cookie sono necessarie delle nuove chiavi segrete. WordPress 2.5 ha introdotto una SECRET_KEY come mezzo per aggiungere un po’ di sicurezza aggiuntiva durante la creazione del cookie. Se si vuole usare il supporto SSL con la versione 2.6, sarà necessario impostare le chiavi segrete per la sicurezza dei cookie. Se non intendete invece utilizzare il supporto SSL, è sufficiente rimanere con la propria SECRET_KEY. Ecco un esempio di come sarebbero le definizioni delle nuove chiavi segrete:

define ( 'AUTH_KEY', 'metti qui la tua sequenza random');
define ( 'SECURE_AUTH_KEY', 'metti qui la tua sequenza random');
define ( 'LOGGED_IN_KEY', 'metti qui la tua sequenza random');

Dovreste cambiare questi esempi con sequenze di caratteri uniche, preferibilmente random. Ogni chiave dovrebbe essere diversa. Per ricevere un set di chiavi random semplicemente da copiare ed incollare nel file wp-config.php andate qui. Ancora una volta, se non si si intende utilizzare l’SSL, si può continuare ad usare la SECRET_KEY che si ha già dalla versione 2.5 di WordPress.

In linea di massima, tutto questo dovrebbe essere invisibile ai plugin ed ai temi. Ci sono però alcuni temi che inviano richieste POST e AJAX a file dentro la cartella dei temi. I cookie di autenticazione sono inviati solo per la cartella wp-admin e quella wp-content/plugins, così i file aperti direttamente da wp-content/themes non vedranno il cookie. I temi dovrebbero inviare le loro richieste POST e AJAX tramite i file admin-post.php e admin-ajax.php. C’è un piccolo articolo nel codex su come i temi ed i plugin dovrebbero gestire le loro richieste POST e AJAX.

I plugin potrebbero anche creare link che non sono prefissati correttamente con “https”. Qualsiasi contenuto in una pagina cifrata deve arrivare attraverso un link HTTPS per evitare gli avvisi del browser circa contenuti parzialmente cifrati. WordPress 2.6 introduce cinque nuove funzioni che si occupano di gestire il protocollo giusto quando si caricano CSS, JavaScript e altri file in una pagina di amministrazione cifrata. Queste funzioni sono: site_url(), admin_url(), includes_ur(), plugins_url(), e content_url(). Ognuna accetta una path “relativa” rispettivamente per i link site, admin, include, plugins e contents. Per esempio per collegarsi a wp-content/plugins/foo/foo.php basta usare plugins_url(‘foo/foo.php’). I plugin che caricano CSS o JavaScript tramite link relativi non hanno bisogno di usare queste funzioni. I link relativi utilizzeranno automaticamente il protocollo corretto.

Emanuele

PS: libera traduzione di quanto scritto da Rayn, sviluppatore di WordPress, se doveste notare qualche inesattezza non esitate a segnalarmela. 🙂

Posted by

Ingegnere. Si divide tra lavoro, bicicletta, monociclo e volontariato. Vive con sua moglie in una casa con un ciliegio e otto pesciolini che non lo aiutano a tenere in ordine.

17 comments » Write a comment

  1. Davvero molto interessante… peccato che il mio sito non supporti al momento SSL…
    Ciao e grazie per l’utile spiegazione!

  2. Utile approfondimento, non avevo trattato la questione sul mio post, ma sicuramente è una novità da considerare.

  3. Scusami, quindi per mettere “dietro https” il pannello di controllo e la schermata di login basta inserire nel file wp-config.php le due righe di codice che menzioni ed aggiungere le tre secret key generate “random” con il tool che hai linkato?
    basta?
    nulla lato server?

  4. Beh Marco, ovviamente il server deve supportare il protocollo HTTPS, altrimenti non risponderà alle richieste (ti ricordo che gli accessi HTTPS avvengono sulla porta 443 e non sulla 80) e tutto l’ambaradan di WordPress sarà inutile.
    Ciao,
    Emanuele

  5. Quindi bisogna comprarsi un certificato SSL, se si vuole usare questa funzionalità 🙂 Peccato che molti provider italiani (compreso Tophost, sob) non abbiano questa caratteristica. Pazienza…

  6. Grazie della risposta, Emanuele.
    Ho mandato una mail a chi tiene il server, vediamo.
    Perchè avevo provato ma non funzionava.
    🙁

  7. Beh camu per 10€ l’anno non si può pretendere di più.
    DreamHost offre il certificato se si acquista l’IP unico.
    Hostingzoom invece offre sia un certificato personale (da acquistare) o permette di utilizzarne uno loro “condiviso” (più che sufficiente in questo caso…).
    In Italia invece, i provider son molto più tirchi. 🙂
    Ciao,
    Emanuele

  8. Risolto l’arcano: devo acquistare un certificato ssl e un ip dedicato, che fanno 185 euro all’anno in più. 🙁

  9. La sicurezza… costa! 🙂 Io uso metodi molto più economici, ma abbastanza robusti. Certo, il famoso attacco dell’uomo “in the middle” è possibile, ma poco plausibile. Riguardo a Tophost, sono il primo a non criticarli, anzi! Per 10 euro danno pure troppo, rispetto alla concorrenza.

  10. interessante devo provare a seguire questa guida.
    ti volevo chiedere una cosa com mai mi da un trackback di un mio articolo da parte di questa pagina ma non vedo link al mio da quest’ultima? L’unica cosa simile al mio articolo è l’immagine forse si tratta di un errore di wordpres? 😆 Comunque se era una cosa voluta mi fa piacere leggere i tuoi articoli quindi mandami semplicemente un mail :joy:
    ciao!

  11. Marco, con che provider? Giusto per farmi un’idea…
    camu, è vero, l’https in fin dei conti non risolve vulnerabilità degli script ma esclusivamente aumenta il grado di sicurezza durante la gestione del blog. Se sappiamo già proteggere le nostre connessioni, difficilmente qualcuno riuscirà a sniffare i nostri dati.
    Tophost lo apprezzo pure io… ma è troppo poco per questo blog. 😐
    niko51, i trackback funzionano diversamente dai pingback, nessun errore di WordPress. I trackback nacquero per segnalare su altri siti web che altrove si stava discutendo su argomenti simili. E’ un modo per allargare la discussione encomiabile dal punto di vista filosofico. 🙂
    Ciao,
    Emanuele

  12. Grazie per i chiarimento Emanuele! Non si finisce mai di imparare! 😀 😛
    A presto,
    niko

  13. Pingback: Gioxx’s Wall » Blog Archive » Best of Week #13

  14. bella guida
    appena ho 5 min ci provo, sperando che nn diventino 5 ore per miei errori 😀
    Matteo

  15. UtilissimO!!! Ci sto facendo una relazione sopra per l’esame di Sicurezza INformatica! Ottimo lavoro!!! 😉

  16. Ciao Emanuele! Ho aperto questo glog con altervista ma non riesco a capire se è possibile attivare ssl. Dal poco che ho capito dovrei trasformarlo in sito… tu per caso ne sai qualcosa? Mi faresti un enorme favore… cosi non posso condividere su Facebook e per me è un grosso handicap.
    ciao e grazie
    Giulia

Lascia un commento

Required fields are marked *.