Quali sono i rischi pratici di http (non https) nelle comunicazioni da server a server

Question

Quali sono i rischi pratici di http (non https) nelle comunicazioni da server a server

#1 da (5 voti)
#2 da (5 voti)
#3 da (5 voti)
#4 da (1 voti)
#5 da (0 voti)

2

Quali sono alcuni dei rischi pratici che derivano da una connessione server-server su http (non protetto con https / SSL)? Non ci sono utenti coinvolti, solo una connessione server-to-server da una compagnia all'altra.

L'attività A chiamerà un endpoint del servizio Web in Business B. Una chiave API verrà inclusa nella chiamata da utilizzare per l'accesso alla porta (ad esempio, la chiave deve essere valida, in regola).

So che è possibile a spiare il traffico. Non è sicuro che sia probabile , solo possibile. Qual è la ragione del rischio associato?

Quali sono altri rischi pratici?

EDIT: per un ulteriore contesto, alcune API Web pubbliche supportano le chiamate basate su http con la chiave passata nel payload o nell'URL. Ad esempio: Posterous, Tumblr (nuova API supporta OAuth su http), Bing, GoodGuide e Flickr.

EDIT 2 17-Mar-2014: ho posto questa domanda due anni fa. Deriva principalmente dalla mia curiosità per i veri vettori di attacco negli scenari server-to-server poiché la maggior parte della visibilità riguarda gli attacchi degli utenti finali o l'hacking nei server. Ma raramente ho sentito "se solo avessimo usato SSL da server a server!" (Anche se ricordo un'eccezione - la violazione del TJX del 2006 - in cui le carte di credito rubate dal canale wifi non protetto, suppongo che http all'interno di esso - sebbene wifi sia il tipico scenario da server a server).

Non è che non capisco o sappia usare SSL (lo faccio, lo uso e capisco la crittografia dietro di esso), quindi questa non è ignoranza del set di strumenti. Nelle risposte fino ad ora, nessuno ha ritenuto che le API web di cui sopra potessero essere utilizzate per compromettere i dati sensibili (una foto privata in Flickr, pubblicando alcuni contenuti dannosi sul mio account in Tumlbr (Posterous è andato!), Accedendo al mio personale ( potrebbe essere molto privato) query di ricerca in Bing e GoodGuide).

Poiché la complessità dell'offerta di API su HTTPS ricade interamente sul servizio - è facile scegliere HTTPS come client (anche se, nello scenario di interesse qui, il "client" è un altro server) - supposi che il i produttori dei produttori di API sopra elencati hanno valutato attentamente i pro ei contro e hanno deciso di consentire a HTTP di andare bene.

Sono d'accordo che ogni volta che ci occupiamo di dati riservati o sensibili dell'utente finale o dell'azienda, abbiamo un obbligo fiduciario implicito nel trattarlo responsabilmente sul filo (se produzione, sviluppo o test - se merita protezione) . Ma questo non è uno scenario (di nuovo, ecco perché ho posto questa domanda).

Ecco alcuni compromessi che potrebbero venire in mente nel caso generale.

Google Maps ha una chiave API che devi esporre in pubblico - vive in JavaScript - e l'accesso al servizio può essere bloccato dal nome del dominio di hosting (intestazione REFERER) - quindi questo non è necessario (e non richiede) SSL. (Questo è più comunemente usato in un modello da utente a server, ma è almeno possibile pensarlo nello scenario da server a server. Possiamo almeno capire la logica.)

Inoltre, le istanze di sviluppo e test di molti servizi ofter sono meglio senza SSL. Sono più facili da eseguire il debug sul cavo quando il traffico non è crittografato. Inoltre, è particolarmente doloroso impostare certificati SSL per la maggior parte degli ambienti perché spesso hanno nomi di dominio in continua evoluzione ad hoc sugli endpoint come gli ambienti vanno e vengono, forse nemmeno abbastanza coerenti per un certificato con caratteri jolly.

Esistono anche scenari da server a server meno vulnerabili di altri, anche se sono trasmessi dati sensibili. Ad esempio, considera i server appartenenti a divisioni diverse all'interno della stessa azienda e i dati non viaggiano su Internet pubblica (ad es. 192.168 intervallo di indirizzi).

Come altro esempio, consideriamo i server in esecuzione su una piattaforma cloud pubblica (Amazon o Azure, ad esempio) - Non penso che tu possa incontrare problemi da altri server in esecuzione nella stessa area del data center perché nessun codice (diverso da l'host della piattaforma) avrà la possibilità di elevare le autorizzazioni sull'hypervisor per impostare la scheda NIC sulla modalità promiscua per spiare il traffico (e anche se potesse, non potrebbe vederlo attraverso l'hypervisor (credo), e anche se potesse potrebbe solo spiare il traffico all'interno della propria rete VNET).

http tls

posta codingoutloud 24.02.2012 - 19:40

fonte

5 risposte

Leggi altre domande sui tag http tls

I captcha basati sull'arte ASCII sono abbastanza sicuri? [chiuso] Quali browser utilizzano openssl

score 5 · Answer 1

"So che è possibile curiosare il traffico. Non è sicuro che sia probabile, è solo possibile. Come può un motivo il rischio associato?"

Pensare in questo modo costa alle società milioni - se avessero appena messo al sicuro le informazioni in primo luogo, sarebbe un non-problema.

Semplice: quanto ti costerà se qualcuno ruba i dati dall'azienda o dalla società b - se è più che il costo di acquistare un certificato SSL economico allora è giustificato. Non è più una questione di "se" accadrà, si tratta di "quando".

score 5 · Answer 2

La scelta di cosa dovresti usare dipende da quali informazioni saranno condivise tra i server.

Se hai intenzione di condividere informazioni sensibili / confidenziali come dati bancari (carte di credito / debito, ecc.), informazioni mediche o qualcosa del genere dovresti UTILIZZARE DEFINITIVAMENTE SSL! Dovresti anche assicurarti che i tuoi server abbiano un firewall e siano visibili l'uno con l'altro (Azienda A- > Azienda B e Società B- > Azienda A).

D'altro canto, se le società condividono solo informazioni non riservate, allora PROBABILMENTE puoi utilizzare solo http.

Riguardo l'annusata - è possibile e molti aggressori lo usano. Le possibilità sono infinite. Un utente malintenzionato può rilevare i pacchetti, quindi provare a inviare pacchetti simili per confondere entrambi i server. Alla fine l'attaccante può ottenere il controllo su entrambi i server.

La ragione per cui Posterous, Tumblr, Bing, GoodGuide e Flickr (e altri) consentono http probabilmente perché non condividono le informazioni sugli utenti che non sono già pubblici. Sicuramente dubito che condividano le password dei loro utenti tramite l'API:)

Anche se ho cercato di spiegarlo nel modo più semplice, per il tuo bene, ti preghiamo di leggere un paio di articoli / libri su come funziona la crittografia, perché e quando è necessario. È una cosa veramente grande che non può essere spiegata in 5-10 frasi.

Ecco un paio di link che possono aiutarti a capire:

score 5 · Answer 3

Supponiamo che tu sia un business. Il business non è un paese per i deboli. Qualunque cosa tu faccia, sei destinato ad avere quel tipo speciale di nemico conosciuto come concorrenti .

I tuoi concorrenti non sono brave persone. Niente potrebbe piacere a loro più che, metaforicamente, entrare nella tua casa, svuotare il tuo frigo, bere tutto il tuo vino, molestare il tuo cane e andarsene con la tua TV e tua figlia. Potrebbero esprimerlo come "guadagnare quote di mercato", ma questo è solo un eufemismo.

Ora supponi di inviare ai tuoi concorrenti una bella lettera contenente una copia delle chiavi della porta anteriore e posteriore, informazioni dettagliate su quando andrai in vacanza e il numero di cellulare di tua figlia. Sempre metaforicamente, è quello che fai usando semplicemente HTTP per le tue connessioni B2B.

Come ragionate sui rischi connessi al semplice HTTP? Ricordando che è una cosa maledettamente stupida da fare . Le analisi dei rischi e dei costi vanno bene in linea di principio, ma quando il rischio è così elevato e il costo così basso, diventano totalmente ridicoli. Plain HTTP è vulnerabile a tutto . HTTPS è economico.

score 1 · Answer 4

I rischi pratici includono: sei vulnerabile alle intercettazioni, al dirottamento DNS e agli attacchi BGP.

Inoltre, se sei sfortunato / non attento, le chiavi di crittografia e altri segreti nell'URL oi parametri di query possono essere registrati nei log o eventualmente trapelati a terze parti in Referer: intestazioni.

Per questi motivi, ti consiglio di usare solo HTTPS. Di solito è facile da attivare ed elimina una classe di rischi per la sicurezza. Anche se questi rischi non sono quelli più probabili, il costo per eliminarli è spesso molto basso, quindi è probabilmente utile il compromesso in termini di costi / benefici.

score 0 · Answer 5

Che si tratti di comunicare tra due server (servizi Web) o di effettuare richieste da un browser, il protocollo che trasporta i dati è ancora HTTP. HTTP per impostazione predefinita non fornisce sicurezza e invia tutti i dati in testo normale sul filo. Ogni volta che sono coinvolti dati critici (dettagli della carta di credito, informazioni sull'identità, ecc.), Si consiglia di utilizzare HTTPS.

L'utilizzo di un semplice HTTP rende la comunicazione vulnerabile agli attacchi come il MITM. La semplice cattura dei pacchetti porterà alla perdita di informazioni critiche.

Se ci sono API pubbliche che implicano lo scambio di chiavi su chiavi http, allora queste chiavi dovrebbero essere pubbliche.