Introduzione
La sicurezza delle transazioni su Internet viene implementata attraverso l'uso della tecnica SSL (Secure Socket Layer), che è uno standard per le protezioni delle transazioni WEB sviluppato da Netscape sulla base di tecniche di crittografia standard note ed in uso negli Stati Uniti
La tecnologia alla base di SSL è stata reimplementata da sviluppatori indipendenti e incorporata in una variante di Apache datta Apache-SSL.
Crittografia a chiave pubblica
Il problema dell'accesso ai servizi telematici da parte di persone non autorizzate viene risolto attraverso l'uso di sistemi di login e password.
Un sistema di login e passord risolve il problema dell'autenticazione ma non garantisce che i dati inviati sul Web non possano essere 'ascoltati' e letti da qualcuno, infatti le informazioni scambiate tra server e client viaggiano 'in chiaro' , attraversano diversi 'provider' e possono quindi essere intercettate facilmente.
Alla base della crittografia c'è un sistema di codifica detto chiave k(), la chiave è una funzione matematica invertibile ed è tale che se m è il messaggio c=k(m) è il messaggio cifrato, due soggetti che devono mettersi in contatto e scambiarsi informazioni cifrate devono possedere entrambi la chiave k().
Il mittente che desidera comunicare il messaggio m lo codifica attraverso la chiave k() ed invia il messaggio c, il destinatario per poter leggere il messaggio lo decodifica utilizzando k-1(c)=m.
Questo sistema funziona fintanto che k() è nota ad entrambe le parti e fintanto che la chiave k() è scambiata tra le parti in forma sicura (non in forma elettronica), se cosi non è la chiave potrebbe essere intercettata ed utilizzata da persone non autorizzate.
Per risolvere questo problema si fa uso della cosidetta chiave pubblica che consente di divulgare una chiave di codifica senza che sia possibile utilizzarla per la decodifica se non da una persona.
La chiave vera e propria k() rimane privata e non viene diffusa, la chiave pubblica è una funzione K() derivata da k() che calcola la stessa funzione ed ha la proprietà di non essere invertibile.
Esaminiamo ora come possa essere possibile utilizzare la chiave pubblica per codificare i messaggi e per firmare digitalmente i messaggi inviati.
Chi desidera inviare il messaggio come mittente (ad esempio inviare i dati della carta di credito) codifica il messaggio utilizzando c=K(m), in questo modo solo il destinatario può decifrare il messaggio utilizzando k-1(c)=m, infatti essendo la chiave pubblica K() impossibile da invertire, nessuno se non l'autorità in possesso della chiave privata può decodificare il messaggio.
Questo meccanismo può essere utilizzato per firmare digitalmente i documenti, in questo caso chi ha diffuso la chiave pubblica diventa il mittente, e il destinatario, in possesso della chiave pubblica la utilizza per verificare l'identità del mittente.
Per garantire la provenienza del messaggio (ad esempio verificare se il server al quale siamo connessi sia effettivamente quello che dice di essere) il mittente invia la firma utilizzando la chiave privata invertita f= k-1(s), il destinatario per verificare la firma utilizza la chiave pubblica K(), se K(f)=K(k-1(s))=k(k-1(s))=s è uguale alla stringa che ci si aspettava allora possiamo essere sicuri che chi ci ha inviato la firma è effettivamente chi ha rilasciato la chiave pubblica.
Infatti la sola funzione in grado di generare questa firma è k-1(s) ottenuta invertendo la chiave privata in possesso esclusivo del mittente, la chiave pubblica K() non è invertibile quindi la firma digitale può essere stata generata solo attraverso la chiave privata.
Chi genera le chiavi pubbliche
Quando si riceve una chiave pubblica non si è certi dell'identità di chi l'ha inviata, esistono quindi delle autorità di certificazione (Certificate Authority, CA) che appongono firme elettroniche alle chiavi pubbliche che vengono diffuse da un ente che desidera utilizzare tecniche di crittografia
Una chiave pubblica firmata è chiamata certificato digitale.La verifica dell'autenticità di un certificato digitale passa per la verifica con la chiave pubblica della CA, tuttavia queste sono rese ampiamente disponibili. Le CA più importanti hanno le le proprie chiavi pubbliche incluse nelle versioni dei browser più famosi.
Chi desidera un certificato digitale se lo fa rilasciare da una CA, pagando il servizio vengono fatti degli accertamenti, se l'identita dell'ente che richiede il certificato digitale è verificata con certezza la CA rilascia il certificato ossia appone la propria firma elettronica alla chiave pubblica della ditta e si può in questo modo diffondere la propria chiave pubblica firmata.
Apache-SSL
Apache può essere configurato per accettare connessioni SSL.
La parte cruciale della configurazione è l'ottenere un certificato digitale che deve essere acquistato da una autorità di certificazione riconosciuta. E' opportuno scgliere una autorità di quelle presenti nei browser più diffusi, ad ogni modo un meccanismo detto di certificate chaining che consente qualora una CA non è riconosciuta dal browser di richiedere automaticamente la certificazione della CA ad un'altra CA fino a che non si raggiunge un CA riconosciuta dal browser.
Per abilitare Apache ad accettare connessioni SSL, occorre modificare il file httpd.conf ed aggiungere le direttive che caricano i moduli SSL e dare delle ulteriori direttive che inicano quali sono i certificati da utilizzare.
Caricando i moduli SSL si ottiene una versione di apache detta httpsd che ha tutte le caratteristiche del server originario ed in più per determinati host virtuali è in grado di supportare connessioni SSL
Per l'accesso ad un server SSL occorre utilizare il protocollo https effettuando la connessione a https://www.lid.it la porta predefinita sulla quale il server si deve trovare è la 443.
Direttive Apache SSL
LoadModule ssl_module modules/ApacheModuleSSL.dll
Questa direttiva carica in modalita DSO (Dynamic Shared Object) il modulo necessario per abilitare apache a supportare connessioni SSL
<IfDefine SSL>
Listen 80
Listen 443
</IfDefine>
Questa direttiva indica ad Apache di ascoltare sulla porta 443
I seguenti comandi si riferiscono ad una tipica configurazione SSL annegata nel file Httpd.conf.
La configurazione SSL è divisa in più sezioni, una globale che si riferisce al server principale e a tutti gli host virtuali abilitati a SSL, ed una per ogni host virtuale abilitato SSL.
##
## SSL Global Context
##
## All SSL configuration in this context applies both to
## the main server and all SSL-enabled virtual hosts.
##
#
# Some MIME-types for downloading Certificates and CRLs
#
<IfDefine SSL>
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl .crl
</IfDefine>
<IfModule mod_ssl.c>
# Pass Phrase Dialog:
# Configure the pass phrase gathering process.
# The filtering dialog program (`builtin' is a internal
# terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog builtin
# Inter-Process Session Cache:
# Configure the SSL Session Cache: First either `none'
# or `dbm:/path/to/file' for the mechanism to use and
# second the expiring timeout (in seconds).
#SSLSessionCache none
#SSLSessionCache shm:logs/ssl/scache(512000)
SSLSessionCache dbm:logs/ssl/scache
SSLSessionCacheTimeout 300
# Semaphore:
# Configure the path to the mutual explusion semaphore the
# SSL engine uses internally for inter-process synchronization.
SSLMutex sem
# Pseudo Random Number Generator (PRNG):
# Configure one or more sources to seed the PRNG of the
# SSL library. The seed data should be of good random quality.
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random 512
#SSLRandomSeed connect file:/dev/random 512
# Logging:
# The home of the dedicated SSL protocol logfile. Errors are
# additionally duplicated in the general error log file. Put
# this somewhere where it cannot be used for symlink attacks on
# a real server (i.e. somewhere where only root can write).
# Log levels are (ascending order: higher ones include lower ones):
# none, error, warn, info, trace, debug.
SSLLog logs/ssl/engine.log
SSLLogLevel info
</IfModule>
<IfDefine SSL>
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot "/Apache/htdocs"
ServerName localhost
ServerAdmin you@your.address
ErrorLog logs/ssl/error.log
TransferLog logs/ssl/access.log
#
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
# Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate. If
# the certificate is encrypted, then you will be prompted for a
# pass phrase. Note that a kill -HUP will prompt again. A test
# certificate can be generated with `make certificate' under
# built time.
SSLCertificateFile "/Apache/conf/ssl.crt/snakeoil-rsa.crt"
#SSLCertificateFile @@ServerRoot@@/conf/ssl.crt/server.crt
#SSLCertificateFile @@ServerRoot@@/conf/ssl.crt/server-dsa.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file.
SSLCertificateKeyFile "/Apache/conf/ssl.key/snakeoil-rsa.key"
#SSLCertificateKeyFile @@ServerRoot@@/conf/ssl.key/server.key
#SSLCertificateKeyFile @@ServerRoot@@/conf/ssl.key/server-dsa.key
# Server Certificate Chain:
# Point SSLCertificateChainFile at a file containing the
# concatenation of PEM encoded CA certificates which form the
# certificate chain for the server certificate. Alternatively
# the referenced file can be the same as SSLCertificateFile
# when the CA certificates are directly appended to the server
# certificate for convinience.
#SSLCertificateChainFile "@@ServerRoot@@/conf/ssl.crt/ca.crt"
# Certificate Authority (CA):
# Set the CA certificate verification path where to find CA
# certificates for client authentication or alternatively one
# huge file containing all of them (file must be PEM encoded)
# Note: Inside SSLCACertificatePath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCACertificatePath "@@ServerRoot@@/conf/ssl.crt"
#SSLCACertificateFile "@@ServerRoot@@/conf/ssl.crt/ca-bundle.crt"
# Certificate Revocation Lists (CRL):
# Set the CA revocation path where to find CA CRLs for client
# authentication or alternatively one huge file containing all
# of them (file must be PEM encoded)
# Note: Inside SSLCARevocationPath you need hash symlinks
# to point to the certificate files. Use the provided
# Makefile to update the hash symlinks after changes.
#SSLCARevocationPath "@@ServerRoot@@/conf/ssl.crl"
#SSLCARevocationFile "@@ServerRoot@@/conf/ssl.crl/ca-bundle.crl"
# Client Authentication (Type):
# Client certificate verification type and depth. Types are
# none, optional, require and optional_no_ca. Depth is a
# number which specifies how deeply to verify the certificate
# issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth 10
# Access Control:
# With SSLRequire you can do per-directory access control based
# on arbitrary complex boolean expressions containing server
# variable checks and other lookup directives. The syntax is a
# mixture between C and Perl. See the mod_ssl documentation
# for more details.
#<Location />
#SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \
# and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
# and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
# and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
# and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20 ) \
# or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>
# SSL Engine Options:
# Set various options for the SSL engine.
# FakeBasicAuth:
# Translate the client X.509 into a Basic Authorisation. This means that
# the standard Auth/DBMAuth methods can be used for access control. The
# user name is the `one line' version of the client's X.509 certificate.
# Note that no password is obtained from the user. Every entry in the user
# file needs this password: `xxj31ZMTZzkVA'.
# ExportCertData:
# This exports two additional environment variables: SSL_CLIENT_CERT and
# SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
# server (always existing) and the client (only existing when client
# authentication is used). This can be used to import the certificates
# into CGI scripts.
# CompatEnvVars:
# This exports obsolete environment variables for backward compatibility
# to Apache-SSL 1.x, mod_ssl 2.0.x, Sioux 1.0 and Stronghold 2.x. Use this
# to provide compatibility to existing CGI scripts.
# StrictRequire:
# This denies access when "SSLRequireSSL" or "SSLRequire" applied even
# under a "Satisfy any" situation, i.e. when it applies access is denied
# and no other module can change it.
# OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
SSLOptions +FakeBasicAuth +ExportCertData +CompatEnvVars +StrictRequire
<Files ~ "\.(cgi|shtml)$">
SSLOptions +StdEnvVars
</Files>
<Directory "/Apache/cgi-bin">
SSLOptions +StdEnvVars
</Directory>
# SSL Protocol Adjustments:
# The safe and default but still SSL/TLS standard compliant shutdown
# approach is that mod_ssl sends the close notify alert but doesn't wait for
# the close notify alert from client. When you need a different shutdown
# approach you can use one of the following variables:
# ssl-unclean-shutdown:
# This forces an unclean shutdown when the connection is closed, i.e. no
# SSL close notify alert is send or allowed to received. This violates
# the SSL/TLS standard but is needed for some brain-dead browsers. Use
# this when you receive I/O errors because of the standard approach where
# mod_ssl sends the close notify alert.
# ssl-accurate-shutdown:
# This forces an accurate shutdown when the connection is closed, i.e. a
# SSL close notify alert is send and mod_ssl waits for the close notify
# alert of the client. This is 100% SSL/TLS standard compliant, but in
# practice often causes hanging connections with brain-dead browsers. Use
# this only for browsers where you know that their SSL implementation
# works correctly.
# Notice: Most problems of broken clients are also related to the HTTP
# keep-alive facility, so you usually additionally want to disable
# keep-alive for those clients, too. Use variable "nokeepalive" for this.
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
# Per-Server Logging:
# The home of a custom SSL log file. Use this when you want a
# compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl/request.log \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
</IfDefine>
|
e-mail