Menu

Certificats SSL [Résolu]

Messages postés
440
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
5 juillet 2019
- - Dernière réponse : mamiemando
Messages postés
28871
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
10 juillet 2019
- 10 juil. 2019 à 10:40
Bonjour,

J'ai de plus en plus l'impression qu'on pousse à faire marcher le commerce de l'Internet. En effet, jusqu'ici, je faisais mes sites web en PHP/MySQL avec ou sans répertoires protégés, avec ou sans connexion (http://.....) sans problème.

Depuis quelque temps, quand on accède à un répertoire protégé ou quand on se connecte, les navigateurs les plus connus comme Mozila Firefox, par exemple, mentionnent systématiquement à l'arrivée dans une zone "login" ou "password" le message : "Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus". Ce qui fait en effet, très mauvaise impression sur les visiteurs. La seule façon d'éviter ce message risquant de repousser ou au mieux de faire hésiter les internautes, est d'acheter (annuellement) un certificat SSL et qui n'est pas donné (c'est pour cela que je parle du "pousse à la consommation").

J'ai posé la question à mon hébergeur qui, naturellement, m'invite à acheter un certificat SSL et me dit : "La programmation du site web doit être adaptée pour utiliser du SSL. Si vous utilisez Wordpress ou d'autres CMS c'est assez facile de passer en HTTPS. En tout cas il faut analyzer chaque site web." (sic pour analyzer) Mais, comme Devos, j'ai des doutes...

D'une part, je crois savoir qu'Apache (sur mon VPS) qui gère les hôtes virtuels redirige les visiteurs vers le site approprié. Si le protocole utilisé est http, il redirige vers le chemin approprié (par exemple: le protocole http, port 80, trouvera les pages en /var/www/vhosts/mon.domaine.fr/httpdocs ou le protocole https, port 443, trouvera les pages en /var/www/vhosts/mon.domaine.fr/httpsdocs) mais la page PHP qui se trouve dans l'un ou l'autre répertoire est produite de la même façon par le compilateur PHP qui se trouve sur le serveur. Il n'y a donc pas, selon moi mais ai-je raison, de programmation appropriée pour l'utilisation de SSL en dehors du fait que, dans les pages, s'il y a des adresses à écrire, il faudrait les écrire avec le bon protocole (http:// ou https://), c'est tout.

Ma première question est donc : Est-ce qu'en dehors des adresses (où l'on écrira https:// à la place de http://) la programmation PHP/MySQL doit changer ou faut-il réécrire toutes les pages ?

J'ai vu dans le répertoire /etc/ssl/certificates/ les certificats des autorités de certification (ex: Thawte_Server_CA.crt) et dans le répertoire /etc/ssl/private/ un seul fichier, clef privée (ssl-cert-snakeoil.key). J'ai vu aussi qu'on pouvait obtenir gratuitement (pour une période de 6 mois ou 1 an) un certificat SSL auprès de CAcert.org (ou de Let's Encrypt). Peut-on utiliser un certificats auprès de ce service et le placer dans ces répertoires ?

Bref, ma seconde question est : Est-il possible d'utiliser un certificat obtenu ailleurs que chez mon hébergeur et si oui, comment ?

Merci beaucoup pour vos réponses.

Configuration: Dual boot: Windows XP Pro SP3 / Debian Linux

Afficher la suite 

4 réponses

Meilleure réponse
Messages postés
28871
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
10 juillet 2019
6596
2
Merci
Bonjour,

1) Non c'est quasiment transparent. Côté client client les changements sont mineurs (
https://monsite.com
au lieu de
https://monsite.com
), mais maintenant c'est sécurisé. Côté serveur, il n'y a rien à faire côté code mais il va faire de la configuration à savoir (illustré avec les commandes qu'on lancerait sous debian/ubuntu) :

a) activer le module ssl

sudo a2enmod ssl
sudo service apache2 restart


b) éventuellement corriger/compléter la configuration de ton (tes) vhost(s) apache. Généralement on déclare un vhost pour le site en https et un pour le site en http. À terme on pourra supprimer le vhost http. Sous debian on configurerait typiquement
/etc/apache2/sites-available/https.monsite.com.conf
ainsi pour un wordpress :

<IfModule mod_ssl.c>
        <VirtualHost _default_:443>
                ServerAdmin webmaster@monsite.com
                ServerName monsite.com

                DocumentRoot /usr/share/wordpress
                Alias /wp-content "/var/lib/wordpress/wp-content"

                <Directory /usr/share/wordpress>
                        Options FollowSymLinks
                        AllowOverride Limit Options FileInfo
                        DirectoryIndex index.php
                        Require all granted
                </Directory>

                <Directory /var/lib/wordpress/wp-content>
                        Options FollowSymLinks
                        Require all granted
                </Directory>

                # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
                # error, crit, alert, emerg.
                # It is also possible to configure the loglevel for particular
                # modules, e.g.
                #LogLevel info ssl:warn

                ErrorLog ${APACHE_LOG_DIR}/error.log
                CustomLog ${APACHE_LOG_DIR}/access.log combined

                # For most configuration files from conf-available/, which are
                # enabled or disabled at a global level, it is possible to
                # include a line for only one particular virtual host. For example the
                # following line enables the CGI configuration for this host only
                # after it has been globally disabled with "a2disconf".
                #Include conf-available/serve-cgi-bin.conf

                #   SSL Engine Switch:
                #   Enable/Disable SSL for this virtual host.
                SSLEngine on

                #   A self-signed (snakeoil) certificate can be created by installing
                #   the ssl-cert package. See
                #   /usr/share/doc/apache2/README.Debian.gz for more info.
                #   If both key and certificate are stored in the same file, only the
                #   SSLCertificateFile directive is needed.
                SSLCertificateFile      /etc/letsencrypt/live/www.lincs.fr/fullchain.pem
                SSLCertificateKeyFile /etc/letsencrypt/live/www.lincs.fr/privkey.pem

                #   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/apache2/ssl.crt/server-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 /etc/ssl/certs/
                #SSLCACertificateFile /etc/apache2/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 /etc/apache2/ssl.crl/
                #SSLCARevocationFile /etc/apache2/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

                #   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 OptRenegotiate:
                #        This enables optimized SSL connection renegotiation handling when SSL
                #        directives are used in per-directory context.
                #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
                <FilesMatch "\.(cgi|shtml|phtml|php)$">
                                SSLOptions +StdEnvVars
                </FilesMatch>
                <Directory /usr/lib/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:
                #   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-6]" \
                #               nokeepalive ssl-unclean-shutdown \
                #               downgrade-1.0 force-response-1.0

        </VirtualHost>
</IfModule>



c) s'assurer que le site est joignable désormais en https (et donc éventuellement corriger les règles de ton pare-feu aka
iptables
).

À ce stade le site devrait devenir joignable en https mais avec un cadenas rouge (certificat invalide, et visible en ajoutant une exception de sécurité, etc...).

2) Le plus simple comme évoqué plus haut est de récupérer un certificat à l'aide de letsencrypt, simple à mettre en place sous linux (il suffit d'installer le paquet correspondant,
certbot-apache
) et gratuit.

sudo apt-get update
sudo apt-get install certbot python-certbot-apache
sudo certbot --apache
sudo certbot renew --dry-run
sudo certbot renew --quiet


Une fois certbot configuré, le cadenas deviendra vert.

Bonne chance

Dire « Merci » 2

Heureux de vous avoir aidé ! Vous nous appréciez ? Donnez votre avis sur nous ! Evaluez CommentCaMarche

CCM 53385 internautes nous ont dit merci ce mois-ci

heliconius
Messages postés
440
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
5 juillet 2019
78 -
avion-f16:
merci pour ta réponse détaillée mais j'avais bien compris la finalité de la sécuristation SSL et de la possibilité d'interception entre le client et le serveur et toutes les actions possibles par les "men of the middle". Je voulais simplement dire qu'acheter une sertificat 150 €/an pour un site professionnel, ça se justifie mais pour un petit site perso sans aucune donnée sensible c'est quand même un peu fort de café. Et les visiteurs devant de tels messages (tout le monde n'a pas ta connaissance sur le sujet, et j'en connais qui sont très basiques) éprouvent une impression de suspicion sur le site pourtant sans secret ni danger, suspicion qu'on ne peut écarter qu'avec une bonne centaine d'euros. Les hébergeurs devraient alors fournir, avec l'hébergement, un certificat SSL quand il s'agit d'un site non professionnel. Mais bien sût ils profitent de la vague et vendent, la plupart du temps plus cher que l'hébergement lui-même (je parle pour les petits sites).

Merci infiniment pour cette aide à la configuration. Je vais détailler ça et m'y atteler. Ayant eu les explications et les docs nécessaires, je marque le sujet Résolu. En cas de besoin, je reviendrai faire un tour... ;-)

En tout cas, merci.
avion-f16
Messages postés
18301
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
10 juillet 2019
4081 -
Mon message était plutôt destiné à WalterP, suite à son message, dans lequel j'ai décelé une confusion entre le rôle de HTTPS et la sécurité du site en lui-même :)

Je trouve que la généralisation de HTTPS est un gros plus pour la sécurité et la confidentialité, même pour les sites qui semblent "sans information confidentielles". Le simple fait d'utiliser HTTPS empêche les FAI/gouvernement de savoir ce qu'on fait en ligne. Même s'ils peuvent encore voir à quelle IP on se connecte, ils ne peuvent plus savoir quel site on visite (si le serveur héberge plusieurs sites, car le site à afficher est déterminé sur base de l'entête HTTP "Host" qui est alors chiffrée), ni les pages qu'on consulte.

Concernant le prix des certificats, heureusement qu'il y a Let's Encrypt, et la plupart des hébergeurs l'intègrent et, de mon point de vue, je n'ai pas l'impression qu'ils poussent à l'achat d'autres certificats. Le problème, c'est que à ma connaissance, il n'y a que Let's Encrypt qui délivre des certificats gratuits. Donc le forcing vers le HTTPS nous oblige à être dépendant d'une seule entité (Let's Encrypt), ou de nous pousser à débourser auprès des autres autorités de certifications payantes. Espérons donc qu'on ait pas un retour de bâton de la part de Let's Encrypt dans quelques temps. (Il y a aussi cPanel qui délivre des certificats "gratuits", mais c'est pas du gratuit car il faut payer une licence)
heliconius
Messages postés
440
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
5 juillet 2019
78 > avion-f16
Messages postés
18301
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
10 juillet 2019
-
OK. La durée de validité de Let's Encrypt est de trois mois, je crois. S'il est fourni par l'hébergeur, son interface de gestion peut s'occuper de le renouveler automatiquement. Mais cela dépend de l'hébergeur. Le mien pourrait s'en occuper mais pour ça, il me faudrait un autre hébergement plus "musclé" et plus cher, naturellement. Je pourrais aussi le faire "à la main" mais :
1) il faut penser à le renouveler périodiquement tous les trois mois sinon le site deviendrait inaccessible. A moins de faire ça par un cron mais il faut prendre le temps de détailler tout ça.
2) j'aurai un peur peur aussi de "foutre la zone" dans la configuration de l'interface graphique de gestion (Plesk) dont les fichiers de configuration sont assez con-Plesk :-) même si son utilisation graphique est simple.

Mais tu as d'autres autorités de certifications que Let's Encrypt qui délivrent des certificats SSL gratuits. Tu as CAcert.org qui délivre des certificats pour une durée variable entre 6 mois et 2 ans selon le nombre de points acquis par un système d'accréditation un peu similaire à la toile de confiance de GPG/PGP. Tu peux te faire accréditer et/ou devenir accréditeur. Cela joue sur la durée de validité du certificat. Va voir et inscris toi et tu liras leur dispositif ; ça fait longtemps que ça existe.

Le sujet étant clos, je ne sais si tu seras averti de ce message. Confirme le moi et, si je n'ai pas de réponse, je t'enverrai ça en MP.
mamiemando
Messages postés
28871
Date d'inscription
jeudi 12 mai 2005
Statut
Modérateur
Dernière intervention
10 juillet 2019
6596 -
OK. La durée de validité de Let's Encrypt est de trois mois, je crois.

En fait
certbot
s'occupe de renouveler ledit certificat automatiquement pour toi. C'est juste un démon qui tourne sur la machine en question. Si tu suis les étapes que je t'ai indiqué il n'y a rien de plus à faire, ensuite tu as ton certificat gratuitement et indéfiniment. Donc plus besoin de se prendre la tête ;-)

Et ça c'est un énorme plus. Une solution classique (même gratuite) pose un problème de taille : tu dois penser à renouveler toi même le certificat. Si tu oublies ton site affiche côté client une erreur de sécurité ce qui est généralement assez dissuasif pour la plupart des utilisateurs.

Enfin,
certbot
agit purement au niveau apache/nginx. A priori les règles configurées sont telles qu'elle n'impacte pas le fonctionnement du site (les règles ajoutées sont typiquement du genre, http://monsite.com devient https://monsite.com). Le vhost sous jacent n'est a priori pas impacté par de telle règle, même si bon nombre de framework sont basés sur des redirections au niveau du serveur web, car ce n'est pas le préfixe de l'URL qui est pris en compte. Donc plesk ou autre n'ont aucune raison d'être impacté, et encore une fois, c'est certbot qui s'occupe d'adapter la configuration apache, pas toi :-)
Commenter la réponse de mamiemando
Messages postés
36608
Date d'inscription
dimanche 7 novembre 2010
Statut
Contributeur
Dernière intervention
12 juillet 2019
3679
1
Merci
Salut,

Question 2 : Let's Encrypt ;-))

Commenter la réponse de zipe31
Messages postés
97
Date d'inscription
lundi 24 mars 2014
Statut
Membre
Dernière intervention
3 juillet 2019
1
1
Merci
Merci heliconius pour cet article ,

je viens de comprendre maintenant pourquoi mon site créé sur Unblog.fr n'est pas en https et pourquoi Mozilla m'indique à chaque connexion " Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus ".

Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté !

Thank you and good luck !
heliconius
Messages postés
440
Date d'inscription
mardi 1 juillet 2008
Statut
Membre
Dernière intervention
5 juillet 2019
78 -
Oui, ça marche comme avant mais c'est repoussant pour les visiteurs...
avion-f16
Messages postés
18301
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
10 juillet 2019
4081 -
Bonjour,

En lisant ce message, j'ai l'impression que tu ne saisis pas le but de HTTPS et des connexions sécurisées, en général. Le but de ces connexions "SSL/TLS" est de mettre en place un cryptage de bout en bout, et faisant intervenir des certificats et des clés de cryptage privées, pour éviter qu'un intervenant "au milieu" n'écoute ou modifie les échanges entre le client/navigateur et le serveur.

« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »

Les navigateurs récents affichent les sites en HTTP comme "non sécurisé" dans le sens où les communications transitent en clair. Cela ne concerne pas la "sécurité" du site en lui-même, mais ces échanges en clair peuvent contenir des données sensibles (dont les mots de passe mais pas seulement) et être modifiés.

Lorsqu'un site est accessible en HTTPS, il est marqué comme "sécurisé" par le navigateur dans le sens où les échanges sont cryptés. Cela ne signifie pas que le site est dénué de vulnérabilités, que ton compte sur ce site ne sera jamais piraté, etc.

« Au départ je pensais que cette plate-forme ( Unblog.fr ) n'était pas sécurisée , ou l'était moins que les autres qui sont en https . Mais j'ai bien dû me rendre compte au fil du temps qu"il n'en était rien car mon site perso créé sur Unblog.fr n'a jamais été attaqué et que je n'ai jamais vu sur le forum Unblog.fr de plainte au sujet d'un site piraté ! »

Personnellement, je suis étonné de voir http://unblog.fr/wp-login.php sans HTTPS...

Si cette plateforme utilise uniquement du HTTP (et c'est le cas), alors navré de te l'apprendre, mais elle est bel et bien moins sécurisée que les autres sites en HTTPS.
Lorsque tu saisis tes identifiants pour te connecter à ton compte, tous les intervenants situés entre toi et le serveur pourraient récupérer le mot de passe. Ces intervenants sont généralement des sociétés sérieuses (ton FAI et les autres) et donc ne pratiquent pas cela. En tout cas, probablement pas pour le le blog d'un client lambda... et pour le reste (des choses plus sérieuses), peut-être le font-ils discrètement, aller savoir.
Il est aussi possible qu'une personne connectée à ton réseau écoute ces échanges, qu'il s'agisse d'un réseau WiFi ouvert ou d'un réseau privé câblé. Même si ces personnes n'ont que de bonnes intentions, es-tu sûr qu'aucun de ces ordinateurs ne soit infecté pas un virus qui pourrait se contenter d'être passif et ramasser un maximum d'informations ?
Pour les sites qui utilisent HTTPS uniquement sur la partie "formulaire de connexion" en pensant que le reste n'est pas important, ils se mettent le doigt dans l'œil : ces autres pages anodines qu'on pense sans grand intérêt pour les hackers, contiennent quand même des informations sensibles ou permettent de faire des actions avec des conséquences (des actions que la hacker pourrait exécuter).

Il y a aussi les attaques "actives", où le "man in the middle" passer au niveau supérieur, il peut modifier les échanges et cela ouvre un autre éventail de possibilités.

Comme exemple, prenons un logiciel qui interroge un serveur en HTTP pour savoir s'il y a une nouvelle mise à jour. Le hacker peut intervenir pour que la réponse soit "oui". Le logiciel demande alors au serveur, toujours en HTTP, l'adresse du nouveau .exe. Le hacker modifie encore la réponse et pousser le téléchargement de son propre .exe. Ce .exe est exécuté par l'application pour l'installation automatique.

Désolé si cela était déjà clair pour toi, mais j'ai eu l'impression que ça n'était pas le cas :)
WalterP
Messages postés
97
Date d'inscription
lundi 24 mars 2014
Statut
Membre
Dernière intervention
3 juillet 2019
1 -
Merci avion-f16 pour cette explication ! Non , ce n'était absolument pas clair du tout pour moi auparavant , et d'ailleurs je crois bien que je vais devoir relire une fois ou deux ton explication ! :)

Il s'agit donc plus du cryptage que de la vulnérabilité du site ! Enfin , disons les 2 si j'ai bien compris . En http les portes d'entrée sont donc ouvertes à beaucoup de monde ...

Lorsque je vais sur mon site Unblog je vois en Url : 1collection.unblog.fr/ et non pas http://1collection.unblog.fr/ . Le http était donc caché et je me demandais bien pourquoi ?

Mais bon , ce site Unblog n'est pas mon site principal , il n'y a aucune donnée sensible , je l'ai pris en exemple car c'est le seul qui m'indique :

« Cette connexion n'est pas sécurisée. Les identifiants saisis ici pourraient être compromis. En savoir plus »

J'utilise Unblog car ce site est rapide , fonctionne très bien et il a une présentation qui me convient bien . Sinon mon site principal est sur wordpress qui est en https , et donc certainement sécurisé je suppose ... :)

En tous cas j'apprécie l'explication que tu as donné ci-dessus et je vais la relire ...

Merci avion-f16 et à plus ...
Commenter la réponse de WalterP
Messages postés
1398
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
13 juillet 2019
67
0
Merci
Salut,

Pour ce qui est de la reecriture du code, tu peux sed :
sed -i -e 's_http_https_g' /usr/local/share/nginx/index.php


Ou tu peux mettre en place des redirections temporaire/permanente dans la configuration de ton apache / nginx / etc...

A plus
Exileur
Messages postés
1398
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
13 juillet 2019
67 -
Et sinon sans commentaires concernant l'envoi de mot de passe sans chiffrement .
avion-f16
Messages postés
18301
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
10 juillet 2019
4081 -
Les redirections http -> https sont une fausse bonne idée, elle est nécessaire mais pas suffisante : la première requête sera en HTTP et peut donc être modifiée ;)
Exileur
Messages postés
1398
Date d'inscription
mercredi 31 août 2011
Statut
Membre
Dernière intervention
13 juillet 2019
67 -
C'est exacte. Le mieux serait d'appliquer les deux solutions :)
En plus de bien former ses utilisateurs sur les questions de sécurité! ( un petit addon sympas -> https://addons.mozilla.org/fr/firefox/addon/https-everywhere/ )
Commenter la réponse de Exileur