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.
È importante capire cosa fa e cosa non fa SSL, soprattutto perché questa è una fonte molto comune di incomprensioni.
Quindi, la risposta rapida dovrebbe essere: "sì, è abbastanza sicuro per trasmettere dati sensibili". Tuttavia, le cose non sono così semplici.
Quindi, risposta più breve? Sì, SSL può essere abbastanza sicuro, ma (come con la maggior parte delle cose) dipende da come lo si usa. :)
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.
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.
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.
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.
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.
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.
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.
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,
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:
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:
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".
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à.
SSL in genere aumenta la sicurezza fornendo:
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.
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).
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.
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:
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!
@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.)
È 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).
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!
Leggi altre domande sui tag web-application tls