Czy HTTP może działać bez certyfikatu?

Ostatnio nasz zespół ds. Infrastruktury powiedział naszemu zespołowi programistów, że nie potrzebujesz certyfikatu dla protokołu https. Wspomnieli, że jedyną korzyścią z zakupu certyfikatu było zapewnienie konsumentom spokoju, że łączą się z odpowiednią witryną.

Jest to sprzeczne ze wszystkim, co zakładałem o https.

Czytam wikipedię i wspomina, że ​​do skonfigurowania https potrzebujesz certyfikatu zaufanego lub certyfikatu z podpisem własnym.

Czy można skonfigurować usługi IIS, aby odpowiadały na https bez żadnego certyfikatu?

Nie. Musisz mieć certyfikat. Może być samopodpisany, ale musi istnieć para kluczy publiczny / prywatny, aby wymienić klucz symetryczny sesji między serwerem a klientem w celu szyfrowania danych.

Krótko mówiąc, nie, ale mogą występować subtelne przypadki w zależności od tego, jak chcesz wdrożyć system.

HTTPS to HTTP przez SSL / TLS i możesz używać SSL / TLS bez certyfikatu lub z certyfikatami innego typu niż X.509 .

• Anonimowe zestawy szyfrów: mogą zapewniać szyfrowanie, ale bez uwierzytelniania. Raczej bezużyteczne ze względów bezpieczeństwa ... Cytując RFC 4346 : „ anonimowa Diffie-Hellman jest zdecydowanie odradzana, ponieważ nie może zapobiec atakom typu man-in-the-middle ”.
• Wstępnie udostępnione klucze : ma własny mechanizm weryfikacji zdalnej tożsamości, ale wspólny charakter kluczy niesie ze sobą własny zestaw problemów (w szczególności ograniczone wdrożenie).
• Zestawy szyfrów Kerberos : klient może zweryfikować tożsamość serwera w stosunku do głównej nazwy Kerberos.

Ściśle mówiąc, specyfikacja HTTP przez TLS mówi:

Zasadniczo żądania HTTP / TLS są generowane przez dereferencję URI. W związku z tym nazwa hosta serwera jest znana klientowi. Jeśli nazwa hosta jest dostępna, klient MUSI sprawdzić ją pod kątem tożsamości serwera przedstawionej w komunikacie certyfikatu serwera, aby zapobiec atakom typu man-in-the-middle.

Jeśli klient ma zewnętrzne informacje o oczekiwanej tożsamości serwera, MOŻNA pominąć sprawdzanie nazwy hosta. (Na przykład klient może łączyć się z komputerem, którego adres i nazwa hosta są dynamiczne, ale klient zna certyfikat, który serwer przedstawi.) W takich przypadkach ważne jest, aby zawęzić zakres dopuszczalnych certyfikatów w jak największym stopniu w aby zapobiec atakom człowieka w środku. W szczególnych przypadkach klient może po prostu zignorować tożsamość serwera, ale należy zrozumieć, że pozostawia to połączenie otwarte na aktywny atak.

Krótko mówiąc, jest wyraźnie przeznaczony do użytku z certyfikatem X.509 (wyraźnie odnosi się do RFC 2459, później zastąpiony przez RFC 3280 i 5280: PKI z certyfikatami X.509).

W przypadku pakietów szyfrów Kerberos może wystąpić przypadek na krawędzi. Rozsądne może być traktowanie biletu usługi Kerberos na serwerze, który może mieć taki sam cel jak certyfikat X.509 w zwykłym HTTPS, do weryfikacji tożsamości strony zdalnej. Nie jest to w pełni zgodne z zasadami RFC 2818 (chociaż może być objęte zakresem „ Jeśli klient ma zewnętrzne informacje dotyczące oczekiwanej tożsamości serwera, sprawdzanie nazwy hosta MOŻE zostać pominięte ”), ale nie byłoby całkowicie absurdalny. To powiedziawszy, nie sądzę, że zwykłe przeglądarki ogólnie obsługują zestawy szyfrów TLS Kerberos (pewna liczba może obsługiwać Kerberos poprzez uwierzytelnianie SPNEGO, ale to nie jest powiązane). Ponadto działałoby to tylko w środowisku, w którym odpowiednie jest używanie Kerberos.

„ Zapewnienie konsumentom spokoju ducha, że ​​łączą się z właściwą witryną ” jest w rzeczywistości jednym z kluczowych wymagań w celu zabezpieczenia komunikacji między nimi a serwerem. Używaj certyfikatu, który mogą zweryfikować, z odpowiednimi konwencjami nazewnictwa (RFC 2818 lub nowszy RFC 6125).

Nie możesz używać protokołu https bez żadnego certyfikatu. Musisz kupić zaufany certyfikat lub utworzyć samopodpisany certyfikat do testowania. Częścią konfigurowania serwera WWW do korzystania z protokołu https jest wskazanie poprawnych plików kluczy. Oczywiście dotyczy to wszystkich serwerów sieciowych, nie tylko iis.