TLS de bout en bout avec Azure Front Door

  • Article

Le protocole TLS (Transport Layer Security), anciennement appelé SSL (Secure Sockets Layer), est la technologie de sécurité standard pour établir une liaison chiffrée entre un serveur web et un client, par exemple, un navigateur web. Cette liaison garantit que toutes les données transmises entre le serveur et le client restent privées et chiffrées.

Pour répondre à vos exigences de sécurité ou de conformité, Azure Front Door prend en charge le chiffrement TLS de bout en bout. Le déchargement TLS/SSL de Front Door met fin à la connexion TLS, déchiffre le trafic sur Azure Front Door, puis rechiffre le trafic avant de le transférer à l’origine. Quand les connexions à l’origine utilisent l’adresse IP publique de l’origine, une bonne pratique de sécurité est de configurer HTTPS comme protocole de transfert sur votre Azure Front Door. En utilisant HTTPS comme protocole de transfert, vous pouvez appliquer le chiffrement TLS de bout en bout à l’ensemble du traitement de la demande entre le client et l’origine. Le déchargement TLS/SSL est également pris en charge si vous déployez une origine privée avec Azure Front Door Premium en utilisant la fonctionnalité Private Link.

Cet article explique comment Azure Front Door fonctionne avec les connexions TLS. Pour plus d’informations sur l’utilisation des certificats TLS avec vos propres domaines personnalisés, consultez HTTPS pour les domaines personnalisés. Pour savoir comment configurer un certificat TLS sur votre propre domaine personnalisé, consultez Configurer un domaine personnalisé sur Azure Front Door en utilisant le portail Azure.

Chiffrement TSL de bout en bout

Le protocole TLS de bout en bout vous permet de sécuriser les données sensibles en transit vers l’origine tout en bénéficiant des fonctionnalités Azure Front Door, comme l’équilibrage de charge et la mise en cache globaux. Certaines des fonctionnalités incluent également le routage basé sur l’URL, le fractionnement TCP, la mise en cache sur l’emplacement de périphérie le plus proche des clients et la personnalisation des requêtes HTTP à la périphérie.

Azure Front Door décharge les sessions TLS à la périphérie et déchiffre les requêtes des clients. Il applique ensuite les règles de routage configurées pour router les demandes vers l’origine appropriée dans le groupe d’origines. Azure Front Door démarre ensuite une nouvelle connexion TLS à l’origine et rechiffre toutes les données en utilisant le certificat de l’origine avant de transmettre la demande à l’origine. Toute réponse de l’origine est chiffrée par le même processus de retour vers l’utilisateur final. Vous pouvez configurer Azure Front Door pour utiliser le protocole HTTPS comme protocole de transfert pour activer le protocole TLS de bout en bout.

Versions TLS prises en charge

Azure Front Door prend en charge quatre versions du protocole TLS : TLS versions 1.0, 1.1, 1.2 et 1.3. Tous les profils Azure Front Door créés après septembre 2019 utilisent TLS 1.2 comme minimum par défaut avec TLS 1.3 activé, mais TLS 1.0 et TLS 1.1 sont toujours pris en charge pour la compatibilité descendante.

Même si Azure Front Door prend en charge TLS 1.2, qui a introduit l’authentification client/mutuelle dans la RFC 5246, Azure Front Door ne prend pas encore en charge l’authentification client/mutuelle (mTLS).

Vous pouvez configurer une version TLS minimale dans Azure Front Door dans les paramètres HTTPS de domaine personnalisé en utilisant le portail Azure ou l’API REST Azure. Actuellement, vous pouvez choisir entre 1.0 et 1.2. Par conséquent, si vous spécifiez TLS 1.2 comme version minimale, vous pouvez contrôler la version TLS minimale acceptable par Azure Front Door. Pour la version minimale de TLS 1.2, la négociation tentera d’établir TLS 1.3 puis TLS 1.2, tandis que pour la version minimale de TLS 1.0, les quatre versions seront tentées. Quand Azure Front Door lance le trafic TLS vers l’origine, il tente de négocier la meilleure version TLS que l’origine peut accepter de manière fiable et cohérente. Les versions de TLS prises en charge pour les connexions d’origine sont TLS 1.0, TLS 1.1, TLS 1.2 et TLS 1.3.

Remarque

  • Les clients avec TLS 1.3 activés sont requis pour prendre en charge l’une des courbes EC compatibles avec Microsoft SDL, notamment Secp384r1, Secp256r1 et Secp521, afin d’effectuer des requêtes avec Azure Front Door à l’aide de TLS 1.3.
  • Il est recommandé que les clients utilisent l’une de ces courbes comme courbe préférée pendant les requêtes pour éviter une latence accrue lors de l’établissement d'une liaison TLS, qui peut être le résultat de plusieurs allers-retours pour négocier la courbe EC prise en charge.

Certificats pris en charge

Quand vous créez votre certificat TLS/SSL, vous devez créer une chaîne de certificats complète avec une autorité de certification (CA) autorisée figurant dans la liste des autorités de certification de confiance Microsoft. Si vous utilisez une autorité de certification non autorisée, votre demande sera rejetée.

Les certificats provenant d’autorités de certification internes ou les certificats auto-signés ne sont pas autorisés.

Agrafage du protocole OCSP (Online Certificate Status Protocol)

L’agrafage OCSP est pris en charge par défaut dans Azure Front Door et aucune configuration n’est nécessaire.

Connexion TLS de l’origine (Azure Front Door vers origine)

Pour les connexions HTTPS, Azure Front Door s’attend à ce que votre origine présente un certificat d’autorité de certification valide avec un nom d’objet correspondant au nom d’hôte de l’origine. Par exemple, si le nom d’hôte de votre origine est défini sur myapp-centralus.contosonews.net et que le certificat que votre origine présente pendant la négociation TLS n’a ni myapp-centralus.contosonews.net ni *.contosonews.net dans le nom d’objet, Azure Front Door refuse la connexion et le client voit une erreur.

Notes

Le certificat doit avoir une chaîne de certificats complète avec des certificats feuille et intermédiaires. L’autorité de certification racine doit faire partie de la liste des autorités de certification de confiance Microsoft. Lorsqu’un certificat sans chaîne complète est présenté, le bon fonctionnement des demandes l’impliquant n’est pas garanti.

Dans certains cas d’utilisation, comme les tests, pour résoudre les échecs de connexion HTTPS, vous pouvez désactiver la vérification du nom d’objet du certificat pour votre Azure Front Door. Notez que l’origine doit toujours présenter un certificat avec une chaîne approuvée valide, mais ne doit pas nécessairement correspondre au nom d’hôte d’origine.

Dans Azure Front Door Standard et Premium, vous pouvez configurer une origine pour désactiver la vérification du nom d’objet du certificat.

Dans Azure Front Door (classique), vous pouvez désactiver la vérification du nom d’objet du certificat en changeant les paramètres Azure Front Door dans le portail Azure. Vous pouvez également configurer la vérification en utilisant les paramètres du pool de back-ends dans les API Azure Front Door.

Notes

Du point de vue de la sécurité, Microsoft ne recommande pas la désactivation de la vérification du nom d’objet du certificat.

Connexion TLS du front-end (client vers Azure Front Door)

Pour permettre au protocole HTTPS de distribuer le contenu de manière sécurisée sur un domaine personnalisé Azure Front Door, vous pouvez choisir d’utiliser un certificat managé par Azure Front Door ou votre propre certificat.

Pour plus d’informations, consultez HTTPS pour les domaines personnalisés.

Le certificat managé d’Azure Front Door fournit un certificat TLS/SSL standard via DigiCert et est stocké dans le coffre de clés d’Azure Front Door.

Si vous choisissez d’utiliser votre propre certificat, vous pouvez intégrer un certificat délivré par une autorité de certification prise en charge ; il peut s’agir d’un certificat TLS standard, d’un certificat de validation étendue ou même d’un certificat générique. Les certificats auto-signés ne sont pas pris en charge. Découvrez comment activer le protocole HTTPS pour un domaine personnalisé.

Rotation automatique des certificats

En ce qui concerne l’option des certificats managés d’Azure Front Door, les certificats sont gérés par Azure Front Door et font l’objet d’une rotation automatique dans les 90 jours précédant leur date d’expiration. En ce qui concerne l’option des certificats managés d’Azure Front Door Standard/Premium, les certificats sont gérés par Azure Front Door et font l’objet d’une rotation automatique dans les 45 jours précédant leur date d’expiration. Si vous utilisez un certificat managé Azure Front Door et que vous voyez que la date d’expiration du certificat est inférieure à 60 jours (30 jours pour le SKU Standard/Premium), créez un ticket de support.

Pour votre propre certificat TLS/SSL personnalisé :

  1. Choisissez « La plus récente » comme version du secret.pour que le certificat soit permuté automatiquement quand une version plus récente est disponible dans votre coffre de clés. Pour les certificats personnalisés, le certificat est renouvelé automatiquement dans un délai de 3 à 4 jours avec une version plus récente du certificat, quelle que soit la date d’expiration du certificat.

  2. Si une version spécifique est sélectionnée, la rotation automatique n’est pas prise en charge. Vous devez resélectionner la nouvelle version manuellement pour faire pivoter le certificat. Le déploiement de la nouvelle version du certificat/secret peut prendre jusqu’à 24 heures.

    Remarque

    Les certificats managés Azure Front Door (Standard et Premium) sont automatiquement permutés si l’enregistrement CNAME de domaine pointe directement vers un point de terminaison Front Door ou pointe indirectement vers un point de terminaison Traffic Manager. Sinon, vous devez revalider la propriété de domaine pour permuter les certificats.

    Assurez-vous que le principal de service pour Front Door a toujours accès au coffre de clés. Consultez la documentation pour accorder l’accès à votre coffre de clés. Cette opération de lancement de certificat mis à jour par Azure Front Door n’interrompt pas la production, à condition que le nom d’objet ou le nom alternatif d’objet (SAN) du certificat ne change pas.

Suites de chiffrement prises en charge

Pour TLS 1.2/1.3, les suites de chiffrement suivantes sont prises en charge :

  • TLS_AES_256_GCM_SHA384 (TLS 1.3 uniquement)
  • TLS_AES_128_GCM_SHA256 (TLS 1.3 uniquement)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Notes

Pour Windows 10 et versions ultérieures, nous vous recommandons d’activer une suite de chiffrement ECDHE_GCM, ou les deux, pour une meilleure sécurité. Windows 8.1, 8 et 7 ne sont pas compatibles avec ces suites de chiffrement ECDHE_GCM. Les suites de chiffrement ECDHE_CBC et DHE ont été fournies pour la compatibilité avec ces systèmes d’exploitation.

Quand vous utilisez des domaines personnalisés avec les protocoles TLS 1.0 et 1.1 activés, les suites de chiffrement suivantes sont prises en charge :

  • TLS_AES_256_GCM_SHA384 (TLS 1.3 uniquement)
  • TLS_AES_128_GCM_SHA256 (TLS 1.3 uniquement)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door ne prend pas en charge la désactivation ou la configuration de suites de chiffrement spécifiques pour votre profil.

Étapes suivantes