Czy wszystkie serwery muszą korzystać z protokołu HTTPS, czy tylko z serwerów publicznych?

38

Mam frontendowy serwer WWW działający na HTTPS - to jest publiczne - tzn. Port jest otwarty.

Mam również serwer API zaplecza, do którego mój serwer WWW wysyła żądania API - jest to publiczny obiekt i wymaga uwierzytelnienia - port jest otwarty.

Te 2 serwery działają na HTTPS.

Za serwerem API znajduje się wiele innych serwerów. Serwer API odwraca serwery proxy do tych serwerów. Porty dla tych innych serwerów nie są otwarte na ruch przychodzący. Można się z nimi rozmawiać tylko za pośrednictwem serwera API.

Moje pytanie ... Czy „wiele innych serwerów” musi działać przez HTTPS, czy, biorąc pod uwagę, że nie można uzyskać do nich dostępu z zewnątrz, czy mogą zamiast tego bezpiecznie korzystać z HTTP?

Myślałem, że to będzie częste pytanie, ale nie mogłem znaleźć na nie odpowiedzi. Dzięki. Jeśli to dupe, proszę wskazać mi właściwą odpowiedź.

danday74
źródło
35
W świetle tego, jak NSA wykorzystała łącza zagraniczne, których Google i Yahoo komunikowały się między swoimi centrami danych w sposób niezaszyfrowany, zalecam, aby zawsze zakładać, że połączenie jest podejrzane. Nigdy nie wiadomo, gdzie ktoś może nasłuchiwać i lepiej być bezpiecznym niż żałować. Chciałbym rozważyć użycie samego HTTP tylko raz, gdy usługa jest uruchomiona na tym samym komputerze, który z niej korzysta, otwarta tylko na połączenia lokalne.
childofsoong
7
Jest to znane jako odciążenie i zakończenie ssl, jeśli chcesz przeprowadzić dalsze badania.
Esben Skov Pedersen
31
To jak pytanie „czy wszystkie drzwi potrzebują zamków, czy tylko drzwi od zewnątrz”? Tylko Ty możesz odpowiedzieć na to pytanie, rozważając zagrożenia w sieci i poza nią.
Ryan Griggs
5
Jak mówi Security.SE : „Bezpieczeństwo jest bardzo kontekstowym tematem: zagrożenia, które są uważane za ważne w twoim środowisku, mogą być nieistotne dla kogoś innego i odwrotnie. Czy próbujesz chronić coś o globalnej wartości przed zaawansowanymi zagrożeniami trwałymi? Lub szukasz niedrogiego rozwiązania dla małej firmy? Aby uzyskać najbardziej pomocne odpowiedzi, powinieneś nam powiedzieć: jakie aktywa chcesz chronić; kto korzysta z aktywów, które chcesz chronić, i kogo myślę, że może chcieć nadużyć (i dlaczego); ...
DW
2
jakie kroki już podjąłeś, aby chronić ten zasób; jakie ryzyko uważasz, że nadal musisz złagodzić. ”Tego rodzaju kontekst jest niezbędny. Sugeruję, abyś zmienił pytanie, aby uwzględnić te informacje.
DW,

Odpowiedzi:

50

Jest to kwestia opinii i ma również związek z kwestiami regulacyjnymi (jeśli masz do czynienia).

Nawet jeśli nie jest to obecnie konieczne, jestem wielkim zwolennikiem utrzymania HTTPS między zaporami ogniowymi / modułami równoważenia obciążenia / serwerami frontonu i serwerami zaplecza na poziomie aplikacji. To o jeden mniej powierzchnia ataku. Zawarłem umowy z miejscami, które musiały zostać przekonwertowane, ponieważ zaczęły być przekazywane bardziej wrażliwe informacje - lepiej zacząć od tego.

To, co ogólnie sugeruję, to użycie wewnętrznego urzędu certyfikacji (jeśli jest dostępny) lub autopodpisania (jeśli nie ma wewnętrznego urzędu certyfikacji) serwerów zaplecza. Ustawiliśmy datę ważności na dobrą i daleką przyszłość, aby uniknąć niepotrzebnych zmian.

Tim Brigham
źródło
1
lepiej zacząć - słowa, które dały ci punkty :)
danday74,
12
To jest dobry pomysł. Nie chcesz, aby NSA robił głupie rysunki twojej topologii sieci .
Kevin
3
Szyfrowanie całej komunikacji zabezpiecza również przed wewnętrznym podsłuchiwaniem - czy to w postaci komputera stażysty, który przechwycił trojana podczas przeglądania zdjęć kotów, czy małego sniffera podłączonego do portu sieciowego za nieużywanym biurkiem, czy też udostępnionego hasła Wi-Fi trochę za luźno.
Doktor J
8
We'd set the expiration date nice and far into the future to avoid unnecessary changes.” i dodaj regułę do preferowanego pakietu monitorowania, aby ostrzec Cię, gdy wkrótce wygaśnie. Proszę!
GnP
2
@GnP Robię to również - jeśli jest to certyfikat z 10-letnim okresem, nasza polityka zawsze nakazuje wymianę serwera zaplecza w tym okresie. Sprawia, że ​​jest to trochę zbędne i nie wydaje się konieczne, aby wspominać w odpowiedzi.
Tim Brigham,
19

TL; DR należy szyfrować ruch, chyba że jest na tym samym hoście.

Nie możesz ufać swojej sieci. Szkodliwe oprogramowanie we własnej sieci może przechwytywać / modyfikować żądania HTTP.

To nie są teoretyczne ataki, ale przykład z życia:

Tomek
źródło
16

Czy „wiele innych serwerów” musi działać przez HTTPS, czy, biorąc pod uwagę, że nie można uzyskać do nich dostępu z zewnątrz, czy mogą zamiast tego bezpiecznie korzystać z HTTP?

To naprawdę zależy od tego, co próbujesz osiągnąć. Zrozumieć, że celem korzystania z HTTPS jest ochrona danych przesyłanych między dwoma punktami. Jeśli obawiasz się, że dane są wąchane w Twojej sieci, być może najpierw należy się tym zająć. Jeśli chcesz zabezpieczyć przesyłane dane w sieci, mówisz, że masz obawy dotyczące bezpieczeństwa danych przechodzących przez twoje systemy wewnątrz sieci lub istnieje jakiś powód związany z zachowaniem zgodności z przepisami, aby szyfrować przesyłane dane.

To jest raczej pytanie poglądowe, ale odpowiedź brzmi: to zależy. Co próbujesz zrobić? Jakie dane szyfrujesz? Z jakimi zagrożeniami próbujesz się bronić? Czy masz wymóg prawny (np. PCI-DSS, HIPAA itp.), Który mówi, że musisz zaszyfrować przesyłane dane? Jeśli dane są wrażliwe i obawiasz się, że mogą zostać niewłaściwie wykorzystane, gdy są przesyłane w Twojej sieci, sugerowałbym spotkanie z zarządem w celu rozwiązania problemu. Więc w końcu, co próbujesz chronić i dlaczego próbujesz to chronić?

użytkownik5870571
źródło
13

Wcześniej ludzie zakładali, że sieci wewnętrzne są bezpieczne jak domy. Kiedyś wdałem się w spór z przełożonym, który był przerażony, że moje wewnętrzne serwery działają z wbudowanymi zaporami ogniowymi. „Jeśli nie możesz zaufać swojej sieci wewnętrznej, komu możesz zaufać?” Zwróciłem uwagę, że w naszej wewnętrznej sieci mamy laptopy dla studentów i że nie ma zapory ogniowej między studentami a moimi serwerami. On, będąc nowym w środowisku akademickim, wydawał się mieć swój wszechświat w strzępach na tę informację.

Sieci wewnętrzne nie są już uważane za bezpieczne, nawet jeśli nie masz laptopów studenckich w sieci. Zobacz przykłady Toma, aby uzyskać przykłady.

To powiedziawszy, tak, to zależy od tego, jakie informacje są przesyłane, od wszelkich problemów związanych z przestrzeganiem prawa itp. Możesz zdecydować, że nie obchodzi Cię, że ktoś wącha, powiedzmy, dane pogodowe. Powiedział, że to jest możliwe, że nawet jeśli nie jest wysłana Dane wrażliwe teraz , ktoś może zdecydować, aby dodać funkcje do aplikacji później, że wrażliwe, więc polecam większą paranoję (łącznie HTTPS).

Katherine Villyard
źródło
Dane pogodowe mogą być wystarczająco wrażliwe: ktoś może opierać swoje błędne decyzje na sfałszowanych danych pogodowych.
Hagen von Eitzen,
1
Właściwie to zależy od tego, do czego używasz danych pogodowych. Próbowałem wymyślić coś nieszkodliwego. :)
Katherine Villyard
1
@HagenvonEitzen lub atakujący wstrzyknąłby tam złośliwe oprogramowanie / reklamy, więc babcia zostaje zaskoczona, gdy sprawdza pogodę na swoim komputerze z systemem Windows XP.
André Borie
8

Dzisiaj, ze specjalnymi instrukcjami procesora dotyczącymi przyspieszenia szyfrowania i nowymi protokołami transportowymi, które w ogóle nie będą działać lub będą działać z obniżoną wydajnością w przypadku niezaszyfrowanego łącza (HTTP / 2, gRPC itp.), Być może lepszym pytaniem jest: czy są jakieś powód, dla którego chcesz obniżyć łącze sieciowe do HTTP? Jeśli nie ma konkretnego powodu, odpowiedzią jest pozostanie przy HTTPS.

Aaron
źródło
Niezły proces myślowy
danday74,
5

Jedynym powodem, dla którego mogę wyłączyć szyfrowanie, jest myśl o wydajności. Jednak w twoim przypadku serwery wewnętrzne są połączone przez HTTP, co oznacza, że ​​już ponoszą one koszty wydajności związane z uruchomieniem serwera WWW, obsługą protokołu HTTP i kodowaniem danych w HTTP / JSON / cokolwiek. Wyłączenie szyfrowania zwolni prawdopodobnie 100 KB pamięci RAM i zapewni kilka mikrosekund na KB przesłanych danych, co nie będzie miało widocznego wpływu na ogólną wydajność. Z drugiej strony będziesz musiał zwracać znacznie większą uwagę na bezpieczeństwo, ponieważ teraz uruchamiasz HTTP w intranecie. W rzeczywistości możliwe jest, że bardziej rygorystyczna konfiguracja zapory ogniowej spowolni bardziej niż wyłączenie szyfrowania przyspieszyło je, powodując gorszą wydajność postrzeganą przez użytkowników końcowych.

Będzie to jak umieszczenie spoilera na ciągniku: teoretycznie zyskujesz prawie nic, a praktycznie wiele niedogodności.

Dmitrij Grigoriew
źródło