Può (e dovrebbe) TLS essere severo riguardo alle cifre che supporta?

Naviga le tue risposte
6

Quando si tenta di stabilire un canale TLS su outlook.com per inoltrare il traffico SMTP, si verificano errori di connessione e si deve continuare senza crittografia.

Un esempio di tale connessione: 

openssl s_client  -starttls smtp -crlf -connect x-com.mail.eo.outlook.com:25 -CApath /etc/ssl/certs/ -cipher DHE-RSA-AES256-SHA  
CONNECTED(00000003)
139677700306600:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 343 bytes and written 137 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Secondo lo snipet sopra, provo TLS usando DHE-RSA-AES256-SHA. Non dovrebbe esserci una rinegoziazione fino a quando le due parti non si associno e stabiliscano una connessione TLS? Cosa succederebbe se una delle parti non fosse in grado di utilizzare tutti i cifrari e gli algoritmi richiesti?

    
posta George 03.11.2015 - 15:09
fonte

2 risposte

12

Si prega di non confondere la negoziazione TLS con un bazar dove tutte le parti negoziano e rinegoziano fino a quando non trovano una soluzione comune. Dal momento che ogni messaggio ha bisogno di tempo per la consegna, sarebbe troppo lento. Quindi c'è una sola offerta da parte del cliente che include tutti i codici che il cliente è disposto a supportare, nell'ordine preferito dal cliente. Se il server ha il supporto per uno di questi codici, sceglierà il migliore in base alla preferenza di server o client. Se non ci sono sovrapposizioni, la negoziazione fallisce in modo permanente.

Nel tuo caso il server accetta i seguenti codici (come determinato da questo strumento ): 

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-SHA256
AES128-SHA256
AES256-SHA
AES128-SHA
DES-CBC3-SHA

Dato che offri solo un singolo cifrario DHE-RSA-AES256-SHA e questo codice non è supportato dal server, la negoziazione fallisce.

    
risposta data 03.11.2015 - 15:15
fonte
4

Sì, TLS dovrebbe essere severo riguardo alle suite di crittografia che supporta. Senza un'attenta selezione della suite di crittografia, si rischia di negoziare con una suite di crittografia non sicura che potrebbe essere compromessa. Se un'altra parte non supporta una suite di crittografia conforme agli standard e la sicurezza di tale connessione è molto importante, non si dovrebbe consentire al sistema di funzionare con suite di crittografia di qualità inferiore.

Tuttavia, le implementazioni TLS sensate supportano anche più suite di crittografia per aumentare le possibilità di compatibilità con altre parti. Nonostante le molte recenti rivelazioni di punti deboli in vari pacchetti di cifrari, restano ancora molti che sono considerati sicuri. Fintanto che controlli solo un lato della conversazione, sarebbe ridicolo limitare il tuo sistema a supportare solo una suite di crittografia e quindi aspettarti che l'intera Internet funzioni secondo i tuoi standard individuali.

Quello che sta succedendo qui è tu scegli di supportare solo una suite di crittografia e l'altro sistema sceglie non per supportare quello. (Solo il proprietario dell'altro sistema può dire perché, ma suppongo che potrebbe avere qualcosa a che fare con Logjam .) Tuttavia, l'altro il sistema probabilmente supporta diverse altre suite di crittografia che sono ugualmente (se non di più) sicure come quella che hai selezionato. (Sembra che @SteffenUllrich abbia la lista.) Scegli uno di quelli con cui ti trovi comodo e configura il tuo sistema per consentirlo.

O semplicemente non usare TLS per quella connessione.

Oppure non parlare affatto a quel server.

La tua scelta.

    
risposta data 03.11.2015 - 15:43
fonte

Leggi altre domande sui tag

Scansione https Avast C'è un vantaggio di sicurezza da collegare su HTTPS se il certificato non è valido?