L'http deve essere utilizzata per le pagine successive di accesso https?

Question

Ho visto molti thread su SO e suggeriscono che la password non può essere trasferita in modo sicuro senza SSL. Quindi supponiamo che io ho https pagina di login ma

1. Dovrei tornare a http dopo che l'utente è stato autenticato tramite HTTPS (supponendo che non le informazioni sensibili viene inviato attraverso dopo il login)? Perché potrebbe caricare la pagina un po 'più velocemente?

2. Potrebbe creare un sovraccarico in termini di sviluppo (con Zend Framework)? Come mantenere diverse strutture di directory e tutto il resto.

Answer 1

1. Se i dati non è sensibile si poteva tornare a http dopo l'autenticazione degli utenti per ottenere un piccolo vantaggio di velocità. Devi ricordarti di passare nuovamente a https se qualsiasi tipo di dati sensibili dovesse apparire sul sito (come il profilo utente o simili). Potrebbe essere effettivamente più semplice avere l'intera sessione sempre crittografata, quindi non dovrai preoccuparti di attivare e disattivare la crittografia a seconda del contenuto della pagina.

2. SSL è trasparente per gli sviluppatori, si crea l'app esattamente come si farebbe per un server non sicuro. È necessario disporre di un certificato SSL che è possibile acquistare o generare autonomamente e configurare il server per gestirlo. Quindi a seconda del protocollo (http o https) la sessione sarà o non verrà crittografata automaticamente. Quindi si tratta di impostare https: // link corretti per le pagine in cui è necessaria una crittografia e collegamenti http: // standard per le altre pagine.

Answer 2

1. Sì, è possibile tornare a http dopo il trasferimento password utente. Non c'è bisogno di criticare tutto il contenuto quando non ci sono dati sensibili su di esso. Quando hai criptato TUTTI i siti: il server deve crittografare tutti i dati e il tuo server ha le peggiori prestazioni che senza criptare.

Answer 3

Il tempo prende per una connessione SSL da codificati e decodificati (dopo che è stato inizializzato) sia trascurabile rispetto al tempo necessario per trasferire i dati. Quindi no, non caricherà "un po '" più veloce anche.

Le cartelle extra dipendono dal server e non dal framework. Se il server indirizza tutte le richieste https attraverso una cartella/httpsdocs o qualcosa del genere, puoi inserire un .htaccess in esso, che lo reindirizza alla cartella/httpdocs.

Answer 4

VolkerK ha ragione, ma la sua risposta sbaglia dalla parte della cautela. La sessione può essere compromessa da tutti i tipi di metodi. Ci sono modi per aggirare questo problema (ad esempio utilizzando un lato client javascript memorizzato nella cache per generare hash contro un valore fisso di una sfida generata con ogni pagina) ma sono disordinati. Di gran lunga la soluzione più semplice è usare sempre SSL. Tuttavia, potresti prendere in considerazione l'utilizzo dell'autenticazione digest abbinata a un cookie di sessione.

Tor Valamo è sbagliato. Oggigiorno la larghezza di banda è molto economica, tuttavia ciò che è difficile da raggiungere è l'eliminazione della latenza - e la latenza è il fattore determinante principale della velocità di trasferimento HTTP (dove la maggior parte del contenuto è relativamente piccola). Per una richiesta HTTP, ci sono almeno 2 round trip sul server - l'handshake TCP quindi la richiesta/risposta. Varia in base alla dimensione dei file e ad altre considerazioni, ma in genere i conti di latenza di andata e ritorno rappresentano il 50-70% del tempo trascorso per recuperare un oggetto.

L'utilizzo di Keep-alive elimina uno dei round trip e quindi migliora notevolmente il throughput.

Con SSL, è necessario almeno un viaggio di andata e ritorno aggiuntivo (per la ripresa di una sessione SSL esistente) e più di uno per la negoziazione SSL iniziale. Il vero killer è che l'implementazione non standard di SSL di Microsoft significa che non è possibile usare keep-alive da qualcosa di diverso da MSIIS quando si parla con un client MSIE (per ulteriori informazioni consultare i documenti mod_ssl).