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

112

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 intercettazioni?

This question was IT Security Question of the Week.
Read the Jul 29, 2011 blog entry for more details or submit your own Question of the Week.

    
posta Peter Smit 11.11.2010 - 22:41
fonte

18 risposte

94

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

  • Codifica il canale
  • Applica il controllo dell'integrità
  • Fornisce l'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 rispetto alle 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 dei canali che il controllo dell'integrità sono configurabili nel protocollo, cioè è possibile scegliere quali algoritmi utilizzare (suite di crittografia). Ovviamente, se si utilizza RSA1024 / SHA512 si sta molto meglio ... Tuttavia, SSL supporta anche una modalità di crittografia NULL - cioè nessuna crittografia, semplicemente avvolgendo le richieste fino al tunnel su protocollo SSL. No, nessuna protezione. (Questo è configurabile sia sul client che sul server, la suite di cifratura selezionata è il primo set corrispondente 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 è sicuramente abbastanza strong, tuttavia la validità dell'autentica autenticazione è valida solo come i controlli di validità: ti preoccupi anche di controllare il certificato? Ti assicuri la sua validità? Catena di fiducia? Chi l'ha emesso? Ecc.
  • Quest'ultimo punto di autenticazione è molto più semplice nelle applicazioni web , in cui il client può facilmente visualizzare il certificato del server, l'icona del lucchetto è facilmente visualizzabile, ecc. Con Web Servizi , di solito devi essere più esplicito nel controllarne la validità (a seconda della scelta della piattaforma). Nota che questo stesso punto ha fatto scattare molte app mobili - anche se lo sviluppatore dell'app si ricordava di utilizzare solo TLS tra il telefono e il server, se l'app non verifica esplicitamente i certificati, allora il TLS è rotto.
  • Anche se ci sono alcuni attacchi per lo più teorici sulla crittografia di SSL, dal mio PoV è ancora abbastanza strong per quasi tutti gli scopi, e lo sarà per molto tempo.
  • Cosa si fa effettivamente con i dati all'altra estremità? Per esempio. se la sua super-sensibile, o anche i dati della carta di credito, non lo si desidera nella cache del browser, o 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 sia esplicitamente contrassegnato con l'attributo "sicuro".

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

    
risposta data 11.11.2010 - 22:59
fonte
22

Qui ci sono alcuni problemi, il più importante è l'autenticazione. Entrambe le parti devono essere sicure che stanno parlando con la persona o l'istituzione giusta per contrastare gli attacchi di tipo "man-in-the-middle". Da parte tua è fondamentale utilizzare un certificato SSL che è considerato affidabile dal browser dell'utente. In questo modo il browser dell'utente può essere sicuro che stia davvero parlando con il sito corretto. Una volta stabilita la connessione, puoi essere sicuro di parlare continuamente con quell'utente e la connessione è crittografata, ossia sicura contro l'intercettazione.

L'autenticazione nella direzione opposta (ad esempio assicurandosi che si stia parlando con l'utente reale) viene solitamente gestita al di fuori del protocollo SSL a livello di applicazione, ad esempio, nome utente / password, openID o qualche altra forma di credenziali.

Come ultima nota va detto che durante la connessione SSL handshake client e server sono d'accordo su una suite di cifratura e il client potrebbe fingere di fare solo "crittografia nulla", cioè non crittografare nessuno dei dati. Se il tuo server accetta questa opzione, la connessione utilizza SSL, ma i dati non sono ancora crittografati. Questo non è un problema in pratica poiché le implementazioni dei server di solito non offrono il codice null come opzione.

    
risposta data 11.11.2010 - 22:54
fonte
19

Oltre a ciò che elenca AviD, SSL è sicuro quanto l'infrastruttura DNS che ti ha indirizzato a quel server e qualsiasi proxy aziendale nel percorso di comunicazione.

Se l'infrastruttura DNS viene compromessa (avvelenamento della cache, ecc.), l'utente malintenzionato potrebbe sottoporre il tuo utente a molti attacchi.

Inoltre, se il cliente passa attraverso software come Fiddler , o un proxy aziendale, quel software può easvdrop sul tuo SSL conversazione.

Per mitigarlo, guarda l'emittente del certificato SSL. Se la connessione SSL sta attraversando un proxy, l'emittente sarà quello del proxy. Se stai attraversando una connessione diretta, vedrai la relativa CA pubblicamente attendibile.

[Ulteriori informazioni]

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

A seconda di chi gestisce il proxy e di come vengono utilizzati i suoi registri, ciò può essere accettabile o negativo dalla tua prospettiva.

Per ulteriori informazioni su come l'intercettazione SSL è stata eseguita, consulta questo link :

When the SSL Proxy intercepts an SSL connection, it presents an emulated server certificate to the client browser. The client browser issues a security pop-up to the end-user because the browser does not trust the issuer used by the ProxySG. This pop-up does not occur if the issuer certificate used by SSL Proxy is imported as a trusted root in the client browser's certificate store.

The ProxySG makes all configured certificates available for download via its management console. You can ask end users to download the issuer certificate through Internet Explorer or Firefox and install it as a trusted CA in their browser of choice. This eliminates the certificate popup for emulated certificates...

Alcune aziende aggirano il problema del pop-up dei certificati sopra menzionato distribuendo i certificati radice (del Proxy) su ogni workstation tramite GPO. Sebbene ciò influirà solo sul software che utilizza l'archivio certificati Microsoft. Software come Firefox e Chrome devono essere aggiornati in modo diverso.

    
risposta data 07.12.2010 - 23:44
fonte
12

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

    
risposta data 11.11.2010 - 22:57
fonte
10

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

    
risposta data 11.11.2010 - 22:45
fonte
9

Esiste 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 rivendica di essere il tuo sito e quindi che inoltra la richiesta. Ovviamente, un utente esperto dovrebbe notare la mancanza di una connessione SSL o del certificato errato, ma la maggior parte degli utenti non è attiva e viene ingannata da una favicon del lucchetto.

Questo non è davvero un problema con SSL stesso, solo qualcosa di cui essere a conoscenza. Puoi tranquillamente presumere che nessuno possa intercettare la connessione SSL tra il tuo sito e l'origine della connessione. Tuttavia, non puoi essere sicuro che la fonte della connessione sia realmente l'utente.

    
risposta data 11.11.2010 - 22:52
fonte
9

Poiché SSL crittografa la trasmissione, nessun dato può essere intercettato (poiché il certificato è attendibile).

Anche se il problema risiede su dove (e quanto) stai usando SSL nella tua webapp: ad esempio, hai bisogno di una connessione SSL solo per autenticare il tuo utente (per far sì che inviino le coppie criptate / passate a il tuo server), quindi quando rispedisci un cookie devi essere consapevole che potrebbe essere facilmente intercettato (come se il tuo utente fosse su una connessione wireless non protetta).

Il recente dramma di FireSheep riguarda tutto questo.

    
risposta data 11.11.2010 - 23:02
fonte
6

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

L'autenticazione viene effettuata tramite le autorità di certificazione (CA). I browser sono dotati di un elenco di certificati SSL per le chiavi di firma delle CA. Le CA firmano i certificati che descrivono la chiave pubblica di un'entità. Ad esempio, se appartenessi a Google.com, lo dimostrerei a Verisign e firmerebbero il mio certificato per un certo periodo di tempo. I problemi si presentano con una CA che firma un certificato che non dovrebbero firmare. Questo può accadere quando qualcuno finge di possedere un altro dominio, acquisisce un certificato jolly che è troppo ampio, o semplicemente XKCDs la CA nell'emettere qualcosa nefasto (governi, forse?). Abbiamo visto casi di tutto quanto sopra accaduto, 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 corrisponda. In circostanze normali, quella 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. Quello che SSL può fare efficacemente è impedirmi di guardare il tuo traffico sul locale Starbucks quando controlli la tua posta su GMail. Ciò che non può fare è impedirmi di utilizzare un attacco MITM in cui inoltrare tutto a te senza SSL e il tuo client non è configurato per preoccuparti del fatto che non abbia mai avviato una sessione crittografata.

    
risposta data 27.04.2011 - 23:18
fonte
6

No. L'analisi del traffico può ancora dire a qualcuno molto.

Traffic analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. In general, the greater the number of messages observed, or even intercepted and stored, the more can be inferred from the traffic.

TLS viene solitamente distribuito per preservare la riservatezza: un utente malintenzionato non dovrebbe raggiungere un elevato livello di sicurezza riguardo ai contenuti della comunicazione.

Supponendo,

  1. un utente malintenzionato conosce il tuo protocollo,
  2. un utente malintenzionato sa chi sta comunicando con chi
  3. l'autore dell'attacco non può decodificare i messaggi.
  4. non oscuri il tuo traffico reale in un sacco di traffico senza senso (chaff)

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

Se il tuo protocollo è molto semplice:

  1. Invia un messaggio "spara alle armi nucleari a ..." quando vuoi sparare le bombe
  2. Non invii un messaggio quando non vuoi sparare alcuna bomba.

Un intercettatore che non può decrittografare i dati può determinare con la semplice presenza di un messaggio che si desidera attivare le armi nucleari, anche se forse non a chi.

Se il tuo protocollo è più complesso:

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

Un utente malintenzionato potrebbe non essere in grado di dire chi sta leggendo "Guerra e pace" contro "Atlas Shrugged" ma può distinguere, basandosi esclusivamente sulla dimensione del messaggio, sia che stiano leggendo uno dei primi contro il romanzo di 55 pagine di Kafka "La metamorfosi".

    
risposta data 01.09.2014 - 19:00
fonte
4

Se non si contano le varie risposte degli altri su altri potenziali problemi, supponendo che si stia utilizzando SSL 3.0 e crittografia avanzata, dovrebbe essere sicuro.

L'uso di protocolli ssl più vecchi (2.0) o l'utilizzo di una chiave di crittografia debole potrebbe aprire la porta a vulnerabilità.

    
risposta data 11.11.2010 - 22:59
fonte
4

SSL in genere aumenta la sicurezza fornendo:

  1. Autenticazione 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 durante il percorso)
  3. (facoltativamente, ma in genere) Privacy dei dati (l'utente e il server sanno che il traffico non viene intercettato durante il percorso)
  4. (facoltativo, ma raro) Autenticazione client, se il client ha anche un certificato

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

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

Avendo detto che SSL e il suo cugino TLS sono ancora molto utili in quanto consentono almeno una comunicazione sicura, anche se lontana dall'essere infallibili.

    
risposta data 27.04.2011 - 20:54
fonte
2

When somebody connects with SSL (https) to our service and submits the correct authentication data, is it safe to transmit all sensitive data over this line, or can it be that there is still eavesdropping?

L'anello debole in questa catena non è quasi sicuramente SSL ma l'utente, che in genere può essere indotto a connettersi a un falso sito intermedio tramite spoofing web / spoofing ipertestuale, oppure presentando un certificato non valido e ignorando l'avviso del browser e procedendo a collegarsi comunque.

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

    
risposta data 19.04.2011 - 16:59
fonte
2

Quando non usi SSL, tutta la comunicazione può essere facilmente intercettata: l'unica cosa che devi fare è lanciare lo sniffer di pacchetti (cioè Wireshark).
SSL lo impedisce, tutti i pacchetti sono crittografati quindi non c'è modo di sapere cosa stai mandando. Fondamentalmente è usato per proteggere password e contenuti privati dall'intercettazione. Ovviamente non vuoi che qualcun altro legga le tue email private, giusto?
Per quanto riguarda la ricerca su Google, l'hanno fatto semplicemente per nascondere ciò che le persone chiedono. Questo perché alcuni governi sono semplicemente troppo curiosi su questo.

In che modo l'SSL aumenta la sicurezza? Non da solo. Che cosa è una combinazione di crittografia (chiave SSL) e PKI (Public Key Infrastructure) - principalmente certificati. OK, la domanda era come. Da un lato protegge il tuo canale di comunicazione (vedi sopra), dall'altro garantisce che tu stia parlando con un'azienda legittima - autentica il server. Quindi il canale è sicuro e affidabile.

Esistono parecchi certificati SSL, in quanto vi sono alcuni Servizi PKI . In pratica, un servizio diverso ha bisogno di un diverso tipo di certificato SSL. Pertanto esistono certificati per la firma del codice, la crittografia e la firma di e-mail, quelli relativi all'autenticazione del server e così via.

    
risposta data 27.04.2011 - 20:55
fonte
2

La risposta breve è no. Risposta più lunga: una raccolta delle risposte sopra più: Se risolviamo l'autenticazione, quindi man-in-the-middle, che con la tradizionale connessione SSL, il somone che sta ascoltando il traffico potrebbe ancora decrittografarlo in seguito se hanno ottenuto una chiave segreta del server (si pensi alle NSA e alle National Security Letters). Esiste un'opzione nel protocollo TLS per utilizzare il protocollo Diffie-Helman per assicurare il collegamento in modo confidenziale. Guarda la seguente figura quando accedo a gmail.com utilizzando Chrome.

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

  1. Server ha offerto il canale SSL RC4_128b con digest SHA
  2. All'interno di questo tunnel ogni messaggio viene crittografato con curve Ecliptic dove la chiave viene derivata utilizzando la funzione Diffie-Helman ed è firmata con il codice Ecliptic Curves utilizzando l'algoritmo di firma digitale

In altre parole, anche se qualcuno ha una 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!

    
risposta data 10.10.2013 - 22:15
fonte
2

@Vladimir ha ragione che il link è desiderabile, ma ha i dettagli sbagliati. Il server ha scelto questa ciphersuite tra quelli offerti 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 Ciphersuite in SSL / TLS fino a poco tempo 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, è parte (la maggior parte) del handshake che si verifica una volta all'inizio della sessione: ECDHE utilizza la variante curva ellittica di Diffie-Hellman in modalità effimera (più alcuni passaggi aggiuntivi non importanti qui) per creare i tasti utilizzati per la crittografia e HMAC ; e lo scambio di chiavi ECDHE (solo) è firmato dalla variante Curva ellittica dell'algoritmo della firma digitale. (Non puoi mai cifrare nulla direttamente con DH o ECDH, ma esegui solo la chiave o altri piccoli accordi segreti.)

    
risposta data 14.02.2014 - 02:27
fonte
2

È 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. Di solito questo tipo di attacco fallisce, perché il certificato fornito all'utente non sarebbe corretto. Ad esempio, l'utente malintenzionato fornisce all'utente un certificato autofirmato per il tuo sito web. Tuttavia, se l'utente agisce in modo stupido, può accettare tale certificato autofirmato. Quindi ora l'attaccante 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 fanno male all'utente, questo è in realtà il loro stesso difetto e il loro stesso problema. E non puoi impedirlo completamente in ogni caso, perché il MITM può tagliarti completamente e solo parlare con l'utente fingendo di essere te stesso. Ma se ficcanaso e modifica del traffico ti fanno male, allora devi fidarti che l'utente non sia stupido, o meglio autenticare anche l'utente (l'utente avrebbe bisogno di un certificato, e puoi verificarlo in un modo che il MITM non può falso).

    
risposta data 26.03.2014 - 18:07
fonte
1

Penso che le persone qui non capiscano la domanda:

Se si dispone di una linea non sicura e si effettua una connessione SSH / SSL riuscita su questa linea, ora chiede se è sicuro di assumere che la linea è "sicura" e che i dati non crittografati possono essere trasmessi LUNGO Connessione crittografata (ad esempio, in bella vista, non all'interno della connessione SSL / SSH crittografata).

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

MA si può essere sicuri che non ci sia nessuno che intercetta (MITM) attivo, il che significa che è possibile stabilire in modo sicuro una connessione SSL / SSH non autenticata con la stessa sorgente / destinazione della linea autenticata. Ciò a condizione che non ci siano intercettatori selettivi di determinati connettori MITM, MA, comunque, l'intercettatore non può sapere se si intende autenticare o meno la connessione, quindi non può sapere quale Connessione a MITM eludere il rilevamento. Il MITMer avrebbe, se MITM, MITM tutti i collegamenti e spero che le persone facciano clic attraverso tutte le finestre di autenticazione semplicemente.

Quindi: 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 eseguire l'autenticazione reciproca dell'impronta digitale SSH, a condizione che tu possa fidati di tutto dietro il router o il firewall NAT dell'altro lato.

Tuttavia, anche se ciò è sicuro in generale, c'è un piccolo rischio che un intercettatore si colleghi semplicemente a MITM casuali e speriamo di non essere rilevato, quindi dal momento che hai già una connessione autenticata con l'IP di destinazione, perché non usare quella Connessione autenticata a verificare reciprocamente l'impronta digitale SSH? È semplice come pubblicare l'impronta digitale SSH corretta su un sito Web protetto da SSL!

    
risposta data 01.09.2014 - 18:39
fonte
0

HTTPS TLS / SSL anche i più aggiornati possono essere facilmente intercettati da un dispositivo Juniper configurato come MITM. Non è sicuro.

link

    
risposta data 10.07.2017 - 16:48
fonte

Leggi altre domande sui tag