HTTP 2.0 solo con HTTPS?

Riportando le conclusioni di un recente incontro canadese dell’HTTP Working Group, Mark Nottingham (Internet Engineering Task Force) ha sottolineato quelle che sarebbero state le posizioni discusse relativamente all’utilizzo della criptazione in HTTP 2.0 nonché quella che attualmente dovrebbe essere l’opinione prevalente in proposito; una tendenza che potrebbe non risultare unanimemente condivisa tra gli addetti ai lavori non presenti ai processi decisionali.

Sostanzialmente, le proposte in discussione sarebbero state le seguenti:

1. cifratura per le URI “http://” senza autenticazione server;
2. cifratura per le URI “http://” con autenticazione server;
3. utilizzo delle sole connessioni sicure via HTTPS per HTTP 2.0 e impiego della prima versione di HTTP per le URI “http://”.

Di queste tre ipotesi l’ultima risulterebbe essere stata quella che ha incontrato maggiore approvazione, questo perché essa dovrebbe garantire una protezione più elevata contro gli attacchi rispetto alla prima proposta, inoltre, sarebbe considerata preferibile alla seconda in quanto non necessiterebbe di specificare meccanismi addizionali e permetterebbe l’uso di HSTS per eventuali downgrade.

In pratica, la prima proposta sarebbe stata scartata dai più perché interpretabile come un incoraggiamento all’adozione incompleta di TLS; la cifratura senza autenticazione server potrebbe però essere introdotta successivamente al passaggio di HTTP 2.0 in fase di produzione. Ad oggi anche i maggiori browser vendor sembrerebbero essere sufficientemente favorevoli ad un’adozione di default dell’HTTPS per il nuovo protocollo.

Del resto, con HTTPS in modalità predefinita l’utilizzo del protocollo crittografico Transport Layer Security risulterebbe ulteriormente incentivato, contestualmente i vendor non avrebbero la necessità di implementare il supporto per le URI “http://” in HTTP 2.0. Essendo tale opinione condivisa da tutti i maggiori soggetti in gioco tra quelli dotati di potere decisionale, essa potrebbe essere presto formalizzata.

Al di là del fatto che la proposta più accreditata sia supportata o meno da argomentazioni ragionevoli dal punto di vista della sicurezza, essa potrebbe comunque suscitare alcune perplessità presso sviluppatori e sysadmin, dovute anche al fatto che l’impiego di HTTPS è comunque costoso per via della necessità di IP dedicati a di certificati SSL.

Via W3C