News Ticker

Handshake Failure – Help me !

null

I dati che attraversano una rete possono essere intercettati da parte di terzi non autorizzati.
La necessità di mantenere una comunicazione confidenziale è uno scenario molto importante, specialmente quando i dati da trasmettere sono dati sensibili come password, dati della carta di credito, informazioni bancarie.

Tale esigenza ha reso necessario l’impiego di opportune tecnologie come il Secure Sockets Layer (SSL) e il Transport Layer Security (TLS):
SSL e TLS sono dei protocolli crittografici usati nel campo delle telecomunicazioni e dell’informatica che permettono una comunicazione sicura dal sorgente al destinatario (end-to-end) fornendo autenticazione, integrità dei dati e cifratura operando al di sopra del livello di trasporto.

Senza entrare nello specifico uno scambio di dati tra 2 entità in maniera sicura avviene solo e soltanto se vengono rispettati precisi requisiti citati sopra.
Se da una delle 2 parti non vengono rispettati certi requisiti non verrà creato nessun canale di scambio dati e sui log avremo molto probabilmente un errore di Handshake Failure.

Per avviare un’analisi sul problema possiamo servirci di un comodo strumento: TestSSL.

Questo script, rilasciato in open source, verifica il supporto di SSL/TLS, vulnerabilità, cifrari e molto altro.

Vediamo alcune interessanti feature che vengono proposte:

Verifica di possibili vulnerabilità:

null
Verifica dei protocolli supportati:

null

Verifica del protocollo e dei cifrari preferenziali usati durante la fase di handshake:

null
Verifica della validità del certificato e delle tecnologia usate ( Server Name Indication (SNI) e Self-signed certificate ):

null

Per utilizzarlo è sufficiente scaricare lo script e lanciarlo nel seguente modo:

./testssl.sh <IP o URI da analizzare>

Di seguito un output del comando:

null

Per effettuare un test con una specifica opzione è sufficiente lanciare lo script senza nessun parametro per avere l’elenco completo di tutti i parametri che possiamo utilizzare.

michele@michele-mmul ~ $ ./testssl.sh
 
testssl.sh
 
-h, --help what you're looking at
 -b, --banner displays banner + version of testssl.sh
 -v, --version same as previous
 -V, --local pretty print all local ciphers
 -V, --local which local ciphers with are available?
 (if pattern not a number: word match)</code>
 
testssl.sh URI ("testssl.sh URI" does everything except -E)
 
-e, --each-cipher checks each local cipher remotely
 -E, --cipher-per-proto checks those per protocol
 -f, --ciphers checks common cipher suites
 -p, --protocols checks TLS/SSL protocols
 -S, --server_defaults displays the servers default picks and certificate info
 -P, --preference displays the servers picks: protocol+cipher
 -y, --spdy, --npn checks for SPDY/NPN
 -x, --single-cipher tests matched of ciphers
 (if not a number: word match)
 -U, --vulnerable tests all vulnerabilities
 -B, --heartbleed tests for heartbleed vulnerability
 -I, --ccs, --ccs-injection tests for CCS injection vulnerability
 -R, --renegotiation tests for renegotiation vulnerabilities
 -C, --compression, --crime tests for CRIME vulnerability
 -T, --breach tests for BREACH vulnerability
 -O, --poodle tests for POODLE (SSL) vulnerability
 -Z, --tls-fallback checks TLS_FALLBACK_SCSV mitigation
 -F, --freak tests for FREAK vulnerability
 -A, --beast tests for BEAST vulnerability
 -J, --logjam tests for LOGJAM vulnerability
 -s, --pfs, --fs,--nsa checks (perfect) forward secrecy settings
 -4, --rc4, --appelbaum which RC4 ciphers are being offered?
 -H, --header, --headers tests HSTS, HPKP, server/app banner, security headers, cookie, reverse proxy, IPv4 address
 
special invocations:
 
-t, --starttls does a default run against a STARTTLS enabled
 --xmpphost for STARTTLS enabled XMPP it supplies the XML stream to-'' domain -- sometimes needed
 --mx tests MX records from high to low priority (STARTTLS, port 25)
 --ip a) tests the supplied instead of resolving host(s) in URI
 b) arg "one" means: just test the first DNS returns (useful for multiple IPs)
 --file mass testing option: Just put multiple testssl.sh command lines in ,
 one line per instance. Comments via # allowed, EOF signals end of .
 
partly mandatory parameters:
 
URI host|host:port|URL|URL:port (port 443 is assumed unless otherwise specified)
 pattern an ignore case word pattern of cipher hexcode or any other string in the name, kx or bits
 protocol is one of ftp,smtp,pop3,imap,xmpp,telnet,ldap (for the latter two you need e.g. the supplied openssl)
 
tuning options:
 
--assuming-http if protocol check fails it assumes HTTP protocol and enforces HTTP checks
 --ssl-native fallback to checks with OpenSSL where sockets are normally used
 --openssl use this openssl binary (default: look in $PATH, $RUN_DIR of testssl.sh
 --proxy : connect via the specified HTTP proxy
 --sneaky be less verbose wrt referer headers
 --quiet don't output the banner. By doing this you acknowledge usage terms normally appearing in the banner
 --wide wide output for tests like RC4, BEAST. PFS also with hexcode, kx, strength, RFC name
 --show-each for wide outputs: display all ciphers tested -- not only succeeded ones
 --warnings "batch" doesn't wait for keypress, "off" or "false" skips connection warning
 --color 0: no escape or other codes, 1: b/w escape codes, 2: color (default)
 --debug 1: screen output normal but debug output in temp files. 2-6: see line ~105
 
All options requiring a value can also be called with '=' (e.g. testssl.sh -t=smtp --wide --openssl=/usr/bin/openssl .
 is always the last parameter.
 
Need HTML output? Just pipe through "aha" (Ansi HTML Adapter: github.com/theZiz/aha) like
 
"testssl.sh | aha &gt; output.html"

Di seguito il link del progetto per approfondire e provare le potenzialità di questo tool.

  • Benjamin Sisko

    Bellissimo !