HTTPS po nowemu

HTTPS to dobra rzecz. Dzieki ochronie kryptograficznej zapewnianej przez SSL/TLS dostajemy ochrone przed podsluchaniem i modyfikacja a dodatkowo mozemy potwierdzac tozsamosc stron zaangazowanych w komunikacje.

Wirtualne site'y (bede poslugiwac sie tym nieladnym slowem, bo znane mi polskie odpowiedniki sa kulawe) to tez dobra rzecz. Jeden serwer webowy moze obsluzyc naprawde duzo zupelnie niezaleznych portali czy stron. Ruch do nich mozemy rozseparowac uzywajac róznych adresów IP (klopotliwe w realiach hostingu), róznych portów (klopotliwe dla klientów) lub poprzez Host Headers, czyli dzieki wykorzystaniu naglówka, który przegladarka wysyla do serwera razem z kazdym zadaniem. Serwer odczytuje ten naglówek i wie, do którego site'u powinno zostac skierowane zadanie. Dzieki Host Headers, na jednym adresie IP i na jednym porcie mozemy uruchomic ogromna ilosc site'ów i kto pamieta rozgrzewke przed Quiz2008, ten wie ze siedmiocyfrowe liczby sa tu zupelnie prosto osiagalne.

Problem jednak pojawia sie w sytuacji, gdy wymienione powyzej zalety zechcemy polaczyc. Jezeli szyfrujemy transmisje, to szyfrowane beda i naglówki Host. A rozszyfrowac je umie tylko wirtualny site, dla którego sa przeznaczone. Tyle, ze póki ich nie rozszyfrujemy, to nie wiadomo, któremu je wyslac... W efekcie chcac miec na jednym serwerze kilka site'ów obslugujacych HTTPS, musimy w praktyce uzywac wielu adresów IP a to zwykle nie jest OK chocby dlatego, ze marnie sie skaluje. Teoretycznie istnieje rozwiazanie ale praktyczne jego zastosowania sa bardzo ograniczone i prawie na pewno nie sprawdza sie w scenariuszach hostingowych.

Istnieje tez rozwiazanie drugie – przeslac ten jeden naglówek w postaci niezaszyfrowanej. Da sie tak zrobic przy wykorzystaniu rozszerzen protokolu TLS. Nazywa sie to Server Name Identification (SNI) i opisane jest w RFC6066.

Na przyklad, dla serwera alice.sni.velox.ch, nawiazanie transmisji (TLS Client Hello) wyglada tak:

Jak widac, wsród listy rozszerzen protokolu znalazl sie rozszerzenie "Server Name" zawierajace potrzebna serwerowi informacje.

A gdybysmy chcieli cos takiego zrobic na serwerze IIS? Uzywam IISa od wersji 2.0 i przyznam sie, ze nieraz mi tego brakowalo. Nauczylem sie (jak to w IT) jakos sobie radzic, ale od pewnego czasu mam do czynienia z IIS w wersji 8 i wbudowane wsparcie dla SNI jest naprawde mila funkcjonalnoscia. Aby skorzystac z jego dobrodziejstw, wystarczy domyslna instalacja IIS. Tworzac nowy site, wybieramy ze ma byc podpiety pod https, wskazujemy certyfikat, podajemy host header i gotowe. Dziala od razu.

Oczywiscie jak to bywa z szyfrowaniem w warstwie aplikacji, wszystkie funkcjonalnosci powinny byc wspierane i przez serwer i przez przegladarke. A co, jezeli nie jest, bo uzytkownik nadal uwaza, ze nastoletni juz Windows XP jest zupelnie OK? Który site dostanie zadanie? Ten, który pasuje adresem IP i portem, ale nie ma zaznaczonej opcji "Require Server Name Identification". Dla klienta prawdopodobnie skonczy sie to ostrzezeniem o certyfikacie z niezgodna nazwa i raczej nieoczekiwana strona w przegladarce, ale bez problemu da sie to rozsadnie poukladac, jezeli tylko ktos ma taka potrzebe. Oczywiscie odznaczenie tej opcji dla wiecej niz jednego site'u na tym samym adresie i porcie nie jest mozliwe.

Skoro juz mowa o certyfikatach w IIS8, to wypada wspomniec jeszcze kilka drobiazgów:

• dostepny w konsoli zarzadzajacej widok certyfikatów pozwala na ich pogrupowanie wedlug daty wygasniecia. Jezeli mamy jeden czy dwa site'y z SSLem, to da sie zyc i bez tego. Jednak tam, gdzie sa ich dziesiatki, funkcjonalnosc robi sie calkiem uzyteczna. Wiem, ze da sie inaczej, ale tak jest po prostu wygodnie.
  
• store certyfikatów komputera ma nowy kontener "Web Hosting" – certyfikaty, które tam sie znajduja dzialaja tak samo jak certyfikaty z "Personal", jednak róznica daje sie zauwazyc w wydajnosci. Kontener "Web Hosting" przygotowany jest do pracy z setkami albo tysiacami certyfikatów. "Personal" – niekoniecznie.
  
• certyfikaty ladowane sa do pamieci wtedy, gdy sa faktycznie potrzebne, bo ktos uzywa ich do zabezpieczenia transmisji z konkretnym site. Brzmi to trywialnie, jednak w starszych IISach ladowane byly wszystkie "na zapas". Poniewaz nie bylo SNI, to certyfikatów nie bylo zwykle duzo i nie bylo to klopotem. W IIS8 podejscie zostalo zmienione i wydaje sie, ze ma to swój sens.

Ostatnia nowosc to CCS czyli Central Certificate Store. W przeciwienstwie do SNI wymaga doinstalowania jako skladnika roli IIS.

CCS to jeden centralny "worek" na certyfikaty w formacie *.pfx. Moga do niego siegac wszystkie skonfigurowane serwery i jezeli tylko dla danego site da sie polaczyc nazwe hosta z nazwa pliku pfx – IIS sam skorzysta z certyfikatów w centralnym repozytorium. Jezeli dany site ma korzystac z CCS, to oczywiscie w jego przypadku reczny wybór certyfikatu staje sie niedostepny.

Jak sie nietrudno domyslec, uzycie CCS wymaga, aby haslo do *.pfx bylo takie samo dla wszystkich plików.

Zalety Central Certificate Store wydaja sie interesujace: latwa wymiana certyfikatów dla wszystkich serwerów na raz, proste tworzenie dostepnych przez HTTPS site'ów, uproszczone dodawanie certyfikatów i podlaczanie ich do site'ów... Choc jest to ciekawe, to nie jestem osobiscie przekonany czy bardzo uzyteczne. Jezeli mamy tak duzo site'ów ze nie zarzadzamy nimi "recznie" to mamy do tego zestaw skryptów i automaty. Dodanie w takim przypadku linijki albo dwóch po to, zeby zajely sie certyfikatami nie jest powaznym problemem. Ale funkcjonalnosc jest dostepna i moze komus sie przyda.

Podsumowujac nowosci dotyczace wsparcia IIS8 dla HTTPS trzeba zwrócic uwage na kierunek wprowadzonych zmian. Praktycznie wszystkie zorientowane sa na wsparcie (funkcjonalnoscia, wydajnoscia albo wygoda zarzadzania) dla duzych srodowisk, gdzie dzialac moze naprawde wiele wirtualnych serwerów dostepnych przez ten protokól. Wydaje sie to calkiem interesujace i z pewnoscia otwiera nowe mozliwosci. Warto przyjrzec sie blizej.

Autor: Grzegorz Tworek [MVP]