Devo dimostrare che le impostazioni di crittografia nella stringa di connessione della nostra app funzionano.Come il traffico di SQL Server è crittografato?
Quale sarebbe il modo più semplice per convalidare il traffico dal nostro sito Web a SQL Server in realtà crittografato?
Si potrebbe usare qualcosa come Wireshark per visualizzare i pacchetti a che stanno trasmessi sulla rete
vorrei impostare la Force Protocol Encryption true e certificati attendibili Server su true nella stringa di connessione db. Il server non dovrebbe riuscire a stabilire una connessione se non può fornire una connessione crittografata come richiesto. C'è un article che copre la crittografia con SQL Server 2005 e versioni successive.
Il test semplice è provare una connessione con e senza crittografia e fallire quando fornisce il tipo di connessione indesiderato. quindi fino a DBA, IT o tu per configurare il server in modo che corrisponda ai tuoi requisiti.
+1 per la tua risposta. Contrariamente all'opzione wireshark, l'ideazione di un test per dimostrare che la connessione non crittografata verrà rifiutata aiuta anche a dimostrare che i requisiti di sicurezza dell'applicazione non possono essere degradati semplicemente modificando le impostazioni sul lato del server del database. –
Sicurezza integrata significa che stai usando l'autenticazione NTLM o Kerberos; non significa che il tuo traffico è crittografato. – Andomar
@andomar è corretto --- Sono a conoscenza che i creds (indipendentemente dalla modalità integrata o mista) sarebbero crittografati --- è il resto del traffico a cui sto pensando. –
È possibile controllare la colonna encrypt_option del DMV sys.dm_exec_connections. In questo modo non puoi solo provare che è crittografato, ma puoi anche convalidare nella tua applicazione all'avvio. Per applicare la crittografia, segui i metodi descritti in questo MSDN How To: Enable Encrypted Connections to the Database Engine. Se il client o il server impone la crittografia e viene fornito un certificato e il client accetta il certificato del server, la connessione verrà crittografata. Per verificare che il traffico sia crittografato, è possibile utilizzare lo strumento integrato netmon.exe (che deve essere installato da componenti di sistema di rimozione/annuncio), scaricare lo strumento migliorato Microsoft Network Monitor 3.2 o altri strumenti di terze parti.
In alternativa, il sito di implementazione può applicare la crittografia IPSec.
+1 per encrypt_option come semplice controllo rapido. Come copia e incolla di una fodera, usa: 'SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@ SPID'. Non dimostra che l'app distribuita utilizza ovviamente la crittografia, ma conferma lo _can_ di SQL Server. – hlascelles
@hlascelles: 'encrypt_option' è un valore after-the-fact. Se dice che è crittografato, significa che l'app * utilizza * il traffico crittografato. In quella sessione, almeno (di solito anche su tutti gli altri). –
Hai ragione. Scusate, stavo arrivando da un punto di vista amministrativo: testare una distribuzione di SQL Server da una workstation (ad es. Verificando i certificati). Come dice @Remus, aggiungi la riga sopra al codice distribuito per un controllo di runtime (usando la clausola WHERE per assicurarti che sia la tua connessione effettiva). – hlascelles
Per garantire che venga utilizzata la crittografia, è necessario enable the force encryption option sul server.
La crittografia lato client non è obbligatoria. Il lato server è obbligatorio.
All'avvio del servizio SQL Server, esso si interrompe se non è in grado di leggere il certificato o vi sono altri ostacoli. Non accetterà connessioni non crittografate.
Per rispondere, ho usato uno sniffer di pacchetti il primo che ho usato per la verifica della crittografia, quindi ho semplicemente fatto affidamento sul fatto che la crittografia lato server è obbligatoria e SQL non verrà avviato.
Tenete a mente che v'è una limitazione della corrente SQL Server se si abilita crittografia sul server. Codifica sarà per tutte le connessioni in entrata. Se si abilita la crittografia sul computer client , tutte le connessioni in uscita da quel client cercano di effettuare una connessione crittografata a qualsiasi SQL Server .
tardo edit:
Utilizzare una versione precedente del client MS JDBC: non può gestire la crittografia lato server ...
Con "è necessario abilitare la crittografia sul server", si intende "è necessario abilitare l'impostazione delle connessioni di crittografia necessarie sul server"? Se l'impostazione non è impostata su true, il server consentirà sia le connessioni crittografate che quelle first-login-packet-only-encrypted. –
@BenGribaudo Una volta attivata la casella di controllo in SQL Server Config, il server accetta solo connessioni crittografate. La crittografia lato server è obbligatoria quando questa è selezionata. Tutti i miei server hanno questo. – gbn
C'è un altro strumento molto sottovalutato da Microsoft stesso: "Microsoft Network Monitor". Fondamentalmente questo è molto simile a wireshark con l'eccezione che alcuni specifici protocolli MS hanno un parser e un supporto di visualizzazione migliori rispetto a wireshark stesso e ovviamente funzionerebbe solo sotto windows ;-).
Lo strumento è piuttosto vecchio e sembra abbandonato (non ha ancora visto una versione più recente) ma fa comunque un buon lavoro e la grammatica per definire nuovi protocolli è abbastanza accurata/interessante - quindi questo possiede ancora molta potenza per il futuro. 
Analisi Esempio - La registrazione viene filtrato per TDS - così gli altri pacchetti vengono discared principalmente:
Questo vale anche per le connessioni server SQL. L'MNM può persino visualizzare i risultati che vanno oltre il filo - abbastanza pulito. Tuttavia wirehark come menzionato sopra sarebbe sufficiente per convalidare la crittografia e i certificati applicati sul filo stesso. Significa che può comprendere completamente il TDS-Protocoll.
Handling TLS
anche con l'estensione (cosiddetti esperti) 'NmDecrypt' e dei certificati di destra (tra cui le chiavi private) - è possibile decifrare protocolls - molto bello per TDS che utilizza TLS Dentro TDS - non c'è da meravigliarsi - nessuno ha veramente realizzato che ancora come protocoll pienamente supportato per Wireshark;)
collegamenti per gli strumenti:
+1 Questo è un grande strumento per questo. – BenAlabaster
+1, ciao-ciao alla mia risposta in ritardo. – karim79
Un altro +1 per Wireshark. Questo è esattamente ciò che uso per dimostrarlo ai clienti quando chiedono se qualcosa è sicuro. –