A proposito di standard e lo scarso supporto di questi…. La mai precedente mail aveva dei problemi di encoding che spero ora siano fixati. Perdonate il mio “quotable-printable”. Grazie Simone per lo spunto di riflessione, ecco i miei 2c sulla questione: 1) Una distinzione secondo me molto importante da fare è tra il traffico HTTP machine to human (faccio una richiesta HTTP e ottengo indietro dell’HTML o Javascript) e machine to machine (servire un file compresso con dentro dati scientifici da analizzare o una API REST). Penso che per il primo tipo di traffico sia importante, e gestibile, avere una politica HTTPS only, per la seconda, come @jhourcle ho un po’ di dubbi. Come faceva notare Ximin quando il traffico in chiaro viene poi processato da un browser si sta esponendo gli utenti del nostro sito web a possibili vettori di attacco come nel caso del DDoS a github di un mese fa. 2) La verifica dei certificati SSL è ubiquo nei browser, ma non è la stessa cosa per un sacco di librerie o tool molto utilizzati. Basti pensare che fino ad un anno fa il package manager di python non verificava i certificati SSL. Stiamo facendo progressi, ma comunque non abbiamo un livello di maturità elevato. 3) E’ importante riconoscere il fatto che avere HTTPS non significa essere per forza. Come faceva notare @jhourcle aumenta la superficie di attacco, ma anche in assenza di vulnerabilità non significa che il traffico dell’utente non transiti in chiaro su internet (ricordate le slide dell’NSA su SSL added and removed here [1]) e potrebbe portare ad un finto senso di sicurezza (sono comunque dell’idea che avere HTTPS sia meglio di nulla). 4) Per realtà piccole è impegnativo gestire certificati SSL ed e’ ancora più difficile gestirli bene. Chiunque ha mai avuto la spiacevole esperienza di dover mettere su un server HTTPS sa di che cosa sto parlando. I tool da usare sono scomodi e presentano così tante opzioni che il culto del cargo [2] è inevitabile. Come faceva notare Fabio ACME e Let’s Encrypt sono due progetti che potrebbero risolvere questo problema nel futuro. In sintesi secondo me HTTPS only sí, ma per il traffico che contiene contenuti attivi (HTML/Javascript/CSS/SWF etc.). Per contenuti che devono invece essere elaborati da qualcosa di diverso da un browser non è ancora venuto il momento di passare a HTTPS only, ma sarebbe comunque il caso di fornire un metodo sicuro per verificare l’integrità del contenuto. ~ Art. [1] http://www.newyorker.com/wp-content/uploads/2013/11/nsa-smiley-face-580.jpg [2] http://it.wikipedia.org/wiki/Culto_del_cargo