it-swarm-eu.dev

Una connessione HTTPS stabilita significa che una linea è davvero sicura?

Dal punto di vista di qualcuno che offre un'applicazione Web, quando qualcuno si connette con TLS (https) al nostro servizio e invia i dati di autenticazione corretti, è sicuro trasmettere tutti i dati sensibili su questa linea o può essere che ci sia ancora un'ascolto?

Questa domanda era Domanda sulla sicurezza IT della settimana.
Leggi il 29 luglio 2011 post di blog per maggiori dettagli o invia il tuo Domanda della settimana.

112
Peter Smit

È importante capire cosa fa e cosa non fa SSL, soprattutto perché questa è una fonte molto comune di incomprensioni.

  • Crittografa il canale
  • Si applica il controllo di integrità
  • Fornisce autenticazione

Quindi, la risposta rapida dovrebbe essere: "sì, è abbastanza sicuro per trasmettere dati sensibili". Tuttavia, le cose non sono così semplici.

  • Le versioni più recenti di SSL - versione 3, o meglio ancora: TLS, anche TLS 1.2, sono decisamente migliori delle versioni precedenti. Per esempio. SSL 2 era relativamente facile da MITM (Man in the middle). Quindi, prima dipende dalla versione del protocollo.
  • Sia la crittografia del canale sia il controllo dell'integrità sono configurabili nel protocollo, ovvero è possibile scegliere quali algoritmi utilizzare (suite di crittografia). Ovviamente, se stai usando RSA1024/SHA512, stai molto meglio ... Tuttavia, SSL supporta anche una modalità di crittografia NULL - cioè nessuna crittografia, avvolgendo semplicemente le richieste fino al tunneling sul protocollo SSL. Cioè, nessuna protezione. (Questo è configurabile sia sul client che sul server, la suite di crittografia selezionata è il primo set di corrispondenza in base all'ordine configurato).
  • L'autenticazione in SSL ha due modalità: solo autenticazione server e autenticazione reciproca (certificati client). In entrambi i casi, la sicurezza garantita dai certificati crittografici è decisamente abbastanza forte, tuttavia la validità dell'autenticazione effettiva è valida solo quanto i controlli di validità: ti preoccupi nemmeno di controllare il certificato? Ne garantisci la validità? Catena di fiducia? Chi l'ha rilasciato? Eccetera.
  • Quest'ultimo punto di autenticazione è molto più semplice nel web applicazioni, in cui il client può visualizzare facilmente il certificato del server, l'icona del lucchetto è facilmente visualizzabile, ecc. Con Web Servizi, di solito è necessario essere più espliciti nel verificarne la validità (a seconda della scelta della piattaforma). Nota che questo stesso punto ha innescato così tante app mobili - anche se lo sviluppatore dell'app ha ricordato di usare solo TLS tra il telefono e il server, se l'app non verifica esplicitamente i certificati, allora il TLS è rotto.
  • Mentre ci sono alcuni attacchi per lo più teorici sulla crittografia di SSL, dal mio PoV è ancora abbastanza forte per quasi tutti gli scopi, e lo sarà per molto tempo.
  • Cosa si fa effettivamente con i dati all'altra estremità? Per esempio. se si tratta di dati relativi a carte di credito super sensibili, o addirittura di carte di credito, non li desideri nella cache dei browser, nella cronologia, ecc.
  • I cookie (e quindi l'autenticazione) possono essere condivisi tra un canale SSL sicuro e un canale HTTP non sicuro, a meno che non siano esplicitamente contrassegnati con l'attributo "sicuro".

Quindi, una risposta più breve? Sì, SSL può essere abbastanza sicuro, ma (come nella maggior parte delle cose) dipende da come lo usi. :)

94
AviD

Ci sono alcuni problemi qui, il principale è l'autenticazione. Entrambe le estremità devono essere sicure che stanno parlando con la persona o l'istituzione giusta per contrastare gli attacchi man-in-the-middle. Da parte tua è fondamentale utilizzare un certificato SSL considerato attendibile dal browser dell'utente. In questo modo il browser dell'utente può essere sicuro che sta davvero parlando con il sito corretto. Una volta stabilita la connessione, puoi essere sicuro di parlare sempre con quell'utente e la connessione è crittografata, vale a dire sicura contro intercettazioni.

L'autenticazione nell'altra direzione (ovvero assicurandosi di parlare con l'utente reale) viene generalmente gestita al di fuori del protocollo SSL a livello di applicazione, ad esempio nome utente/password, openID o altre forme di credenziali.

Come ultima nota, va detto che durante la stretta di mano della connessione SSL client e server concordano un Cipher suite e il client potrebbe fingere di fare solo "crittografia nulla", cioè non crittografare nessuno dei dati . Se il tuo server accetta tale opzione, la connessione utilizza SSL, ma i dati non sono ancora crittografati. Questo non è un problema in pratica poiché le implementazioni del server di solito non offrono la crittografia nulla come opzione.

23
Tronic

Oltre a ciò che AviD elenca, SSL è sicuro solo come l'infrastruttura DNS che ti ha indirizzato a quel server e tutti i proxy aziendali nel percorso di comunicazione.

Se l'infrastruttura DNS viene compromessa (avvelenamento da cache, ecc.), L'attaccante potrebbe sottoporre l'utente a molti attacchi.

Inoltre, se il client sta attraversando un software come Fiddler , o un proxy aziendale, quel software può facilitare la conversazione SSL.

Per mitigare ciò, guarda l '"emittente" del certificato SSL. Se la connessione SSL passa attraverso un proxy, l'emittente sarà quello del proxy. Se stai attraversando una connessione diretta, vedrai la relativa CA attendibile pubblicamente.

[Ulteriori informazioni]

Un proxy HTTPS aziendale è qualcosa che gestisce la connessione tra il browser Web e il proxy (il cui indirizzo IP viene visualizzato nei registri del server Web). In tal caso, il contenuto Web (anche la password HTTPS) viene decrittografato e successivamente nuovamente crittografato nel proxy aziendale e presentato al server.

A seconda di chi gestisce il proxy e di come vengono utilizzati i suoi registri, questo può essere accettabile o negativo dal punto di vista della prospettiva.

Per ulteriori informazioni su come viene eseguita l'intercettazione SSL, vedere questo collegamento :

Quando il proxy SSL intercetta una connessione SSL, presenta un certificato server emulato al browser client. Il browser client emette un pop-up di sicurezza per l'utente finale perché il browser non si fida dell'emittente utilizzato da ProxySG. Questo pop-up non si verifica se il certificato emittente utilizzato dal proxy SSL viene importato come radice attendibile nell'archivio certificati del browser client.

ProxySG rende tutti i certificati configurati disponibili per il download tramite la sua console di gestione. È possibile chiedere agli utenti finali di scaricare il certificato dell'emittente tramite Internet Explorer o Firefox e installarlo come CA affidabile nel proprio browser preferito. Ciò elimina il popup del certificato per i certificati emulati ...

Alcune aziende risolvono il problema relativo al pop-up dei certificati sopra menzionato distribuendo i certificati radice (del proxy) su ciascuna workstation tramite GPO. Sebbene ciò influirà solo sul software che utilizza l'archivio certificati Microsoft. Software come Firefox e Chrome deve essere aggiornato in modo diverso.

20

Poiché SSL si basa su Certificate-Authorities (CA) e praticamente qualsiasi organizzazione può diventare una CA, sono sempre possibili attacchi man-in-the-middle con certificati falsi ma firmati da CA. Quindi, sebbene SSL sia ancora un enorme miglioramento rispetto alla non crittografia, la sua sicurezza è sopravvalutata a causa del sistema CA rotto. A tale proposito, i certificati autofirmati sarebbero altrettanto sicuri di qualsiasi altro certificato firmato dalla CA, tuttavia i browser li segnalano come sospetti.

11
Jörn Zaefferer

SSL è molto sicuro, anche se qualcuno può rubare il cookie di sessione di qualcuno se si esegue QUALSIASI pagina su una linea non crittografata. Se potessi, renderei il sito tutto SSL. O forse hanno il cookie inviato solo per connessioni crittografate e hanno pagine pubbliche non protette non specifiche per quell'utente.

10
James T

C'è ancora la possibilità di un attacco man-in-the-middle, che nel tuo caso sarebbe l'utente che si connette a una terza parte che afferma di essere il tuo sito e quindi inoltra la richiesta. Naturalmente, un utente esperto dovrebbe notare la mancanza di una connessione SSL o un certificato errato, ma la maggior parte degli utenti non è attivata e viene ingannata da una favicon lucchetto.

Questo non è davvero un problema con SSL stesso, solo qualcosa di cui essere consapevoli. Puoi tranquillamente supporre che nessuno sia in grado di intercettare la connessione SSL tra il tuo sito e l'origine della connessione. Non puoi, tuttavia, essere sicuro che l'origine della connessione sia davvero l'utente.

9
Magnus

Poiché SSL cripta la trasmissione, non è possibile intercettare dati (poiché il certificato è attendibile).

Sebbene il problema risieda su dove (e quanto) stai usando SSL nella tua webapp: diciamo, ad esempio, che hai bisogno di una connessione SSL solo per autenticare il tuo utente (per consentire loro di inviare coppie crittografate/utente al tuo server) , quindi quando rispedisci un cookie dovresti essere consapevole che potrebbe essere facilmente intercettato (come se il tuo utente si trova su una connessione wireless non protetta).

Il recente dramma di FireSheep è tutto su questo.

9
gbr

No. Analisi del traffico può ancora dire molto a qualcuno.

L'analisi del traffico è il processo di intercettazione ed esame dei messaggi al fine di dedurre informazioni dai modelli di comunicazione. Può essere eseguito anche quando i messaggi sono crittografati e non possono essere decifrati. In generale, maggiore è il numero di messaggi osservati, o anche intercettati e memorizzati, tanto più si può dedurre dal traffico.


TLS viene di solito utilizzato per preservare la riservatezza: un utente malintenzionato non dovrebbe raggiungere un livello elevato di confidenza sui contenuti della comunicazione.

Assumendo,

  1. un aggressore conosce il tuo protocollo,
  2. un aggressore sa chi sta comunicando con chi
  3. l'attaccante non può decrittografare i messaggi.
  4. non oscuri il tuo traffico reale in un sacco di traffico senza senso (chaff)

Un utente malintenzionato può probabilmente dire quando sei sveglio e quando dormi, indipendentemente dal protocollo, e potrebbe essere in grado di dire molto di più a seconda della natura del protocollo che stai utilizzando.


Se il tuo protocollo è molto semplice:

  1. Si invia un messaggio "sparare le bombe atomiche a ..." quando si desidera sparare bombe atomiche
  2. Non si invia un messaggio quando non si desidera sparare bombe atomiche.

Un intercettatore che non è in grado di decrittografare i tuoi dati può determinare dalla semplice presenza di un messaggio che vuoi sparare bombe atomiche, anche se forse non a chi.


Se il protocollo è più complesso:

  1. Chiedi un libro.
  2. Ti mando il contenuto.

Un attaccante potrebbe non essere in grado di dire chi sta leggendo "Guerra e pace" vs "Atlas Shrugged" ma può distinguere, basandosi esclusivamente sulla dimensione del messaggio, se sta leggendo uno dei primi contro i 55 di Kafka romanzo di pagina "La metamorfosi".

7
Mike Samuel

SSL esegue due attività di base: autenticazione e crittografia.

L'autenticazione viene eseguita tramite autorità di certificazione (CA). I browser vengono forniti con un elenco di certificati SSL per le chiavi di firma delle autorità di certificazione. Le autorità di certificazione firmano certificati che descrivono la chiave pubblica di un'entità. Ad esempio, se possedessi Google.com, lo dimostrerei a Verisign e firmerebbero il mio certificato per un certo periodo di tempo. I problemi che sorgono con una CA indicano che non dovrebbero firmare. Ciò può accadere quando qualcuno finge di possedere un altro dominio, acquisisce un certificato jolly troppo ampio o semplicemente XKCD la CA nell'emettere qualcosa di nefasto (i governi, forse?). Abbiamo visto accadere casi di tutto quanto sopra, ma è piuttosto raro.

Se un certificato per un sito è firmato correttamente e non esiste alcun certificato falso nella catena di fiducia, quando ti connetti a un sito puoi (a fini di discussione) essere sicuro che il certificato corrisponde. In circostanze normali, tale connessione è crittografata. Ciò impedisce a chiunque di leggere i tuoi dati.

I certificati SSL sono molto complessi e esistono numerosi attacchi contro le implementazioni SSL. Ciò che SSL può effettivamente fare è impedirmi di controllare il tuo traffico su Starbucks locale quando controlli la tua e-mail su GMail. Ciò che non può fare è impedirmi di utilizzare un attacco MITM in cui ti inoltro tutto senza SSL e il tuo client non è configurato per disturbarti sul fatto che non ha mai avviato una sessione crittografata.

6
Jeff Ferland

Non contando le varie risposte di altri su altri potenziali problemi, supponendo che tu stia utilizzando SSL 3.0 e crittografia avanzata, dovrebbe essere sicuro.

L'uso di protocolli SSL precedenti (2.0) o l'utilizzo di una chiave di crittografia debole potrebbe farti vulnerare.

4
Doozer Blake

SSL generalmente aumenta la sicurezza fornendo:

  1. Autenticazione del server (l'utente sa che sta parlando con il sito "corretto")
  2. Integrità dei dati (l'utente e il server sanno che il traffico non viene modificato lungo il percorso)
  3. (facoltativamente, ma in genere) Privacy dei dati (l'utente e il server sanno che il traffico non viene intercettato lungo il percorso)
  4. (facoltativo, ma raro) Autenticazione client, se anche il client ha un certificato

Esistono essenzialmente solo due tipi di certificati SSL, il certificato del server (che è sempre coinvolto) e un certificato client (che è facoltativo).

Questo è solo uno schizzo e ci sono molti se, e e ma. Nello scenario più tipico, SSL basato su browser, lo schema può essere rotto in molti casi senza interrompere la crittografia o il protocollo, ma semplicemente facendo affidamento sull'utente per fare la cosa sbagliata (cioè ignorare gli avvisi del browser e connettersi comunque). Gli attacchi di phishing possono anche funzionare inviando l'utente a un sito protetto SSL falso, creato per assomigliare a quello reale a tutti gli effetti tranne l'URL.

Detto questo, SSL e suo cugino TLS sono ancora molto utili in quanto consentono almeno una comunicazione sicura, sebbene tutt'altro che infallibile.

4
frankodwyer

@Vladimir ha ragione nel dire che http://en.wikipedia.org/wiki/Forward_secrecy è desiderabile, ma ha i dettagli sbagliati. Il server ha scelto questa suite di cifratura tra quelle offerte dal browser. "crittografato con RC4_128 con SHA1 per l'autenticazione dei messaggi" utilizza la crittografia RC4 a 128 bit e il controllo di integrità HMAC-SHA-1. (I nomi di Ciphersuite in SSL/TLS fino a poco tempo fa dicono SHA ma significano SHA-1 e in realtà HMAC-SHA-1.) "ECDHE_ECDSA come meccanismo di scambio di chiavi" non si applica ai singoli messaggi , fa parte (la maggior parte) della stretta di mano che si verifica una volta all'inizio della sessione: ECDHE utilizza la variante Curva ellittica di Diffie-Hellman in modalità effimera (oltre ad alcuni passaggi aggiuntivi non importanti qui) per creare la sessione chiavi utilizzate per la crittografia e HMAC; e lo scambio di chiavi ECDHE (solo) è firmato dalla variante Elliptic Curve di Digital Signature Algorithm. (Non puoi mai crittografare nulla direttamente con DH o ECDH, fanno solo accordi chiave o altri piccoli accordi segreti.)

2

Quando non si utilizza SSL, tutte le comunicazioni possono essere facilmente intercettate: l'unica cosa che occorre fare è avviare lo sniffer di pacchetti (ovvero Wireshark).
SSL lo impedisce, tutti i pacchetti sono crittografati, quindi non c'è modo di sapere cosa stai inviando. Fondamentalmente viene utilizzato per proteggere le password e i contenuti privati ​​dall'intercettazione. Ovviamente non vuoi che qualcun altro legga le tue e-mail private, giusto?
Per quanto riguarda la ricerca su Google, lo hanno fatto semplicemente per nascondere ciò che la gente chiede. Questo perché alcuni governi sono troppo curiosi al riguardo.

In che modo SSL aumenta la sicurezza? Non lo fa da solo. Ciò che fa è una combinazione di crittografia (chiave SSL) e PKI (infrastruttura a chiave pubblica), principalmente certificati. OK, la domanda era come. Da un lato protegge il tuo canale di comunicazione (vedi sopra), dall'altro assicura che stai parlando con un business legittimo - autentica il server. Quindi il canale è sicuro e affidabile.

Esistono alcuni certificati SSL, in quanto ce ne sono alcuni Servizi PKI . Un servizio sostanzialmente diverso richiede un diverso tipo di certificato SSL. Esistono quindi certificati per la firma del codice, la crittografia e la firma e-mail, quelli relativi all'autenticazione del server e così via.

2
Paweł Dyda

Quando qualcuno si connette con SSL (https) al nostro servizio e invia i dati di autenticazione corretti, è sicuro trasmettere tutti i dati sensibili su questa linea o può essere che ci sia ancora intercettazione?

Il collegamento debole in questa catena non è quasi certamente SSL ma l'utente, che in genere può essere indotto a collegarsi a un sito intermedio falso tramite spoofing Web/spoofing hyperlink, o presentando un certificato non valido e chiudendo l'avviso del browser e procedendo a connettiti comunque.

Tuttavia, il sistema che descrivi è comunque la migliore pratica, non c'è molto altro che puoi fare (oltre a istruire i tuoi utenti a prendere sul serio gli avvisi SSL se puoi).

2
frankodwyer

La risposta breve è no. Risposta più lunga: una raccolta di risposte sopra plus: Se risolviamo l'autenticazione, quindi man-in-the-middle, che con la connessione SSL tradizionale qualcuno che ascolta il traffico potrebbe ancora decrittografarlo in seguito se ottenessero una chiave segreta del server (pensa di NSA e National Security Letters). Nel protocollo TLS è presente un'opzione per utilizzare il protocollo Diffie-Helman per assicurare il collegamento in modo confidenziale. Vedi la figura seguente quando accedo a gmail.com usando Chrome. connection security

Guarda il testo RC4_128 con SHA1 per l'autenticazione dei messaggi ECDHE_ECDSA. Questo dice:

  1. Il server ha offerto il canale SSL RC4_128b con SHA
  2. All'interno di questo tunnel ogni messaggio è criptato con curve Ecliptic in cui la chiave viene derivata usando la funzione Diffie-Helman ed è firmato con il codice Ecliptic Curves usando l'algoritmo di firma digitale

In altre parole, anche se qualcuno ha la chiave privata del server SSL, i messaggi sono stati crittografati con chiavi temporanee che vengono scartate dalla memoria subito dopo l'uso. Buona fortuna NSA!

2
Vladimir Jirasek

È sicuro per l'utente o è sicuro per te? Supponi un attacco man-in-the-middle. L'attaccante riesce a catturare il traffico dell'utente, finge di essere tu per l'utente e finge di essere l'utente per te. Questo tipo di attacco di solito fallirebbe, perché il certificato fornito all'utente non sarebbe corretto. Ad esempio, l'attaccante fornisce all'utente un certificato autofirmato per il tuo sito Web. Tuttavia, se l'utente agisce stupidamente, può accettare quel certificato autofirmato. Quindi ora l'aggressore può leggere e modificare tutto il traffico tra l'utente e te, e per quanto ne so non c'è modo per te di rilevarlo.

Quindi, se lo snooping e la modifica del traffico danneggiano l'utente, è davvero colpa loro e dei loro problemi. E comunque non puoi impedirlo completamente, perché il MITM può escluderti completamente e parlare con l'utente fingendo di essere te. Ma se lo snooping e la modifica del traffico ti fanno male, devi fidarti che l'utente non sia stupido o autenticare meglio anche l'utente (l'utente avrebbe bisogno di un certificato e puoi verificarlo in un modo che il MITM non può falso).

2
gnasher729

Anche le versioni più moderne di HTTPS che utilizzano TLS possono essere facilmente intercettate da un MitM (ad esempio un dispositivo Juniper configurato allo scopo) se il client si fida della CA. In quel caso particolare, non è sicuro.

1
user3260912

Penso che le persone qui non capiscano la domanda:

Se si dispone di una linea non sicura e si stabilisce correttamente una connessione SSH/SSL su questa linea, ora chiede se è sicuro ipotizzare che la linea sia "sicura" e che i dati non crittografati possano essere trasmessi ALONGSIDE con la connessione crittografata ( ad esempio, in bella vista, non all'interno della connessione crittografata SSL/SSH).

Direi di no. In questo caso, potrebbe esserci un intercettatore passivo che ignora semplicemente i dati crittografati e salva i dati non crittografati.

MA puoi essere certo che non esiste un intercettatore attivo (MITM), il che significa che puoi stabilire in sicurezza una connessione SSL/SSH non autenticata con la stessa origine/destinazione della linea autenticata. Questo a condizione che non vi siano intercettatori selettivi che MITM certi connettori, MA tuttavia, l'intercettazione non può sapere se si intende autenticare o meno la connessione, quindi non può sapere quale connessione a MITM eludere il rilevamento. Il MITMer dovrebbe, se MITM, MITM tutte le connessioni e sperare che le persone facciano semplicemente clic su tutte le finestre di autenticazione.

Pertanto: se ti connetti autenticato a un servizio SSL da diciamo 123.123.123.123 a 24.24.24.24, puoi anche connettere in sicurezza un client SSH da 123.123.123.123 a 24.24.24.24 senza autenticare reciprocamente l'impronta digitale SSH, a condizione che tu possa fidarti di tutto ciò che c'è dietro l'altra parte è NAT router o firewall.

Ma anche se questo è generalmente sicuro, c'è IS un piccolo rischio che un intercettatore intercetti semplicemente connessioni MITM casuali e speri di non essere rilevato, quindi poiché hai già una connessione autenticata all'IP di destinazione, perché non utilizzare quella connessione autenticata per verificare reciprocamente l'impronta digitale SSH? È semplice come pubblicare l'impronta digitale SSH corretta su un sito Web protetto SSL!

1