Tutti i server devono utilizzare il protocollo HTTPS o solo server pubblici?

Ho un server Web front-end in esecuzione su HTTPS - questo è pubblico - cioè la porta è aperta.

Ho anche un server API back-end al quale il mio server web fa richieste API - questo è pubblico e richiede autenticazione - la porta è aperta.

Questi 2 server funzionano su HTTPS.

Dietro il server API, ci sono molti altri server. Il server API inoltra i proxy a questi server. Le porte per questi altri server non sono aperte al traffico in entrata. Possono essere consultati solo tramite il server API.

La mia domanda ... I "molti altri server" devono funzionare su HTTPS o, dato che non possono accedervi esternamente, possono invece correre su HTTP in modo sicuro?

Ho pensato che sarebbe stata una domanda comune ma non sono riuscito a trovare una risposta. Grazie. Se questo è un duplicato, ti prego di indicarmi la risposta giusta.

Questa è una questione di opinione, e ha anche a che fare con questioni normative (se si affrontano).

Anche se al momento non è necessario, sono un grande sostenitore del mantenimento dell'HTTPS abilitato tra qualsiasi firewall a livello di applicazione / bilanciamento del carico / server front-end e server back-end. È una superficie di attacco in meno. Ho stipulato un contratto con luoghi che dovevano essere convertiti quando sono iniziate le informazioni più sensibili - è meglio iniziare da lì.

Quello che in genere suggerirei è di utilizzare una CA interna (se disponibile) o un auto segno (se nessuna CA interna) i server back-end. Fisseremmo la data di scadenza piacevole e lontana nel futuro per evitare cambiamenti inutili.

TL; DR dovresti crittografare il traffico a meno che non si trovi sullo stesso host.

Non puoi fidarti della tua rete. I malware nella propria rete possono intercettare / modificare le richieste http.

Non sono attacchi teorici, ma esempi di vita reale:

• Router (probabilmente hackerati) all'interno della rete di alcuni siti Web che iniettano annunci pubblicitari: https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-studio-wp.pdf

• Network indiano che annusa tra cloudfare e back-end: https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -E-90935f7f6d98 # .hymc3785e

• L'ormai famoso "SSL aggiunto e rimosso qui :-)" dalla NSA

I "molti altri server" devono funzionare su HTTPS o, dato che non sono accessibili dall'esterno, possono invece funzionare su HTTP in modo sicuro?

Questo dipende davvero da ciò che stai cercando di realizzare. Comprendere lo scopo dell'utilizzo di HTTPS è proteggere i dati in transito tra due punti. Se sei preoccupato per i dati che vengono sniffati all'interno della tua rete, allora forse dovresti occupartene prima. Se devi proteggere i dati in transito all'interno della tua rete, ciò che stai dicendo è che hai una preoccupazione per la sicurezza dei dati che attraversano i tuoi sistemi all'interno della tua rete o c'è qualche motivo relativo alla conformità per crittografare i dati in transito.

Questa è davvero una domanda di opinione, ma la risposta è che dipende. Cosa stai cercando di fare? Che tipo di dati stai crittografando? Quali minacce stai cercando di difendere? Hai un requisito legale (ad es. PCI-DSS, HIPAA, ecc.) Che dice che devi crittografare i dati in transito? Se i dati sono sensibili e si teme che potrebbero essere utilizzati in modo improprio durante la trasmissione all'interno della rete, suggerirei di collaborare con la direzione per risolvere il problema. Quindi, alla fine, cosa stai cercando di proteggere e perché stai cercando di proteggerlo?

In passato, la gente pensava che le reti interne fossero sicure come case. Una volta ho avuto una disputa con un supervisore che era sconvolto dal fatto che i miei server interni stessero eseguendo i loro firewall integrati. "Se non puoi fidarti della tua rete interna, di chi puoi fidarti?" Ho sottolineato che avevamo laptop degli studenti sulla nostra rete interna e che non c'erano firewall tra i laptop degli studenti e i miei server. Lui, essendo nuovo al mondo accademico, sembrava avere il suo universo a brandelli su queste informazioni.

Le reti interne non sono più considerate sicure, anche se non hai laptop per studenti sulla tua rete. Vedi la risposta di Tom per alcuni esempi.

Detto questo, sì, dipende da quali informazioni vengono trasmesse, da eventuali problemi di conformità legale, ecc. Potresti decidere che non ti interessa se qualcuno annusa, diciamo, i dati meteorologici. Detto questo, è possibile che, anche se l'inviato i dati non è sensibile ora , qualcuno potrebbe decidere di aggiungere funzionalità alla vostra applicazione in seguito che sono sensibili, quindi vi consiglio di maggiore paranoia (compresi HTTPS).

Oggi con istruzioni CPU specializzate per accelerare la crittografia e nuovi protocolli di trasporto che non funzioneranno affatto o funzioneranno con prestazioni degradate su un collegamento non crittografato (HTTP / 2, gRPC, ecc ...), forse la domanda migliore è: c'è qualche motivo per cui è necessario eseguire il downgrade di un collegamento di rete a HTTP? Se non esiste un motivo specifico, la risposta è rimanere con HTTPS.

L'unico motivo per disabilitare la crittografia che mi viene in mente è la prestazione. Tuttavia, nel tuo caso i server interni sono interfacciati tramite HTTP, il che significa che hanno già il costo delle prestazioni di esecuzione di un server Web, che supporta il protocollo HTTP e codifica i dati in HTTP / JSON / qualunque cosa. La disabilitazione della crittografia libererà forse 100 KB di RAM e ti farà guadagnare qualche microsecondo per KB di dati trasmessi, il che non avrà alcun impatto visibile sulle prestazioni complessive. D'altra parte, dovrai prestare molta più attenzione alla sicurezza poiché esegui HTTP nella tua intranet ora. In effetti, è possibile che una configurazione più rigorosa del firewall rallenti le cose più che la disabilitazione della crittografia le abbia accelerate, con conseguente peggioramento delle prestazioni percepite dagli utenti finali.

Sarà come mettere uno spoiler su un trattore: in teoria non guadagni quasi nulla e praticamente molti inconvenienti.