SSL et Apache

Transcription

SSL et Apache

WEBMESTRE : CONCEPTION DE SITES ET
ADMINISTRATION DE SERVEURS WEB
Installation et administration d’un serveur web
Module 25793 TP A5 (1/2 valeur)
Chapitre 12
SSL et Apache
Le plus grand soin a été apporté à la réalisation de ce support pédagogique afin de vous fournir une information
complète et fiable. Cependant, le Cnam Champagne-Ardenne n'assume de responsabilités, ni pour son
utilisation, ni pour les contrefaçons de brevets ou atteintes aux droits de tierces personnes qui pourraient résulter
de cette utilisation.
Les exemples ou programmes présents dans cet ouvrage sont fournis pour illustrer les descriptions théoriques.
Ils ne sont en aucun cas destinés à une utilisation commerciale ou professionnelle.
Le Cnam ne pourra en aucun cas être tenu pour responsable des préjudices ou dommages de quelque nature
que ce soit pouvant résulter de l'utilisation de ces exemples ou programmes.
Tous les noms de produits ou autres marques cités dans ce support sont des marques déposées par leurs
propriétaires respectifs.
Ce support pédagogique a été rédigé par Michel Melcior, enseignant vacataire au Cnam Champagne-Ardenne.
Copyright  2001-2003 Centre d'Enseignement A Distance du Cnam Champagne-Ardenne.
Tous droits réservés.
Toute reproduction, même partielle, par quelque procédé que ce soit, est interdite sans autorisation préalable du
Cnam Champagne-Ardenne. Une copie par xérographie, photographie, film, support magnétique ou autre,
constitue une contrefaçon passible des peines prévues par la loi, du 11 mars 1957 et du 3 juillet 1995, sur la
protection des droits d'auteur.
CONSERVATOIRE NATIONAL DES ARTS ET METIERS
SSL ET APACHE
1. OBJECTIFS
En fin de séance, vous devriez être capable :
•
•
De décrire les mécanismes de cryptage par paires de clefs et l'utilité des certificats.
De créer une clef privée et un certificat de test et utiliser l'ensemble avec Apache.
2. INTRODUCTION
Le protocole HTTP n'est pas conçu pour apporter une quelconque sécurité. Les échanges d'informations se font
en clair dans les paquets qui circulent sur le réseau.
Il suffit, par exemple, d'insérer un analyseur de réseau entre le client et le serveur pour reconstituer très
facilement l'ensemble des informations échangées.
Ce mode de fonctionnement n'est pas acceptable pour certains types d'échanges comme :
Les transactions financières avec échange d'informations comme des numéros de carte bancaire ;
D'une manière générale, dès que les informations échangées prennent un caractère confidentiel.
La solution pour le traitement de ce type d'échange est le recours au chiffrement des transactions.
Le module d'Apache permettant d'obtenir ce résultat s'appelle mod_SSL.
SSL signifie Secure Socket Layer. C'est un protocole de sécurisation des échanges, développé par Netscape. Il
a été conçu pour assurer la sécurité des transactions sur Internet (notamment entre un client et un serveur), et il
est intégré depuis 1994 dans les navigateurs.
Il existe plusieurs versions: la version 2.0 développée par Netscape; la version 3.0 qui est actuellement la plus
répandue, et la version 3.1 baptisée TLS (transport Layer Security, RFC 2246) et standardisée par l'IETF
(Internet Engineering Task Force).
SSL fonctionne de manière indépendante par rapport aux applications qui l'utilisent; il est obligatoirement audessus de la couche TCP et certains le considèrent comme un protocole de niveau 5 (couche session). Les
données passées à TCP (couche 4, transport) vont être cryptées.
Dans la pratique, l'accès à ce type de site se fera avec une URL commençant par https et non http.
Exemple : https://www.monsite-securise.com/
Installation et administration d’un serveur web 1
3. LE CHIFFREMENT ASYMETRIQUE A DEUX CLEFS
Tout repose sur l'existence d'algorithmes de cryptage à deux clefs. Une clef est simplement un fichier comportant
une suite de bits. Voici un exemple de clef :
-----BEGIN RSA PRIVATE KEY----Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,F23A96255F3F177A
R7GcxbfXoBEprasrQY1kVk9a+LN+8roRVZjq0EJoY3t8dYHnv6yVQfi/lvLKuA0/
5yoCN/kTv0KlqpHmv/8jIBuQSCCV9cRyt9VPypEBDot52mHseubA3oWbxF3M+Nat
IP5Es11Xu6n9HtCnXf82fYAAsjAZHk5cRmYA1lOs8lekrk3jY1JpOxMzWYGPtwQw
46akos1WUeFMh6ngKehDdbRtykGcQoE+5XB1KU2btV6QaOpWLcskM8X65bIDvMvI
LIw1yjLNNkigKkV96vqWWkAWuUmiRjyAHqejAsdTMzzQ/G8dD7HuVhlpSrp8PyAA
xp8/u6Vja9BulW9k51gmlgqqlaybWjhPzKkLmwJw7yXGGrTzequHeld/FaCnOcsL
gQlnUszVl4xZb1r70vml6Exh3s/uujyqAtfywypelv7/j5bMCEY9kK+CjEHFUBub
ds+PQtfriYKsFK6igQwPixFuNT5xgRfb6vT6XWjzPYuWatyNfKLlIkGPyj9KMTHa
t/UF+m8i+bXwIPrYWre/eOCqev2GQ+kQ7vViY/3ZnnfRI211cxdUrqBAmK0aedPk
F+Cf7SmcmxmFsg6BoGeKYlxgVLIMmVcjTimq2JCLgeeQecYqmYbujd2ODjlhNDGS
v3VWEx7wFYGktl+V97+7tX29FQ6Ca0CSA4XzDkgVbXCbU1vys8zqeM2id/5SIZfl
I4nAJiCRRy7OhF1Iy/37xp59V6qjyvp/R4+ruOtdpZ2J8makyCE2+HiZMbotXo/5
cQCVK5Zz3VYIOtutU6qC2Dhg4UGHE2cBtYKMBcSNKBDl3JdIzE1UTg==
-----END RSA PRIVATE KEY----Nous appellerons une de ces deux clefs, "clef A" et l'autre "clef B".
Le principe est le suivant, un message en clair est crypté à l'aide de l'algorithme et d'une des deux clefs. Prenons
l'exemple d'un cryptage à l'aide de la clef A.
Message en clair :
"Bonjour"
Algorithme de cryptage
Message codé :
"AxdU5v"
Clef A :
"Oj5gtv49dExZa7"
En possession de la clef A et du message codé avec cette clef A, il est impossible dans un temps raisonnable de
revenir au message en clair d'origine.
Le décodage du message ne peut se faire qu'avec la deuxième clef (ici, la clef B).
SSL et Apache 2
Message codé :
"AxdU5v"
Algorithme de cryptage
Message en clair :
"Bonjour"
Clef B :
"Ph6sf34xwT8km"
Ce processus fonctionne aussi dans l'autre sens. Si on code avec la clef B, on ne peut décoder qu'avec la clef A.
Ce mécanisme nous donne une solution pour traiter les problèmes de confidentialité. Si un client se connnecte à
un serveur web SSL, celui-ci lui renvoie une des deux clefs.
Client
1. Envoi de la clef
publique
Serveur
Clef publique
Clef privée
Poste en interception
Cette clef, envoyée sur le réseau est appelée "clef publique" car n'importe quel poste placé en interception peut
la lire.
Le serveur web ne diffuse pas la deuxième clef. Pour cette raison, elle sera baptisée "clef privée".
Pour la suite des échanges, le client utilise la clef publique pour crypter les données envoyées au serveur.
2. Le client envoie une
réponse codée
Serveur
Message
crypté
Client
Clef publique
Clef privée
Si une tierce partie intercepte un message envoyé par le client, il ne pourra pas le décrypter car seul le serveur
dispose de la clef privée.
Tout le système repose sur la très grande quantité de calculs nécessaires pour réussir à décrypter un message
si l'on ne dispose que de la clef utilisée pour le crypter. Ce n'est pas impossible mais très long et fonction de la
longueur de la clef utilisée. Plus votre clef comportera de bits, plus le degré de sécurité (le temps de calcul
nécessaire pour "casser le code") sera élevé.
Les clefs actuelles autorisées assurent un degré de protection élevé contre le piratage de nature délictuel mais,
ne vous y trompez pas, les organismes gouvernementaux possèdent les moyens de calcul nécessaires pour
casser ce genre de codage en temps réel.
Le mécanisme décrit plus haut est généralement celui que vous utilisez pour accéder à des sites de paiement en
ligne.
Il est possible de le compléter en utilisant une paire de clefs également sur le client.
Clef publique
Clef privée
Client
Message
crypté
Message
crypté
Serveur
Clef publique
Clef privée
ne peut décrypter dans
aucun sens
SSL et Apache 4
Mais ce schéma n'est pas souvent utilisé car il est rare de posséder une paire de clefs sur le client.
4. LES CERTIFICATS
Nous venons de voir le principe des échanges cryptés à deux clefs.
Ils assurent la confidentialité des transactions mais une question reste posée :
Est on certain de l'identité et de la confiance que l'on doit attribuer au serveur web sécurisé par SSL ?
Le certificat est une réponse à cette question. Il est censé attester de l'identité de celui qui émet la clef publique.
Un certificat doit donc être émis par un serveur qui souhaite être crédible.
Un certificat contient principalement :
•
La clef publique de l'émetteur.
•
Des informations sur l'identité de l'émetteur.
•
Une date de validité de début et de fin.
•
Une signature électronique d'un tiers de confiance attestant l'authenticité des informations
d'identité.
La norme X509 est reconnue internationalement pour la création des certificats.
En fait, par le principe de la signature d'un tiers, on reporte le problème de la confiance sur ce tiers. ou émetteurs
de certificats (Certificate Authority, CA en anglais).
Ce sont des organismes privés, comme ceux donnés en exemple, ci-dessous qui vont se charger (moyennant
finances) d'apporter leur signature électronique aux certificats.
•
Verisign
http://www.verisign.com
•
Thawte
http://www.thawte.com
Ces organismes publient des annuaires de certificats signés par leur soin.
Les certificats X.509 en sont à la troisième version. (et depuis le 30.01.03 quatrième version)
Les certificats X509, version 3, sont utilisés dans diverses applications ou protocoles comme :
•
SSL/TLS.
•
IPSec.
•
authentification...
Pour procéder à la signature d'un certificat, l'organisme tiers effectue une condensation puis un cryptage des
données avec une clef privée.
Bien entendu, la clef publique de l'organisme est à la disposition de tous. En fait, les pré-réglages des
explorateurs comme Internet Explorer incluent une liste d'organismes certificateurs.
En voici un exemple :
SSL et Apache 6
La liste des organismes certificateurs déclarés est longue…
Pour résumer, si vous vous connectez sur un site SSL dont le certificat est signé par l'un des organismes déclaré
sur votre explorateur, vous n'aurez pas d'alerte de sécurité car le site sera crédité d'un certain niveau de
confiance.
La première étape du schéma de base des échanges entre serveur SSL et client devient donc :
1. Envoi du certificat contenant la
clef publique du serveur et crypté
par la clef privée du certificateur
Le client possède la clef
publique de l'organisme de
certification en pré-réglage
Serveur
Client
Clef publique
Clef publique
Clef privée
Certificateur
Clef privée
Si le certificat n'est pas signé par un organisme reconnu, vous aurez une alerte au moment de la connexion au
serveur https comme ci-dessous :
Ce sera à vous de décider si vous pouvez faire confiance ou non à ce site.
L'effet est plutôt désastreux sur un client qui ne connaît pas le site et qui ne sait pas encore s'il doit lui accorder
sa confiance.
Il est donc fortement conseillé de se faire signer un certificat par un organisme réputé "sérieux".
La procédure à suivre est la suivante :
On génère la paire de clefs puis on s'adresse à l'organisme certificateur en lui envoyant une demande, la clef
publique, les justificatifs demandés (inscription au registre du commerce, preuve de la possession du nom de
domaine…), et le prix fixé (comptez 200$ par an au minimum).
SSL et Apache 8
5. LA CONFIGURATION INSTALLEE PAR DEFAUT
Vous avez installé une distribution RedHat ou Mandrake.
OpenSSL est probablement déjà installé.
Testez le fonctionnement avec un https://127.0.0.1/
Examinez le certificat proposé.
Les fichiers de configurations relatifs au fonctionnement de SSL et d'Apache sont dans le répertoire
/etc/httpd/conf/ssl.
Les clefs et certificats sont dans le répertoire /etc/ssl/apache.
L'activation de SSL est effectué avec la directive SSLengine on . Repérez cette directive.
Cette directive peut s'utiliser dans un contexte serveur ou d'hôte virtuel.
On peut forcer l'accès SSL à un répertoire avec la directive SSLrequireSSL admise dans des conteneurs
Directory ou Location.
6. CREATION DE CLEFS ET D'UN CERTIFICAT DE TEST
OpenSSL va vous servir à créer des clefs et des certificats non signés par un organisme officiel. Cela sera
suffisant pour des tests ou dans le cadre d'un intranet.
Nous allons commencer par créer une clef au standard rsa, privée, de 1024 bits. L'algorithme de cryptographie
utilisé sera "des3" réputé résistant.
Notez le nom (localhost) de votre serveur web.
Ouvrez une console en tant que root et créez vous un dossier /etc/httpd/conf/clefs
Déplacez vous dans ce dossier et exécutez la commande :
openssl genrsa –des3 1024 > localhost.key
Un mot de passe vous sera demandé (toto).
Nous allons créer maintenant le fichier requête pour une demande de certificat avec la commande :
openssl req -new -key localhost.key -out localhost.csr
Répondez aux questions posées ou simplement tapez "." si vous ne souhaitez pas compléter un champ.
SSL et Apache 10
Nous allons enfin créer le certificat provisoire avec la commande (sur une ligne) :
openssl req –x509 -key localhost.key -in localhost.csr -out localhost.crt
Il ne reste qu'à déclarer les fichiers localhost.key et localhost.crt à la place de ceux utilisés dans le fichier
/etc/httpd/conf/ssl/ssl.default-vhosts.conf
Le seul problème est qu'il faudra entrer le mot de passe au prochain démarrage d'Apache.
Il va falloir passer automatiquement votre mot de passe au démarrage en changeant la valeur de la
directive SSLPassPhraseDialog (actuellement à builtin) du fichier mod_ssl.conf.
Créez un fichier /etc/httpd/conf/clefs/sslpasswd, éditez-le et, si votre mot de passe est "toto" entrez :
#!/bin/sh
echo toto
Rendez ce fichier exécutable puis modifiez la ligne SSLPassPhraseDialog du fichier mod_ssl.conf
comme suit :
SSLPassPhraseDialog exec:/etc/httpd/conf/clefs/sslpasswd
Vous pouvez redémarrer Apache et tester l'accès au site sécurisé avec un navigateur.
7. ANNEXE.
7.1. LE FICHIER MOD_SSL.CONF
<IfModule mod_ssl.c>
##-------------------------------------------------------------------------## Add additional SSL configuration directives which provide a
## robust default configuration: virtual server on port 443
## which speaks SSL.
##-------------------------------------------------------------------------##
## SSL Support
##
## When we also provide SSL we have to listen to the
## standard HTTP port (see above) and to the HTTPS port
##
Listen 443
##
##
##
##
##
##
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
#
AddType application/x-x509-ca-cert .crt
AddType application/x-pkcs7-crl
.crl
#
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
dbm:logs/ssl_scache
SSLSessionCache
shm:logs/ssl_scache(512000)
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.
SSL et Apache 12
SSLRandomSeed startup builtin
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random
#SSLRandomSeed startup file:/dev/urandom
#SSLRandomSeed connect file:/dev/random
#SSLRandomSeed connect file:/dev/urandom
512
512
512
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>
7.2. LE FICHIER SSL.DEFAULT-VHOST.CONF
<IfModule mod_ssl.c>
##
## SSL Virtual Host Context
##
<VirtualHost _default_:443>
# General setup for the virtual host
DocumentRoot /var/www/html
#ServerName new.host.name
#ServerAdmin [email protected]
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:!EXPORT56: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 /etc/ssl/apache/server.crt
#
#
#
Server Private Key:
If the key is not combined with the certificate, use this
directive to point at the key file.
SSLCertificateKeyFile /etc/ssl/apache/server.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/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/ssl.crt
#SSLCACertificateFile @@ServerRoot@@/conf/sssl/sl.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/ssl.crl
#SSLCARevocationFile @@ServerRoot@@/conf/ssl/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
SSL et Apache 14
#
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
#
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"
RewriteEngine On
RewriteOptions inherit
</VirtualHost>
</IfModule>

SSL et Apache

Transcription

Documents pareils

Document 578151

Messagerie académique sur Smartphone Android

HyperText Transfer Protocol Secure Sommaire Définition

Télécharger le cas d`étude

TP-IIS Certificats

Fiche produit HUBLOT AXIOME T1 E27 1X42W HF SSL

Fiche produit DOME APPLIQUE E27 75W SSL HF BLC