Just enough SSL TLS certificates
Un certificat est utilisé pour garantir la confiance entre deux devices pendant une transaction.
Par exemple, lorsqu'un utilisateur souhaite se connecter à un serveur web, les certificats TLS sont là pour assurer que la communication entre les deux est correctement chiffrée et que le serveur est là où il prétend être.
Il existe plusieurs méthodes de chiffrements.
Chiffrement symétrique
La méthode la plus simple pour chiffrer et accéder à des données est via un couple login/password.
sequenceDiagram
participant Client
participant WebServer
Note over Client: Génère une requête Q
loop Chiffrement
Client->>Client: Chiffrement via K
end
activate Client
Client->>WebServer: Enc(Q)
Client->>WebServer: clé K
deactivate Client
loop Déchiffrement
WebServer->>WebServer: Déchiffrement via K
end
Note over WebServer: Traîtement de Q
Note over WebServer: Génère une réponse A
loop Chiffrement
WebServer->>WebServer: Chiffrement via K
end
activate WebServer
WebServer->>Client: Enc(A)
deactivate WebServer
loop Déchiffrement
Client->>Client: Déchiffrement via K
endChiffrement asymétrique
Plutôt que d'utiliser une seule clé, le chiffrement asymétrique utilise une paire de clés: une clé publique et une clé privée. Pour la suite de l'explication, on peut penser à la clé publique comme un cadenas publique.
Le chiffrement asymétrique est également connu sous le nom de cryptographie à clé publique.
Un cadenas publique est mise gratuitement à la disposition de toute personne susceptible de vouloir chiffrer le message.
La seconde clé privée est gardée secrète afin que seul l'utilisateur initial puisse la connaître.
Un message crypté à l'aide d'un cadenas publique ne peut être déchiffré qu'à l'aide d'une clé privée, tandis qu'un message chiffré à l'aide d'une clé privée peut être déchiffré à l'aide d'un cadenas publique.
Seul le cadenas publique transite vers le serveur, et l'unique clé pouvant débloquer l'accès est alors la clé privée contenue sur le device du Client.
Une commande du type ssh -i id_rsa user1@server1 permet alors de se connecter en ssh au serveur.
L'ensemble des clés
Exemple
Dans le cas où l'on souhaite sécuriser l'accès à un WebServer via SSH. On peut alors générer la clé privée et le cadenas via la commande ssh-keygen. On a alors la clé privée id_rsa et le cadenas id_rsa.pub.
La liste des entrées possibles sur le serveur, ie les clés/cadenas publiques permettant de s'y connecter sont listées dans ~/.ssh/authorized_keys.
sequenceDiagram
participant Client
participant WebServer
loop ssh-keygen
Client->>Client: Clé privée généré K
Client->>Client: Cadenas publique <br/> généré L
end
activate Client
Client->>WebServer: L
deactivate Client
Note over WebServer : Réception de L
Note over WebServer : SécurisationUne seule clé/cadenas publique peut être utilisée pour sécuriser l'accès à plusieurs serveurs, tant que la clé privée ne fuite pas cela ne pose pas de soucis.
Dans le cas où un autre Client souhaite accéder aux serveurs, il n'a alors qu'a générer une nouvelle paire de clés pour lui via ssh-keygen et vous fournir sa clé publique. Vous ayant accès au serveur pourra alors la rajouter à la liste des clés publiques autorisées dans ~/.ssh/authorized_keys.
openssl et https
Question
Est-il possible de sécuriser le transfert de la clé K lors d'un chiffrement symétrique ?
Oui, avec du chiffrement asymétrique.
Supposons que nous sommes dans le cas d'un chiffrement symétrique, comme au dessus, et que l'on souhaite transférer de façon sure la clé de chiffrement.
Une solution est alors de créer une paire de clé côté serveur via openssl.
| Génération de la clé publique | |
|---|---|
| Génération de la clé/cadenas publique associée | |
|---|---|
- pem file difference - ssh-keygen vs openssl
- What are the differences between ssh generated keys(ssh-keygen) and OpenSSL keys (PEM)and what is more secure for ssh remote login?
- How to get a .pem file from ssh key pair?
- OpenSSL Quick Reference Guide
- 6 OpenSSL command options that every sysadmin should know
La première fois que le Client se connecte en https au serveur, il devine la clé publique générée ma_cle.pem lui ai transmise.
Le browser du Client chiffre alors la clé symétrique via la ma_cle.pem qui vient de lui être transmise.
Le couple (clé symétrique chiffrée, ma_cle.pem) fait alors le chemin inverse vers le serveur, où la clé symétrique est déchiffrée avec ma_cle.key.
sequenceDiagram
participant Client
participant WebServer
activate Client
Client->>WebServer: Première connexion https
deactivate Client
Note over Client: clé symétrique K
Note over WebServer: openssl
loop Génération
WebServer->>WebServer: ma_cle.key
WebServer->>WebServer: ma_cle.pem
end
activate WebServer
WebServer->>Client: ma_cle.pem
deactivate WebServer
loop Chiffrement via ma_cle.pem
Client->>Client: Enc(K)
end
activate Client
Client->>WebServer: Enc(K)
deactivate Client
loop Déchiffrement via ma_cle.key
WebServer->>WebServer: K
end
activate WebServer
WebServer->>Client: Accès autorisé
deactivate WebServerAfin d'éviter les problèmes, y-a-t'il un moyen de vérifier que les clés/cadenas du style ma_cle.pem que l'on reçoit du serveur sont authentiques, et non pas des clés qu'un hacker aurait pu générer en reroutant votre connexion vers son serveur ?
En réalité, le serveur n'envoie pas que la clé ma_cle.pem, il envoie aussi un certificat, qui ne contient pas uniquement la clé, mais aussi l'adresse DNS du serveur ainsi que toutes les adresse DNS alternatives par lesquelles il peut être connu.
Pour vérifier la légitimité d'un certificat, il est nécessaire qu'il soit signé, cela se fait par des autorités de certifications (CA) publiques tierces. Il est aussi possible d'avoir des autorités des certifications privées, par exemple pour chiffer le réseau interne d'une entreprise.
PKI : Public Key Infrastructure.
Certificats générés pour une clé publique :
server.crtserver.pemclient.crtclient.pem
Certificats générés pour une clé privée :
server.keyserver-key.pemclient.keyclient-key.pem
Exemple
Create a CSR (certificate signing request) /etc/httpd/csr/app01.csr (key name should be app01.key). Below are the required details which should be used while creating CSR.
- Country Name = SG
- State or Province Name = Capital Tower
- Locality Name = CT
- Organization Name = KodeKloud
- Organizational Unit Name = Education
- Common Name = app01.com
- Email Address = admin@kodekloud.com
- Keep challenge password blank.
- Keep optional company name blank.
cd into /etc/httpd/csr directory and run command sudo openssl req -new -newkey rsa:2048 -nodes -keyout app01.key -out app01.csr to generate a CSR file.
To verify the entries we used to create a CSR, run the command:
openssl req -noout -text -in app01.csr
Great! We have now generated the CSR. We must now send it to a CA to get it signed. However there is no CA available, so we will create our own self signed certificate.
On app01 create a self signed certificate /etc/httpd/certs/app01.crt (key name should app01.key). Below are the required details which should be used while creating the certificate.
- Country Name = SG
- State or Province Name = Capital Tower
- Locality Name = CT
- Organization Name = KodeKloud
- Organizational Unit Name = Education
- Common Name = app01.com
- Email Address = admin@kodekloud.com
cd into /etc/httpd/certs directory and run command sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout app01.key -out app01.crt and then pass in the details given above.
On app01 server we have an Apache web server already installed and configured and ssl mode is already enabled. In the /etc/httpd/conf.d/ssl.conf file update the SSL certificate and key to use your app01.crt and app01.key files. After making changes remember to restart Apache config.
For your reference the certificate you created in the previous steps is at /etc/httpd/certs/app01.crt and the key is at /etc/httpd/certs/app01.key. The properties in the file are SSLCertificateFile and SSLCertificateKeyFile. To test if server is using correct certificate or not run this command and check if it returns your certificate:
echo | openssl s_client -showcerts -servername app01.com -connect app01:443 2>/dev/null | openssl x509 -inform pem
Modify the settings in the file /etc/httpd/conf.d/ssl.conf to point to the self signed cert and key you created. Then restart httpd service using the command sudo service httpd restart.