Więc jeśli dobrze rozumiem pytanie poprawnie:
- Masz aplikację internetową, które można otworzyć za pomocą żądań między pochodzenia.
- Ta aplikacja zostanie wdrożona w sieciach lokalnych, tj. Będzie dostępna za pośrednictwem niepublicznego adresu IP (maszyna obsługująca to w tej sieci, nazywam to "serwerem lokalnym").
- Chcesz zabezpieczyć połączenie między klientem a serwerem lokalnym, najlepiej za pomocą protokołu SSL.
Możesz to zrobić! Spraw, aby ktokolwiek sprawował kontrolę nad lokalnym serwerem, uzyskał certyfikat SSL dla somesubdomain.SomeDomainHeControls.com, wdrożył ten certyfikat na serwerze lokalnym i wskazał tę poddomenę lokalnemu IP. Po uzyskaniu dostępu do aplikacji za pośrednictwem tego adresu nie otrzymasz żadnych ostrzeżeń, a połączenie zostanie zabezpieczone. Tak długo, jak klient tylko uzyskuje dostęp do aplikacji przy użyciu tej domeny, jest to bezpieczne, ponieważ tylko właściciel serwera ma dostęp do klucza.
Jeśli samodzielnie kontrolujesz serwer lokalny (nikt nie może wyodrębnić klucza prywatnego), możesz po prostu uzyskać certyfikat z dowodami na dzierżawę dla *.aDomainForThisPurposeThatYouControl.com i utworzyć subdomenę dla każdego wdrożenia wskazaną odpowiednim adresem IP.
Jeśli nie kontrolujesz lokalnego serwera, a ktokolwiek nie może uzyskać własnego certyfikatu, możesz uzyskać dla nich indywidualne certyfikaty. Oznaczałoby to utworzenie deployment1.aDomainForThisPurposeThatYouControl.com, skierowanie go na lokalny adres IP, utworzenie zwykłego certyfikatu dla tej nazwy i zainstalowanie go na serwerze lokalnym. Ze względów bezpieczeństwa nie używaj tej domeny do niczego innego, ponieważ wydałeś klucze prywatne hostom w tej domenie.
Można również hostować samą aplikację na serwerze zewnętrznym pod kontrolą, jeśli sieci lokalne mają dostęp do Internetu. Wdróż zwykły SSL na tym serwerze. Po bezpiecznym załadowaniu samej aplikacji z serwera zewnętrznego może on wysyłać proste żądania HTTP w celu pobrania danych z serwera lokalnego. Spowoduje to wyświetlenie ostrzeżenia o "mieszanej zawartości", ale nie będzie błędu SSL. Następnie można użyć szyfrowania opartego na języku JavaScript w celu ochrony danych. Na przykład, jeśli chcesz tylko chronić dane przesyłane od klienta do serwera, zewnętrzny, zaufany serwer może dostarczyć klientowi zaufane biblioteki kryptograficzne JS i klucz publiczny RSA serwera wewnętrznego (przez połączenie uwierzytelnione SSL), następnie po prostu zaszyfruj swoje dane po stronie klienta, zanim wyślesz je przez zwykły HTTP. Teoretycznie można nawet utworzyć klienta SSL w JavaScript, dostarczyć skrypt i certyfikat zaufanego serwera do klienta, użyć tunelu HTTP lub WebSockets, a przez ten tunel uruchomić własne połączenie SSL między serwerem lokalnym a klientem JavaScript . Jest to oczywiście mało praktyczne, ale bezpieczne (ponieważ JS jest pobierany za pośrednictwem bezpiecznego połączenia). Możesz również załadować mały skrypt JavaScript z zaufanego serwera, który następnie pobiera resztę z lokalnego serwera, weryfikuje podpis/hash i wykonuje go. Megaupload robi coś takiego.
"Aplikacja używa tylko javascript i nie wiem, jak mogę ją chronić" Powiedziałbym, że javascript jest językiem klienta, którego nie można zabezpieczyć! –
Jaka jest rola WIFI w tej konfiguracji? – likeitlikeit
Korzystanie z protokołu SSL (HTTPS) zapewnia bezpieczną komunikację (integralność i poufność), nawet jeśli aplikacja internetowa jest dostępna za pośrednictwem otwartego Wi-Fi, ponieważ wszystkie żądania HTTP i dane odpowiedzi są szyfrowane przed wysłaniem przez sieć. Zabezpieczenie Wi-Fi obejmuje korzystanie z jednego z protokołów bezpieczeństwa bezprzewodowego, Wired Equivalent Privacy (WEP) lub Wi-Fi Protected Access (WPA) (http://en.wikipedia.org/wiki/Wireless_security), który może być używane niezależnie od używania SSL, aby chronić otwartą sieć Wi-Fi. Pamiętaj, że protokół SSL zapewnia ochronę w Internecie między klientem a aplikacją internetową. –