Sicurezza degli accessi remoti Sicurezza degli

Transcript

La sicurezza degli accessi remoti
(remote - gen'01)
Situazione standard
Sicurezza
Sicurezza degli
degli accessi
accessi remoti
remoti
■
Antonio Lioy
< lioy @ polito.it >
■
■
Politecnico di Torino
Dip. Automatica e Informatica
Sicurezza orientata al canale di
comunicazione
Protocolli:
■ SSL / TLS
■ SSH
■ ad-hoc (es. deslogin, stel)
■ PCT
SSL (Secure Socket Layer)
■
■
■
proposto da Netscape Communications
protocollo di trasporto sicuro (circa livello
sessione):
■ crittografia simmetrica dei messaggi
■ autenticazione (server, server+client)
■ integrità dei messaggi
■ protezione da replay e da filtering
applicabile facilmente a HTTP, SMTP, NNTP, FTP,
TELNET, ...
■ HTTP sicuro (https://....) = TCP/443
■ NNTP sicuro = TCP/563
Porte ufficiali per applicazioni SSL
nsiiops
261/tcp # IIOP Name Service over TLS/SSL
https
443/tcp # http protocol over TLS/SSL
smtps
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 # SSLshell
ldaps
636/tcp # ldap protocol over TLS/SSL (was sldap)
ftps-data 989/tcp # ftp protocol, data, over TLS/SSL
ftps
990/tcp # ftp protocol, control, over TLS/SSL
telnets
992/tcp # telnet protocol over TLS/SSL
imaps
993/tcp # imap4 protocol over TLS/SSL
ircs
994/tcp # irc protocol over TLS/SSL
pop3s
995/tcp # pop3 protocol over TLS/SSL (was spop3)
msft-gc-ssl 3269/tcp # MS Global Catalog with LDAP/SSL
© Antonio Lioy - Politecnico di Torino (1995-2001)
autenticazione ed autorizzazione basate su
password
■ problema: password snooping
autenticazione basata su indirizzo IP (server
WWW; comandi R: rsh, rlogin, rcp, ...)
■ problema: IP spoofing
problemi generali:
■ data snooping
■ shadow server
SSL - autenticazione e integrità
■
■
all’apertura del canale:
■ il server si autentica presentando la propria
chiave pubblica (certificato X.509) e
subendo una sfida asimmetrica
■ l’autenticazione del client (con chiave
pubblica e certificato X.509) è opzionale
per l’integrità il protocollo prevede:
■ un digest (MD5 o SHA-1) protetto
■ un MID per evitare il replay e la cancellazione
1
(remote - gen'01)
SSL - riservatezza
■
■
SSL
il client genera una session key utilizzata per
la cifratura simmetrica dei dati (RC2, RC4,
DES, 3DES o IDEA)
la chiave viene comunicata al server
cifrandola con la chiave pubblica del server
(RSA, Diffie Hellman o Fortezza-KEA)
(1) https://www.polito.it/
(2) configurazione di sicurezza
(3) cert (www.polito.it)
server
Web
sicuro
(3bis) server challenge /response
browser
(4) cert (utente)
(4bis) client challenge /response
(5) canale sicuro (SSL)
Architettura di SSL-3
SSL
handshake
protocol
SSL
change cipher
spec protocol
SSL
alert
protocol
SSL-2 - il protocollo
■
due tipi di record:
■ SSL Handshake Protocol
permette di negoziare gli algoritmi di cifratura
e autenticazione utilizzati
■ SSL Record Protocol
consente di incapsulare dati e informazioni di
autenticazione
■
SESSION KEY PRODUCTION
a partire dalla session-master-key vengono
generate la session-write-key e la sessionread-key
SERVER VERIFY (solo per RSA)
il server ‘‘sfida’’ il client per verificare la
session-master-key ricevuta
CLIENT AUTHENTICATION (opzionale)
il server può richiedere l’autenticazione del
client (X.509 v3)
FINISHED conclude l’handshake
application
protocol
(es. HTTP)
SSL record protocol
reliable transport protocol (es. TCP)
network protocol (es. IP)
SSL-2 handshake protocol
Permette alle parti di negoziare le specifiche di
sicurezza della transazione
■ HELLO
■ scelta del tipo di cifratura e di digest
■ il server invia il proprio certificato ed il
connection-id
■ KEY EXCHANGE
■ il client genera la session-master-key e la
invia al server
■ RSA, Diffie Hellman e Fortezza-KEA
■
■
■
A questo punto si dispone di un canale sicuro per
inviare dati secondo il protocollo applicativo
scelto.
2
(remote - gen'01)
Connection-id
Connection-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.
per evitare di dover ri-negoziare ad ogni
sessione i parametri crittografici il server SSL
può offrire un connection identifier
se il client, all’apertura della sessione,
presenta un connection-id valido si salta la
fase di negoziazione e si procede subito col
dialogo SSL
il server può rifiutare l’uso del connection-id
(in assoluto o dopo un certo tempo dalla sua
emissione)
SSL-3 record protocol
SSL con session-ID
dati
datiapplicativi
applicativi
(1) https://www.polito.it/
frammentazione
F1
F1
(1bis) session-ID
F2
F2
compressione
server
Web
sicuro
browser
calcolo del MAC
MAC
MAC
padding
MAC
MAC
PP
cifratura
(5) canale sicuro (SSL)
header
SSL - calcolo del MAC
MAC = message_digest (
key, data, padding, seq_number)
■
■
■
message_digest: dipende dall’algoritmo di
scelto
key: sender-write-key (receiver-read-key)
seq_number: intero a 32 bit
HH
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
3
(remote - gen'01)
TLS
■
■
■
■
■
Transport Layer Security
standard IETF (TLS-1.0 = RFC-2246)
TLS-1.0 = SSL-3.1
al 99% coincide con SSL-3
enfasi su algoritmi crittografici e di digest
standard (non proprietari):
■ DH + DSA + 3DES
■ HMAC
Netscape versione esportazione
■
■
■
■
IE versione esportazione
■
■
■
■
genera / importa chiavi asimmetriche da 512
bit
usa chiavi simmetriche a 40 bit
usa chiavi simmetriche a 56 bit a partire da IE
5.0 per Windows-2000
usa interfaccia MS-CAPI per il motore
crittografico (CSP)
Fortify
■
■
■
■
Sicurezza del WWW
■
■
HTTP-1.0
■ password-based
l’accesso è limitato da username e
password inviate con UUENCODE
(Basic Protection Scheme)
■ address-based
il server consente/impedisce l’accesso
in base all’indirizzo IP del client
entrambi gli schemi sono altamente
insicuri (perché HTTP suppone che sia
sicuro il canale!)
genera chiavi asimmetriche da 512 bit
importa chiavi asimmetriche da 1024 bit
dalla versione 4.6 usa chiavi simmetriche a 56
bit (in precedenza: 40 bit)
usa interfaccia PKCS-11 per il motore
crittografico (CSP)
http://www.fortify.net
eleva la sicurezza dei browser Netscape 4.x
versione esportazione alla versione
americana
effettua la patch binaria degli eseguibili
quindi bisogna fare attenzione ad usare la
versione giusta
ovviamente non funziona con altri browser
(es. Internet Explorer)
HTTP - basic protection scheme
GET /path/alla/pagina/protetta
HTTP/1.0 401 Unauthorized - authentication failed
WWW-Authenticate: Basic realm="RealmName"
Authorization: Basic UU_encoded_username_password
HTTP/1.0 200 OK
Server: NCSA/1.3
MIME-version: 1.0
Content-type: text/html
<HTML> pagina protetta … </HTML>
4
(remote - gen'01)
Client authentication SSL
a livello applicativo
Sicurezza del WWW
■
■
■
canale SSL:
■ protezione delle transazioni
■ protezione delle password applicative
password:
■ del servizio HTTP
■ del S.O. che ospita il server (es. NT o UNIX)
ACL per accedere ai documenti:
■ in funzione dell’autenticazione effettuata
(utenti del S.O., DN per X.509)
■
■
tramite la client authentication è possibile
identificare l’utente che ha aperto un canale
alcuni server web permettono di fare un
mapping (semi-)automatico tra credenziali
estratte dal certificato X.509 e utenti del
server web e/o del S.O.
Coesistenza di SSL
con altri protocolli
S-HTTP
■
■
■
■
■
■
■
nuova versione del protocollo HTTP-1.0
sviluppato da EIT-Terisa
incapsula comandi e risposte HTTP in una
busta sicura (PEM, PGP o PKCS-7)
negoziazione delle chiavi in linea, fuori linea
o con Kerberos
certificati X.509 o PKCS-6
firme RSA o DSA
digest MD2, MD5 o SHA-1
crittografia DES, IDEA, RC2, RC4
■
■
■
■
sostituzione completa dei comandi R
(rsh, rlogin, rcp) + X11 forwarding
crittografia del canale
vari tipi di autenticazione:
■ indirizzi IP (= rlogin + crypto)
■ chiave RSA di host
■ chiave RSA di utente
public-domain per UNIX, commerciale
per MS-Windows
protocollo in corso di pubblicazione
come RFC
S/MIME
telnet
SMTP
SMTP
SSL
SSL
TCP
TCP
IP
IP
Internet
SSH (Secure SHell)
■
S/MIME
telnet
SSH - crittografia del canale
■
■
utilizza DES, triplo DES, RC4, IDEA oppure
ISS
la chiave di cifratura è una chiave di sessione
scambiata in fase di connessione
5
SSH - certificazione
■
■
usa chiavi RSA ma non usa certificati di
alcun tipo
la chiave pubblica, non essendo associata
ad un certificato di una CA, deve essere
nota alla controparte per poter essere
verificata:
■ i client tengono la chiave pubblica dei
server in ~/.ssh/known_hosts
■
(remote - gen'01)
SSH - protezione delle chiavi private
■
■
i server tengono le chiavi pubbliche dei
client in ~/.ssh/authorized_keys
la chiave privata del server è conservata in
chiaro in un file:
■ tenerlo nascosto
■ cancellare il file di configurazione che dice
qual è il file in questione
la chiave privata del client è conservata
crittografata con un passphrase P:
■ P richiesta all’utente quando occorre
■ uso di ssh-agent per trasmettere P
automaticamente ai sottoprocessi
SSH - autenticazione dei client
■
■
standard dei comandi r:
■ indirizzo IP + connessione attraverso porta
privilegiata
■ file ~/.rhosts o /etc/hosts.equiv
SSH - autenticazione dei client
■
■
uso di login+password Unix all’interno di un
canale crittografato
challenge RSA puro, ossia senza controllo
dell’indirizzo IP
standard + RSA challenge:
■ il client deve rispondere ad una sfida
crittografica (verificabile dal server perché
conosce le chiavi pubbliche dei client)
■ il server verifica comunque ~/.rhosts e
/etc/hosts.equiv
SSH - autenticazione dei server
■
solo ed esclusivamente mediante challenge
RSA
K-commands
■
■
■
■
■
K-telnet, K-ftp, Klogin, Kcp, Ksh, K-POP
autenticazione con Kerberos
crittografia del canale con DES
disponibile per UNIX e PC (DOS, Windows,
Mac)
richiedono Kerberos!
6
(remote - gen'01)
SSL-telnet, SSL-ftp, SSL-rsh
■
■
■
■
applicazione standard modificata con
trasporto SSL
si appoggia sulla libreria OpenSSL (ex
SSLeay)
usa certificati X.509
modalità di fall-back = se l’autenticazione
SSL fallisce si può:
■ rifiutare la connessione
■ collegarsi col protocollo standard
SSL-x: autenticazione
■
■
■
DESLOGIN
il server è sempre autenticato:
■ chiave privata in chiaro in un file
■ passphrase all’avvio per aprire il file che
contiene la chiave privata
per default, il client è autenticato tramite
login+password Unix ma su un canale
crittografato
opzionalmente si può usare la client
authentication di SSL; in questo caso la
passphrase che protegge la chiave privata è
richiesta all’utente
Funzionamento di DESLOGIN
Mr.X vuole entrare!
■
■
■
■
■
■
emulazione di terminale (VT100)
autenticazione del server e del client tramite
sfida simmetrica (challenge-response con
una passphrase)
crittografia del canale con DES
non richiede modifiche al sistema di
autenticazione nativo (doppia autenticazione)
disponibile per UNIX e PC (Windows)
semplice ma utile
{sfida}PFX
sfida
canale crittografato
demone di
Deslogin
login?
password?
comandi, dati
risultati
chiave = {{sfida}PFX }PFX
Il sistema X-windows (X11)
SERVER
(video, tastiera, mouse)
A
CLIENT
(CPU, RAM)
Sicurezza di X-windows
■
A
A
B
VAX/VMS
B
B
SPARC/Solaris
■
autenticazione:
■ indirizzi IP ( xhost +host )
■ cookie (da X11R4)
■ Kerberos V5 (da X11R6)
■ avere autenticazione debole significa che con
le primitive di X11 (es. xwindump) posso
catturare tutto l’I/O del terminale grafico
senza bisogno di fare sniffing
forwarding di X11 su canale sicuro:
■ SSH
■ IPsec
7
(remote - gen'01)
Protezione della chiave privata
■
■
■
■
deve usarla un processo
in chiaro dentro un file (facile ma
richiede la protezione del server)
in un file criptato, con chiave fornita
all’avvio (operatore all’avvio +
attaccabile da root via debug della RAM
+ non usabile per processi automatici)
su un dispositivo protetto (acceleratore
crittografico o crypto-engine) che
effettua anche le operazioni di
crittografia:
■ genera la coppia Kpub / Kpri
■ cifra e decifra
Sicurezza degli accessi remoti a DBMS
■
modalità di accesso a dati remoti:
■ in emulazione di terminale
= protezione del canale (SSL-telnet, SSH, ...)
■ tramite interfaccia WWW
= protezione del Web (SSL, ...)
■ client-server
= sistema di sicurezza proprietario, oppure
transazioni appoggiate su IPsec
Sicurezza degli accessi
client-server a DBMS
■
Oracle SNS
esempio: Oracle SNS (Secure Network
Services)
■ add-on per Oracle SQL*Net
■ autentica client e server
■ protegge i dati (query, update, risposte)
da:
■ intercettazione (data encryption)
■ modifiche (data integrity)
■ cancellazione (data filtering)
■
■
■
applicabile a:
■ DB Oracle centralizzato/distribuito
■ DB federato con parti non Oracle
non richiede modifiche alle applicazioni
esistenti
non richiede dispositivi hardware
SNS - schema funzionale
server
serverOracle
Oracle
SQL*Net
SQL*Net
SNS - applicabilità
applicazione
applicazione
SQL*Net
SQL*Net
dati non protetti
dati non protetti
SNS
SNS
■
■
qualunque oggetto SQL*Net V2
anche prodotti non Oracle tramite Oracle
Open Gateway
SNS
SNS
dati protetti
dati protetti
Oracle
OracleNPA
NPA
network
networksw
sw
Oracle
OracleNPA
NPA
network
networksw
sw
SQL*Net V2
SNS
SNS
FoxPro
FoxPro
SNS
SNS
Oracle
Oracle
Open
OpenGateway
Gateway
DB2
DB2
dati protetti
PC MS-Windows
host MVS
rete
8
(remote - gen'01)
SNS - supporto multiprotocollo
■
SNS - supporto cross-protocollo
■
poichè SNS si appoggia sopra Oracle
Network Protocol Adapter (NPA) supporta
tutti i protocolli supportati da Oracle
■ TCP/IP
■ SPX/IPX
■ APPC
■ DECnet
■ X.25
■ Netbios
■ ...
■
client
client
SNS
SNS
SPX / IPX
Crittografia in SNS
■
■
■
■
■
■
terze parti con accordi esclusivi !
Banyan - Universal StreetTalk
■ login singolo di rete
Bull - Integrated System Management
■ SESAME
■ identificazione basata su token
CyberSAFE - Challenger
■ Kerberos V5 (V4, DCE)
■ applicativi kerberizzati
■ GSS-API
canale sicuro
Oracle
Oracle
MultiProtocol
MultiProtocol
Interchange
Interchange
server
server
SNS
SNS
TCP / IP
Vantaggi di SNS
negoziazione dell’algoritmo:
■ ce n’è uno di default
■ default diverso tra client e server:
negoziazione
■ possibile rifiuto della connessione
attivazione automatica:
■ per default può essere disattivata
■ attivazione automatica e trasparente quando
ci si collega ad un server che la richiede
SNS - identificazione ed autenticazione
degli utenti
SNS è integrato in Oracle MultiProtocol
Interchange
cambio di protocollo senza rimettere i
dati in chiaro: velocità + inattaccabilità
■
■
■
■
■
■
Oracle 7 client-server non trasmette le
password in chiaro ...
... ma lascia in chiaro:
■ la trasmissione dei dati
■ i cambi di password
SNS crittografa tutta la sessione e quindi
elimina questi problemi
ICL - AccessManager
■ login singolo di rete
■ A: RACF, ACF2, TopSecret, DCE, Kerberos
■ I: SDI SecurID, PCSL StopLockV, RACF
Passticket
Identix - TouchSafeII
■ verifica delle impronte digitali
■ interfaccia ISA
Security Dynamics Technologies - SecurID
■ autenticatore hardware
■ PIN + numero casuale (cambia ogni minuto)
9
(remote - gen'01)
SNS - integrità dei dati
■
■
SNS usa MD5 come checksum
■ normalmente non inserita
■ inseribile a richiesta
SNS opzionalmente:
■ numera i pacchetti
■ controlla che non ne manchino e non ci
siano duplicati
■ arresta il sistema in caso di attacco
Sistemi di pagamento elettronico
■
■
■
fallimento della moneta elettronica per
problemi tecnici e normativi
(es. bancarotta di DigiCash)
attualmente il metodo più usato è
trasmissione del numero di carta di credito
su canale SSL ...
... che però non garantisce contro le frodi:
VISA Europa dichiara che il 50% dei tentativi
di frode nascono da transazioni Internet, che
però sono solo il 2% del suo volume d’affari!
Sicurezza delle transazioni
basate su carta di credito
■
■
■
STT
(Secure Transaction Technology)
VISA + Microsoft
SEPP
(Secure Electronic Payment Protocol)
Mastercard, IBM, Netscape, GTE, CyberCash
SET = STT + SEPP
(Secure Electronic Transaction)
SET
■
■
■
SET non è un sistema di pagamento ma un
insieme di protocolli per usare in rete aperta
in modo sicuro un’infrastruttura esistente
basata su carte di credito
usa certificati X.509v3 dedicati
esclusivamente alle transazioni SET
assicura la privacy degli utenti perché mostra
a ciascuna parte solo i dati che le competono
Architettura di SET
Caratteristiche di SET
■
■
■
■
■
versione 1.0 (maggio 1997)
digest: SHA-1
crittografia simmetrica: DES
scambio chiavi: RSA
firma digitale: RSA con SHA-1
merchant
cardholder
INTERNET
payment
gateway
payment
network
issuer
acquirer
10
(remote - gen'01)
Attori in SET (I)
■
■
■
cardholder
legittimo possessore di una carta di credito
aderente a SET
merchant
venditore di un prodotto via Internet (Web o
e-mail)
issuer
istituto finanziario che ha emesso la carta di
credito dell’utente
Attori in SET (II)
■
■
■
Doppia firma SET
■
■
■
■
per garantire privacy all’utente nei confronti
di merchant e del sistema finanziario
(acquirer + issuer) si usa una doppia firma
al merchant non vengono fatti sapere gli
estremi del pagamento
alla banca non viene fatto sapere quale merce
si è acquistata
solo l’utente può dimostrare l’associazione
tra merce e pagamento
Doppia firma SET: dettagli
■
■
■
■
■
■
■
Problemi di SET
acquirer
organizzazione finanziaria che stabilisce un
rapporto col mercante e lo interfaccia con
uno o più circuiti di pagamento
payment gateway
sistema che traduce transazioni SET nel
formato richiesto dal circuito di pagamento
dell’acquirer
certification authority
emette certificati X.509v3 e CRL X.509v2 per
tutti gli altri attori di SET
PI: Purchase Information (pagamento)
OI: Order Information (merce)
DS = E ( H( H(PI),H(OI) ), Ukpri)
DS+H(PI) al merchant
merchant conosce OI e può calcolare
H(H(PI),H(OI)) verificando che corrisponda al
valore estratto dalla firma
DS+H(OI) all’acquirer
acquirer conosce PI e può calcolare
H(H(PI),H(OI)) verificando che corrisponda al
valore estratto dalla firma
Architettura di pagamento via Web
1. offerta
■
■
■
■
software molto caro (sia per le CA, sia per il
merchant e l’acquirer)
necessita di un’applicazione speciale dal lato
utente (SET wallet)
procedura di rilascio del certificato a chiave
pubblica per gli utenti complessa
in sviluppo la versione 2.0 di SET che farà a
meno del wallet (userà un browser)
2. ordine
cardholder
5.
4.
da
ric
h
ti
c
SS
L
.c
.
Internet
ie
st
a
c.
8.
c.
POS
virtuale
payment
gateway
ct
ire
red
!
3.
OK
to
en
m
ga
pa
6.
da
ti
c.c
.
7.
OK
!
merchant
mondo
finanziario
OK
?
payment
network
11
(remote - gen'01)
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
12

Sicurezza degli accessi remoti Sicurezza degli

Transcript

Documenti analoghi

Collegamenti Sicuri SSL

Politica per la Salute e Sicurezza sul lavoro

La INNSE-BERARDI Spa pone tra i propri obiettivi prioritari al pari

Disattivazione del protocollo crittografico SSL v3 per internet Bug di

LA POLITICA PER LA SALUTE E SICUREZZA SUI LUOGHI DI

Protocollo Porta standard Porta SSL HTTP 80 443 NNTP 119 563

HUMAN MANAGEMENT SYSTEM PER LA SALUTE E SICUREZZA

SSL_Presentazione Aziendale

Errore su Firefox: "Connessione sicura non riuscita

Configurazione SSL di un account Aruba in Outlook 2013