Sicurezza delle applicazioni di retesecurity.polito.it/~lioy/03gsd/remote_2x.pdfSSL-3 handshake...

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



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



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



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



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



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)



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.



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



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



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)



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



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



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



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



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



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



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



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



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)



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



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)


TLS, no chiave effimera, client auth

CLIENT SERVER



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



TLS, chiave effimera, no client auth

CLIENT SERVER



3*. certificate (digitalSignature)

4*. server key exchange (signed RSA key or DH exponent)

5. client key exchange (encrypted key or client exponent)





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



TLS, ripresa di una sessione

CLIENT SERVER

1*. client hello (…, session-id X)

2*. server hello (…, session-id X)





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



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



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



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



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



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




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)


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



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



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)



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



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



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.



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



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



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> "]



$ $ 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!



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



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



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

Sicurezza delle applicazioni di retesecurity.polito.it/~lioy/03gsd/remote_2x.pdfSSL-3 handshake...

Documents

Transcript of Sicurezza delle applicazioni di retesecurity.polito.it/~lioy/03gsd/remote_2x.pdfSSL-3 handshake...