Protocole de transfert hypertexte sécurisé de

Le protocole de transfert hypertexte sécurisé ( HTTPS ) est un protocole de communication sur le World Wide Web qui permet de transmettre des données en toute sécurité. Il représente un cryptage de transport .

HTTPS a été développé par Netscape et publié pour la première fois avec leur navigateur en 1994 avec SSL 1.0.

Techniquement, il a été défini comme un schéma d'URI , une couche supplémentaire entre HTTP et TCP .

Utiliser

HTTPS est utilisé pour établir la confidentialité et l'intégrité de la communication entre le serveur Web et le navigateur Web ( client ) sur le World Wide Web . Ceci est réalisé grâce au cryptage et à l' authentification , entre autres.

Sans cryptage, les données transmises sur Internet peuvent être lues en clair par toute personne ayant accès au réseau concerné. Avec la diffusion croissante des WLAN ouverts (c'est-à-dire non cryptés) , l'importance du HTTPS augmente car il permet de crypter le contenu indépendamment du réseau.

L'authentification est utilisée pour que les deux côtés de la connexion puissent vérifier l'identité du partenaire de connexion lors de l'établissement de la communication. Ceci est destiné à empêcher les attaques de type " man-in-the-middle" et, dans certains cas, le phishing .

Technologie

HTTPS est syntaxiquement identique au schéma pour HTTP, le cryptage supplémentaire des données s'effectue à l'aide de SSL/TLS : À l'aide du protocole de prise de contact SSL, une identification et une authentification protégées du partenaire de communication ont d'abord lieu. Une clé de session symétrique partagée est ensuite échangée à l'aide d' un chiffrement asymétrique ou d'un échange de clés Diffie-Hellman . Ceci est finalement utilisé pour crypter les données de l'utilisateur .

Le port par défaut pour les connexions HTTPS est 443.

En plus des certificats de serveur, des certificats client signés selon X.509 .3 peuvent également être créés. Cela permet aux clients d'être authentifiés par rapport au serveur, mais est rarement utilisé.

Une variante de protocole plus ancienne de HTTPS était S-HTTP .

traitement des clients

Avec le développement de HTTPS par Netscape, le protocole et le logiciel client côté utilisateur ont été intégrés très tôt dans les navigateurs Web. Cela signifie généralement qu'aucune autre installation de logiciel séparé n'est nécessaire.

Une connexion HTTPS est sélectionnée par une URL https et indiquée par le logo SSL. Ceci est affiché sous la forme d'un petit symbole de cadenas dans la barre d'adresse de tous les navigateurs courants.

Variantes de numérotation HTTPS

La décision d'utiliser un HTTPS sécurisé au lieu d'une connexion HTTP peut être prise de différentes manières :

• Seul le HTTPS est autorisé côté serveur, comme c'est généralement le cas avec la banque en ligne ; parfois une adresse http sélectionnée est automatiquement transmise à https.
• La connexion est forcée via HTTPS, puis un cookie HTTP est installé dans le navigateur et, afin de gagner du temps de calcul, le reste du service est traité en clair ; par exemple. Par exemple sur eBay .
• Côté client via HSTS : Si le serveur n'autorise que HTTPS (comme décrit ci-dessus), le navigateur peut s'en souvenir et se connectera toujours via HTTPS à l'avenir. Si le serveur figure également sur la liste de préchargement HSTS, le navigateur établit une connexion HTTPS directement lors de la première visite. ^[1]
• Entrée côté client de la variante HTTPS ou du plug-in de navigateur (par exemple pour Firefox et Chrome " HTTPS Everywhere "), qui remplace les requêtes http par des requêtes https pour les services prenant en charge les deux variantes.
• Depuis 2020 (version 83), Firefox peut être configuré pour n'utiliser que HTTPS. ^[2] Si un site Web n'est accessible que via HTTP non sécurisé, l'accès n'aura lieu qu'après que l'utilisateur aura donné son consentement explicite.

Selon la conception d'origine, après avoir sélectionné l'adresse HTTPS, le navigateur client doit d'abord afficher le certificat à l'utilisateur. Ce dernier décide maintenant s'il fait confiance au certificat pour cette session ou s'il le sauvegarde définitivement, si nécessaire après avoir vérifié les liens fournis. Sinon la connexion HTTPS ne sera pas établie ("Quitter cette page" pour Firefox ou "Cliquez ici pour quitter cette page." pour Internet Explorer).

Certificats préinstallés

Afin d'éviter cette requête, qui peut être irritante pour les non-initiés, les fabricants de navigateurs ont accepté un certain nombre de certificats racine au fil du temps, qui sont déjà saisis lors de l'installation. Les sites Web qui ont les certificats appropriés, ainsi que les sous-certificats dérivés de ceux-ci, sont alors acceptés sans invite lorsqu'ils sont appelés. Le fait qu'un certificat racine soit connu du navigateur dépend de la version du navigateur ; De plus, la liste des certificats est parfois mise à jour en ligne dans le cadre de la mise à jour du système, comme avec Microsoft Windows.

Avec Internet Explorer 7 , Microsoft, et peu après Mozilla avec Firefox 3 , ont resserré l'avertissement pour les certificats non enregistrés : Auparavant, seul un "Avis de sécurité" contextuel apparaissait, qui différenciait par le nom, la source et le terme du certificat, maintenant c'est le contenu de la page Web est masqué et un avertissement s'affiche avec la recommandation de ne pas utiliser la page. Afin de pouvoir les voir, l'utilisateur doit alors explicitement "ajouter une exception". Un certificat qui n'est pas saisi dans le navigateur devient de plus en plus inadapté aux applications de masse.

La question des certificats à inclure dans les navigateurs a parfois conduit à de longues discussions dans la communauté open source, comme entre CAcert , un fournisseur de certificats gratuits, et la Fondation Mozilla , voir CAcert (fiabilité) .

Fin 2015, Let's Encrypt a été mis en ligne, fondé par ex. par Mozilla et l' Electronic Frontier Foundation . Il propose des certificats gratuits pour tous dans le but de favoriser la diffusion du HTTPS dans son ensemble. Cependant, un logiciel séparé est requis sur le serveur pour l'installation et la mise à jour continue des certificats.

fonctionnement du serveur

Une bibliothèque SSL telle que OpenSSL est requise comme logiciel pour l'exploitation d'un serveur Web compatible HTTPS . Celui-ci est souvent déjà inclus ou peut être installé en tant que module. Le service HTTPS est généralement fourni sur le port 443.

certificat

Le certificat numérique pour SSL qui permet l'authentification doit être fourni par le serveur : un document binaire, qui est généralement délivré par une autorité de certification (AC, elle-même certifiée ) , qui identifie de manière unique le serveur et le domaine . Lors de la candidature, les données d'adresse et le nom de l'entreprise du demandeur sont vérifiés.

Les certificats saisis dans les navigateurs courants sont généralement proposés à des prix compris entre 15 € et 600 € par an, des services, sceaux ou assurances supplémentaires étant inclus au cas par cas. Un certain nombre d'autorités de certification délivrent des certificats gratuitement. Les certificats délivrés par Let's Encrypt , par exemple, sont acceptés par presque tous les navigateurs modernes sans message d'erreur. CAcert crée également des certificats gratuits, mais jusqu'à présent, il n'a pas été possible de les inclure dans la liste des certificats automatiquement acceptés par le navigateur ; voir ci- dessus . Un tel certificat doit donc être importé manuellement par l'utilisateur lors du traitement client ; cependant, ce comportement peut également être souhaitable.

Les listes de révocation de certificats ( CRL ) sont utilisées pour déclarer invalides des certificats obsolètes ou non sécurisés . La procédure prévoit que ces listes soient régulièrement vérifiées par les navigateurs et que les certificats bloqués soient immédiatement rejetés.

Avec l' OCSP (Online Certificate Status Protocol), complété par le SCVP (Server-based Certificate Validation Protocol), la prise en charge des vérifications de certificats peut être implémentée côté serveur. ^[3]

Pour les attaques sur le système de certificat, voir ci- dessous .

Auto-signé

Un opérateur de serveur peut également créer des certificats auto-signés gratuitement, sans l'intervention d'un tiers. Celles-ci doivent être confirmées manuellement par l'utilisateur du navigateur ("Ajouter une exception"). Dans ce cas, aucun tiers ne garantit l'authenticité du fournisseur. Un tel certificat peut à son tour être délivré à l'avance de manière sécurisée à l'utilisateur et importé dans son application cliente afin de représenter l'authenticité d'une manière différente.

Certificat de validation étendue

Dans le contexte d'attaques de phishing croissantes sur les applications Web sécurisées par HTTPS, le CA/Browser Forum a été créé aux États-Unis en 2007 et se compose de représentants d'organismes de certification et de fabricants de navigateurs. Au moment de sa création, les fabricants de navigateurs KDE, Microsoft, Mozilla et Opera étaient impliqués. ^[4] En juin 2007, une première directive commune est alors adoptée, l' Extended Validation Certificate , EV-SSL en abrégé en version 1.0, puis en avril 2008 en version 1.1.

Un opérateur de domaine doit accepter des vérifications supplémentaires pour ce certificat : alors qu'auparavant seule l'accessibilité de l'administrateur (par téléphone et e-mail) devait être vérifiée, l'adresse postale du demandeur est désormais vérifiée et, dans le cas des entreprises, le contrôle est effectué pour les personnes autorisées à signer. Cela entraîne également des coûts nettement plus élevés.

Adresses IP pour plusieurs domaines

Pendant longtemps, l'exploitation d'un serveur Web HTTPS nécessitait une adresse IP distincte pour chaque nom d'hôte .

Cela n'est pas nécessaire avec le HTTP non chiffré : étant donné que les navigateurs ont également envoyé le nom d'hôte dans l' en-tête HTTP , plusieurs serveurs Web virtuels, chacun avec son propre nom d'hôte, peuvent être servis sur une adresse IP, par exemple avec Apache en utilisant le mécanisme NameVirtualHost . Cette procédure est désormais utilisée pour la grande majorité des domaines, puisque le propriétaire du domaine n'y exploite pas de serveur .

Cependant, étant donné qu'avec HTTPS, le serveur Web doit fournir un certificat distinct pour chaque nom d'hôte, mais que le nom d'hôte n'est transmis qu'après la prise de contact SSL dans la couche HTTP supérieure, la déclaration du nom d'hôte dans l'en-tête HTTP n'est pas applicable. ici. Par conséquent, une distinction n'était possible que sur la base de la combinaison IP/port ; un port autre que 443 n'est pas accepté par de nombreux proxies .

Dans ce contexte, certains fournisseurs ont utilisé une solution de contournement pour permettre à leurs clients d'utiliser HTTPS sans leur propre adresse IP, comme le « SSL partagé ». Ils ont utilisé des certificats génériques valides pour tous les sous-domaines d'un domaine en conjonction avec des sous-domaines personnalisés. D'autres fournisseurs utilisaient un « Proxy SSL » qui acheminait les requêtes via un domaine utilisé par plusieurs clients.

La solution à ce problème est venue avec Server Name Indication (SNI), ^[5] basé sur Transport Layer Security 1.2, puisque le nom d'hôte souhaité par le navigateur peut déjà être transmis lors de la poignée de main SSL. Avec cela, les autres techniques mentionnées ci-dessus sont devenues inutiles. Le processus nécessite un logiciel à jour côté serveur et navigateur et a été pris en charge par eux à partir de 2006.

Dans le cas du serveur Apache , le traitement SNI est par ex. B. contrôlé par une instruction de configuration légèrement modifiée : ^{[6] [7]}
<VirtualHost _default_:443>

l'intégration

L'intégration de HTTPS dans un site Web ou une application est analogue aux variantes de numérotation HTTPS mentionnées ci-dessus :

• Si seul HTTPS est autorisé, cela peut être implémenté par :
  • Redirection ( rafraîchissement HTML ) ou une réécriture de l'URL
  • Configuration des pages HTML ou des scripts en SSL obligatoire, avec Apache par exemple via l'instruction SSLRequireSSLen .htaccess . Si une telle page est accessible via HTTP, le serveur génère un code d'erreur HTTP '403 – Forbidden' .
• L'utilisateur est informé de la possibilité d'utiliser SSL par un lien correspondant.
  • Dans certains cas, notamment lors de l'introduction du HTTPS, une application via un lien est supprimée. L'utilisateur ne peut basculer manuellement vers HTTPS qu'en ajoutant le "s" après "http" dans l'URL.
• Génération contrôlée par script de liens HTTPS pour diriger l'utilisateur vers une page HTTPS pour certaines étapes de travail ou sorties. Vous pouvez alors vérifier dans le script s'il a été appelé via HTTPS, par exemple avec PHP en utilisant la condition :$_SERVER['HTTPS']=='on'

conversion

Avec l'augmentation des performances du processeur et la sensibilisation à la sécurité, il est régulièrement nécessaire de convertir un site Web qui était auparavant basé sur HTTP en HTTPS. Dans le cas du site Web Stack Overflow avec un grand nombre d'utilisateurs et de services, ce processus a pris plusieurs années ^[8] et n'est pas terminé en mars 2017. Entre autres, travaillé sur les sujets suivants : ^[9]

• Éviter l'intégration de données non chiffrées (données médias, feuilles de style, etc.) dans une page chiffrée ( contenu dit mixte ^[10] ). Sinon, les avertissements du navigateur tels que "Une partie de cette page n'est pas sécurisée" ou les données ne se chargeront pas.
• Toute l'infrastructure doit être convertie en SSL, y compris les équilibreurs de charge et les proxys
• Organisation des certificats, éventuellement pour un grand nombre de sous-domaines
• Conversion du code de sa propre application Web, dans laquelle HTTP est codé en dur
• Conversion de l'ancien et test du nouveau code utilisateur, qui peut utiliser HTTP
• contrôle qualité
• Mise en place de sessions en continu sans perdre leur contenu (fonctionnement 24h/24 et 7j/7)

performance

Lorsque la connexion est établie, le serveur définit un algorithme de chiffrement. En théorie, le serveur devrait s'orienter vers les souhaits du client. Cependant, afin de gagner du temps de calcul, les chiffrements de flux sont préférés sur les serveurs à fort trafic de données , car ils sont moins gourmands en calcul que les chiffrements de blocs tels que AES ou Camellia . De nombreuses méthodes utilisées depuis longtemps, telles que RC4 , sont considérées comme non sécurisées et ne sont donc plus prises en charge par les principaux navigateurs Web depuis 2016 . ^[11]

Des accélérateurs matériels SSL sont également disponibles pour soulager le CPU du serveur : cartes enfichables PCI avec des processeurs spéciaux optimisés qui sont adressés à partir de la bibliothèque SSL. Il existe également des périphériques autonomes, généralement montés en rack, qui cryptent automatiquement des parties du flux de données HTTP. Des serveurs avec des unités de calcul programmables sont également proposés, qui, avec les bibliothèques SSL appropriées, atteignent des performances supérieures à celles des processeurs universels comparativement complexes, selon le MAU ( Modular Arithmetic Unit ) de Sun. Cependant, ce matériel spécial est en concurrence étroite avec le développement constant des systèmes multiprocesseurs et multicœurs des principaux fabricants de processeurs Intel et AMD. ^[12]

Par exemple, en 2010, le chiffrement utilisait moins de 1 % de la charge du processeur de Gmail , moins de 10 Ko de mémoire par connexion et moins de 2 % du trafic réseau . ^[13] 10 ans plus tôt, l'effort de calcul du cryptage pesait encore lourdement sur les serveurs. ^[13]

Attaques et vulnérabilités

Avec l'augmentation générale des connaissances de la technologie HTTPS, les attaques contre les connexions sécurisées par SSL ont également augmenté. De plus, les lacunes dans la mise en œuvre sont devenues connues grâce à la recherche et à la recherche. Une distinction fondamentale doit être faite entre les faiblesses du cryptage lui-même et celles du système de certificats. En 2013, dans le cadre de l' affaire mondiale de surveillance et d'espionnage , on apprend que la NSA utilise les deux canaux d'attaque pour accéder à des connexions cryptées.

chiffrement

Les méthodes de cryptage utilisées avec SSL sont vérifiées régulièrement, quelle que soit leur utilisation prévue, et sont considérées comme mathématiquement sûres, c.-à-d. En d'autres termes, ils ne peuvent théoriquement pas être rompus avec les techniques connues aujourd'hui. La fiabilité des algorithmes est régulièrement vérifiée, par exemple par le biais de concours entre cryptologues . La prise en charge des méthodes de chiffrement obsolètes qui ne sont plus considérées comme sécurisées sur la base de l'état actuel de la technique est régulièrement supprimée des spécifications et des implémentations et de nouvelles méthodes sont ajoutées. ^[14]

Des problèmes sont survenus à plusieurs reprises dans le passé en raison d'une mise en œuvre incorrecte de la cryptologie. En particulier, les vulnérabilités de la très répandue bibliothèque OpenSSL telle que Heartbleed ont reçu une grande attention du public.

Étant donné que les utilisateurs ne demandent généralement pas explicitement une connexion chiffrée en spécifiant le protocole HTTPS ( https:// ) lors de l'appel d'un site Web, un attaquant peut empêcher le chiffrement de la connexion avant qu'elle ne soit initialisée et peut initier un man-in-the- attaque moyenne effectuer. ^[15]

La méthode HTTP Strict Transport Security ou HSTS a été introduite en 2012 spécifiquement pour se défendre contre les attaques de rétrogradation contre le chiffrement et le détournement de session . Il est activé par un en-tête HSTS de la part du serveur, après quoi par ex. http à convertir en URL https.

système de certificat

Les connexions SSL sont fondamentalement vulnérables aux attaques de l' homme du milieu , dans lesquelles l'attaquant intercepte le trafic de données entre le client et le serveur, par exemple en se faisant passer pour un intermédiaire. Un certain nombre de méthodes d'attaque nécessitent que l'attaquant se trouve sur le réseau de la victime. Dans le cas du DNS spoofing , en revanche , ces prérequis n'existent pas.

Afin de se faire passer pour un (autre) serveur, l'attaquant doit également produire un certificat. Cela est possible, par exemple, s'il réussit à pénétrer le système d'une autorité de certification ou entre autrement en possession d'un certificat avec lequel d'autres certificats peuvent être délivrés. En particulier, dans le cas d'attaquants influents, tels que des agences gouvernementales, de telles opportunités peuvent exister, car il existe parfois aussi des autorités de certification étatiques. ^[16] L'épinglage de clé publique HTTP et la transparence des certificats rendraient ces attaques plus difficiles.

Hameçonnage et HTTPS

Un inconvénient de la confirmation automatique des certificats est que l'utilisateur n'a plus connaissance d'une connexion HTTPS. Cela a récemment été exploité dans des attaques de phishing qui simulent des applications bancaires en ligne , par exemple, et prétendent une connexion sécurisée à l'utilisateur afin de "pêcher" le code PIN / TAN qui a été saisi. En réponse, les entreprises concernées ont averti leurs clients de ne pas cliquer sur les liens des e-mails et de ne saisir les URL https que manuellement ou via des signets .

En raison des contrôles parfois superficiels lors de la délivrance des certificats, les fabricants de navigateurs ont introduit le certificat de validation étendue , voir ci- dessus .

Contenu mixte

Le rechargement de ressources non chiffrées permet à un attaquant d' injecter un code malveillant dans le site Web qui a été transmis à l'origine sous forme chiffrée à l'aide d'une attaque de l'homme du milieu . Les versions actuelles des navigateurs Web courants bloquent donc par défaut le rechargement des ressources non chiffrées. De même, un cookie HTTP utilisé à la fois pour les connexions cryptées et non cryptées court le risque de détournement de session , même si l' authentification a été effectuée via une connexion cryptée.

Vulnérabilité MD5

En décembre 2008, lors du 25e Chaos Communication Congress à Berlin, une attaque réussie contre le système de certificat SSL a été publiée. Dans le cadre d'une coopération internationale entre cryptologues et en utilisant du matériel spécialement programmé - un cluster de 200 consoles de jeux Playstation 3 - il a été possible de générer une collision dans l' algorithme MD5 , sur la base de laquelle un attaquant pourrait émettre lui-même n'importe quel certificat. ^[17] L'utilisation de l'algorithme MD5 était auparavant déconseillée dans les cercles d'experts ; il ne peut de toute façon pas être utilisé avec les certificats EV . La plupart des navigateurs Web n'acceptent pas les certificats MD5 depuis 2011. ^[18]Pour éviter des problèmes similaires, les fabricants de navigateurs ont annoncé qu'ils ne prendraient en charge les certificats SHA1 que pendant une durée limitée. ^[19]

Caractéristiques

• RFC 2818 - HTTP sur TLS

liens web

• Comment fonctionne HTTPS ?
• Apache.org : introduction à SSL

les détails