HSTS

[usu]

“HTTP Strict Transport Security and You” — Mike West

Mi ero sempre posto il problema lavorando con https, ma non pensavo esistesse una soluzione.
Magari può venire utile anche ad altri

[andrea.paiola]

interessante, grazie

[guest]

Non mi è chiara una cosa, però.
Se io accedo ad un dominio, tutti i cookie validi per quel dominio saranno inviati dal browser al server sin dalla prima richiesta, pertanto se il cliente dovesse sbagliare a caricare la URL mettendo HTTP invece di HTTPS, i dati di login passerebbero in chiaro, se non codificati direttamente dal sito.

[usu]

Non mi è chiara una cosa, però.
Se io accedo ad un dominio, tutti i cookie validi per quel dominio saranno inviati dal browser al server sin dalla prima richiesta, pertanto se il cliente dovesse sbagliare a caricare la URL mettendo HTTP invece di HTTPS, i dati di login passerebbero in chiaro, se non codificati direttamente dal sito.

Questo header (sui browser che lo implementano) serve proprio ad evitare questo, la primissima richiesta sarà l'unica a poter passare in http, ma essendo appunto la primissima l'utente non avrà cookie da inviare.

[guest]

Primo accesso al sito, viene salvato il cookie:

$ curl -c cookie.txt -v http://127.0.0.1/prova.php > /dev/null
* About to connect() to 127.0.0.1 port 80 (#0)
*   Trying 127.0.0.1...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /prova.php HTTP/1.1
> User-Agent: curl/7.21.0 (i686-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: 127.0.0.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Fri, 07 Oct 2011 20:33:18 GMT
< Server: Apache/2.2.16 (Ubuntu)
< X-Powered-By: PHP/5.3.3-1ubuntu9.5
* Added cookie PHPSESSID="6euljcli1ugpn4g5dm078q7ut0" for domain 127.0.0.1, path /, expire 0
< Set-Cookie: PHPSESSID=6euljcli1ugpn4g5dm078q7ut0; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Strict-Transport-Security: max-age=31556926; includeSubDomains
< Vary: Accept-Encoding
< Content-Length: 0
< Content-Type: text/html
< 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connection #0 to host 127.0.0.1 left intact

* Closing connection #0

Secondo giro, il cookie viene sparato indietro al sito, anche se c'è l'header di cui si parla:

$ curl -b cookie.txt -v http://127.0.0.1/prova.php > /dev/null
* About to connect() to 127.0.0.1 port 80 (#0)
*   Trying 127.0.0.1...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /prova.php HTTP/1.1
> User-Agent: curl/7.21.0 (i686-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18
> Host: 127.0.0.1
> Accept: */*
> Cookie: PHPSESSID=6euljcli1ugpn4g5dm078q7ut0
> 
< HTTP/1.1 200 OK
< Date: Fri, 07 Oct 2011 20:34:30 GMT
< Server: Apache/2.2.16 (Ubuntu)
< X-Powered-By: PHP/5.3.3-1ubuntu9.5
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Strict-Transport-Security: max-age=31556926; includeSubDomains
< Vary: Accept-Encoding
< Content-Length: 0
< Content-Type: text/html
< 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Connection #0 to host 127.0.0.1 left intact

* Closing connection #0

Questo perchè l'http è asincrono, se richiami una pagina, essa viene inviata tutta, e nella richiesta della pagina devi inviare tutto ciò di cui sei in possesso, come ad esempio i cookie. quindi prima ti mando i cookie, contestualmente alla richiesta pagina ,poi vedo cosa ha da dirmi il server.

A meno che i browser non facciano una prima richiesta 'fasulla', magari un HEAD alla ricerca di tale header e se presente girano tutto in HTTPS altrimenti rifanno la richiesta con il metodo corretto passando i cookie.

Ma in questo caso diventano sempre due richieste per volta.

Cosa mi son perso?

[guest]

Questo header (sui browser che lo implementano) serve proprio ad evitare questo, la primissima richiesta sarà l'unica a poter passare in http, ma essendo appunto la primissima l'utente non avrà cookie da inviare.

Quindi mi stai dicendo che i browser si salvano da qualche parte i siti che hanno tale header e le volte successive lo richiamano solo via HTTPS?

[usu]

Ma non devi avere cookies nella pagina http, la pagina http avrà solamente un redirect all'https, altrimenti qual è il senso?

La prima volta in assoluto che l'utente visita il sito inserisce nella barra del browser banca.it
Il server di banca.it sparerà fuori un bel 301 all'https che poi manderà il famoso header che farà sì, sui browser che lo supportano, che l'utente non passi più per l'http anche se nella barra del browser scrive l'indirizzo senza https.
Almeno, questo è quello che ho capito dalla teoria, poi nella pratica non ho ancora provato, è un articolo di oggi :P

[guest]

I cookie sono basati sul dominio, non sul protocollo.
Quindi banca.it e https://www.banca.it avranno gli stessi cookie.
Se io acceso alla versione http, avrò un redirect su https. ok. l'https mi salva un cookie.
La volta dopo, per errore, acceso all'http. in questo preciso momento in browser spara
indietro tutti i cookie che ha ricevuto da https, visto che il dominio è uguale.

A meno che, il browser non si salvi da qualche parte dominio+header, in tal caso, riconoscendo
il dominio, non effettua nemmeno la prima richiesta. Così facendo l'header si può intendere usa-e-getta,
necessario giusto per far salvare il dominio nella lista dei "protetti" la prima volta.

Non mi piace affatto, mi sembra una pezza di poco conto, il primo browser che non supporta lo standard
espone agli stessi rischi di sicurezza precedenti. In sostanza, è una falsa sicurezza.

E' molto più semplice fare un dominio ad-hoc accessibile SOLO in https, ovvero:

https://secure.banca.it

se vai in http, il server non risponde. Se accedi in banca.it hai un brutale
redirect al secure.

Domini diversi, cookie diversi.

[usu]

I cookie sono basati sul dominio, non sul protocollo.
Quindi banca.it e https://www.banca.it avranno gli stessi cookie.
Se io acceso alla versione http, avrò un redirect su https. ok. l'https mi salva un cookie.
La volta dopo, per errore, acceso all'http. in questo preciso momento in browser spara
indietro tutti i cookie che ha ricevuto da https, visto che il dominio è uguale.

A meno che, il browser non si salvi da qualche parte dominio+header, in tal caso, riconoscendo
il dominio, non effettua nemmeno la prima richiesta. Così facendo l'header si può intendere usa-e-getta,
necessario giusto per far salvare il dominio nella lista dei "protetti" la prima volta.

Non mi piace affatto, mi sembra una pezza di poco conto, il primo browser che non supporta lo standard
espone agli stessi rischi di sicurezza precedenti. In sostanza, è una falsa sicurezza.

E' molto più semplice fare un dominio ad-hoc accessibile SOLO in https, ovvero:

https://secure.banca.it

se vai in http, il server non risponde. Se accedi in banca.it hai un brutale
redirect al secure.

Domini diversi, cookie diversi.

Infatti è proprio quello che fa, il browser memorizza l'impostazione.
Certo, per una banca rimarrà sempre meglio un dominio separato, ma per siti basati su cms che non permettono una separazione di dominio può essere una cosa interessante, sicuramente è una sicurezza in più.

[guest]

Infatti è proprio quello che fa, il browser memorizza l'impostazione.

Ah, ok, ecco svelato il mistero.

Certo, per una banca rimarrà sempre meglio un dominio separato, ma per siti basati su cms che non permettono una separazione di dominio può essere una cosa interessante, sicuramente è una sicurezza in più.

Uhm, basterebbe salvare i cookie cifrati. Quando lo integri in joomla, wordpress e drupal, tempo 10 giorni e si adeguano tutti gli altri CMS. Alla fine si tratta di una manciata di righe di codice.

[Uno]

Magari non ho capito nulla io, ma oltre al cookie cifrato non è sufficiente cambiarlo (o cambiarli) subito dopo il passaggio in https?

[guest]

Magari non ho capito nulla io, ma oltre al cookie cifrato non è sufficiente cambiarlo (o cambiarli) subito dopo il passaggio in https?

Cosa intendi per "cambiare il cookie?"
Il problema è che se te visiti un sito HTTPS chiamato Pippo.it il cercatrova, lui ti salva, magari, dei cookie di autenticazione.
La volta dopo, se per sfortuna visiti la versione NON HTTPS, ma con lo stesso dominio, i cookie il tuo browser li manda comunque al server, in questo modo però invieresti dei potenziali dati di autenticazione su una connessione non sicura.

Pertanto:
- o cifri i cookie in modo che essi non siano intercettabili in maniera semplice indipendentemente dal protocollo di trasmissione
- l'https lo metti in ascolto su un dominio ad-hoc, che non avrà la sua controparte http, in questo modo i cookie essendo per due domini differenti, in chiaro non saranno mai inviati.

[Uno]

Il browser manda i cookies anche senza richiesta?
Non mi sono mai posto il problema perchè comunque per me il cookie se ha dati importanti deve essere sicuro a prescindere (criptato)

Se è così, si, allora l'unico sistema è la crittazione (cosa che comunque facevo per i cookies importanti, quali per esempio quelli di autenticazione) altrimenti basta che il server (tramite il linguaggio utilizzato) chieda un coockie per http ed uno diverso (diverso nome quindi) per https.

[guest]

Non esiste una richiesta per l'invio di cookie. Esiste un header apposito per istruire il browser a salvare un dato cookie sul pc, ma al prossimo accesso al sito, il browser vede che ha determinati cookie per quel dominio e li spara tutti indietro, a prescindere da tutto.

Il problema è che non c'è alcuna distinzione di protocollo, Pippo.it il cercatrova e https://www.pippo.it a livello di cookie sono la stessa identica cosa, perchè i cookie sono basati su Pippo.it il cercatrova

Però, leggo proprio ora, che esiste l'attributo Secure ed in tal caso il browser invierà tale cookie solo tramite connessioni https.
A che serve quindi l'header in questione?

[Uno]

Si esatto, c'erano già delle istruzioni per costringere l'uso di https al posto di http. In ogni caso, come già detto, non mi sono mai posto il problema perchè ho sempre criptato i cookies importanti. L'unico limite del cookie criptato è che non può contenere più di tanti dati, ma se lo si usa solo per qualche stringa e poi tutto quello che non è importante nascondere lo si mette in altri cookies normali è semplice.
Se mi intercettano un cookie che tiene traccia del template usato dall'utente (per esempio) chi se ne importa.