Let’s encrypt e nginx

22 Dicembre 2015

Durante l’ultima workweek Mozilla a Orlando ho assistito a una breve presentazione di Let’s Encrypt da parte di Eric Rescorla (:ekr). Mi ero ripromesso di fare qualche prova al ritorno e, complice il passaggio da dedicato+debian+apache a vps+ubuntu+nginx, mi sono finalmente deciso a farlo.

Che cos’è “Let’s Encrypt”: un’autorità di certificazione indipendente e aperta che permette al proprietario di un sito web di ottenere gratuitamente dei certificati. Per ulteriori dettagli consiglio la lettura del post inaugurale del blog.

Veniamo al dunque: come ottenere un certificato per il dominio che ospita questo blog e configurare nginx per utilizzarlo.

Per prima cosa bisogna clonare il repository (non esiste ancora un pacchetto per Ubuntu):

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Come spiegato nella documentazione: letsencrypt-auto è un wrapper che si occupa di installare le dipendenze e creare un ambiente virtuale per Python, e il plugin per nginx è ancora altamente sperimentale (al contrario di Apache).

Nel mio caso voglio:

  • ottenere solamente il certificato senza modificare alcuna configurazione;
  • utilizzare il webserver “standalone” per recuperare il certificato. Siccome il plugin occupa la porta 80 o la 443, potrebbe essere necessario bloccare temporaneamente il server nginx.

Questo è il contenuto del file di configurazione per evitare una linea di comando infinita (modificare l’indirizzo email)

# Use a 4096 bit RSA key instead of 2048
rsa-key-size = 4096
email = YOUREMAIL@EXAMPLE.COM

# Standalone authenticator on port 443
authenticator = standalone
standalone-supported-challenges = tls-sni-01

E questo il comando da lanciare (modificare il dominio e il percorso al file di configurazione)

./letsencrypt-auto certonly --config /root/cli.ini -d EXAMPLE.COM

La prima volta verrà chiesto di accettare le condizioni di servizio. Dopo pochi istanti il certificato verrà salvato in una sottocartella di /etc/letsencrypt/live/.

A questo punto bisogna aggiornare la configurazione del dominio in nginx. Personalmente ho utilizzato il generatore messo a disposizione da Mozilla, modificando

    ssl_dhparam /etc/nginx/dhparam.pem;
    ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem;

E rimuovendo la linea ssl_session_tickets off; (non compatibile con la mia versione di nginx).

Per utilizzare questa configurazione, la prima volta bisogna generare una chiave Diffie-Hellman:

cd /etc/nginx
openssl dhparam -out dhparam.pem 2048

Se riuscite a leggere questo post, significa che non è esploso nulla.


Da qualche ora è disponibile per il download Firefox 2.0.0.5: questa versione risolve il bug emerso nei giorni scorsi relativo all’URI protocol handling.

Da subito si è parlato di un bug di Firefox e non di Internet Explorer: ma ne siamo così sicuri? A quanto pare il bug in questione affligge un numero imprecisato di applicazioni Windows: qui c’è un POC (Proof of Concept) per Trillian, ma non si tratta di un caso isolato:

I can still automatically launch a wide range of external applications from Internet Explorer and provide them with arbitrary command line arguments. AcroRd32.exe (Adobe Acrobat PDF Reader), aim.exe (AOL Instant Messenger), Outlook.exe, msimn.exe (Outlook Express), netmeeting.exe, HelpCtr.exe (Windows Help Center), mirc.exe, Skype.exe, wab.exe (Windows Address Book) and wmplayer.exe (Windows Media Player) – just to name a few.

Scrive Window Snyder:

This patch for Firefox prevents Firefox from accepting bad data from Internet Explorer. It does not fix the critical vulnerability in Internet Explorer. Microsoft needs to patch Internet Explorer, but at last check, they were not planning to. Mark Griesi is quoted in Infoworld saying “We don’t feel that there’s an issue in IE, and therefore, there’s nothing to be fixed.”

In altre parole: noi ci abbiamo messo una pezza, ma il problema non è di Firefox quanto di Internet Explorer. Naturalmente in Microsoft non la pensano allo stesso modo: “Non pensiamo che questo sia un problema di IE, perciò non c’è nulla da sistemare.”

Da IEBlog:

The limitless variety of applications and their unique capabilities make it very difficult to have any meaningful automated parameter validation by the hosting (caller) application. It is the responsibility of the receiving (called) application to make sure it can safely process the incoming parameters.

La colpa è di chi riceve la chiamata (Firefox), non di chi la passa (Internet Explorer): troppo complicato gestire il problema a monte.

Dalle parti di Mozilla la pensano in modo diverso:

At Mozilla, we were able to address the biggest part of this problem in Firefox ages ago by simply escaping quotes in URLs before handing them off.

When you’re surfing the web in Firefox and a website wants to send an address to some other application like AIM or Skype or Acrobat Reader, Firefox packages up that address before handing it off to another application. We think it’s Firefox’s job to ensure that users are protected from malicious websites when they’re surfing the web in Firefox. Apparently Microsoft doesn’t think the same for IE.

Saying it’s too hard is not a justification for failing to take even the bare minimum steps to protect users. Microsoft needs to reconsider here and do what’s right for the millions of IE users at risk instead of trying to shift the responsibility to “limitless variety of applications” that users have installed.

Making good software is hard. Making good software secure can be even harder. At Mozilla, we vigorously take up that challenge. We don’t use it as an excuse for inaction.

In sostanza: pensiamo che sia compito di Firefox garantire una navigazione sicura agli utenti che navigano usando Firefox. Come dargli torto? 😉