Řešení 1:
Je to věc názoru a souvisí to také s regulačními problémy (pokud s nějakými čelíte).
I když to v současné době není nutné, jsem velkým zastáncem zachování HTTPS povoleného mezi firewally na aplikační úrovni / nástroji pro vyrovnávání zatížení / front-end servery a back-end servery. Je to o jednu útočnou plochu méně. Uzavřel jsem smlouvy s místy, která potřebovala převést, když se začaly předávat citlivější informace – je lepší začít tam.
Obecně bych navrhoval použití interního CA (pokud je k dispozici) nebo vlastního podpisu (pokud neexistuje interní CA) serverů back-end. Datum vypršení platnosti bychom nastavili pěkně a daleko do budoucnosti, abychom se vyhnuli zbytečným změnám.
Řešení 2:
TL;DR měli byste přenos zašifrovat pokud není na stejném hostiteli.
Své síti nemůžete věřit. Malware ve vaší vlastní síti může zachytit/upravit http požadavky.
Nejsou to teoretické útoky, ale příklad ze skutečného života:
-
Směrovače (pravděpodobně hacknuté) v síti některých webových stránek, které vkládají reklamy:https://www.blackhat.com/docs/us-16/materials/us-16-Nakably-TCP-Injection-Attacks-in-the-Wild- A-Large-Scale-Study-wp.pdf
-
Indická síť čichající mezi cloudfare a back-endem:https://medium.com/@karthikb351/airtel-is-sniffing-and-censoring-cloudflares-traffic-in-india-and-they-don-t-even-know -it-90935f7f6d98#.hymc3785e
-
Nyní známé „SSL Added and Remove here :-)“ od NSA
Řešení 3:
Potřebuje „spousta dalších serverů“ běžet přes HTTPS, nebo vzhledem k tomu, že k nim není možný externí přístup, mohou místo toho běžet bezpečně přes HTTP?
To opravdu záleží na tom, čeho se snažíte dosáhnout. Pochopte, že účelem použití HTTPS je chránit data při přenosu mezi dvěma body. Pokud se obáváte, že data jsou sniffována ve vaší síti, možná byste se o to měli postarat jako první. Pokud potřebujete chránit data při přenosu ve vaší síti, říkáte, že buď máte obavy o bezpečnost dat procházejících vašimi systémy uvnitř vaší sítě, nebo existuje nějaký důvod související s dodržováním předpisů, abyste data při přenosu šifrovali.
To je opravdu spíše otázka názoru, ale odpověď je, že záleží. Co se snažíš udělat? Jaký druh dat šifrujete? Před jakými hrozbami se snažíte bránit? Máte zákonný požadavek (např. PCI-DSS, HIPAA atd.), který říká, že musíte data při přenosu šifrovat? Pokud jsou data citlivá a máte obavy, že by mohla být zneužita, když jsou přenášena ve vaší síti, navrhuji, abyste se spojili s vedením a problém vyřešili. Takže nakonec, co se snažíte chránit a proč se to snažíte chránit?
Řešení 4:
Dříve lidé předpokládali, že vnitřní sítě jsou bezpečné jako domy. Jednou jsem se dostal do sporu s nadřízeným, který byl zděšen tím, že na mých interních serverech běží jejich vestavěné firewally. "Pokud nemůžete věřit své interní síti, komu můžete věřit?" Poukázal jsem na to, že máme v interní síti studentské notebooky a že mezi studentskými notebooky a mými servery není žádný firewall. On, protože byl na akademické půdě nový, se zdálo, že jeho vesmír je po této informaci v troskách.
Interní sítě již nejsou považovány za bezpečné, i když v síti nemáte studentské notebooky. Některé příklady viz Tomova odpověď.
To znamená, že ano, záleží na tom, jaké informace jsou přenášeny, jaké jsou problémy s dodržováním právních předpisů atd. Můžete se rozhodnout, že vám bude jedno, jestli někdo šňupe, řekněme, data o počasí. To znamená, že je možné, že i když odesílaná data nejsou citlivá nyní , někdo se může později rozhodnout přidat do vaší aplikace funkce, které jsou citlivý, takže bych doporučil větší paranoiu (včetně HTTPS).
Řešení 5:
Dnes se specializovanými instrukcemi CPU pro urychlení šifrování a novými transportními protokoly, které nebudou fungovat vůbec nebo budou fungovat s horším výkonem přes nešifrované spojení (HTTP/2, gRPC atd...), možná je lepší otázka:Existuje nějaký důvod, proč požadujete downgrade síťového odkazu na HTTP? Pokud neexistuje žádný konkrétní důvod, odpovědí je zůstat u HTTPS.