Domanda:
HTTPS è richiesto per la comunicazione dal server di rete locale al server
asinkxcoswt
2020-03-08 17:09:46 UTC
view on stackexchange narkive permalink

Sto creando applicazioni web per l'azienda del mio cliente. Sul lato server, ci saranno 2 tipi di comunicazione di rete da server a server.

  1. Server API REST separati che effettuano richieste tra loro.
  2. Comunicazione da bilanciatori di carico dell'applicazione ( AWS ALB in particolare) alle istanze EC2 a scalabilità automatica.

Attualmente tutte queste comunicazioni utilizzano il protocollo HTTP. Solo i nodi rivolti all'utente (come il bilanciamento del carico o il proxy inverso del server Web) serviranno HTTPS con certificati validi.

Il cliente ci chiede di cambiarli tutti in HTTPS poiché ritiene che sia il best practice moderna per utilizzare sempre HTTPS invece di HTTP ovunque.

Vorrei contestare con il cliente ma non sono un esperto di sicurezza. Aiutaci a rivedere la mia comprensione di seguito ea correggermi se sbaglio.


A mio avviso, penso che lo scopo del protocollo HTTPS sia quello di essere un canale affidabile in un ambiente non affidabile (come Internet ). Quindi non vedo alcun vantaggio nel cambiare il canale già affidabile in HTTPS. Inoltre, la necessità di installare i certificati su tutti i server ne rende difficile la manutenzione, è probabile che un giorno in futuro il cliente scoprirà che i propri server delle applicazioni non funzionano perché alcuni server hanno un certificato scaduto e nessuno lo sa.

Un altro problema, se dobbiamo configurare tutto il server delle applicazioni, ad esempio apache, dietro il bilanciamento del carico per servire HTTPS, qual è il ServerName da mettere all'interno di VirtualHost ? Al momento non abbiamo problemi a utilizzare il nome di dominio come my-website.example.com per HTTP VirtualHost . Ma se fosse HTTPS dobbiamo installare il certificato di my-website.example.com su tutte le istanze dietro il load balancer? Penso che sia strano perché poi abbiamo molti server che affermano di essere my-website.example.com .

Vale la pena di google: reti zero-trust.Hai ragione sul fatto che HTTPS è inteso per consentire comunicazioni sicure in un canale non sicuro.Presumi che la tua rete interna sia affidabile.
I tuoi commenti sui certificati SSL sono solo un dettaglio di implementazione e non sono realmente in argomento qui (anche se il resto va bene).Il tuo lavoro come fornitore di servizi è calcolare il costo di queste modifiche in modo da poter dire al tuo cliente quanto costerà e lasciare che sia lui a decidere se ne vale la pena per la sua attività.In questo momento sembra che tu non voglia essere disturbato a fare lo sforzo, il che non è davvero un approccio ragionevole.Ora, se queste fossero modifiche richieste alla fine di un processo di rilascio per cui non verrai pagato, rifiuterei sicuramente.
Google non aveva la crittografia del traffico all'interno dei suoi data center e poi è emerso che c'era un'alta probabilità che gli attori statali leggessero quei dati, quindi Google è passato alla crittografia ovunque ...
Google * era solito * non utilizzare HTTPS internamente.Quindi, Snowden ha fatto sapere a tutti che l'NSA aveva aggiunto materiale extra al sistema di Google in modo che l'NSA potesse vedere tutto il traffico.Ora Google utilizza HTTPS internamente.Questa diapositiva qui: https://www.businessinsider.com/leaked-nsa-slide-of-google-cloud-2013-10?r=DE&IR=T
Oltre alla sicurezza, ci sono anche motivi di prestazioni per utilizzare HTTPS.Ad esempio, l'utilizzo di H / 2 (invece di HTTP / 1.1), che AWS ALB supporta per impostazione predefinita.
@Matthew iirc non c'è motivo per cui non puoi usare http2 senza TLS se controlli il server e il client.
Probabilmente non vale la pena una risposta a sé stante, ma il ServerName per VirtualHost dovrebbe essere il nome che inserirai nell'URI che utilizzi per connetterti al server, che si tratti di un indirizzo IP o di un nome host.Se stai firmando certificati con una CA interna (che consiglierei comunque), puoi utilizzare nomi host o IP come nomi alt del soggetto, quindi non ci sono problemi a ottenere un certificato per quel nome (le CA pubbliche sono più pignole sui certificati perIP, ma non avrai quel problema se lo gestisci internamente).
@user253751 Ma è stato d'aiuto?
@Matthew Ho usato HTTP / 2 senza HTTPS senza problemi.I fornitori di browser hanno appena deciso di non supportarlo, ma nelle specifiche non c'è nulla che vieti tale combinazione.
@Michael Bene, ha chiuso * quel * vettore di attacco.Ora la NSA deve fare cose più rischiose, come infilare chip extra nei loro server (congettura).
Sei risposte:
#1
+42
Demento
2020-03-08 18:48:24 UTC
view on stackexchange narkive permalink

La risposta alla tua domanda si riduce alla modellazione delle minacce. L'utilizzo di protocolli crittografici come HTTPS è un meccanismo di sicurezza per la protezione da determinate minacce. Se tali minacce sono rilevanti per te, devono essere analizzate:

  • Ci sono potenziali attori di minacce nella tua rete interna? Sulla base della tua domanda sembri presumere che rete può essere completamente attendibile. Questo è spesso un malinteso, perché ci sono diversi modi in cui la tua rete interna può essere compromessa (ad esempio, utenti validi con accesso a questa rete stanno diventando dannosi, un sistema in questa rete viene compromesso, una configurazione errata apre il segmento di rete, ecc.).
  • L'architettura sarà soggetta a modifiche? È probabile che il sistema cambierà nel tempo e i precedenti presupposti di sicurezza (ad esempio, la mia rete interna è attendibile) non saranno più validi. Se questo è uno scenario ragionevole, potrebbe essere una buona idea costruire in anticipo il meccanismo di sicurezza necessario. Ecco a cosa servono le migliori pratiche di sicurezza. Fornire sicurezza in un'area di incertezza.
  • Esiste un requisito normativo, legale o di conformità che deve essere soddisfatto? Hai affermato che il tuo cliente considera HTTPS allo stato dell'arte -arte / best practice moderne. La fonte di questa dichiarazione formulata in modo amichevole potrebbe effettivamente essere un requisito guidato dall'esterno, che deve essere soddisfatto. La non conformità è una minaccia che dovrebbe essere trattata anche in un'analisi delle minacce.

Questi sono argomenti importanti che vale la pena analizzare. Quando progetto architetture di sistema e sono in dubbio, preferisco sbagliare sul lato della sicurezza. In questo caso l'approccio best practice consiste effettivamente nell'utilizzare HTTPS per la comunicazione, indipendentemente dalle circostanze, a condizione che non vi sia un impatto considerevole sull'applicazione (ad es. Impatto sulle prestazioni).

La difficoltà di mantenere i certificati del server non dovrebbe essere un problema al giorno d'oggi, poiché questa è una pratica comune. Questo dovrebbe far parte della normale attività delle operazioni pianificate.

Detto questo, è ovviamente necessario uno sforzo aggiuntivo per utilizzare HTTPS invece di HTTP ed è tuo diritto addebitare al cliente questo impegno aggiuntivo. Ti suggerisco di calcolare quanto costerà durante lo sviluppo e nel tempo durante il funzionamento e lasciare che il cliente decida se il costo vale il vantaggio.

"La difficoltà di mantenere i certificati del server non dovrebbe essere un problema al giorno d'oggi, poiché questa è una pratica comune".Dovresti dirlo alle persone di Microsoft Azure.O chiunque abbia avuto interruzioni a causa del problema Let's Encrypt solo la scorsa settimana, oppure .. Potrei andare avanti.No davvero, la quantità di interruzioni dovute a problemi con i certificati anche nelle reti più grandi mostra che questo non è così banale come le persone amano pensare in teoria.E le conseguenze sono gravi.Non si dovrebbe davvero sottovalutare questo fattore.
@Voo Per l'autenticazione interna da server a server, non c'è motivo di utilizzare una CA pubblica come Let's Encrypt, anzi è probabilmente meglio non farlo.È possibile utilizzare una CA gestita internamente per i certificati interni, quindi non è necessario preoccuparsi del rinnovo (è possibile impostare la scadenza a 100 anni o altro), non è necessario fornire ai server l'accesso a Internet e non c'è possibilità che qualcuno possaindurre una CA pubblica a emettere un certificato in modo errato, poiché devono essere validi solo i certificati firmati dalla CA interna.
@James Certo, ma potrei anche citare i problemi con quell'approccio .. ricordi quando Chrome ha deciso di richiedere nomi di soggetti alternativi per la convalida del certificato?Avevamo vecchi certificati interni che non li impostavano.O sul divertimento di configurare le applicazioni del nodo per utilizzare la tua CA radice interna.E così via.Il punto non è che queste cose sono insormontabili, ma che non dovresti sottovalutarle.
@BoogaRoo per la comunicazione da server a server, non importa se Apple si fida o meno dei tuoi certificati, solo se il tuo server lo fa.Se stai utilizzando librerie che ti consentono di configurarle di conseguenza (molte lo fanno), puoi utilizzare SHA-1, RSA a 1024 bit, nessun nome alternativo di soggetto, periodi di scadenza irragionevolmente lunghi e tutti i tipi di cose che non soddisfanoi requisiti di base, i browser e le autorità di certificazione pubbliche verrebbero a mancare.Il che non vuol dire che dovresti ignorare le buone pratiche senza motivo, ma a seconda del modello di minaccia, la convenienza potrebbe essere una ragione sufficiente.
@James_pic in qualche modo l'ho interpretato erroneamente come "RSA a 1 bit".
#2
+8
symcbean
2020-03-08 23:11:47 UTC
view on stackexchange narkive permalink

Mescolare e abbinare HTTP e HTTPS non è una buona idea: dovrai costantemente destreggiarti tra le configurazioni.

Di solito l'aggiunta di un componente in un sistema dovrebbe essere eseguita solo se c'è una ragione molto specifica per questo - solo perché qualcuno ha pensato che fosse una buona idea non è un motivo specifico.

Non sto dicendo che HTTPS sia una cattiva idea - al contrario - ma devi imparare molto da fare. Il modello che proponi mina il rapporto di fiducia che è il motivo principale per utilizzare TLS in primo luogo. Inoltre, non sembra che tu abbia pensato a come pianificare la tua PKI.

server rotti un giorno in futuro perché alcuni server hanno un certificato scaduto e nessuno lo sa

Se stai fornendo il servizio, dovresti configurare il monitoraggio per il servizio, inclusa la scadenza del certificato.

Sembra che tu stia cercando motivi per discutere con l'approccio del rilascio dei certificati. Leggendo tra le righe qui, sembra che al momento ti manchino le competenze e la pianificazione necessarie per implementarle.

Sì, è molto lavoro, ma questo è il modello di business: tu valuti la quantità di lavoro, le competenze che devi acquisire e quelle che puoi acquistare e fai pagare al cliente per questo. (Serge evidenzia il costo dei certificati, ma questo è il costo più basso dell'intero esercizio).

L'uso di https sulla rete interna (o sulla rete solo host ...) provoca mal di testa perché è necessario prendersi cura dei certificati che non verranno visualizzati da nessuno, ma i sistemi dovranno continuamente lavorare su handshake TLS non necessari.Dovrai gestire certificati mai visti da nessuno.E avrai ancora molti mal di testa a causa dei diversi metadati dei certificati.Mentre un software scritto correttamente non dovrebbe avere problemi a funzionare ovunque, incluso un server http che gira dietro un proxy https.
Non dovresti davvero giudicare la conoscenza di qualcuno sulla base di così poche informazioni fornite nella domanda ...
@peterh-ReinstateMonica: il sovraccarico dell'infrastruttura, anche con microservizi distribuiti, è così piccolo che è quasi impossibile misurarlo.E implementarlo in anticipo quando ne hai bisogno è un enorme risparmio in termini di costi e sforzi.Se questa non è la tua esperienza, allora stai sbagliando.Ma questi rimangono irrilevanti per il mio punto principale: il cliente lo vuole, il cliente lo paga, non fa male.
(almeno non fa male se è fatto correttamente)
Le statistiche di @symcbean mostrano che la ricomparsa dei visitatori dipende molto dal numero di decimi di secondo che una pagina appare loro.Non a caso, chiedendo loro feedback, dicono solo che la pagina non è abbastanza veloce, se è veramente lenta.Sì, i decimi di secondo sono importanti se sei interessato alle statistiche delle visite.Nota, mentre un handshake SSL non è in genere un trasferimento di grandi quantità di dati, ha molti blocchi: circa 5-10 volte deve aspettare da una parte all'altra.(Questo può essere ridotto dal pool di connessioni e dalle sessioni tls, bel compito per configurarli ovunque.)
@symcbean C'è ancora un altro argomento: crittografando il traffico interno si perde molta debuggabilità.Se hai una comunicazione crittografata, puoi solo eseguire il debug di ciò che i software stanno effettivamente parlando tra loro, se esegui il debug del software stesso (come apache dump_io o simili).Mentre puoi analizzare il traffico http senza la collaborazione / modifica dei parttakers.
@Persistence Non avevo intenzione di comunicazione negativa.
@peterh-ReinstateMonica il mio commento era rivolto a chi ha risposto, non a te.Dal momento che dicono esplicitamente "attualmente ti mancano le competenze", il che è infondato
#3
+8
Peteris
2020-03-09 18:35:04 UTC
view on stackexchange narkive permalink

Le reti interne non sono sicure

In generale, le reti interne sono più sicure dei sistemi rivolti al pubblico, ma non dovrebbero essere considerate completamente sicure. Una parte significativa degli attacchi proviene dall'interno: spearphishing, ingegneria sociale e attacchi interni sono tutti vettori popolari che iniziano con un punto d'appoggio all'interno della tua rete.

Quindi non c'è una buona ragione per il traffico non crittografato di segreto o privato informazioni anche sulle reti interne. Non hai necessariamente bisogno di nomi pubblici o gerarchia CA: se disponi di canali di comunicazione bilaterali ben definiti, potrebbe essere più semplice avere una relazione di fiducia esplicita in cui i tuoi bilanciatori del carico sono configurati per fidarsi di un particolare certificato autofirmato del tuo server di backend e nient'altro.

Inoltre: ricorda che puoi utilizzare tecnologie come VPN basate su certificati su reti interne e su reti esterne, ei vantaggi sono gli stessi.Puoi wall-off porzioni della tua rete interna in modo che non sia possibile accedervi tranne che da quei sistemi interni che possiedono credenziali crittografiche uniche che solo la tua azienda può emettere.La cosa bella delle VPN è che proteggono * tutto * ... eppure lo fanno * in modo trasparente * ai client che le impiegano.Aggiunge un ulteriore livello di responsabilità, facilmente e gestibile.
#4
+4
Serge Ballesta
2020-03-08 19:05:43 UTC
view on stackexchange narkive permalink

Come professionista, devi dare consigli al tuo cliente, ma non dovresti prendere la decisione da solo.

Gli argomenti da presentare al tuo cliente sono:

  • cos'è il guadagno nell'utilizzo di HTTPS all'interno della rete di server? Se questa rete è isolata da qualsiasi altro sistema e solo gli amministratori di sistema possono accedervi, si potrebbe sostenere che il guadagno può essere trascurato perché si tratta solo di proteggere un sistema da qualcuno che ha già privilegi di amministratore. Se altri membri del personale senza privilegi di amministratore possono accedervi, il guadagno non è nullo, né lo sono i sistemi per altri clienti.
  • qual è il rischio di farlo? La disgrazia sui certificati è principalmente ... una disgrazia. Ma il fatto è che HTTPS è un protocollo più complesso di HTTP e qualsiasi complessità aggiunta aggiunge rischi per errori di implementazione. Se il passaggio precedente ha concluso che il guadagno è trascurabile, questo è sufficiente per consigliare al cliente di non farlo.
  • quale sarebbe il costo aggiuntivo? Qui devi considerare i costi diretti e indiretti. I costi diretti potrebbero includere il prezzo di certificati aggiuntivi se si utilizzano quelli esterni o il tempo per la creazione di certificati privati ​​se si utilizza una PKI privata. Includerebbero anche il tempo per la configurazione del sistema. Inoltre, dovrebbero includere i tempi di manutenzione come costi ricorrenti, compreso un rinnovo programmato dei certificati: questa parte è nel tuo dominio di responsabilità, ma puoi addebitare il tempo al tuo cliente. I costi indiretti sono più difficili da stabilire, ma dovresti usare la tua esperienza per valutare il rischio di errori a causa della complessità aggiunta e delle loro possibili conseguenze. E IMHO puoi addebitare al tuo cliente per questo se insiste nel non seguire i tuoi consigli.

Ma quando hai detto tutto, il cliente è responsabile della decisione.

#5
+3
fraxinus
2020-03-09 23:17:17 UTC
view on stackexchange narkive permalink

La crittografia è economica. La perdita di dati o la perdita di dati non lo sono.

Usa la crittografia tra i server (ed è ancora meglio usare l'autenticazione TLS tra i server).

E quando dico economico, è anche economico considerando la gestione delle chiavi e dei certificati. Potrebbe essere ragionevole emettere un certificato autofirmato e di lunga durata a entrambi i server.

Ci sono alcune eccezioni alla regola:

  1. O il client o server sono legacy con vulnerabilità SSL / TLS note. È sempre meglio aggiornare il codice vulnerabile, ma sappiamo tutti che non è sempre possibile. A volte è meglio (ancora non va bene, ma meglio) disabilitare completamente il codice vulnerabile, eseguire testo in chiaro e mitigare i rischi in un modo o nell'altro.

  2. Stai scambiando un pazzo quantità di dati e / o necessitano di una latenza incredibilmente bassa. La crittografia può diventare un collo di bottiglia e / o un divoratore di risorse. Puoi scegliere di non crittografare e fare anche qualcos'altro per proteggere la cosa.

#6
  0
Mike Robinson
2020-03-10 01:59:27 UTC
view on stackexchange narkive permalink

"https" non solo protegge le comunicazioni mentre passano sulla rete, ma verifica anche il certificato presentato dal server. Ciò ti consente di sapere che stai davvero parlando con il sito corretto. E questo, secondo me, è il vero vantaggio di "https".

"letsencrypt.org", che rilascia certificati firmati gratuitamente, ha molto materiale sul proprio sito web che discute di questi vantaggi . Sostengono ... abbastanza giustamente, penso ... che "tutto dovrebbe essere https, indipendentemente dal fatto che il materiale sia effettivamente sensibile o meno."

( mod_ssl et al sono anche in grado di imporre il possesso di certificati anche dal lato client , sebbene ciò sia fatto raramente. Per un'applicazione interna sicura, tuttavia, potresti voler fare una cosa del genere. il server è quindi in grado di limitare quali computer sono in grado di connettersi ad esso, limitandoli in base alle credenziali che devono possedere.)



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...