Cosa deve sapere uno sviluppatore PHP sulle connessioni https/secure socket layer?

Question

Non so quasi nulla riguardo al come e al perché delle connessioni https.Ovviamente, quando trasmetto dati sicuri come password o soprattutto informazioni sulla carta di credito, https è uno strumento fondamentale.Ma cosa devo sapere a riguardo?Quali sono gli errori più comuni che vedi commettere dagli sviluppatori quando lo implementano nei loro progetti?Ci sono momenti in cui https è semplicemente una cattiva idea?Grazie!

Answer 1

Per un sito viene fornito un certificato HTTPS o Secure Sockets Layer (SSL) ed è in genere firmato da un'autorità di certificazione (CA), che è effettivamente una terza parte attendibile che verifica alcuni dettagli di base sul tuo sito e ne certifica l'uso nei browser.Se il tuo browser considera attendibile la CA, considera attendibili tutti i certificati firmati da tale CA (nota come catena di fiducia).

Ogni richiesta HTTP (o HTTPS) è composta da due parti:una richiesta e una risposta.Quando richiedi qualcosa tramite HTTPS, in realtà accadono alcune cose in background:

• Il client (browser) esegue un "handshake", in cui richiede la chiave pubblica e l'identificazione del server.
  • A questo punto il browser può verificarne la validità (il nome del sito corrisponde?l'intervallo di date è attuale?è firmato da una CA di cui si fida?).Può anche contattare la CA e assicurarsi che il certificato sia valido.
• Il client crea un nuovo segreto pre-master, che viene crittografato utilizzando la chiave pubblica del server (in modo che solo il server possa decrittografarlo) e inviato al server
• Sia il server che il client utilizzano questo pre-master secret per generare il master secret, che viene poi utilizzato per creare una chiave di sessione simmetrica per l'effettivo scambio di dati
• Entrambe le parti inviano un messaggio dicendo che hanno terminato la stretta di mano
• Il server elabora quindi la richiesta normalmente e quindi crittografa la risposta utilizzando la chiave di sessione

Se la connessione viene mantenuta aperta, per ciascuno verrà utilizzata la stessa chiave simmetrica.

Se viene stabilita una nuova connessione ed entrambe le parti hanno ancora il master secret, è possibile generare nuove chiavi di sessione in un "handshake abbreviato".In genere un browser memorizzerà un master secret finché non verrà chiuso, mentre un server lo memorizzerà per alcuni minuti o diverse ore (a seconda della configurazione).

Per ulteriori informazioni sulla durata delle sessioni vedere Quanto dura una chiave simmetrica HTTPS?

Certificati e nomi host

Ai certificati viene assegnato un Common Name (CN), che per HTTPS è il nome del dominio.Il CN deve corrispondere esattamente, ad esempio, un certificato con un CN di "example.com" NON corrisponderà al dominio "www.example.com" e gli utenti riceveranno un avviso nel proprio browser.

Prima SNI, non era possibile ospitare più nomi di dominio su un IP.Poiché il certificato viene recuperato prima ancora che il client invii la richiesta HTTP effettiva e la richiesta HTTP contiene l'Host:riga di intestazione che indica al server quale URL utilizzare, non c'è modo per il server di sapere quale certificato servire per una determinata richiesta.SNI aggiunge il nome host a parte dell'handshake TLS e, finché è supportato sia sul client che sul server (e nel 2015 è ampiamente supportato), il server può scegliere il certificato corretto.

Anche senza SNI, un modo per servire più nomi host è con certificati che includono nomi alternativi soggetto (SAN), che sono essenzialmente domini aggiuntivi per i quali il certificato è valido.Google, ad esempio, utilizza un unico certificato per proteggere molti dei suoi siti.

Un altro modo consiste nell'utilizzare certificati con caratteri jolly.È possibile ottenere un certificato come ".example.com" nel qual caso "www.example.com" e "foo.example.com" saranno entrambi validi per quel certificato.Tuttavia, tieni presente che "example.com" non corrisponde a ".example.com", e nemmeno "foo.bar.example.com".Se usi "www.example.com" per il tuo certificato, è necessario reindirizzare chiunque su "Esempio.com" al "www". luogo.Se lo richiedono https://esempio.com, a meno che non lo ospiti su un IP separato e disponga di due certificati, verrà visualizzato un errore di certificato.

Naturalmente, puoi combinare sia caratteri jolly che SAN (a condizione che la tua CA te lo consenta) e ottenere un certificato sia per "example.com" che con SAN ".example.com", "example.net" e ".example.net", per esempio.

Forme

A rigor di termini, se stai inviando un modulo, non importa se la pagina del modulo stesso non è crittografata, purché l'URL di invio vada a un URL https://.In realtà, gli utenti sono stati addestrati (almeno in teoria) a non inviare pagine a meno che non vedano la piccola "icona del lucchetto", quindi anche il modulo stesso dovrebbe essere servito tramite HTTPS per ottenere questo.

Traffico e carico del server

Il traffico HTTPS è molto più grande del traffico HTTP equivalente (a causa della crittografia e del sovraccarico dei certificati) e sottopone anche a uno sforzo maggiore il server (crittografia e decrittografia).Se disponi di un server molto carico, potrebbe essere opportuno essere molto selettivi su quali contenuti vengono serviti utilizzando HTTPS.

Migliori pratiche

• Se non utilizzi solo HTTPS per l'intero sito, dovrebbe reindirizzare automaticamente a HTTPS come richiesto.Ogni volta che un utente effettua l'accesso, dovrebbe utilizzare HTTPS e, se utilizzi cookie di sessione, il cookie dovrebbe avere l'estensione set di bandiere sicure.Ciò impedisce l'intercettazione del cookie di sessione, il che è particolarmente importante data la popolarità delle reti Wi-Fi aperte (non crittografate).

• Tutte le risorse sulla pagina dovrebbero provenire dallo stesso schema utilizzato per la pagina.Se provi a recuperare immagini da http:// quando la pagina è caricata con HTTPS, l'utente riceverà avvisi di sicurezza.Dovresti utilizzare URL completi oppure un altro modo semplice è utilizzare URL assoluti che non includano il nome host (ad esempio, src="/images/foo.png") perché funzionano per entrambi.

  • Ciò include risorse esterne (ad esempio Google Analytics)

• Non eseguire POST (invii di moduli) quando si passa da HTTPS a HTTP.La maggior parte dei browser lo contrassegnerà come un avviso di sicurezza.

Answer 2

Non approfondirò l'SSL in generale, gregmac ha fatto un ottimo lavoro, vedi sotto ;-).

Tuttavia, alcuni degli errori più comuni (e critici) commessi (non specificamente PHP) riguardo all'uso di SSL/TLS:

1. Consentire HTTP quando dovresti applicare HTTPS
2. Recupero di alcune risorse su HTTP da una pagina HTTPS (ad es.immagini, IFRAME, ecc.)

3. Indirizzamento involontario alla pagina HTTP dalla pagina HTTPS: tieni presente che questo include pagine "false", come "about:blank" (l'ho visto usato come segnaposto IFRAME), ciò farà apparire inutilmente e spiacevolmente un avviso.

4. Server Web configurato per supportare versioni vecchie e non sicure di SSL (ad es.SSL V2 è comune, ma orribilmente rotto) (ok, questo non è esattamente il problema del programmatore, ma a volte nessun altro lo gestirà ...)

5. Server Web configurato per supportare le suite di cifrature non sicure (ho visto i cifre null solo in uso, che fondamentalmente non fornisce assolutamente nessuna crittografia) (idem)

6. Certificati autofirmati: impediscono agli utenti di verificare l'identità del sito.

7. Richiedere le credenziali dell'utente da una pagina HTTP, anche se si invia a una pagina HTTPS.Ancora una volta, questo impedisce a un utente di convalidare l'identità del server PRIMA di fornirgli la propria password...Anche se la password viene trasmessa crittografata, l'utente non ha modo di sapere se si trova su un sito fasullo o se sarà crittografato.

8. Cookie non sicuro: cookie relativi alla sicurezza (come sessionId, token di autenticazione, token di accesso, ecc.) DOVERE essere impostato con l'attributo "secure" impostato.Questo è importante!Se non è impostato su sicuro, il cookie di sicurezza, ad es.SessionId, può essere trasmesso su HTTP (!) - e gli aggressori possono garantire che ciò accada - consentendo così il dirottamento della sessione, ecc.Già che ci sei (anche se questo non è direttamente correlato), imposta anche l'attributo HttpOnly sui tuoi cookie (aiuta a mitigare alcuni XSS).

9. Certificati eccessivamente permissivi: supponiamo che tu abbia diversi sottodomini, ma non tutti hanno lo stesso livello di fiducia.Ad esempio, hai www.tuodominio.com, download.tuodominio.com e publicaccess.tuodominio.com.Quindi potresti pensare di utilizzare un certificato con caratteri jolly....MA hai anche secure.tuodominio.com o finanza.tuodominio.com, anche su un server diverso.publicaccess.tuodominio.com sarà quindi in grado di impersonare secure.tuodominio.com....Anche se potrebbero esserci casi in cui questo va bene, di solito vorresti una certa separazione dei privilegi...

Questo è tutto ciò che ricordo in questo momento, potrei modificarlo di nuovo più tardi...

Per quanto riguarda quando è una CATTIVA idea utilizzare SSL/TLS - se disponi di informazioni pubbliche che NON sono destinate a un pubblico specifico (un singolo utente o membri registrati) E non sei particolarmente interessato a recuperarle specificamente da la fonte corretta (es.i valori dei titoli azionari DEVONO provenire da una fonte autenticata...) - allora non c'è alcun motivo reale per sostenere costi generali (e non solo prestazioni...sviluppo/test/cert/ecc.).

Tuttavia, se hai risorse condivise (ad es.stesso server) tra il tuo sito e un altro sito PIÙ SENSIBILE, sarà il sito più sensibile a impostare le regole qui.

Inoltre, le password (e altre credenziali), i dati della carta di credito, ecc. dovrebbero SEMPRE essere su SSL/TLS.

Answer 3

Assicurati che, quando sei su una pagina HTTPS, tutti gli elementi della pagina provengano da un indirizzo HTTPS.Ciò significa che gli elementi dovrebbero avere percorsi relativi (ad es."/images/banner.jpg") in modo che il protocollo venga ereditato o che sia necessario eseguire un controllo su ogni pagina per trovare il protocollo e utilizzarlo per tutti gli elementi.

NB:Ciò include tutte le risorse esterne (come i file JavaScript di Google Analytics)!

L'unico lato negativo a cui riesco a pensare è che aggiunge tempo di elaborazione (quasi trascurabile) per il browser e il server.Suggerirei di crittografare solo i trasferimenti necessari.

Answer 4

Direi che gli errori più comuni quando si lavora con un sito abilitato per SSL sono:

1. Il sito reindirizza erroneamente gli utenti a http da una pagina come https
2. Il sito non passa automaticamente a https quando è necessario
3. Le immagini e altre risorse su una pagina https vengono caricate tramite http, il che attiverà un avviso di sicurezza dal browser.Assicurati che tutte le risorse utilizzino URI completi che specificano https.
4. Il certificato di sicurezza funziona solo per un sottodominio (come www), ma il tuo sito in realtà utilizza più sottodomini.Assicurati di ottenere un certificato con caratteri jolly se ne avrai bisogno.

Answer 5

Suggerirei in qualsiasi momento Qualunque i dati degli utenti vengono archiviati in un database e comunicati, utilizzare https.Considera questo requisito anche se i dati dell'utente sono banali, perché anche molti di questi dettagli banali vengono utilizzati da quell'utente per identificarsi su altri siti web.Considera tutte le domande di sicurezza casuali che la tua banca ti pone (ad esempio, in quale strada vivi?).Questo può essere ricavato molto facilmente dai campi dell'indirizzo.In questo caso, i dati non sono ciò che consideri una password, ma potrebbe anche esserlo.Inoltre, non è mai possibile prevedere quali dati utente verranno utilizzati per una domanda di sicurezza altrove.Puoi anche aspettarti che, con l'intelligenza dell'utente web medio (pensa a tua nonna), quel bocconcino di informazione possa costituire parte della password di quell'utente da qualche altra parte.

Un puntatore se usi https

fare in modo che se l'utente digitahttp://www.website-that-needs-https.com/etc/yadda.phpverranno reindirizzati automaticamente ahttps://www.website-that-needs-https.com/etc/yadda.php(Piacenza personale)

Tuttavia, se stai semplicemente creando una semplice pagina Web html, si tratterà essenzialmente di una trasmissione unidirezionale di informazioni dal server all'utente, non preoccuparti.

Answer 6

Tutti ottimi consigli qui...ma voglio solo aggiungere una cosa..
Ho visto alcuni siti che ti forniscono una pagina di accesso http e ti reindirizzano a https solo dopo aver pubblicato il tuo nome utente/pass.Ciò significa che il nome utente viene trasmesso in chiaro prima che venga stabilita la connessione https.

In breve, crea la pagina in cui accedi da SSL, invece di pubblicare su una pagina SSL.

Answer 7

L'ho scoperto provandoci <link> a un foglio di stile inesistente causava anche avvisi di sicurezza.Quando ho utilizzato il percorso corretto, è apparsa l'icona del lucchetto.