La necessità di avere una connessione sicura nasce verso la fine degli anni '90 del XX Secolo quando inizia a farsi strada l'uso sempre più massivo di movimentazione bancaria online con la nascita delle prime aziende (ad esempio Amazon, eBay, ecc) che svolgono correntemente la vendita online di beni e servizi.
Il World Wide Web, il sistema progettato solo pochi anni prima da Sir Tim Berners-Lee e Robert Cailliau al CERN di Ginevra (su workstation NeXT di Steve Jobs) aveva preso preponderantemente consenso a livello globale e necessitava di strutture di protezione che incoraggiassero (facendoli sentire sicuri) gli utenti ad investire e comprare, come detto, beni e servizi.
Nasce da questa esigenza l'idea di mettere un catenaccio (come mostra l'immagine sopra) ad una connessione.
Il seguente articolo, come molti altri del resto, è particolarmente lungo ma cerca di portare con mano sicura l'utente/amministratore che approccia questo genere di esperienza, con una visione d'insieme a 360°
Il funzionamento a livello teorico di SSL
Il principio sul quale si basa il Secure Socket Layer (SSL) è quello di usare una porta diversa da 80 (infatti si usa la porta 443) e di associare ad esso una cifratura a chiave pubblica tra client e server
Nella prima fase, il client e il server negoziano il protocollo di cifratura che sarà utilizzato nella comunicazione sicura, il protocollo per lo scambio delle chiavi e l'algoritmo di autenticazione nonché il Message authentication code (MAC).
L'algoritmo per lo scambio delle chiavi e quello per l'autenticazione normalmente sono algoritmi a chiave pubblica o, come nel caso di TLS-PSK, fanno uso di una chiave precondivisa (Pre-Shared Key).
L'integrità dei messaggi è garantita da una funzione di hash che usa un costrutto HMAC per il protocollo TLS o una funzione pseudorandom non standard per il protocollo SSL.
Attualmente sono in funzione protocolli TLS 1.2 ed 1.3 sono considerati tra i più sicuri in ambito generale
In definitiva ciò che occorre per costruire un sistema protetto è un webserver (come quello analizzato fino a questo momento, tipo Server Aruba Cloud ed un certificato di sicurezza rilasciato da un ente certificatore, come, ad esempio, Actalis (aruba.it), ZeroSSL, DigiCert, Google Trust Service.
Certificato blog.dicecca.net TLS 1.3 Google Trust Service
Certificato blog.dicecca.net TLS 1.2 Actalis (aruba.it)
Installare il Mod SSL su un Server CentOS 7
In linee generali i Server Aruba (fisici e Cloud) hanno di base installato il mod_ssl, ma partiamo dal caso che questo non sia accaduto.
1 - Accedere al server con utente root, quindi, al prompt scrivere
yum -y install httpd mod_ssl
Premere y quando richiesto ed aspettare che il sistema finisca l'installazione del pacchetto
2 - Nella cartella /etc/httpd/conf.d è comparso, dopo l'installazione un nuovo file chiamato ssl.conf
In questo file, da questo momento in poi, a differenza di quanto pubblicato per la sola porta 80, andranno tutti i virtual host del sistema, sia essi su porta 80 (non protetti) che su porta 443 (protetti)
Il certificato SSL da mettere sul Server
Mentre per i VH su porta 80 basta semplicemente il dominio che si vuole usare (di primo o secondo livello), per quanto riguarda invece i VH su porta 443 (SSL), oltre al domini (ad esempio www.dicecca.net, oppure blog.dicecca.net) servono tre file che sono i certificati da installare nel sistema.
I certificati in genere si comprano e si pagano.
Ci sono delle soluzioni tipo Open SSL (ma non lo tratteremo qui) che consentono di creare sulla macchina dei certificati, ma questi, in genere, non sono considerati attendibili dai Browser, ovvero compare una schermata di questo tipo
Cliccando su Avanzate (il pulsante in grigio), compare
A questo punto cliccando su Accetta il rischio e continua (pulsante in grigio) si accede al sito cifrato
Il sistema pur dandoci il catenaccio ci avvisa che la connessione non è sciura e
sui dettagli
Il campo verificato da Webmin Webserver on localhost.localdomain per il sistema non è affidabile, ma la crittografia è sicura (per paradosso)
Quindi è necessario un autorità certificatrice che ci rialsci un certificato di sicurezza certificato (con tanto di gioco di parole)
Come detto sono a pagamento quasi tutti, eppure, esiste almeno un sito che ci consente di avere un certificato gratuito:
Questo sito consente, previa registrazione di un dominio di poter avere un certificato valido per 90 giorni (tutto sommato efficace per il nostro test)
Nota: Per dominio non si intende, ad esempio dicecca.net e tutti i sotto domini possibili (www.dicecca.net, blog.dicecca.net, ecc) ma si intende solo uno dei possibili, quindi www.dicecca.net oppure blog.dicecca.net, ecc
La registrazione non è oggetto del post, ma è facile
Per il nostro test (visto che lo abbiamo già registrato) useremo un certificato per il dominio www.1000vani.it
Il sito di ZeroSSL rilascerà un file zip contenente tre file che vanno caricati sul server
Per comodità abbiamo preferito usare, su Server Aruba Cloud CentOS 7, la cartella
/etc/ssl/
Andremo quindi a creare una cartella (o più cartelle a seconda di quanti domini certificati avremo) con dentro i seguenti file:
- certificate.crt
- private.key
- ca_bundle.crt
Nel caso nostro sarà: /etc/ssl/1000vani.it
Ora non rimane che creare modificare il file ssl.conf in /etc/httpd/conf.d con tutti i domini (su porta 80 e 443) del nostro server
Il file ssl.conf
Il file ssl.conf di suo è molto lungo (prima di operare conviene sempre fare una copia del file di sicurezza), ma quello che noi prenderemo di esempio è solo ciò che viene incluso nei tag
########################
###### Porta 443 - Inzio
###
### Creazione del VirtualHost www.1000vani.it
### con certificato ssl
####
<VirtualHost www.1000vani.it:443>
{...}
</VirtualHost>
###### Porta 443 - Fine
########################
########################
###### Porta 80 - Inziio
###
### - www.1000vani.it:80
### - Con accesso con .htaccess
### - e con error.log
######
<VirtualHost www.1000vani.it:80>
{...}
</VirtualHost>
###### Porta 80 - Fine########################
Perché i cancelletti (hashtag) che ci indicano porta 80 e 443?
Poiché il file è unico, per meglio suddividere i VH con SSL e quelli senza, si possono raggruppare in questo modo.
E' obbligatorio inserire :80 e :443 (ovvero le porte dove Apache deve "ascolatare" le richieste) per instradare meglio le richieste (scarica qui il file usato per questo esempio)
Vediamo il VH 443
########################
###### Porta 443 - Inzio
###
### Creazione del VirtualHost www.1000vani.it
### con certificato ssl
####
<VirtualHost www.1000vani.it:443>
# General setup for the virtual host, inherited from global configuration
DocumentRoot "/domini/1000vani.it/sicuro"
ServerName www.1000vani.it:443
# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn
# SSL Engine Switch:
# Enable/Disable SSL for this virtual host.
SSLEngine on
# SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect. Disable SSLv2 access by default:
#SSLProtocol all -SSLv2 -SSLv3
# SSL Cipher Suite:
# List the ciphers that the client is permitted to negotiate.
# See the mod_ssl documentation for a complete list.
#SSLCipherSuite HIGH:3DES:!aNULL:!MD5:!SEED:!IDEA
# Speed-optimized SSL Cipher configuration:
# If speed is your main concern (on busy HTTPS servers e.g.),
# you might want to force clients to specific, performance
# optimized ciphers. In this case, prepend those ciphers
# to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
# Caveat: by giving precedence to RC4-SHA and AES128-SHA
# (as in the example below), most connections will no longer
# have perfect forward secrecy - if the server's key is
# compromised, captures of past or future traffic must be
# considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
#SSLHonorCipherOrder on
# 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 new
# certificate can be generated using the genkey(1) command.
### fatto con zerossl
SSLCertificateFile /etc/ssl/1000vani.it/certificate.crt
# Server Private Key:
# If the key is not combined with the certificate, use this
# directive to point at the key file. Keep in mind that if
# you've both a RSA and a DSA private key you can configure
# both in parallel (to also allow the use of DSA ciphers, etc.)
### fatto con zerossl
SSLCertificateKeyFile /etc/ssl/1000vani.it/private.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 /etc/pki/tls/certs/server-chain.crt
### fatto con zerossl
SSLCertificateChainFile /etc/ssl/1000vani.it/ca_bundle.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)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# 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.
# o 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'.
# o 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.
# o StdEnvVars:
# This exports the standard SSL/TLS related `SSL_*' environment variables.
# Per default this exportation is switched off for performance reasons,
# because the extraction step is an expensive operation and is usually
# useless for serving static content. So one usually enables the
# exportation for CGI and SSI requests only.
# o 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.
# o OptRenegotiate:
# This enables optimized SSL connection renegotiation handling when SSL
# directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
SSLOptions +StdEnvVars
</Files>
###### directory generale del sistema da togliere
#<Directory "/var/www/cgi-bin">
#SSLOptions +StdEnvVars
#</Directory>
### cartella di destinazione del dominio
DirectoryIndex index.html index.htm index.php
<Directory "/domini/1000vani.it/sicuro">
allow from all
AllowOverride All
#Options None
Require all granted
</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:
# o 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.
# o 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.
# Similarly, one has to force some clients to use HTTP/1.0 to workaround
# their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
# "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
# 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>
###### Porta 443 - Fine
########################
Com'è facilmente osservabile la cartella sulla quale ho inviato il file è chiamato sicuro.
Questo perché, per contraltare andiamo a vedere il VH della porta 80 (che metteremo di seguito)
########################
###### Porta 80 - Inziio
###
### - www.1000vani.it:80
### - Con accesso con .htaccess
### - e con error.log
######
<VirtualHost www.1000vani.it:80>
DocumentRoot "/domini/1000vani.it/non-sicuro"
ServerName www.1000vani.it:80
<Directory "/domini/1000vani.it/non-sicuro">
allow from all
AllowOverride All
#Options None
Require all granted
</Directory>
</VirtualHost>
###### Porta 80 - Fine
######################
Dopo la fine della definizione della Porta 80, va riportato questo codice (inamovibile):
########################################
# Parte che deve stare qua a fine file
#
# INAMOVIBILE
########################################
# Begin copied text
# from https://cipherli.st/
# and https://raymii.org/s/tutorials/Strong_SSL_Security_On_Apache2.html
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On
# Disable preloading HSTS for now. You can use the commented out header line that includes
# the "preload" directive if you understand the implications.
#Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains; preload"
Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains"
Header always set X-Frame-Options DENY
Header always set X-Content-Type-Options nosniff
# Requires Apache >= 2.4
SSLCompression off
SSLUseStapling on
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"
# Requires Apache >= 2.4.11
# SSLSessionTickets Off
Qui avremo l'accesso ad una cartella differente che conterrà un testo che ci dirà che il sito non è sicuro
A questo punto non ci resta che salvare tutto e riavviare il Servizio httpd (sempre sotto root)
sudo systemctl restart httpd
In aggiunta ci sono anche gli ulteriori comandi
sudo systemctl stop httpd
sudo systemctl start httpd
Il risultato
Per meglio osservare il risultato è consigliabile usare o FireFox o Microsoft Edge, poiché Google Chrome caricherà per default il sito con https, bypassando il nostro test
Se digitiamo nella barra degli indirizzi
avremo questo risultato
Questo è il testo della pagina html relativa alla cartella
/domini/1000vani.it/non-sicuro
Se invece sempre su Edge o FireFox digitiamo
Questo è il testo relativo alla pagina sotto SSL
Quindi è possibile non solo creare lo stesso sito con e senza la possibilità di accedere alla stessa cartella, ma è anche possibile creare un sito sicuro ed uni non sicuro dove il discriminante è solo una s dopo http
Osservazione: L'osservazione che nasce spontanea è il concetto che sta alla base dei siti con SSL.
Di base SSL come detto serve a dare una sicurezza per quanto riguarda applicazioni specifiche come eCommerce e accessi ad aree riservate di qualunque tipo.
I nuovi algoritmi di SEO di Google (e non solo) danno un chep in più di affidabilità ai siti che usano tecnologia SSL rispetto ai vecchi siti su porta 80 a scapito, però, dell'utenza che non necessariamente hanno necessità di creare delle connessioni sicure.
Un caso su tutti possono essere i blog che fanno informazione pubblica senza necessità di accesso ad area riservata diventa quasi uno spreco di denaro, anche perché un certificato SSL costa non meno di 30€ l'anno se non associato ad un hosting come nel caso di alcuni ISP o tipologie di contratto.
Nota: Sotto SSL, potrebbe non funzionare il costrutto iframe (X-Frame-Options), clicca qui per vedere come risolvere il problema
Commenti