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

• Cripta il canale
• Applica il controllo di integrità
• Fornisce l'autenticazione

Quindi, il rapido la risposta 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 ancora migliore: 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 che il controllo dell'integrità sono configurabili nel protocollo, ovvero puoi scegliere quali algoritmi utilizzare (cipher suite). Ovviamente, se stai usando RSA1024 / SHA512 stai molto meglio ... Tuttavia, SSL supporta anche una modalità di crittografia NULL, ovvero nessuna crittografia, semplicemente avvolgendo le richieste fino al tunnel sul protocollo SSL. Cioè, nessuna protezione. (Questo è configurabile sia sul client che sul server, la suite di cifratura selezionata è il primo set di corrispondenza in base all'ordine configurato).
• L'autenticazione in SSL ha due modalità: solo autenticazione del server e autenticazione reciproca (certificati client). In entrambi i casi, la sicurezza assicurata dai certificati crittografici è decisamente abbastanza forte, tuttavia la validità dell'autenticazione vera e propria vale solo quanto i tuoi controlli di validità: ti preoccupi nemmeno di controllare il certificato? Ne garantisci la 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 visibile, ecc. Con i servizi Web em>, di solito devi essere più esplicito nel controllarne la validità (a seconda della tua scelta di piattaforma). Nota che questo stesso punto ha fatto scattare così tante app mobili, anche se lo sviluppatore dell'app si è ricordato di utilizzare solo TLS tra il telefono e il server, se l'app non verifica esplicitamente i certificati, il TLS è rotto.
• Sebbene ci siano alcuni attacchi per lo più teorici alla crittografia di SSL, dal mio PoV è ancora abbastanza forte per quasi tutti gli scopi e lo sarà per molto tempo.
• Che cosa viene effettivamente fatto con i dati dall'altra parte? Per esempio. se si tratta di dati super sensibili, o anche di carte di credito, non vuoi che nella cache del browser, o nella cronologia, ecc.
• I cookie (e quindi l'autenticazione) possono essere condivisi tra un canale SSL sicuro e un canale HTTP non protetto, a meno che non sia esplicitamente contrassegnato con l'attributo "secure".

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

Ci sono alcuni problemi qui, il principale è l'autenticazione. Entrambe le parti devono essere sicure di parlare 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 di parlare realmente con il sito corretto. Una volta stabilita la connessione, puoi essere certo di parlare con quell'utente tutto il tempo e la connessione è crittografata, cioè protetta contro le intercettazioni.

L'autenticazione nell'altra direzione (cioè assicurandosi di parlare 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 menzionato che durante l'handshake della connessione SSL client e server concordano 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 del server di solito non offrono la cifratura nulla come opzione.

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

Se l'infrastruttura DNS viene violata ( avvelenamento della cache, ecc.), l'aggressore potrebbe sottoporre l'utente a molti attacchi.

Inoltre, se il client utilizza software come Fiddler o un proxy aziendale, quel software può easvdrop sulla tua conversazione SSL.

Per mitigare questo problema, guarda l '"emittente" del certificato SSL. Se la connessione SSL sta passando attraverso un proxy, l'emittente sarà quello del proxy. Se stai effettuando una connessione diretta, vedrai la CA pubblicamente attendibile pertinente.

[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 tuo 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 log, questo può essere accettabile o essere un problema dal tuo punto di vista.

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

Quando il proxy SSL intercetta una connessione SSL, presenta un certificato del server emulato al browser del client. Il browser client invia un popup di sicurezza all'utente finale perché il browser non si fida dell'emittente utilizzato da ProxySG. Questo popup non si verifica se il certificato dell'emittente utilizzato da SSL Proxy 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. Puoi chiedere agli utenti finali di scaricare il certificato dell'emittente tramite Internet Explorer o Firefox e installarlo come CA attendibile nel browser preferito. Ciò elimina il popup del certificato per certificati emulati ...

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ò interesserà solo il software che utilizza l'archivio certificati Microsoft. Software come Firefox e Chrome devono essere aggiornati in modo diverso.

Poiché SSL si basa sulle autorità di certificazione (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 rappresenti ancora un enorme miglioramento rispetto alla non crittografia, la sua sicurezza è sopravvalutata a causa del sistema CA danneggiato. A questo proposito, i certificati autofirmati sarebbero sicuri quanto qualsiasi certificato firmato da una CA, ma i browser li contrassegnano come sospetti.

SSL è molto sicuro, sebbene qualcuno possa rubare il cookie di sessione di qualcuno se esegui QUALSIASI pagina su una linea non crittografata. Se potessi, renderei il sito completamente SSL. O possibilmente fare in modo che il cookie venga inviato solo per connessioni crittografate e avere pagine pubbliche non protette non specifiche per quell'utente.

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. Ovviamente, un utente esperto dovrebbe notare la mancanza di una connessione SSL o il certificato sbagliato, ma la maggior parte degli utenti non è così attivata e viene ingannata da una favicon con lucchetto.

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

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

Anche se il problema risiede su dove (e quanto) stai utilizzando SSL nella tua webapp: ad esempio, per esempio, richiedi una connessione SSL solo per autenticare il tuo utente (per fargli inviare le coppie utente / passaggio criptate al tuo server), quindi quando rispedisci un cookie dovresti essere consapevole che potrebbe essere facilmente intercettato (come se il tuo utente ha una connessione wireless non protetta).

Il recente dramma di FireSheep riguarda tutto questo.

No. L'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 decrittografati. In generale, maggiore è il numero di messaggi osservati, o addirittura intercettati e archiviati, maggiore è il numero di messaggi dedotti dal traffico.

TLS viene solitamente implementato per preservare la riservatezza: un l'aggressore non dovrebbe raggiungere un livello elevato di sicurezza sui contenuti della comunicazione.

Supponendo che

1. un utente malintenzionato conosca il tuo protocollo,
2. lo sappia chi sta comunicando con chi
3. l'autore dell'attacco non può decrittografare i messaggi.
4. non oscuri il tuo traffico reale in un traffico senza senso (chaff)

Un malintenzionato può probabilmente capire 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. mandi un messaggio "spara le bombe a ..." quando vuoi sparare le bombe
2. Non mandi un messaggio quando non vuoi sparare armi nucleari.

Un intercettatore che non può decifrare i tuoi dati c determinare dalla semplice presenza di un messaggio che si desidera sparare armi nucleari, anche se forse non a chi.

Se il tuo protocollo è più complesso:

1. Tu chiedi un libro.
2. Ti mando il contenuto.

Un utente malintenzionato potrebbe non essere in grado di capire chi sta leggendo "Guerra e pace" vs " Atlas Scrolled " ma può distinguere, basandosi esclusivamente sulla dimensione del messaggio, se stanno leggendo uno dei precedenti romanzi di 55 pagine di Kafka" The Metamorphosis ".

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

L'autenticazione viene eseguita per mezzo di autorità di certificazione (CA). I browser vengono forniti con un elenco di certificati SSL per le chiavi di firma delle CA. Le CA firmano certificati che descrivono la chiave pubblica di un'entità. Ad esempio, se possedessi Google.com, lo dimostrerei a Verisign e loro firmerebbero il mio certificato per un certo periodo di tempo. Problemi con una CA firma un certificato 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 emette qualcosa di nefasto (i 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 (per scopi di discussione) essere sicuro che il certificato corrisponda. In circostanze normali, tale connessione è crittografata. Ciò impedisce a chiunque di leggere i tuoi dati.

I certificati SSL sono molto complessi ed esistono numerosi attacchi contro le implementazioni SSL. Ciò che SSL può fare in modo efficace è impedirmi di guardare il tuo traffico allo Starbucks locale quando controlli la tua posta su GMail. Quello che non può fare è impedirmi di utilizzare un attacco MITM in cui ti inoltro tutto senza SSL e il tuo client non è configurato per infastidirti del fatto che non ha mai avviato una sessione crittografata.

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

Utilizzando protocolli SSL precedenti (2.0) o una chiave di crittografia debole potrebbe esporti a vulnerabilità.

SSL generalmente aumenta la sicurezza fornendo:

1. Autenticazione del server (l'utente sa che sta parlando al sito "corretto")
2. Integrità dei dati (l'utente e il server sapere che il traffico non viene modificato durante il percorso)
3. (facoltativo, ma in genere) Privacy dei dati (l'utente e il server sanno che il traffico non viene intercettato durante il percorso)
4. (facoltativamente , ma raro) Autenticazione client, se anche il client ha 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 se e ma. Nello scenario più tipico, SSL basato su browser, lo schema può essere interrotto in molti casi senza rompere la crittografia o il protocollo, ma semplicemente affidandosi all'utente per fare la cosa sbagliata (cioè ignorare gli avvisi del browser e si connette comunque). Gli attacchi di phishing possono funzionare anche inviando l'utente a un sito protetto SSL fasullo, fatto in modo da assomigliare a quello reale in tutto e per tutto tranne l'URL.

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

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

L'anello debole di questa catena non è quasi certamente SSL, ma l'utente, che generalmente può essere indotto a connettersi a un sito intermedio falso tramite spoofing web / spoofing collegamento ipertestuale o presentando un certificato non valido e ignorando l'avviso del browser e procedendo comunque alla connessione.

Comunque il sistema che descrivi è comunque la migliore pratica, non c'è molto altro che puoi fare (a parte educare i tuoi utenti a prendere seriamente gli avvisi SSL se puoi).

Quando non si utilizza SSL, tutte le comunicazioni possono essere facilmente intercettate: l'unica cosa da fare è avviare lo sniffer di pacchetti (ad esempio Wireshark).
SSL lo impedisce, tutti i pacchetti sono crittografati quindi non c'è nessun modo per sapere cosa stai inviando. Fondamentalmente viene utilizzato per proteggere le password e il contenuto privato dall'intercettazione. Ovviamente non vuoi che qualcun altro legga le tue email private, giusto?
Per quanto riguarda la ricerca su Google, lo hanno fatto semplicemente per nascondere ciò che le persone chiedono. Questo perché alcuni governi ne sono semplicemente troppo curiosi.

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 aziende legittime - autentica il server. Quindi il canale è sicuro e affidabile.

Esistono parecchi certificati SSL, in quanto esistono parecchi servizi PKI. Fondamentalmente un servizio diverso richiede un tipo diverso di certificato SSL. Quindi ci sono certificati per la firma del codice, la crittografia e la firma della posta elettronica, quelli riguardanti ad esempio l'autenticazione del server e così via.

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

Guarda il testo RC4_128 con SHA1 per l'autenticazione del messaggio ECDHE_ECDSA. Si legge:

1. Il server ha offerto il canale SSL RC4_128b con SHA digest
2. All'interno di questo tunnel ogni messaggio è crittografato con curve eclittiche dove la chiave è derivata utilizzando la funzione Diffie-Helman, ed è firmato con cifratura Ecliptic Curves utilizzando 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 uso. Buona fortuna NSA!

@Vladimir ha ragione sul fatto che http://en.wikipedia.org/wiki/Forward_secrecy sia desiderabile, ma ha i dettagli sbagliati. Il server ha scelto questa ciphersuite 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 dell'integrità HMAC-SHA-1. (I nomi Ciphersuite in SSL / TLS fino a poco tempo fa dicevano 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) del handshake che si verifica una volta all'inizio della sessione: ECDHE utilizza la variante Elliptic Curve di Diffie-Hellman in modalità Ephemeral (più alcuni passaggi aggiuntivi non importanti qui) per creare le chiavi di sessione 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 chiavi o altri piccoli accordi segreti.)

È sicuro per l'utente o è sicuro per te? Assumi un attacco man-in-the-middle. L'aggressore riesce a catturare il traffico dell'utente, finge di essere te per l'utente e finge di essere l'utente per te. Questo tipo di attacco di solito fallisce, perché il certificato fornito all'utente non sarebbe corretto. Ad esempio, l'autore dell'attacco fornisce all'utente un certificato autofirmato per il tuo sito web. Tuttavia, se l'utente agisce in modo stupido, può accettare il 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 danneggiano l'utente, è davvero colpa loro e problema loro. E comunque non puoi impedirlo completamente, perché il MITM può escluderti completamente e parlare con l'utente che finge di essere te. Ma se lo snooping e la modifica del traffico ti feriscono, 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 hai una linea non sicura e fai una connessione SSH / SSL riuscita su questa linea, ora ti chiede se è sicuro fare l'ipotesi che la linea è "sicura" e che i dati non crittografati possono essere passati INSIEME alla 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 puoi essere certo che non ci sia alcun intercettatore attivo (MITM), il che significa che puoi stabilire in sicurezza un SSL / non autenticato Connessione SSH con la stessa origine / destinazione della linea autenticata. Ciò a condizione che non ci siano intercettatori selettivi che MITM certi connettori, MA tuttavia, l'intercettatore non può sapere se si intende autenticare la connessione o meno, quindi non può sapere quale connessione a MITM a eludere il rilevamento. Il MITMer, se MITM, MITM tutte le connessioni e sperare che le persone facciano clic su tutte le finestre di dialogo di autenticazione semplicemente.

Quindi: se ti connetti autenticato a un servizio SSL da 123.123.123.123 a 24.24.24.24, tu può anche connettere in modo sicuro un client SSH da 123.123.123.123 a 24.24.24.24 senza autenticare reciprocamente l'impronta digitale SSH, a condizione che ci si possa fidare di tutto ciò che si trova dietro il router NAT o il firewall dell'altro lato.

Ma anche se generalmente significa sicuro , c'è un piccolo rischio che un intercettatore semplicemente casuali connessioni MITM 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 da SSL!

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.