Comment nginx configure HSTS

Netcraft a récemment publié ses recherches sur les tests de sites Web SSL/TLS et a noté que seulement 5 % des utilisateurs ont correctement implémenté HTTP Strict Transport Security HSTS.

Qu'est-ce que HSTS

HTTPS (SSL et TLS) garantit la sécurité des communications entre les utilisateurs et les sites Web, ce qui rend difficile l'interception, la modification et l'usurpation d'identité des attaquants. Lorsque l'utilisateur saisit manuellement un nom de domaine ou un lien http://, la première requête vers le site Web n'est pas cryptée, en utilisant du http simple. Les sites Web les plus sécurisés renvoient immédiatement une redirection dirigeant l'utilisateur vers une connexion https. Cependant, un attaquant de type man-in-the-middle peut être en mesure d'intercepter la requête http initiale et ainsi contrôler les réponses ultérieures de l'utilisateur.

Naturellement, HSTS a été créé pour résoudre ce problème de sécurité potentiel. Même si l'utilisateur saisit un nom de domaine ou une connexion http, le navigateur passera strictement à une connexion https.

Comment fonctionne HSTS

Les politiques HSTS sont émises dans les en-têtes de réponse HTTP envoyés depuis les sites HTTPS sécurisés.

Strict-Transport-Security: max-age=31536000

Lorsque le navigateur voit cet en-tête provenant d'un site HTTPS, il sait que le nom de domaine n'est accessible que via HTTPS (SSL ou TLS). Et mettez en cache ces informations dans 31536000, soit 1 an.

Le paramètre facultatif includeSubDomains indique au navigateur que la stratégie s'applique à tous les sous-domaines du domaine actuel.

Strict-Transport-Security: max-age=31536000; includeSubDomains

nginx configure HSTS

Définissez les en-têtes de réponse HSTS sur le fichier de configuration nginx. Le paramètre

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

always garantit que toutes les réponses ont cet en-tête défini, y compris les réponses d'erreur générées en interne. Les versions de nginx antérieures à 1.7.5 ne prennent pas en charge le paramètre Always et les réponses d'erreur générées en interne ne définissent pas ces informations d'en-tête.

Règles d'héritage de la directive add_header :

Le bloc de configuration nginx hérite du bloc d'encapsulation où se trouve la directive add_header, il vous suffit donc de placer la directive add_header dans le bloc serveur de niveau supérieur. Il existe également une exception importante : si un bloc contient la directive add_header lui-même, il n'héritera pas de l'en-tête du bloc englobant et vous devrez redéfinir toutes les directives add_header.

server {
    listen 443 ssl;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
 
    # This 'location' block inherits the STS header
    location / {
        root /usr/share/nginx/html;
    }
 
    # Because this 'location' block contains another 'add_header' directive,
    # we must redeclare the STS header
    location /servlet {
        add_header X-Served-By "My Servlet Handler";
        add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        proxy_pass http://localhost:8080;
    }
}

Test de la sécurité du transport HTTP Strict :

Une fois qu'un utilisateur propose une politique HSTS, sa période d'informations de cache est spécifiée par max-age. Pendant ce temps, le navigateur refusera l'accès au service Web via HTTP non crypté et refusera d'accorder des exceptions pour les erreurs de certificat (si le site Web a déjà soumis un certificat valide et fiable). Si un paramètre includeSubDomanis est spécifié, ces restrictions s'appliquent également à tous les sous-domaines du domaine actuel.

Lorsque vous testez HSTS, réduisez la durée d'âge maximum.

Si chaque réponse HTTPS doit avoir un en-tête STS :

Notre objectif est de restituer la politique HSTS le plus rapidement possible lorsque l'utilisateur démarre une réponse HTTPS. S'ils reçoivent des politiques HSTS pendant la session, ils sont toujours vulnérables aux attaques de piratage HTTP. Le navigateur ne doit examiner l'en-tête STS qu'une seule fois, il n'est donc pas strictement nécessaire de l'ajouter à chaque bloc d'emplacement et à chaque réponse. Cependant, le simple fait de l'ajouter à la page d'accueil ou à la page de connexion peut ne pas suffire. Si vous l'ajoutez uniquement à la réponse mise en cache, le client risque de ne pas la voir. Assurez-vous de couvrir autant de parties de votre URL que cela est raisonnable, en accordant une attention particulière au contenu dynamique.

HTTP et HTTPS en parallèle

Parfois, un site Web doit fonctionner à la fois sous HTTP et HTTPS

server {
    listen  80;
    listen  443 ssl;
    ...
}

Parfois, les requêtes http doivent être redirigées vers https

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
 
    # Discourage deep links by using a permanent redirect to home page of HTTPS site
    return 301 https://$host;
 
    # Alternatively, redirect all HTTP links to the matching HTTPS page
    # return 301 https://$host$request_uri;
}
 
server {
    listen 443 ssl;
    server_name www.ttlsa.com;
 
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}

Améliorer HSTS

Protéger les clients de l'interception HTTP, à partir de Il voit l'en-tête STS jusqu'à l'âge maximum déclaré. Cependant, HSTS n'est pas une solution parfaite pour le détournement de session HTTP. Les utilisateurs sont toujours vulnérables s'ils accèdent à un site Web protégé par HSTS via HTTP :

1. N'ont jamais visité le site Web auparavant

2. Ils ont récemment réinstallé leur système d'exploitation

3. Ils ont récemment réinstallé leur navigateur

4. Passer à un nouveau navigateur

5. Passer à un nouvel appareil tel qu'un téléphone mobile

6. Supprimer le cache du navigateur

7. Je n'ai pas visité le site récemment et l'âge maximum a expiré

Afin de résoudre ce problème, Google insiste pour conserver un nom de domaine et un nom de sous-domaine de site « liste de préchargement HSTS », et soumet son nom de domaine via https://hstspreload.appspot.com/. Cette liste de noms de domaine est distribuée et codée en dur dans les principaux navigateurs Web. Les clients accédant aux noms de domaine de cette liste utiliseront activement HTTPS et refuseront l'accès au site en utilisant HTTP.

Une fois l'en-tête STS défini ou votre domaine soumis à la liste de préchargement HSTS, il est impossible de le supprimer. Il s'agit d'une décision à sens unique pour rendre votre nom de domaine disponible via HTTPS.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!