Soluzione 1:
Questa è una questione di opinione e ha anche a che fare con problemi normativi (se ne affronti).
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 man mano che iniziavano a essere trasmesse informazioni più sensibili:è meglio iniziare da lì.
Quello che generalmente suggerirei è utilizzare una CA interna (se disponibile) o autofirmare (se nessuna CA interna) i server back-end. Fisseremmo la data di scadenza in modo piacevole e lontano nel futuro per evitare modifiche non necessarie.
Soluzione 2:
TL;DR dovresti crittografare il traffico a meno che non si trovi sullo stesso host.
Non puoi fidarti della tua rete. I malware nella tua rete possono intercettare/modificare le richieste http.
Non sono attacchi teorici, ma esempi di vita reale:
-
Router (probabilmente violati) all'interno della rete di alcuni siti Web che iniettano annunci:https://www.blackhat.com/docs/us-16/materials/us-16-Nakibly-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Studio-wp.pdf
-
Rete indiana che sniffa tra cloudfare e back-end:https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -it-90935f7f6d98#.hymc3785e
-
L'ormai famoso "SSL aggiunto e rimosso qui :-)" dalla NSA
Soluzione 3:
I "molti altri server" devono essere eseguiti su HTTPS o, dato che non è possibile accedervi dall'esterno, possono invece essere eseguiti su HTTP in modo sicuro?
Questo dipende davvero da ciò che stai cercando di realizzare. Comprendere che 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, forse dovresti occupartene prima. Se hai bisogno di proteggere i dati in transito all'interno della tua rete, ciò che stai dicendo è che sei preoccupato 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 più una domanda di opinione, ma la risposta è dipende. Cosa stai cercando di fare? Che tipo di dati stai crittografando? Da quali minacce stai cercando di difenderti? Hai un requisito legale (ad es. PCI-DSS, HIPAA, ecc.) che richiede di crittografare i dati in transito? Se i dati sono sensibili e temi che possano essere utilizzati in modo improprio quando vengono trasmessi all'interno della tua rete, suggerirei di riunirti con la direzione per risolvere il problema. Quindi, alla fine, cosa stai cercando di proteggere e perché stai cercando di proteggerlo?
Soluzione 4:
In passato, la gente pensava che le reti interne fossero sicure come le case. Una volta ho avuto una disputa con un supervisore che era sconvolto dal fatto che i miei server interni eseguissero 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'era alcun firewall tra i laptop degli studenti e i miei server. Lui, essendo nuovo nel mondo accademico, sembrava avere il suo universo a brandelli a queste informazioni.
Le reti interne non sono più considerate così sicure, anche se non hai laptop degli studenti sulla tua rete. Vedi la risposta di Tom per alcuni esempi.
Detto questo, sì, dipende da quali informazioni vengono trasmesse, 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 i dati inviati non siano sensibili ora , qualcuno potrebbe decidere di aggiungere funzioni alla tua applicazione in un secondo momento sono sensibile, quindi consiglierei una maggiore paranoia (incluso HTTPS).
Soluzione 5:
Oggi con istruzioni CPU specializzate per velocizzare la crittografia e nuovi protocolli di trasporto che non funzioneranno affatto o funzioneranno con prestazioni ridotte 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 c'è un motivo specifico, allora la risposta è rimanere con HTTPS.