sicurezza delle applicazioni di retesecurity.polito.it/~lioy/03gsd/remote_2x.pdfssl-3 handshake...
Post on 03-Aug-2019
214 Views
Preview:
TRANSCRIPT
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 1
Sicurezza delle applicazioni di rete
Antonio Lioy
< lioy @ polito.it >
Politecnico di Torino
Dip. Automatica e Informatica
Situazione standard
autenticazione debole:
username e password
problema: password snooping
indirizzo IP (server web; comandi R = rsh, rlogin, rcp, ...)
problema: IP spoofing
altri problemi frequenti:
data snooping / forging
shadow server / MITM
replay, cancellazione
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 2
Sicurezza di canale
protezione solo durante il transito nel canale (es. autenticazione singola o mutua, integrità, segretezza, …)
nessuna possibilità di non ripudio
richiede poca (o nulla) modifica alle applicazioni
. . . 01 00 11 . . .
01 00 01 00
01 00
Sicurezza di messaggio (o dei dati)
protezione auto-contenute nel messaggio (es. autenticazione del mittente, integrità, segretezza)
possibilità di non ripudio
richiede modifica alle applicazioni
01
01 00
00 11
01 00
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 3
Sicurezza interna alle applicazioni
ogni applicazione implementa la sicurezza al proprio interno
la parte in comune si limita ai canali di comunicazione (socket)
possibili errori di implementazione (inventare protocolli di sicurezza non è semplice!)
interoperabilità non garantita
canale logico (socket)
TCP
IP
sec
APP #1
sec
APP #N. . .
rete
Sicurezza esterna alle applicazioni
il livello sessione sarebbe ideale per implementare molte funzioni di sicurezza
… ma non esiste in TCP/IP!
è stato proposto un livello “sessione sicura”:
semplifica il lavoro degli sviluppatori applicativi
evita possibili errori di implementazione
a scelta dell’applicazione
canale logico (socket)
TCP
IP
canale logico sicuro
APP #1 . . .
rete
sec
APP #N
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 4
Protocolli di sicurezzaorientati al canale di comunicazione
SSL / TLS
il più diffuso al mondo
SSH
ha avuto un momento di gloria (legato ai divieti di esportazione USA), ma oggi è una soluzione di nicchia
PCT
proposto da MS come alternativa a SSL
uno dei pochi fiaschi di MS!
SSL (Secure Socket Layer)
proposto da Netscape Communications
protocollo di trasporto sicuro (circa livello sessione):
autenticazione (server, server+client)
riservatezza dei messaggi
autenticazione ed integrità dei messaggi
protezione da replay e da filtering
applicabile facilmente a tutti i protocolli basati su TCP:
HTTP, SMTP, NNTP, FTP, TELNET, ...
es. famoso HTTP sicuro (https://....) = 443/TCP
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 5
Porte ufficiali per applicazioni SSL
nsiiops 261/tcp # IIOP Name Service over TLS/SSLhttps 443/tcp # http protocol over TLS/SSLsmtps 465/tcp # smtp protocol over TLS/SSL (was ssmtp)nntps 563/tcp # nntp protocol over TLS/SSL (was snntp)imap4-ssl 585/tcp # IMAP4+SSL (use 993 instead)sshell 614/tcp # SSLshellldaps 636/tcp # ldap protocol over TLS/SSL (was sldap)ftps-data 989/tcp # ftp protocol, data, over TLS/SSLftps 990/tcp # ftp protocol, control, over TLS/SSLtelnets 992/tcp # telnet protocol over TLS/SSLimaps 993/tcp # imap4 protocol over TLS/SSLircs 994/tcp # irc protocol over TLS/SSLpop3s 995/tcp # pop3 protocol over TLS/SSL (was spop3)msft-gc-ssl 3269/tcp # MS Global Catalog with LDAP/SSL
SSL - autenticazione e integrità
peer authentication all’apertura del canale:
il server si autentica presentando la propria chiave pubblica (certificato X.509) e subendo una sfida asimmetrica implicita
l’autenticazione del client (con chiave pubblica, certificato X.509 e sfida esplicita) è opzionale
per l’autenticazione e l’integrità dei dati scambiati il protocollo prevede:
un keyed digest (MD5 o SHA-1)
un MID per evitare replay e cancellazione
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 6
SSL - riservatezza
il client genera una session key usata per la cifratura simmetrica dei dati (RC2, RC4, DES, 3DES, IDEA, AES, …)
la chiave viene comunicata al server o concordata tramite crittografia a chiave pubblica (RSA, DH o Fortezza-KEA)
SSL – schema concettuale
(1) https://www.polito.it/
(3) cert (www.polito.it)
(4) cert (utente)
(2) configurazione di sicurezza
serverWeb
sicurobrowser(3bis) server challenge / response
(4bis) client challenge / response
(5) canale sicuro (SSL)
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 7
Architettura di SSL-3
SSL record protocol
reliable transport protocol (es. TCP)
network protocol (es. IP)
SSLhandshake
protocol
SSLchange cipherspec protocol
SSLalert
protocol
applicationprotocol
(es. HTTP)
Session-id
Tipica transazione Web:
1. open, 2. GET page.htm, 3. page.htm, 4. close
1. open, 2. GET home.gif, 3. home.gif, 4. close
1. open, 2. GET logo.gif, 3. logo.gif, 4. close
1. open, 2. GET back.jpg, 3. back.jpg, 4. close
1. open, 2. GET music.mid, 3. music.mid, 4. close
Se ogni volta si devono rinegoziare i parametri crittografici per SSL, il collegamento si appesantisce molto.
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 8
Session-id
per evitare di ri-negoziare ad ogni connessione i parametri crittografici, il server SSL può offrire un session identifier (ossia più connessioni possono far parte della stessa sessione logica)
se il client, all’apertura della connessione, presenta un session-id valido si salta la fase di negoziazione e si procede subito col dialogo SSL
il server può rifiutare l’uso del session-id (in assoluto o dopo un certo tempo dalla sua emissione)
SSL con session-ID
(1) https://www.polito.it/
(1bis) session-ID
(5) canale sicuro (SSL)
serverWeb
sicurobrowser
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 9
SSL / TLS: sessioni e connessioni
sessione SSL
associazione logica tra client e server
creata dal protocollo di handshake
definisce un insieme di parametri crittografici
è usata da una o più connessioni SSL (1:N)
connessione SSL
un canale SSL temporaneo tra client e server
associata ad una specifica sessione SSL (1:1)
sessioni connessioni
SSL-3 / TLS record protocol
dati applicativi
compressione
F1 F2frammentazione
header H
cifratura
padding MAC P
calcolo del MAC MAC
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 10
TLS-1.0 record format
uint8 type = change_cipher_spec (20), alert (21), handshake (22), application_data (23)
uint16 version = major (uint8) + minor (uint8)
uint16 length:
<= 2**14(record non compressi)per compatibilità con SSL-2
<= 2**14 + 1024(record compressi)
major minor
type
length
. . .fragment [ length ]
. . .
TLS - calcolo del MAC
MAC = message_digest ( key, seq_number ||type || version || length || fragment )
message_digest
dipende dall’algoritmo scelto
key
sender-write-key o receiver-read-key
seq_number
intero a 64 bit (mai trasmesso ma calcolato implicitamente)
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 11
Problemi di SSL-2
P1) nella versione esportazione, riduce senza motivo la chiave di autenticazione a 40 bit (stessa lunghezza della chiave di cifratura)
P2) MAC debole (keyed-digest custom)
P3) i byte di padding sono inclusi nel calcolo del MAC … ma la lunghezza del padding non lo è!
ciò permette ad un attaccante attivo di cancellare byte alla fine dei messaggi
P4) ciphersuite rollback attack – poiché l’handshake non è autenticato, un attaccante attivo può cambiare le ciphersuite nei messaggi di Hello per forzare l’uso di cifratura debole (minimo 40 bit, perché la cifratura è obbligatoria in SSL-2)
SSL-3: soluzioni ai problemi di SSL-2
S1) usa chiavi di autenticazione a 128 bit, anche con chiavi di cifratura da 40 bit
S2) usa HMAC (più forte del keyed digest custom usato in SSL-2)
S3) cambia l’ordine di MAC e padding
S4) l’handshake è autenticato (tranne i messaggi Change Cipher Spec) tramite i messaggi Finished
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 12
SSL-3: novità rispetto a SSL-2
compressione dei dati:
opzionale
prima della cifratura (dopo non serve …)
opzionalità della cifratura dei dati:
per avere solo autenticazione e integrità
possibilità di rinegoziare la connessione:
cambio periodico delle chiavi
cambio degli algoritmi
SSL-3 handshake protocol
concordare una coppia di algoritmi per confidenzialità ed integrità
scambiare dei numeri casuali tra client e server per la successiva generazione delle chiavi
stabilire una chiave simmetrica tramite operazioni a chiave pubblica (RSA, DH o Fortezza)
negoziare il session-id
scambiare i certificati necessari
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 13
Protezione dei dati
chiaveper MAC
numerodi sequenza
dati[ compressi ]
datiprotetti
MAC
IV
chiave percifrare
generazionedel MAC
cifraturasimmetrica
padding
Rapporto tra chiavi e sessioni(tra il server ed uno stesso client)
pre-master secret( stabilito con PKC )
master secret
client randomserver random
chiavi per MACchiavi per cifrare
IV per cifrare
generatiad ogni connessione
comunea più connessioni
diverseper ogni connessione
comunea più connessioni
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 14
Meccanismi “effimeri”
chiavi usa-e-getta generate al volo:
per avere autenticazione devono essere firmate (es. devo avere un certificato X.509)
DH adatto, RSA lento
compromesso per RSA = riuso N volte
perfect forward secrecy:
chi conosce la chiave privata può decifrare tutte le sessioni
con meccanismi effimeri la chiave privata del server viene usata solo per firma
CLIENT
SERVER
client hello
server key exchange
certificate request
certificate
server hello
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 15
CLIENT
SERVER
certificate
client key exchange
certificate verify
change cipher spec
change cipher spec
finished
finished
Client hello
versione di SSL preferita dal client
28 byte pseudo-casuali (Client Random)
un identificatore di sessione (session-id)
0 per iniziare una nuova sessione
diverso da 0 per chiedere di riesumare una sessione precedente
elenco delle “cipher suite” (=algo di cifratura + scambio chiavi + integrità) supportate dal client
elenco dei metodi di compressione supportati dal client
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 16
Server hello
versione di SSL scelta dal server
28 byte pseudo-casuali (Server Random)
un identificatore di sessione (session-id)
nuovo session-id se session-id=0 nel client-hello oppure rifiuta il session-id proposto dal client
session-id proposto dal client se il server accetta di riesumare la sessione
“cipher suite” scelta dal server
dovrebbe essere la più forte in comune col client
metodo di compressione scelto dal server
Cipher suite
algoritmo di scambio chiavi
algoritmo di cifratura simmetrico
algoritmo di hash (per il MAC)
esempi:
SSL_NULL_WITH_NULL_NULL
SSL_RSA_WITH_NULL_SHA
SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
SSL_RSA_WITH_3DES_EDE_CBC_SHA
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 17
Certificate (server)
certificato per server authentication
il subject / subjectAltName deve coincidere con l’identità del server (nome DNS, indirizzo IP, ...)
può essere solo di firma od anche per cifratura
descritto nel campo keyUsage
se è solo per firma allora è poi necessaria la fase server-key exchange
Certificate request
serve per autenticazione del client
specifica anche la lista delle CA che il server ritiene fidate
i browser mostrano all’utente per il collegamento solo i certificati emessi da CA fidate
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 18
Server key exchange
contiene la chiave pubblica (per scambio chiave) del server, firmato dal server stesso
richiesto solo nei seguenti casi:
server ha certificato RSA solo per firma
si usa DH anonimo o effimero per stabilire il pre-master-secret
ci sono problemi di export e si devono usare chiavi RSA/DH temporanee
Fortezza
importante: unico messaggio con firma esplicita del server
Certificate (client)
trasporta il certificato per la client authentication
il certificato deve essere stato emesso da una delle CA fidate elencate dal server nel messaggio Certificate Request
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 19
Client key exchange
varie possibilità
pre-master secret cifrato con la chiave pubblica RSA del server (temporanea o dal certificato)
parte pubblica di DH
Fortezza
Certificate verify
prova esplicita di firma
hash calcolato su tutti i messaggi di handshake che precedono questo e firmato con la chiave privata del client
solo in caso di client authentication (per evitare impostori)
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 20
Change cipher spec
provoca l’aggiornamento degli algoritmi da usare per la protezione
permette di passare dai messaggi precedenti in chiaro all’uso nei messaggi successivi degli algoritmi appena negoziati
a rigore fa parte di un protocollo specifico e non dell’handshake
varie analisi indicano come sia eliminabile
Finished
primo messaggio protetto con gli algoritmi negoziati
fondamentale per autenticare tutto lo scambio
contiene un MAC calcolato su tutti i messaggi di handshake precedenti (escluso change cipher spec) tramite l’uso del master secret
evita attacchi man-in-the-middle di tipo rollback (version downgrade o ciphersuite downgrade)
differenziato per client e server
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 21
TLS, no chiave effimera, no client auth
CLIENT SERVER
1. client hello (ciphersuite list, client random)
2. server hello (ciphersuite, server random)
3. certificate (keyEncipherment)
4. client key exchange (key encrypted for server)
5. change cipher spec (activate protection on client side)
6. finished (MAC of all previous messages)
7. change cipher spec (activate protection on server side)
8. finished (MAC of all previous messages)
TLS, no chiave effimera, client auth
CLIENT SERVER
1. client hello (ciphersuite list, client random)
2. server hello (ciphersuite, server random)
3. certificate (keyEncipherment)
4*. certificate request (cert type, list of trusted CAs)
5*. certificate (client cert chain)
6. client key exchange (encrypted key)
7*. certificate verify (signed hash of previous messages)
8+9. change cipher spec + finished
10+11. change cipher spec + finished
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 22
TLS, chiave effimera, no client auth
CLIENT SERVER
1. client hello (ciphersuite list, client random)
2. server hello (ciphersuite, server random)
3*. certificate (digitalSignature)
4*. server key exchange (signed RSA key or DH exponent)
5. client key exchange (encrypted key or client exponent)
6. change cipher spec (activate protection on client side)
7. finished (MAC of all previous messages)
8. change cipher spec (activate protection on server side)
9. finished (MAC of all previous messages)
TLS, scambio dati e chiusura canale
CLIENT SERVER
(… handshake …)
N. client data (MAC, [ encryption ] )
N+1. server data (MAC, [ encryption ] )
… … …
LAST-1. alert close notify
LAST. alert close notify
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 23
TLS, ripresa di una sessione
CLIENT SERVER
1*. client hello (…, session-id X)
2*. server hello (…, session-id X)
3. change cipher spec (activate protection on client side)
4. finished (MAC of all previous messages)
5. change cipher spec (activate protection on server side)
6. finished (MAC of all previous messages)
TLS 1.0 (SSL 3.1)
Transport Layer Security
standard IETF:
TLS-1.0 = RFC-2246 (gennaio 1999)
TLS-1.0 = SSL-3.1 (al 99% coincide con SSL-3)
enfasi su algoritmi crittografici e di digest standard (non proprietari); supporto obbligatorio:
DH + DSA + 3DES
HMAC-SHA1
... ossia la ciphersuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 24
TLS 1.1 (SSL 3.2)
RFC-4346 (aprile 2006)
per proteggere da attacchi (*) contro CBC:
IV implicito rimpiazzato da IV esplicito
errori di padding ora usano il messaggio di alert bad_record_mac (invece di decryption_failed)
registrazione IANA dei parametri del protocollo
una chiusura prematura del canale non implica più che non si possa riprendere la sessione
note addizionali per chiarire vari possibili attacchi
(*) S.Vaudenay, “Security flaws induced by CBC padding – applicationsto SSL, IPSEC, WTLS ...”, LNCS-2332, pp. 534-545, 2002
TLS 1.2 (SSL 3.3)
RFC-5246 (agosto 2008)
ciphersuite specifica anche la PRF(pseudo-random function)
uso esteso di SHA-256 (es. in Finished, HMAC)
supporto per authenticated encryption(AES in modo GCM o CCM)
incorpora le estensioni (RFC-4366) e le AES ciphersuite (RFC-3268)
default ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA
deprecate le ciphersuite con IDEA e DES
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 25
Evoluzione di TLS (I)
ciphersuites / encryption:
(RFC-3268) AES
(RFC-4492) ECC
(RFC-4132) Camellia
(RFC-4162) SEED
(RFC-6209) ARIA
ciphersuites / authentication:
(RFC-2712) Kerberos
(RFC-4279) pre-shared key (secret, DH, RSA)
(RFC-5054) SRP (Secure Remote Password)
(RFC-6091) OpenPGP
Evoluzione di TLS (II)
compressione:
(RFC-3749) compression methods + Deflate
(RFC-3943) protocol compression using LZS
altro:
(RFC-4366) extensions (specific and generic)
(RFC-4681) user mapping extensions
(RFC-5746) renegotiation indication extensions
(RFC-5878) authorization extensions
(RFC-6176) prohibiting SSL-2
(RFC-4507) session resumption w/o server state
(RFC-4680) handshake with supplemental data
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 26
TLS e server virtuali: problema
server virtuale (frequente in caso di web hosting)
diversi nomi logici associati allo stesso indirizzo IP
es. libri.myweb.it=1.2.3.4, food.myweb.it =1.2.3.4
facile in HTTP/1.1
il client usa l’header Host per identificare il server a cui vuole collegarsi
… ma difficile con HTTPS
perché TLS è attivato prima di HTTP
quale certificato usare? (deve contenere il nome del server)
TLS e server virtuali: soluzioni
certificato collettivo (wildcard)
es. CN=*.myweb.it
chiave privata condivisa tra tutti i server
trattato in modo diverso dai vari browser
certificato con elenco di server in subjectAltName
chiave privata condivisa tra tutti i server
occorre ri-emettere il certificato ad ogni aggiunta o cancellazione di un server
usare estensione SNI (Server Name Indication)
in ClientHello (permesso da RFC-4366)
supporto limitato da parte di browser e server
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 27
Estensione ALPN(Application–Layer Protocol Negotiation) RFC-7301
negozia il protocollo applicativo (per TLS-then-proto) per velocizzare la creazione della connessione, evitando round-trip addizionali per la negoziazione applicativa
(ClientHello) ALPN=true + lista protocolli appllicativisupportati
(ServerHello) ALPN=true + protocollo app. scelto
importante per negoziare HTTP/2 e QUIC
Chrome e Firefox supportano HTTP/2 solo su TLS
utile anche se server usa certificati diversi per i differenti protocolli applicativi
DTLS
Datagram Transport Layer Security (RFC-4347)
applica i concetti di TLS alla sicurezza dei datagrammi (es. UDP)
non offre tutti i servizi di sicurezza di TLS
in competizione con IPsec e sicurezza applicativa
esempio – sicurezza di SIP:
con IPsec
con TLS (solo per SIP_over_TCP)
con DTLS (solo per SIP_over_UDP)
con secure SIP
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 28
Heartbleed
RFC-6520 = TLS/DTLS Heartbeat Extension
tenere una connessione aperta senza rinegoziare continuamente una sessione SSL (DTLS!)
anche utile in PMTU discovery
CVE-2014-0160 = openssl bug (buffer over-read)
server TLS risponde con più dati (sino a 64kB) di quanti inviati nella richiesta di heartbeat
si veda http://xkcd.com/1354/
attaccante può ottenere dati sensibilipresenti in quel blocco di RAM, qualiuser+pwd e/o chiave privata del server(se non si usa un HSM)
Altri attacchi contro SSL/TLS (1)
CRIME (2012) un attaccante con l'abilità di
(a) iniettare chosen plaintext nelle richieste(b) misurare la dimensione del traffico cifrato
può recuperare specifiche parti del plaintext sfruttando informazioni deducibili dalla compressione
BREACH (2013) deduce un segreto contenuto nelle risposte HTTP fornite da un server che
(a) usa compressione HTTP (b) inserisce input utente nelle risposte HTTP (c) riflette un segreto (es. un token CSRF) nelle risposte HTTP
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 29
Altri attacchi contro SSL/TLS (2)
BEAST (Browser Exploit Against SSL/TLS) 2011
canale SSL che usa CBC con IV concatenati
un MITM può decifrare gli header HTTP usando un attacco blockwise-adaptive chosen-plaintext
permette di decifrare richieste HTTPS e rubare informazioni quali i cookie di sessione
POODLE (Padding Oracle On Downgraded Legacy Encryption) è un attacco MITM che sfrutta un fallback a SSL3 per decifrare i dati
POODLE, variante dic-2014, sfrutta errori in CBC in TLS1.0-1.2 (quindi anche se si disabilita SSL3)
Altri attacchi contro SSL/TLS (3)
FREAK (Factoring RSA Export Keys) 2015
downgrade a chiavi RSA export-level
quindi fattorizzazione e decifratura del canale
SSLv3 disabilitato su molti browser (es. da FX34) o disabilitabile
FX/SM : security.tls.version.min = 1(cioè TLS1.0, alias SSL3.1)
… ma SSLv3 necessario per IE6 (ultima versione disponibile per Windows-XP) e TLS indispensabile
testare browser/server coi test Qualys SSL labs
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 30
Il problema di downgrade in TLS (I)
client invia (in ClientHello) la versione più alta supportata
il server notifica al client (in ServerHello) la versione da usare (la più alta in comune)
negoziazione normale delle versione:
accordo su TLS-1.2
(C > S) 3,3
(S > C) 3,3
fallback a TLS-1.1 (es. il server non supporta TLS-1.2)
(C > S) 3,3
(S > C) 3,2
Il problema di downgrade in TLS (II)
downgrade (insicuro):
alcuni server non mandano la risposta corretta ma chiudono direttamente la connessione …
in questo caso il client non ha altra scelta che tentare di nuovo con un numero di versione inferiore
attacco di downgrade:
l'attaccante invia una falsa risposta del server, per forzare ripetutamente il downgrade sino a raggiungere una versione vulnerabile (es. SSL-3) …
per poi eseguire un attacco appropriato (es. Poodle)
non è sempre un attacco (es. connessione col server interrotta prematuramente per un problema di rete)
61
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 31
TLS Fallback SignalingCipher Suite Value (SCSV)
RFC-7507
per prevenire attacchi di downgrade del protocollo
nuova ciphersuite (dummy) TLS_FALLBACK_SCSV
DOVREBBE essere inviata dal client quando apre una connessione downgraded (come ultima nella lista delle ciphersuite)
nuovo valore di Alert fatale "inappropriate_fallback"
DEVE essere inviato dal server quando riceve TLS_FALLBACK_SCSV con una versione più bassa di quella massima che lui supporta
il canale deve poi essere chiuso ed il client dovrebbe riprovare col suo numero di versione più alto
SCSV – note
molti server non supportano ancora SCSV
… ma la maggior parte dei server hanno corretto il loro comportamento errato quando il client richiede una versione più alta di quella che il server supporta
… così ora i browser possono disabilitare il downgrade insicuro
Firefox (dal 2015) e Chrome (dal 2016)
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 32
Sicurezza di HTTP
meccanismi di sicurezza definiti in HTTP/1.0:
“address-based” = il server controlla l’accesso in base all’indirizzo IP del client
“password-based” (o Basic Authentication Scheme) = accesso limitato da username e password, codificate con Base64
entrambi gli schemi sono altamente insicuri(perché HTTP suppone che sia sicuro il canale!)
HTTP/1.1 introduce “digest authentication” basatasu sfida simmetrica
RFC-2617 “HTTP authentication: basic and digestaccess authentication”
HTTP - Basic Authentication
GET /path/alla/pagina/protetta
HTTP/1.0 401 Unauthorized - authentication failed
WWW-Authenticate: Basic realm="POLITO – didattica"
Authorization: Basic czEyMzQ1NjpTZWdyZXRpc3NpbWE=
HTTP/1.0 200 OKServer: Apache/1.3Content-type: text/html
<html> ... pagina protetta ... </html>
$ echo czEyMzQ1NjpTZWdyZXRpc3NpbWE= | openssl enc –a –d
s123456:Segretissima
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 33
HTTP digest authentication
RFC-2069
tecnicamente obsoleto
ma considerato come caso base in RFC-2617
calcolo del keyed-digest:
HA1 = md5 ( A1 ) = md5 ( user ":" realm ":" pwd )
HA2 = md5 ( A2 ) = md5 ( method ":" URI )
response = md5 ( HA1 ":" nonce ":" HA2 )
usa un server nonce per evitare replay
il server di autenticazione può inserire un campo "opaque" per trasportare informazioni di stato (es. token SAML) verso il server del contenuto
HTTP digest authenticationGET /private/index.html HTTP/1.1
HTTP/1.0 401 Unauthorized - authentication failed
WWW-Authenticate: Digest realm="POLITO",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
Authorization: Digest username="lioy",realm="POLITO",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",uri="/private/index.html",response="32a8177578c39b4a5080607453865edf",opaque="5ccc069c403ebaf9f0171e9517f40e41"
HTTP/1.1 200 OKServer: NCSA/1.3Content-type: text/html
<HTML> pagina protetta ... </HTML>
pwd=antonio
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 34
HTTP e SSL/TLS
due alternative:
“TLS then HTTP”(RFC-2818 – HTTP over TLS)
“HTTP then TLS”(RFC-2817 – upgrading to TLS within HTTP/1.1)
nota: “SSL then HTTP” usato ma non documentato
non equivalenti e con impatto su applicazioni, firewall e IDS
concetti applicabili in generale a tutti protocolli:
“SSL/TLS then proto” vs. “proto then TLS”
Client authentication SSLa livello applicativo
tramite la client authentication è possibile identificare l’utente che ha aperto un canale (senza richiedergli username e password)
alcuni server web permettono di fare un mapping (semi-)automatico tra credenziali estratte dal certificato X.509 e utenti del servizio HTTP e/o del S.O.
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 35
Autenticazione nelle applicazioni web
più in basso si fà il controllo e meno parti si espongono agli attacchi
inutile ripetere l’autenticazione (id propagabile)
applicazione ASP, PHP, JSP(application server)
canale HTTP(server web)
canale SSL(libreria)
SSL client-auth. (X.509)
HTTP basic/digestauthentication
autenticazioneapplicativa
mapping
Username e password in un form?
tecnicamente, non importa la sicurezza della pagina in cui si introducono i dati
http://www.ecomm.it/login.html
… perché la sicurezza effettiva dipende dalla URI del metodo usato per inviare username e password al server
<form … action=“https://www.ecomm.it/login.asp”>
… ma psicologicamente è importante la sicurezza della pagina in cui si introducono i dati perché pochi utenti hanno le conoscenze tecniche necessarie a verificare la URI del metodo usato per l’invio
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 36
HTTP Strict Transport Security (HSTS)
RFC-6797
HTTP server indica che la sua interazione con UA deve essere solo tramite HTTPS
previene protocol downgrade e cookie hijacking
valido solo su risposte HTTPS
scadenza rinnovata ad ogni accesso
può includere sottodomini (consigliato)
può essere pre-caricato
pericoloso (HTTPS o niente) e rimozione difficile
preload lista mantenuta da Google ed usata da tutti i browser = https://hstspreload.org/
HSTS – sintassi ed esempiStrict-Transport-Security:
max-age = <expire-time-in-seconds>
[ ; includeSubDomains ]
[ ; preload ]
$ curl –s –D- https://www.paypal.com/ | fgrep –i strict
strict-transport-security: max-age=63072000
$ curl –s –D- https://accounts.google.com/ | grep –istrict
strict-transport-security: max-age=31536000; includeSubDomains
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 37
HTTP Public Key Pinning (HPKP)
RFC-7469
sito HTTPS specifica il digest della propria chiave pubblica e/o di una o più CA della propria catena (tranne la root!)
UA prende nota e rifiuta di collegarsi a sito con chiave diversa
pericolo se si perde il controllo della chiave
problema quando si deve cambiare chiave
includere sempre almeno una chiave di backup
URI per riportare violazioni
modalità enforcing o report-only
HPKP– sintassi ed esempiPublic-Key-Pins:
pin-sha256 = " <base64-sha256-of-public-key> ";
max-age = <expireTime-in-seconds>
[; includeSubDomains]
[; report-uri = " <reportURI> "]
Public-Key-Pins-Report-Only:
pin-sha256 = " <base64-sha256-of-public-key> ";
max-age = <expireTime-in-seconds>
[; includeSubDomains]
[; report-uri = " <reportURI> "]
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 38
$ $ curl -s -D - https://scotthelme.co.uk/| fgrep -i public-key
public-key-pins:pin-sha256="9dNiZZueNZmyaf3pTkXxDgOzLkjKvI+Nza0ACF5IDwg="; pin-sha256="X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg="; pin-sha256="V+J+7lHvE6X0pqGKVqLtxuvk+0f+xowyr3obtq8tbSw="; pin-sha256="9lBW+k9EF6yyG9413/fPiHhQy5Ok4UI5sBpBTuOaa/U="; pin-sha256="ipMu2Xu72A086/35thucbjLfrPaSjuw4HIjSWsxqkb8="; pin-sha256="+5JdLySIa9rS6xJM+2KHN9CatGKln78GjnDpf4WmI3g="; pin-sha256="MWfCxyqG2b5RBmYFQuLllhQvYZ3mjZghXTRn9BL9q10="; includeSubDomains; max-age=2592000;report-uri="https://scotthelme.report-uri.com/r/d/hpkp/
enforce"
public-key-pins-report-only:pin-sha256="X3pGTSOuJeEVw989IJ/cEtXUEmy52zs1TZQrU06KUKg="; pin-sha256="Vjs8r4z+80wjNcr1YKepWQboSIRi63WsWXhIMN+eWys="; pin-sha256="IQBnNBEiFuhj+8x6X8XLgh01V9Ic5/V3IRQLNFFc7v4="; max-age=2592000;report-uri="https://scotthelme.report-uri.com/r/d/hpkp/
reportOnly"
Sistemi di pagamento elettronico
fallimento della moneta elettronica per problemi tecnici e normativi (es. bancarotta di DigiCash)
fallimento di un protocollo specifico per i pagamenti (SET, Secure Electronic Transactions) per problemi tecnici ed organizzativi
attualmente il metodo più usato è la trasmissione del numero di carta di credito su canale TLS ...
... che però non garantisce contro le frodi: alacunianni fa VISA Europa ha dichiarato che il 50% dei tentativi di frode nascono da transazioni Internet, che però sono solo il 2% del suo volume d’affari!
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 39
mondo finanziario
Architettura di pagamento via Web
cardholder merchant
POSvirtuale
paymentnetwork
1. offerta
2. ordine
Internet
paymentgateway
Pagamento con carta di credito via Web
ipotesi base:
l’acquirente possiede una carta di credito
l’acquirente ha un browser con SSL
conseguenze:
la sicurezza effettiva dipende dalla configurazione sia del server sia del client
il payment gateway ha tutte le informazioni (pagamento + merce) mentre il merchant ha solo le informazioni sulla merce
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 40
PCI DSS
Payment Card Industry Data Security Standard
oggi richiesto da tutte le carte di credito per transazioni Internet
molto più prescrittivo rispetto ad altre norme di sicurezza (es. HIPAA = Health Insurance Portability and Accountability Act)
https://www.pcisecuritystandards.org
v2.0 = ott 2010
v3.0 = nov 2013
v3.1 = apr 2015 (no SSL o "vecchio" TLS)
v3.2 = apr 2016 (MFA, test funzioni/procedure, descrizione architettura, …)
Requisiti PCI DSS (I)
costruire e mantenere una rete protetta:
R1 = installare e mantenere una configurazione con firewall per proteggere i dati dei titolari delle carte
R2 = non usare password di sistema predefinite o altri parametri di sicurezza impostati dai fornitori
proteggere i dati dei titolari delle carte:
R3 = proteggere i dati dei titolari delle carte memorizzati
R4 = cifrare i dati dei titolari delle carte quando trasmessi attraverso reti pubbliche aperte
La sicurezza delle applicazioni di rete (remote - nov'18)
© Antonio Lioy - Politecnico di Torino (1995-2018) 41
Requisiti PCI DSS (II)
rispettare un programma per la gestione delle vulnerabilità
R5 = usare e aggiornare con regolarità l’antivirus
R6 = sviluppare e mantenere applicazioni e sistemi protetti
implementare misure forti per il controllo accessi
R7 = limitare l’accesso ai dati dei titolari delle carte solo se effettivamente indispensabili per lo svolgimento dell’attività commerciale
R8 = dare un ID univoco ad ogni utente del SI
R9 = limitare la possibilità di accesso fisico ai dati dei titolari delle carte
Requisiti PCI DSS (III)
monitorare e testare le reti con regolarità
R10 = monitorare e tenere traccia di tutti gli accessi effettuati alle risorse della rete e ai dati dei titolari delle carte
R11 = eseguire test periodici dei processi e dei sistemi di protezione
adottare una Politica di Sicurezza
R12 = adottare una Politica di Sicurezza
top related