Cześć,
chciałem się upewnić w następującej kwestii:
Gdy tworzy się Web API w asp.net to jest opcja skonfigurowania HTTPS.
Gdybym chciał postawić sobie takie API np. na Nginx i tam skonfigurować SSL to czy w WEB API ten parametr powinien być zahaczony czy lepiej go odhaczyć?
Ogólnie standardem w firmach i wszędzie jest HTTPS. Jeśli tylko lokalnie sobie programujesz to nie ma większego znaczenia. Wyobraź sobie, że piszesz na karteczce wszystkie swoje sekrety, których nie chciałbyś nikomu zdradzić.
Teraz masz rurę do której wrzucasz karteczkę dla przykładu to strzał do Twojego API:
Ty -> Przeglądarka na komputerze -> Komputer -> Router -> Router / Switch dostawcy Internetu -> Masa urządzeń sieciowych po drodze -> Proxy / LoadBalancer -> Serwer z API
Jak karteczka jest zaszyfrowana przez HTTPS to teoretycznie na całej drodze nikt nie odczyta tego co napisałeś. Tu warto poczytać o czymś takim jak rozpruwanie SSL przez urządzenia brzegowe.
Jeśli leci po HTTP to wszędzie gdzie ktoś nasłuchuje ruch (np. za pomocą WireSharka) i przechwyci Twój pakiet może podejrzeć wszystko co napisałeś jawnym tekstem.
W firmach czasem jest też tak, że np. ruch HTTPS jest od klienta do LoadBalancera / Proxy firmy, ale już na tym LB / Proxy następuje terminacja SSL i np. z racji, że LB oraz inny serwer są w sieci wewnętrznej np. segmentowanej to może lecieć po HTTP. Wtedy aplikacja backendowa nie musi się męczyć z rozszyfrowaniem, ale aktualnie nie są to duże narzuty. Wiadomo, że rozszyfrowywanie musi spalić trochę pracy CPU niż nicnierobienie.
W Twoim przykładzie możesz np. wystawić sobie tylko po HTTPS 443 adres Nginxa, czyli jak strzał leci po HTTPS do Nginxa to odbiera go zaszyfrowanego, ale już następnie kieruje po HTTP do API .NET po http w obrębie tego samego serwera. Tutaj przypadek, że Nginx jak i API są na tej samej maszynie. Jak np. są to 2 osobne maszyny to lepiej szyfrować, bo strzał przechodząc między serwerami jak zostanie przechwycony to też może być odczytany.
Ogólnie nie wiem czy wiesz, ale nowy .NET ma własny serwer o nazwie Kestrel i wystarczy, że odpalisz API i odblokujesz port na którym chodzi i nie potrzebujesz Nginxa. Przy czym w faktycznych zastosowaniach dedykowany serwer HTTP jak Nginx, Windows IIS czy Apache są zalecane, bo dają różne inne możliwości jak rewrite rule, kompresje, certyfikaty itd.
Polecam poczytać:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/linux-nginx?view=aspnetcore-10.0&tabs=linux-ubuntu
https://learn.microsoft.com/pl-pl/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-10.0
@Ryan_1975 dzięki, chociaż większość tekstu jest raczej zbędna. Ja nie pytałem się czym jest SSL/HTTPS i czy jest mi to potrzebne. Bardziej miałem wątpliwość czy jak skonfiguruję SSL na Nginx (w sensie serwerze www a nie proxy czy LB) to czy muszę dodatkowo konfigurować SSL po stronie ASP.NET, żeby to działało. Ale jeśli dobrze to rozumiem, to nie muszę konfigurować SSLa w ASP.NET i lepiej ten parametr odhaczyć.
Wiem również o Kestrelu, ale zdaje się, że on się nie lubi z Let's Encrypt.
czy jak skonfiguruję SSL na Nginx (w sensie serwerze www a nie proxy czy LB) to czy muszę dodatkowo konfigurować SSL po stronie ASP.NET, żeby to działało. Ale jeśli dobrze to rozumiem, to nie muszę konfigurować SSLa w ASP.NET
Nie musisz, terminacja TLS może następować na nginx (czy tam innym serwerze czy load-balancerze).
Ale wtedy ruch od serwera do twojej aplikacji jest nieszyfrowany, a jeżeli są potencjalnie w dwóch różnych sieciach albo "po drodze" ktoś może przechwycić, to może warto, aby też był szyfrowany.
A ten "prztyczek" w konfiguracji aplikacji tak naprawdę ustawia chyba ze dwie dodatkowe opcje w Program.cs, które potem można wyłączyć (albo dodać) ręcznie - np. UseHttpsRedirection().
Jeśli ufasz wszystkiemu pomiędzy reverse proxy a twoim serwerem lub nginx stoi na tym samym serwerze to https jest zbędny a wręcz przeszkadza, komplikuje zarządzanie i odnawianie certyfikatów i niepotrzebnie marnuje zasoby. Ja bym odhaczył