Https peut-il fonctionner sans certificat?

Récemment, notre équipe d'infrastructure a déclaré à notre équipe de développement que vous n'avez pas besoin d'un certificat pour https. Ils ont mentionné que le seul avantage d'acheter un certificat était de donner au consommateur la tranquillité d'esprit qu'il se connectait au bon site Web.

Cela va à l'encontre de tout ce que je supposais à propos de https.

J'ai lu wikipedia et il mentionne que vous avez besoin d'un certificat de confiance ou d'un certificat auto-signé pour configurer https.

Est-il possible de configurer IIS pour répondre à https sans aucun certificat?

— marque
source

Vous constaterez peut-être que ce n'est qu'un problème de communication. Votre serveur a probablement des certificats auto-signés prêts à l'emploi. Soit dit en passant , c'est cet avertissement que vous évitez en utilisant un certificat de confiance public: m86security.com/kb/article.aspx?id=13446 Cela peut être acceptable dans votre environnement ou non. Je dirais que c'est plus qu'une simple tranquillité d'esprit - dans un site Web public, c'est un signe de professionnalisme!

— Dan

Les certificats auto-signés vous offrent un cryptage, mais il ne peut pas protéger contre les attaques de l'homme au milieu, car vous obtenez les mêmes avertissements concernant les certificats non valides ou non vérifiés pour les auto-signés que pour un gars interceptant le trafic, le décryptant, voler les données et les rechiffrer pour les retourner au client.

— Bart Silverstrim

"Les certificats auto-signés vous offrent un chiffrement, mais ils ne peuvent pas protéger contre les attaques de l'homme du milieu [...]", à moins que l'utilisateur ne puisse faire confiance à ces certificats auto-signés explicitement par un mécanisme hors bande, qui est réaliste que possible pour une petite base d'utilisateurs qui vous connaît via un tel mécanisme hors bande. Peu probable, en effet.

— Bruno

Ou s'ils lui font confiance la première fois, ils seront avertis si cela change à l'avenir. Tout comme les signatures SSH, vraiment.

— mfinni

Techniquement, SSL / TLS n'a pas besoin de certificats pour sécuriser un canal de communication. En fait, SSL / TLS peut utiliser un autre mécanisme pour sécuriser le canal: certificats pgp, nom d'utilisateur / mot de passe, clés pré-partagées ou "anonymes" (pas d'authentification du tout). De même, SSL / TLS ne garantit pas le cryptage, il existe de nombreux cyphers différents qu'il peut utiliser, y compris "null" (pas de cryptage du tout). Et il existe des options similaires pour l'authentification Digest. C'est donc très bien, mais quels programmes utilisent tout cela: fondamentalement aucun, certainement aucun serveur ou logiciel de navigation majeur (ils nécessitent tous des certificats).

— Chris S

Réponses:

Non. Vous devez avoir un certificat. Il peut être auto-signé, mais il doit y avoir une paire de clés publique / privée en place pour échanger la clé symétrique de session entre le serveur et le client pour crypter les données.

— Driftpeasant
source

Diffie-Hellman anonyme, comme indiqué dans une autre réponse, a permis une connexion sans certificat - mais les versions OpenSSL modernes sont généralement compilées sans aucun support pour ADH.

— Brandon Rhodes

En bref, non, mais il peut y avoir des cas subtils selon la façon dont vous souhaitez déployer le système.

HTTPS est HTTP sur SSL / TLS, et vous pouvez utiliser SSL / TLS sans certificat ou avec des certificats d'autres types que X.509 .

Suites de chiffrement anonymes: elles peuvent fournir un chiffrement, mais sans authentification. Plutôt inutile en matière de sécurité ... Pour citer la RFC 4346 : " Diffie-Hellman anonyme est fortement déconseillé car il ne peut pas empêcher les attaques de l'homme du milieu " .
Clés pré-partagées : il possède son propre mécanisme pour vérifier l'identité à distance, mais la nature partagée des clés pose son propre ensemble de problèmes (en particulier un déploiement limité).
Suites de chiffrement Kerberos : le client peut vérifier l'identité du serveur par rapport au nom principal Kerberos.

À strictement parler, la spécification HTTP sur TLS dit ce qui suit:

En général, les requêtes HTTP / TLS sont générées en déréférençant un URI. Par conséquent, le nom d'hôte du serveur est connu du client. Si le nom d'hôte est disponible, le client DOIT le vérifier par rapport à l'identité du serveur telle que présentée dans le message de certificat du serveur, afin de prévenir les attaques de l'homme du milieu.

Si le client dispose d'informations externes sur l'identité attendue du serveur, la vérification du nom d'hôte PEUT être omise. (Par exemple, un client peut se connecter à une machine dont l'adresse et le nom d'hôte sont dynamiques mais le client connaît le certificat que le serveur présentera.) Dans de tels cas, il est important de restreindre autant que possible la portée des certificats acceptables dans afin d'empêcher l'homme au milieu des attaques. Dans des cas particuliers, il peut être approprié que le client ignore simplement l'identité du serveur, mais il faut comprendre que cela laisse la connexion ouverte à une attaque active.

En bref, il est clairement destiné à être utilisé avec un certificat X.509 (il fait clairement référence à RFC 2459, remplacé par la suite par RFC 3280 et 5280: PKI avec certificats X.509).

Il peut y avoir un cas particulier lorsque vous utilisez des suites de chiffrement Kerberos. Il peut être judicieux de traiter le ticket de service Kerberos du serveur pourrait être supposé avoir le même objectif que le certificat X.509 en HTTPS habituel, pour la vérification de l'identité de la partie distante. Il ne correspond pas tout à fait aux règles de la RFC 2818 (bien qu'il puisse tomber sous " Si le client dispose d'informations externes sur l'identité attendue du serveur, la vérification du nom d'hôte PEUT être omise. "), Mais elle ne le serait pas complètement absurde. Cela étant dit, je ne pense pas que les navigateurs habituels prennent en charge les suites de chiffrement TLS Kerberos en général (un certain nombre peut prendre en charge Kerberos via l'authentification SPNEGO, mais cela n'est pas lié). De plus, cela ne fonctionnerait que dans un environnement où l'utilisation de Kerberos est appropriée.

« [Donner] la tranquillité d'esprit au consommateur qu'il se connecte au bon site Web » est en fait l'une des exigences clés pour sécuriser la communication entre lui et votre serveur. Utilisez un certificat qu'ils peuvent vérifier, avec les conventions de dénomination appropriées (RFC 2818 ou plus récemment RFC 6125).

— Bruno
source

Vous NE POUVEZ PAS utiliser https sans aucun certificat. Vous devez soit acheter un certificat de confiance, soit en créer un auto-signé pour les tests. Une partie de la configuration de votre serveur Web pour utiliser https consiste à le pointer vers les bons fichiers clés. Bien sûr, cela s'applique à tous les serveurs Web, non seulement à iis.

— Khaled
source

Pour tester si votre OpenSSL peut prendre en charge les connexions sans certificat , exécutez openssl cipherset recherchez un ADHprotocole comme ADH-AES256-SHA- si un tel protocole est présent, vous pouvez techniquement configurer une connexion sans aucun certificat impliqué.

— Brandon Rhodes