Https

De Mi caja de notas

Révision datée du 3 novembre 2019 à 17:58 par Xtof (discussion | contributions)
(diff) ← Version précédente | Voir la version actuelle (diff) | Version suivante → (diff)


Cette page a démarré sur iwc:https et migrera après traduction sur iwc:https-fr

HTTPS est l'abréviation de Hypertext Transfer Protocol Secure, littéralement « protocole de transfert hypertexte sécurisé », supporté par les serveurs web (comme Apache & nginx) et les navigateurs. HTTPS est la combinaison du Protocole de Transfert Hypertexte (HTTP) avec une couche de chiffrement comme les protocoles SSL/TLS.

Pourquoi

Pourquoi ?

  • Confidentialité par défaut. Tim Bray a posté sur le fait de servir son site via https (https://www.tbray.org/ongoing/When/201x/2012/12/02/HTTPS)
    • "Ce blog n'est pas très controversé, mais si les choses "controversées" sont privées, alors la vie privée est elle-même suspecte.
    • "Parce que je peux, c'est la seule petite partie de l'Internet où j'ai le contrôle complet." (https://willnorris.com/2012/12/all-https-all-the-time)
  • Réduire la persécution politique/religieuse/sociale. Si l'employeur d'un lecteur, une école/université, une communauté religieuse ou la famille suivent l'usage du net, activer le HTTPS/SSL veut dire qu'ils ne peuvent pas voir quelles sont les pages spécifiques qui ont été vues sur ce site. C'est un bon outil (loin d'être parfait) pour se protéger contre les "petits adversaires" —persécuteurs politiques, des membres de la famille homophobes, des communautés religieuses intolérantes à la critique ou à la libre pensée— de voir quelles sont les pages d'un site Web particulier que quelqu'un est en train de regarder.
    • tommorris : Si je me trompe de cybersécurité, certains de mes amis pourraient ne pas avoir de maisons.
  • Gains de performance à utiliser HTTP/2 (https://www.httpvshttps.com). La plupart des vendeurs de navigateurs ont décidé de n'implémenter que HTTP/2 au lieu de TLS, i.e. https://. [1]
  • Rang de recherche. Google classe désormais les sites https plus haut que les sites non-https (http://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-ranking-signal_6.html)
  • Intégrité de pubication. Si vos pages sont distribuées via https, les ISP's, ou quiconque au milieu, ne peuvent pas injecter de contenu et des headers dans votre site - c'est à dire :
  • Réduire le traçage niveau opérateur

Comment faire

Obtenir un certificat

Acheter ou obtenir des certificats SSL gratuits aujourd'hui

  • Let's Encrypt est une autorité ouverte de certificat, gratuite, automatisée, qui existe pour le bénéfice public. Sponsorisée par Mozilla et l'Electronic Frontier Foundation, parmi d'autres, Let’s Encrypt automatise et vous évite les maux de crâne, et permet aux opérateurs de site d'activer et de gérer HTTPS avec de simples commandes.
  • StartSSL offre des certificats SSL gratuits pour les domaines uniques. Si vous vérifiez votre identité, ils vous permettent aussi d'enregistrer des certs gratuits wildcard. Néanmoins, en 2016 il a été retiré du certificat racine de Mozilla et d'Apple. cf iwc:StartSSL#Criticism
  • namecheap.com offre des certificats SSL domaine-unique pour $7.95/year et des certificats wildcard pour $85/year
  • GlobalSign offre des certificats wildcard gratuits (!) pour les projets open source.
  • ssls.com a des certificats SSL bon marché provenant de plusieurs fournisseurs. En date du 2014/03/08, un certificat PositiveSSL valait $4.99/an pour un engagement sur 5 ans. Ils fournissent aussi des certificats SSL *gratuits* SSL pour des périodes de 90 jours.
  • CAcert est une organisation à but non lucratif qui fournit des certificats wildcard gratuits. Malheureusement le certificat racine n'est pas inclus par défaut dans la majorité des systèmes d'exploitation et navigateurs. Ces certs sont généralement utilisés dans la communauté GNU.
  • Amazon Web Services fournit des certificats SSL gratuits qui peuvent être utilisés avec d'autres services Amazon. Il n'y a pas d'installation requise autre que de cliquer dans l'interface web.
  • WoSign est une autorité de certification qui offre des certificats validés pour les domaines. Néanmoins, en 2016 elle a été retirée du certificat racine de Mozilla et Apple. Voir iwc:StartSSL#Criticism

Valider votre Achat

Les fournisseurs de certificats SSL exigent quelque forme de validation de vous, votre domaine, et votre propriété du domaine.

Génération CSR — Une "Certificate Signing Request" doit être générée pour votre site. Par exemple, sur un fournisseur d'hébergement qui utilise Cpanel, le "Manager SSL/TLS" a une section "Certificate Signing Requests".

Approuver Email — ssls.com asks for an "Approver Email" from a list of administration email addresses and Domain Registration email addresses. Choose one that you use, and receive the Domain Control Validation email, which contains a link and a "validation code". Click the link and enter the code to verify that you own the domain.

Certificate Email — ssls.com send the certificate to the "Administrator Email" that you specified during the purchase process. This certificate is used in the process below.

Gérer

Quand vous aurez terminé avec votre achat, vous aurez un ou plusieurs fichiers pour chaque certificat :

  • Le certificat lui-même, par ex. snarfed.org.ssl.crt.
  • La clé privée que vous avez utilisée pour générer le certificat, par ex. id_rsa-2048.
  • Facutltatif : Votre certificat intermédiaire d'Autorité de Certification par ex., sub.class1.server.ca.pem.
  • Facultatif : Votre racine de CA, par ex. ca.pem. En espérant que vous aurez choisi une Autorité de Certification dont le cert racine soit distribué avec la plupart des OS/navigateurs ; si c'était le cas, vous pouvez ignorer cela. (Si ce n'est pas le cas, vous devriez réétudier !)

Tous ces fichiers sont généralement au format X.509 mis à part la clé privée, qui est RSA ou tout autre format de clé privée.

La ligne de commande openssl est votre amie pour inspecter et modifier les certificats. Par exemple pour avoir l'info concernant un cert : 

openssl x509 -text -in snarfed.org.ssl.crt

Si votre CA vous a fourni un cert intermédiaire, vous devrez le fournir à votre serveur web avec votre propre cert. Pour les serveurs qui n'acceptent qu'un fichier unique, vous devrez concaténer les certs, par ex. : 

cat snarfed.org.ssl.crt sub.class1.server.ca.pem > snarfed.org.unified.ssl.crt

As another example, it seems like this command line should verify that a cert is valid: 

openssl verify -verbose -CAfile ca.pem snarfed.org.unified.ssl.crt

...but User:snarfed.org gets this error: 

error 20 at 0 depth lookup:unable to get local issuer certificate

You will get the "error 20" error above when openssl is unable to locate the root or intermediate certificates in your chain - if you are on Linux, or know where your OS stores the certificate list, you can run: 

openssl verify -verbose -CApath /etc/ssl/certs snarfed.org.unified.ssl.crt

If you have gnutls command line tools installed, you can verify self-signed certs: 

certtool -e --infile snarfed.org.unified.ssl.crt

Réglages

L'IETF a un document avec des recommandations pour un Usage Sûr des TLS et DTLS.

Mozilla a un outil génial pour construire la Configuration SSL pour différents outils : Mozilla SSL Configuration Generator.

https://cipherli.st est une anti-sèche rapide pour la configuration Apache, nginx et Lighttpd TLS.

testssl.sh est un outil ligne de commande pour visualiser vos configurations TLS.

Apache

Apache est vraiment facile. Voici un bon post "how-to". TL;DR: Put the certificate files somewhere your Apache user can read, then set the SSLCertificate* config directives, e.g.: 

SSLCertificateKeyFile /home/ryan/.ssh/id_rsa-2048
SSLCertificateFile /home/ryan/www/snarfed.org.ssl.crt
SSLCACertificateFile /home/ryan/www/sub.class1.server.ca.pem

User:ShaneHudson.net - As well as the certificates and keys, it is also useful to have forward secrecy and HSTS. I used the following lines in httpd.conf, the articles I found them in are in the FAQs further below. This went from C to A+ on the SSL test. 

SSLProtocol all -SSLv2 -SSLv3
    SSLHonorCipherOrder on
    SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"

App Engine

Si vous servez sur l'AppEngine intégré de Google du domaine appspot.com, vous y êtes presque ! Ajoutez simplement secure: always (ou optional) aux handler(s) dans votre app.yaml ou tout autre fichier de configuration d'app, et vous pourrez accéder à votre app sur https. Détails ici.

Si vous utilisez la runtime Java sur App Engine, ajoutez ce stanza à votre fichier web.xml. 

<?xml version="1.0" encoding="ISO-8859-1"?>
<web-app 
   ...> 

  <security-constraint>
    <web-resource-collection>
      <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>

You may additionally want to send a HSTS header to further improve security. In java, the easiest way from a servlet running on AppEngine is to add this header to all responses when running on the production server. 

import com.google.appengine.api.utils.SystemProperty;

...

      if (SystemProperty.environment.value() ==
          SystemProperty.Environment.Value.Production) {
          // force ssl for six months.
          response.addHeader("Strict-Transport-Security", "max-age=15768000");
      }

If you also deliver static content, you may want to enable the HSTS header here as well. An example stanza within your appengine-web.xml file might look like this. 

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
...
    <static-files>
    <include path="/static/**" >
      <http-header name="Strict-Transport-Security" value="max-age=15768000"/>
...



If you're on a custom domain, you can use either SNI or a VIP. Details here. You'll need to upload your SSL cert files to the Google Apps control panel for your domain, then add and configure SNI or VIP slots in App Engine.

nginx

We can setup nginx to listen on port 443 with our SSL sertificate quite easily: 

server {
    listen 443 ssl;
    server_name example.org;

     ssl_certificate /path/to/unified.crt;
     ssl_certificate_key /path/to/my-private-decrypted.key;

     //usual nginx config here like location blocks
}

For more detailed nginx config instructions see the page on nginx

Test

Production

Le Test Serveur de Qualys est un moyen facile de tester le certificat SSL sur votre site. Voir par exemple la carte de compte-rendu pour brid.gy, ou en comparaison celle de jonnybarnes.uk qui a des résultats légèrement différents.

shaaaaaaaaaaaaa.com vérifiera si votre SSL Cert utilise SHA-1 ou SHA-2 et explique pouquoi ça devient de plus en plus important.

https://securityheaders.io testera la dureté d'en-tête de sécurité du serveur web et offre des raisons

Observatory par Mozilla vérifie différents aspects de sécurité d'un site et donne un score, en plus d'agréger les résultats à partir de tiers qui scannent les sites tels que https://securityheaders.io.

testssl.sh est un script ligne de commande qui peut tourner localement pour vérifier les certificats et configurations TLS.

Vous pouvez utiliser openssl s_client pour debuger les problèmes de connexion, par exemple : 

openssl s_client -connect snarfed.org:443

If your server uses SNI, you'll need to provide the hostname too: 

openssl s_client -servername www.brid.gy -connect www.brid.gy:443

Here's an example of debugging a single SSL issue:

Brand new StartSSL certificates may give an OCSP validation error for 6-24 hours after purchase. This seems to only affect Firefox and resolves itself when the certificate propagates to the validation server[2]. Firefox users can disable the check temporarily with Edit > Preferences > Advanced > Certificates > Validation, and uncheck "Use the Online Certificate Status Protocol"

Local

Au moment de développer un site web localement, il peut être utile de pouvoir tester le site via https. Par exemple, au moment d'écrire un client OAuth, quelques fournisseurs ne redirigeront pas une page qui n'utilise pas https.

Le moyen le plus facile de faire ça est de rediriger temporairement votre site vers votre propre localhost (juste pour vous) et d'utiliser votre cert de site. Ajoutez juste une ligne comme ceci à votre fichier hosts : 

127.0.0.1	snarfed.org

This is obviously temporary, though. For a more permanent setup, you can either generate a self-signed SSL certificate for your testing domain (localhost, etc) or you can create your own SSL certificate authority and sign the certificate with that.

Pour aider sur ce point, aaronpk a créé une autorité racine "IndieWebCamp" qui peut signer des certificats pour les domaines finissant par ".dev".

Vous pouvez ajouter une ligne vers votre fichier hosts pour votre domaine test comme : 

127.0.0.1   mondomaine.dev

Et ensuite vous pouvez utiliser le certificat d'autorité IndieWebCamp pour générer un cert SSL.

Renew

A few things to be aware of when you need to renew your certificates.

Because all of the browsers now share lists of certificates that are invalid and/or broken as part of OCSP stapling you should renew your certificate at least two days prior to it expiring and then update your server with the certificate at least a day before. This allows the various OCSP lists to update before you touch your server - if you do not you may get some customers whose browsers have an older list and your certificate will not pass their OCSP check, which is different than it being on the revocation list.

Let's Monitor is a free service to monitor your sites and alert you via SMS or email when your certificates are out of date or aren't working.

Trucs, astuces et bonnes pratiques

  • pour éviter des alertes de contenus mixés, remplacez chaque lien entrant http:// et https:// ( votre domaine ) vers seulement le préfixe // . Ceci est supporté dans tous les navigateurs modernes et retrouvera automatiquement le protocole quand vous voudrez accéder à la page.

Posts concernant HTTPS

Niveaux IndieMark

Les niveaux IndieMark du support HTTPS recommandé pour votre propre site web, en tant que partie du composant sécurité


Niveau 1 sécurité

Niveau 1 - Don't do the wrong thing. (what's the minimal "not wrong thing"?). Possible reasonable behaviors:

  • Refuser la connexion, parce que si vous ne support pas SSL, généralement vous n'écoutez pas le 443, ainsi les clients ne peuvent pas se connecter. Défi : l'utilisateur n'a pas idée de ce qui ne va pas, ni la façon de corriger ça (c'est à dire essayer de nouveau le site avec "http:").

Pourquoi ?

  • Éviter une expérience-utilisateur trompeuse.

Exemples IndieWeb

  • ... ajoutez-vous ici vous-même avec la date de votre Niveau 1 vérifié !


Niveau 2 sécurité

Niveau 2 - Sécurisez l'admin de votre site - supporter https pour vos pages d'UI de connexion/admin avec un certificat auto-signé.

  • Vos page(s) admin :
    1. DOIVENT être disponible sur https
    2. DEVRAIENT rediriger automatiquement de http à https, afin que vous ne vous connectiez pas accidentellement en clair sur http (c'est à dire envoyer vos identifiants login et mot de passe de votre site en clair)
    3. DEVRAIT inclure le marqueur de sécurité (détails PHP) au moment de régler les cookies de session/credential, de telle façon que les cookies ne fuirent pas sur d'autres (probablement non-admin) requêtes http (c'est à dire permettre les attaques de réutilisation de cookie style Firesheep)

Pourquoi ?

  • Sécurité pour l'accès-en-écriture pour votre site ! Autrement n'importe qui peut hacker votre CMS et poster des choses à votre place (par exemple utiliser un outil comme Firesheep pour aspirer vos cookies de connexion de session, et les ré-utiliser pour avoir accès à vos pages admin.

Comment faire

  • Comment faire que vos admin page(s) soient disponibles sur https :
    • installez un certificat auto-signé (voyez avec votre fournisseur d'hébergement web pour les détails)
    • naviguez explicitement (par ex. en tapant) vers la version https:// de votre site.
  • Comment rediriger votre UI admin de http à https automatiquement :
    • faites que Admin Wordpress utilise SSL : http://codex.wordpress.org/Administration_Over_SSL
    • faire que vos propres autres logiciels utilisent SSL sur Apache en utilisant .htaccess (dérivé de ctte référence WP), par ex. pour votre URL admin example.com/my-adm/

      # HTTPS-only my-adm
      RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
      RewriteCond %{HTTPS} !=on [NC]
      RewriteRule ^/?(my-adm/) https://example.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]

      où:
      • example.com est votre domaine personnel, et
      • my-adm/ est le chemin vers votre UI admin web login.

N.B. vérificateur utile du fichier htaccess : htaccess checker - vous laisse coller dans votre fichier htaccess et allez à l'URL test en utilisant des URLs échantillons.

  • Comment sécuriser vos cookies, par ex. in PHP :
    • régler différents params de session avant d'appeler session_start() :

      ini_set("session.cookie_httponly", 1);
      ini_set("session.use_only_cookies", 1);
      ini_set("session.cookie_secure", 1);
      session_start();

    • nettoyez vos cookies dans votre navigateur, utilisez votre login pour vous connecter sur votre site web, puis double-cliquez pour vérifier que vos cookies soient sûres, par exemple dans Firefox :
      • choisissez Preferences... dans le menu Firefox.
      • clicquez onglet Privacy
      • clicquez Show Cookies...
      • enter your domain name into the dialog's search box
      • sélectionnez la cookie réglée par votre code, par ex. "PHPSESSID"
      • L'info sous la liste des cookies devrait afficher :

        Send For: Encrypted connections only

        Si ce n'était pas le cas, ou si cela dit quelque chose comme

        Send For: Any type of connection

        alors la cookie n'est pas sûre.


Note : Si vous réglez un vrai cert SSL pour l'ensemble de votre domaine et servez votre interface d'admin provenant du même domaine, vous êtes parvenu au Niveau 3.

Exemples IndieWeb

  • portrait Tantek Çelik pour tantek.com sur son interface admin Falcon sur https://tantek.com/falcon/ since 2014-05-23, et redirige l'UI d'admin de domaine de http vers https automatiquement et sécurise la cookie de sessions depuis 2014-09-02.
  • ...
  • ... ajoutez-vous ici avec la date à laquelle vous avez atteint le Niveau 2 !

Niveau 3 sécurité

Niveau 3 - Servez facultativement sur toutes vos pages - fournissez votre front-end à la fois sur http et https avec un cert provenant d'un CA certifié, mais pas nécessairement du contenu externe, par conséquent vous pourriez encore avoir des avertissements de contenus mélangés.

Pourquoi ?

  • Vous pouvez lier à partir de profils silo vers votre site via https
  • Vous pouvez commencer par utiliser (requis!) votre URL https pour les connexions IndieAuth (par ex. le wiki)
  • Vos lecteurs peuvent accéder en sécurité à votre site sans pop-up d'avertissement étrange.
  • La privacy pour vos lecteurs (ce qu'ils choisissent de lire)[3]

Exemples IndieWeb

Exemples IndieWeb avec http vers des redirections https (qui ont encore besoin d'être réparées d'alertes de contenus mélangés) - nous recommandons explicitement de ne pas rediriger vos pages http vers https à moins que vous ne soyez sûr de ne pas avoir d'alertes de contenus mixés.

  • 2014-??-?? Indiewebcamp.com itself

Niveau 4 sécurité

Niveau 4 - Icône verrou ou mieux au moment de servir https - soyez certain qu'il y ait au moins une icône de cadenas prêt du https dans la barre d'adresse. Servez tout (page d'accueil, permaliens, images) sur https quand l'utilisateur requête https. Éliminez les alertes de contenus mixés (par ex un triangle avec un point d'exclamation prêt du https dans la barre d'URL).

Pourquoi ?

  • Eviter de montrer au lecteur un message d'alerte ou une icône de triangle dans la barre d'adresse du navigateur.
  • Si vous permettez l'accès http ou https à votre site, et que votre accès https *manque* le message d'avertissement de contenu mixé, vous aidez au moins vos visiteurs https.
  • Eliminer les avertissements de contenu-mixé est important parce que ces avertissements rendent le https inefficace. L'utilisateur n'a pas d'idée combien une page, ses images, scripts ou textes créés à partir des scripts viennent d'une connexion encapsulate http.
  • Eviter le contenu http/https qui est bloqué par défaut sur Firefox & Chrome. Voir : https://blog.mozilla.org/security/2013/05/16/mixed-content-blocking-in-firefox-aurora/, https://code.google.com/p/chromium/issues/detail?id=81637

Exemples IndieWeb par ordre d'implémentation


FAQ :
Comment vous assurez-vous que le contenu externe est sur https ? c'est à dire si j'ai un avatar pour un commentaire de portrait Tantek Çelik il sera sur http parce qu'il utilise http.

  • Quand vous recevez une web mention, téléchargez l'image provenant de la h-card et servez-la sur votre propre serveur.
  • Alternativement, utilisez un proxy https d'image comme https://github.com/atmos/camo (utilisé par GitHub)
  • A moins que ce ne soit une mention Twitter, auquel cas liez vers :
    • https://twitter.com/nomutilisateur/image_profil
    • Voir Twitter#Profile_Image_URLs pour en savoir plus sur les images de profil Twitter.

Niveau 5 sécurité

Level 5 - Rediriger tout vers https - envoie les redirection à partir de http -> https. par ex. vos pages ont toujours automatiquement une icône de verrou dans la barre d'adresse du navigateur (et pas d'avertissements).

Pourquoi ?

  • Toutes vos URLs de site seront cohérentes.
  • Les utilisateurs recevront du contenu que vous avez décidé de leur servir
  • Tous les avantages vers une sécurité internet plus large de servir toujours https (documenté en intro tout en haut)

Exemples IndieWeb par ordre d'implémentation

  • 2014-??-?? Ryan Barrett on https://snarfed.org/ (via HSTS header)
  • 2014-05-23 Kartik Prabhu on https://kartikprabhu.com/ (via 301 redirect)
  • David Shanske on https://david.shanske.com/ since 2014-12-25.
    • At Level 3 from 2014-08-29
    • Was at Level 4 for a bit, but did not note date.
    • All posts, resources, including external user pics.
    • Caveat: There may be some older posts with embedded images from http that still give the mixed content warning. I think I have them all
      • Dropped down to B...updated ciphers and added a custom DHE parameter. As of 2016-02-14 am back at A+.
  • 2015-06-19 Scott Gruber on https://scottgruber.me Installed renewal cert on 2016-04-18.
  • ...
  • ... add yourself here with the date you reached Level 5!

Vérifiez la barre d'adresse du navigateur où votre URL est affichée et assurez-vous :

  • Il y a une icône de verrou avant (en face de) l'URL dans la barre d'adresse
  • Il n'y a pas d'icône triangle d'avertissement (en face) de l'URL dans la barre d'adresse

Pourquoi mon site avance si lentement ?

  • I found that moving my https redirect into httpd instead of .htaccess, and explicitly setting it to go to www meant it would be faster and wouldn't go through multiple redirects. This SO question came in handy for getting httpd to redirect. ~ Shane Hudson

Pourquoi suis-je seulement en A et non A+ ?

Niveau 6 sécurité

Niveau 6 - Correct ciphers, support forward secrecy, etc. per https://www.ssllabs.com/ssltest/ (all previous levels required, i.e. document method of http to https redirection)

Pourquoi ?

Exemples IndieWeb

Crittique

Legacy Software and SNI Support

A server has an IP address. It used to be that each server would host one website (domain) in HTTP/1. Then HTTP/1.1 introduced the Host header which allowed a server to host multiple domains. However, the connection needs to be encrypted before the Host header can be sent. So which certificate should the server send initially? When the wrong one is chosen we get issues. The solution to this problem is called Server Name Indication. SNI is supported by all modern browsers and cryptography libraries. OpenSSL is one of the most popular and has supported SNI since 2010 for example. However, we can run into issues when older software tries to interact with your site: http://indiewebcamp.com/irc/2015-12-06/line/1449416119493

General X509 Criticism

Taxe de maintenance et fragilité du site

Adding HTTPS to your site adds the extra maintenance tax of HTTPS certificate renewal (and updating).

As a result, if you fail to do this, or get it wrong, your site goes down.

Evidence:

Let’s Encrypt are trying to fix this by making updating TLS certificates an automated process via their Let’s Encrypt client.

En rapport

Sessions

Sessions at IndieWebCamps about https:


Voir aussi

Articles à lire

Récupérée de « https://ducamp.me/index.php?title=Https&oldid=16260 »