Pytanie:
Czy Google przesadza, zmuszając mnie do korzystania z TLS?
tylerl
2014-03-26 01:20:27 UTC
view on stackexchange narkive permalink

Gmail został niedawno zmieniony i wymaga protokołu HTTPS dla wszystkich, niezależnie od tego, czy chcą go używać, czy nie. Chociaż zdaję sobie sprawę, że HTTPS jest bezpieczniejszy, co jeśli ktoś nie dba o bezpieczeństwo niektórych kont?

Niektórzy krytykowali Google za to, że jest zły, zmuszając ich do bezpiecznego połączenia, nawet jeśli nie chcą być bezpieczni. Twierdzą, że jeśli to tylko ich własne konto, czy nie powinni być jedynymi, którzy decydują, czy się zabezpieczyć, czy nie?

Uwaga: To pytanie zostało opublikowane w nawiązaniu do powyższego artykułu w celu udzielenia kanonicznej odpowiedzi na pytanie zadawane poza witryną (dlatego odpowiedziała na nie ta sama osoba, która je zadała).

Możesz nie chcieć się zabezpieczać, ale mogę się założyć, że 99% innych ludzi chce być bezpiecznych, zwłaszcza gdy sprawy takie jak NSA wciąż istnieją. Chodzi mi o to, że nie chciałbym, żeby ktoś obcy czytał moje rozmowy na Skype - są prywatne. Dlatego mamy je w Internecie, a nie gdzieś publicznie. Nie chciałbym, żeby ktoś obcy na drugim końcu świata czytał moje e-maile. Często mam wiele wrażliwych e-maili, które są bardzo osobiste (nie w ten sposób!;).
Czasami można wymusić bezpieczeństwo. Przykładem jest HTTPS. Chociaż nie jest doskonały, jest znacznie lepszy niż czysty HTTP. W zasadzie nic nie kosztuje i utrudnia nadzór masowy. Pojawiły się nawet myśli, że HTTP 2.0 będzie tylko SSL.
Czy Google przesadza, zmuszając Cię do logowania przy użyciu hasła?
Czy Google złem za zmuszając używać HTML? ̶ lub przeglądarki? ̶ lub, ̶ powiedzieć, ̶ Internet? ̶ niestety uważam, że kwestia ta doesnt większego ̶s̶e̶n̶s̶e̶.̶.̶. Nie przeczytałem twojej odpowiedzi. Pytanie nie miało większego sensu, dopóki nie zdałem sobie sprawy, że możesz się nad nim zastanawiać, a potem chciałeś na nie odpowiedzieć, więc najpierw musiałeś je zadać (;
Czy rząd przesadza z żądaniem zapinania pasów podczas jazdy?
Prawdopodobnie nie dbasz o swoją prywatność w Internecie, ale inni ludzie to robią, nawet z TLS Google (lub dowolną stroną trzecią używającą SSL / TLS) mogą uzyskać dostęp do twojego konta, ponieważ mają klucz używany do szyfrowania.
Aby to było „złe”, musiałbyś argumentować, że powoduje jakąś krzywdę.
@JeffGohlke: Ale ktoś musi podnosić części ciała, więc mogę zrozumieć tę decyzję. Ta osoba nie zrobiła nic złego, to jego praca.
Chcę opcję skoku z samolotu, zwł. kiedy mam spadochron i wiem, że wyląduję na lądzie.
@Shiki To trochę zwodniczy argument. Mogę użyć twojej logiki, aby zakazać wszelkich ludzkich zachowań. Każdy ma prawo i władzę nad własnym życiem. Niezależnie od tego oryginalny przykład w rzeczywistości nie jest odpowiedni dla danego pytania. Rząd jest w innej sytuacji niż biznes, a ja tak naprawdę płacę za drogi i policjantów, płacąc podatki, podczas gdy użytkownik Google otrzymuje bezpłatną usługę i dlatego musi „głosować” na podstawie tego, z których usług zdecyduje się skorzystać. Jeśli nienawidzisz tego, że Google zmusza Cię do korzystania z TLS, skorzystaj z Yahoo! lub inną usługę. Tak działa biznes.
Osobiście z zadowoleniem przyjmuję tę zmianę. Byłem mile zaskoczony, gdy wyszukiwarka (tj. `Https: // www.google.com /`) załadowała się przez TLS na Chromebooku, który był podłączony do sieci, która korzystała z subdomeny `nossl.`. Szczerze mówiąc, gdyby każda witryna nagle zaczęła wymuszać TLS (_good_ TLS; 1.1 lub lepszy i [z tajemnicą przekazywania] (https://security.stackexchange.com/a/54233/42192)), byłbym o wiele szczęśliwszy. \ * mamrocze coś, że żadna główna przeglądarka nie ma wbudowanej funkcji wymuszającego TLS \ *
Nie rozumiem tego pytania ... Dlaczego ktoś miałby sprzeciwiać się lepszemu zabezpieczeniu?
Tak, Google jest zły, zmuszając Cię do korzystania z protokołu opartego na transakcjach, takiego jak http, i przez rozszerzenie https, dla aplikacji opartej na sesji, takiej jak ich usługa e-mail. Każda usługa oparta na sesji powinna używać połączenia trwałego zamiast protokołu HTTP; Google powinien wyraźnie udostępniać swoją usługę poczty e-mail za pośrednictwem prostego protokołu TLS zamiast https.
Czym to się różni od, powiedzmy, * Slashdot zmusza mnie do używania protokołów TCP / IP i HTTP do rozmowy z nimi. Albo ten ekranowany na bursztynowo terminal WYSE zmusza mnie do podłączenia kabla RS-232 do komputera. Albo ten pracownik fast foodów nalega na przyjmowanie zamówień tylko po angielsku. * (Nie jestem sarkastyczny; ktoś mi to zwraca. Czy to dlatego, że zawiera mechanizm bezpieczeństwa?)
Rezygnując z rozsądnych środków bezpieczeństwa, pamiętaj, aby jasno powiedzieć wszystkim w swoich kontaktach: „Sprzeciwiam się ochronie Twoich danych. Pamiętaj, że wysyłasz mi jakiekolwiek wiadomości z danymi osobowymi. Google nie tylko będzie mieć pełny dostęp do te dane, ale także każdą osobę, która słucha moich niezaszyfrowanych interakcji z serwerami Google ”. To nie tylko * twoje * dane, stary!
Dziwią mnie komentarze dotyczące rzekomej prywatności w Internecie, podczas gdy w rzeczywistości Google nie tylko aktywnie nadużywa Twoich e-maili, ale także aktywnie przekazuje je do agencji w USA (co nie jest ich winą, mają niewielki wybór). TLS może uniemożliwić 14-letniemu dzieciakowi z Kijowa czytanie twojej poczty, ale ludzie, o których powinieneś się martwić, ci naprawdę złośliwi, i tak dostają wszystko. Prywatność w Internecie to iluzja.
@Damon To naprawdę bardzo dobra uwaga. Dziwię się, że nie zostało to jeszcze poruszone w całej tej dyskusji. Wydaje mi się, że „iluzja prywatności” faktycznie działa.
Jest jeden argument przeciwko „https”. Uzgadnianie jest znacznie wolniejsze w sieciach oddalonych od USA i na słabszych komputerach. Może to być jeden z powodów, dla których StackExchange zachował swoje strony na bardziej zwięzłym http.
@joeytwiddle SE zmierza w kierunku https wszędzie. Sprawili, że działa w wielu obszarach, ale nadal jest w toku. Największym problemem jest to, że strona https wymaga, aby wszystkie zasoby (w tym strony trzecie) były również dostarczane przez https. Może to być problematyczne w przypadku obrazów wbudowanych i tym podobnych.
{Tinfoil Hat on}: Google wykorzystał He * rtbl ** d, aby uzyskać pewne dane z przeglądarek użytkowników. {Tinfoil Hat off}, nie mam pojęcia, dlaczego to zrobili, skoro już mają wszystkich za takich a takich bez dodatkowych sztuczek.
Dwanaście odpowiedzi:
tylerl
2014-03-26 01:35:00 UTC
view on stackexchange narkive permalink

Nie chodzi tylko o Ciebie . Zmuszając użytkowników do korzystania z TLS, tworzą bezpieczniejsze środowisko dla każdego.

Bez TLS nie jest ściśle wymuszone, użytkownicy są podatni na ataki, takie jak sslstrip. Zasadniczo, uczynienie niezaszyfrowanych połączeń opcją prowadzi do możliwości, że atakujący zmuszają użytkowników do połączeń niezaszyfrowanych .

Ale to nie jest wszystko. Wymaganie TLS to pierwszy krok w kierunku egzekwowania HSTS w domenie google.com. Google już stosuje oportunistyczne egzekwowanie HSTS - co oznacza, że ​​nie wymagają TLS, ale ograniczają, które certyfikaty mogą być używane na Google.com (uwaga: ta technika nazywa się teraz HPKP) . To jest poprawa, ale ostatecznie nie jest to rozwiązanie.

Aby w pełni egzekwować HSTS, muszą upewnić się, że wymaganie TLS we wszystkich usługach Google w domenie nie zepsuje żadnych rozwiązań innych firm. Po włączeniu wymuszania nie można go łatwo wyłączyć. Tak więc przenosząc usługi pojedynczo do ścisłego egzekwowania TLS, torują drogę do urzeczywistnienia wymuszania HSTS w całej domenie.

Po wprowadzeniu tego egzekwowania przeglądarki po prostu odmówią połączenia się z Google przez niezabezpieczone lub przejęte połączenie. Wysyłając to ustawienie w samej przeglądarce, obejście stanie się praktycznie niemożliwe.

Zastrzeżenie: Pracuję teraz dla Google, ale nie pracowałem dla Google, kiedy pisałem to. To jest moja opinia, a nie Google (co powinno być od razu jasne dla każdego, kto ma podstawową wiedzę na temat chronologii).

* Nie chodzi tylko o ciebie. * Nie powinno tak być * Nie chodzi tylko o mnie. *
@VarunAgw analizuje lepiej w ten sposób. Rozmowa między dwiema różnymi osobami jest łatwiejsza do prześledzenia mentalnie niż zagmatwany monolog.
Jest to podobne do tego, jak szczepienie przeciwko chorobie pomaga każdemu (ponieważ nie jest już w stanie zarazić się chorobą), nie tylko tobie.
Jednym z powodów używania połączeń niezaszyfrowanych we wspomnianym artykule jest wydajność. Możesz ulepszyć swoją odpowiedź, wspominając, że usługi Google w porównaniu z przeglądarką Chrome prawdopodobnie używają SPDY, który dzięki konstrukcji pozwala uniknąć wielu wad wydajnościowych, które ma HTTPS. Będzie tylko jeden zaszyfrowany kanał, który jest multipleksowany we wszystkich połączeniach, więc cały narzut negocjacyjny i powolny start TCP znikną.
Mam pytanie dotyczące technicznego aspektu Twojej odpowiedzi. W jaki sposób zapobiega to technikom takim jak sslstrip? Jako człowiek w środku, czy nie możesz nadal łączyć się z Google przez TLS, ale działać jako serwer HTTP bez SSL, aby obsługiwać Google w niezaszyfrowanej formie? Może musiałbyś również usunąć trochę JavaScript, który sprawdza TLS po stronie klienta. Nie rozumiem, jak można zapobiec tego typu atakom, jeśli sama przeglądarka nie ma wbudowanej reguły, takiej jak „nigdy nie odwiedzaj google.com bez TLS”. Dopóki HSTS nie jest obsługiwany, to się nie stanie
Chronieni są nie tylko użytkownicy, ale Google jest chronione przed użyciem jako narzędzia do złośliwych celów. To znaczy. jeśli Google zezwoli na niezabezpieczone połączenia iw rezultacie konta zostaną przejęte, konta te mogą zostać wykorzystane do uruchomienia kampanii e-mailowych wyłudzających informacje, dystrybucji złośliwego oprogramowania lub innych oszustw z tych kont Gmail. Można by dyskutować, czy Google był „zły” / odpowiedzialny za umożliwienie swojej bazie użytkowników obsługi kont w niezabezpieczony sposób, który pozwalał na takie zdarzenia.
+1 dla [HSTS] (https://www.owasp.org/index.php/HTTP_Strict_Transport_Security)
To taka tandetna odpowiedź.Jeśli ktoś ma kontrolę nad Twoim upstreamem, może robić, co zechce.Albo twoja przeglądarka akceptuje wszystko, albo wyświetla komunikat o błędzie.W przypadku Google nadal obsługują HTTP dla wyszukiwarki Google, BTW.
Tom Leek
2014-03-26 01:54:40 UTC
view on stackexchange narkive permalink

Pozwól, że przeformułuję Twoje pytanie kilkoma dodatkowymi szczegółami, które są niejawne, ale być może nie dla wszystkich oczywiste:

„Czy Google nie jest złe, zapewniając mi bezpłatną usługę poczty e-mail i gigabajtów pamięci i zmuszając mnie do bezpiecznego połączenia, gdy uzyskuję dostęp do usługi, którą hojnie mi przyznali i której nikt nie zmusza mnie do korzystania , nawet jeśli nie chcę być bezpieczny ? Jeśli to tylko moje własne konto na ich serwerach i udostępnione mi bezpłatnie, wyłącznie na podstawie warunków użytkowania, na które się zgodziłem , czy nie powinienem decydować tylko o tym co powinno się stać z ICH serwerami i czy zabezpieczyć się technologią, której koszty są całkowicie po stronie serwera i która nie ma dla mnie rzeczywistej szkody ? ”

Naprawdę, nerw, jaki mają w Google!


Komentarz: reakcje na Google w tym zakresie wyglądają jak odruchowe odruchy: automatyczne, niedoskonale ukierunkowane, a nie z udziałem dowolnego mózgu a t wszyscy.

**ZŁO**. To jest to, co dey ar. Daj mi darmowe rzeczy i upewnij się, że będę bezpieczny. To znaczy, taka jest oferta diabła.
Niezależnie od tego, czy usługa jest bezpłatna, czy nie (a jeśli się nad tym zastanowić, gmail nie jest darmowy - transakcja po prostu nie obejmuje $ s) nie ma nic wspólnego z pytaniem. Pytanie brzmi po prostu, czy to dobrze, czy źle, że HTTPS jest wymagany i nie jest pozostawiony wyborowi użytkowników. Bezpłatne czy nie, nie ma z tym nic wspólnego. Pytanie wydaje się całkowicie słuszne (bez odniesienia do „zła”, chociaż „zło” jest ugruntowane w niezbyt subtelnych odniesieniach do Google, nie jest złe i pozwala użytkownikom na kontrolę nad swoimi danymi).
@LB2: liczy się to, że jest transakcja: korzystasz z Gmaila na podstawie uzgodnionych warunków użytkowania. Brak możliwości wymiany pieniędzy oznacza, że ​​użytkownik nie ma możliwości decydowania o własnych warunkach. Podstawowym tonem jest to, że ludzie często zapominają, że Google nie jest usługą publiczną, do korzystania z której mają _upoważnione_ korzystanie, na ich własnych warunkach.
@TomLeek Zgadzam się z tobą! To jest transakcja; jest zupełnie odwrotnie, gdy odpowiesz „_zapewniając mi bezpłatną usługę poczty elektronicznej_”. Jest to transakcja i oznacza, że ​​użytkownik rezygnuje z czegoś w zamian za coś. Płacenie 0 $ w porównaniu do 1 $ daje równoważną ilość lewarowania lub możliwości wykorzystania na „_własnych warunkach_”, a mój argument jest taki, że jest to _kontekstowo_ nieistotne. Pomimo złych uwag, czytam post OPs jako „dlaczego Google nie zezwoli na dostęp przez http i pozostawi bezpieczeństwo użytkownika według jego uznania?” (na co moja odpowiedź brzmi: konieczność zapewnienia wszystkim bezpieczeństwa i jest to dobra rzecz).
Google nie jest darmowe? Proszę edytować. Płacę za Google jak większość usług internetowych, będąc bombardowanym reklamami. Niektóre usługi pozwalają na płatną wersję bez dodatków, w tym Google w ramach licencji dla przedsiębiorstw.
@DeanMeehan Płacisz za oglądanie reklam?
Płatność @Brian niekoniecznie jest gotówką
„Jeśli nie płacisz za usługę, jesteś produktem”
Dobra odpowiedź - uwielbiam ironię!
@Brian Płacę **, ** oglądając reklamy
@DeanMeehan Reklamy w usługach, z których korzystasz, nic Cię nie kosztuje, dlatego nie płacisz. Wyjątkiem są reklamy YouTube przed filmami, które wymagają czasu.
@Brian To również kosztuje „czas” na przeglądanie reklam opartych na stronie internetowej. jedyna różnica między reklamami w witrynie a reklamami wideo polega na tym, że dodanie do witryny internetowej zawiera 1 klatkę, która zajmuje mniej czasu na przesłanie wiadomości. Ta 1/2 sekundy mojego czasu kosztuje mnie czas, kosztuje reklamodawcę i sprawia, że ​​webmaster kosztuje tyle samo
Google jest zły, chociaż nie z powodu tej polityki. Są źli z powodu obrzydliwości, którą stworzyli, zwanej „Androidem”.
HTTPS to nie wszystko po stronie serwera: gdyby to było wszystko po stronie serwera, nie byłbyś w stanie nawiązać bezpiecznego połączenia z komputerem. Wszystkie protokoły HTTPS wymagają obliczeń kryptograficznych na komputerze użytkownika końcowego. Nawet w przypadku SPDY nadal musisz wykonywać kryptowaluty na bezpiecznych danych, aczkolwiek bez dodatkowych kosztów.
Teraz wiem, co przypomniała mi „zła” Black Company z serii Long Earth ...
Brian
2014-03-26 01:27:37 UTC
view on stackexchange narkive permalink

Jeśli firma Google chce, aby zawartość jej serwerów była bezpiecznie przesyłana, pozostaje to całkowicie w jej gestii, nawet jeśli ta zawartość to Twoja skrzynka e-mail.

Ivaylo Slavov
2014-03-26 13:17:07 UTC
view on stackexchange narkive permalink

W rzeczywistości nie, Google nie jest w tym zły, wcale.

Pierwszą ważną rzeczą jest to, że korzystanie z bezpiecznego połączenia nie jest preferencją użytkownika ani jakimś spersonalizowanym ustawieniem. Dla niektórych osób może to być mylące, ponieważ znają system tylko z pozycji użytkownika końcowego . Sam będąc programistą, mogę powiedzieć, że bezpieczeństwo odbywa się na poziomie aplikacji i dotyczy wszystkich użytkowników systemu. Nie ma możliwości technicznego wymuszenia bezpieczeństwa uwierzytelniania w oparciu o wybór użytkownika bez narażania bezpieczeństwa całego systemu i wszystkich innych użytkowników, z których większość może polegać na ochronie ich danych w systemie. Jeśli jednak to możliwe, z pewnością chciałbym wiedzieć, jak to zrobić.

Logicznym wyborem dla Google, jako dostawcy usług publicznych, jest stworzenie bezpiecznego środowiska dla wszystkich swoich użytkowników. Nie dzieje się tak ze względu na bezpieczeństwo użytkowników, ale także firmy. Wyobraź sobie, że ktoś stanie się ofiarą naruszenia bezpieczeństwa i wytoczy proces przeciwko Google i udowodni, że to on jest odpowiedzialny? Mogłoby tak się stać, gdyby nie podjęli standardowych środków w celu ochrony danych użytkownika i mogliby stawić czoła całej społeczności wściekłych użytkowników w sądzie. Przykładem takiej sytuacji jest niestosowanie protokołu HTTPS - każdy może przechwycić Twoje żądanie sieciowe i zobaczyć informacje jako zwykły tekst. Dane użytkownika Google są rozsądne. Wygląda na to, że jest to prosty adres e-mail i hasło, ale te dwa elementy stanowią klucz do wszystkich Twoich kontaktów, korespondencji i spersonalizowanych usług Google.

Ponadto Google jest dostawcą OpenID, co oznacza, że ​​to samo hasło użytkownika (jedno z kont Google) może zostać użyte do uwierzytelnienia w systemach zewnętrznych (takich jak witryn w sieci StackExchange, w tym ten, YouTube, Disqus, Picasa i wiele innych popularnych systemów). Trudno mi sobie wyobrazić, że ktoś wolałby, aby jego „klucz” do tak wielu kont i usług był niezabezpieczony.

Ogólnie rzecz biorąc, jest to miara wymagań technicznych, a nie egzekwowanie preferencji użytkownika . Osobiście nigdy nie ufałbym systemowi, który nie wymusza minimalnych warunków bezpieczeństwa, takich jak bezpieczne połączenie i uwierzytelnianie, jeśli chodzi o pocztę e-mail, płatności online i inne usługi działające z moimi prywatnymi danymi .

Craig
2014-03-27 03:43:35 UTC
view on stackexchange narkive permalink

Zło za zmuszanie cię do korzystania z bezpiecznego połączenia?

Nie, nie sądzę, że to zło. Chroni całą społeczność bez żadnych wad dla Ciebie jako jednostki.

Myślę, że to jedyne zło, jeśli zmuszają Cię do korzystania z SSL / TLS, a następnie nie używają poufności przekazywania, a zatem dając Tobie i wszystkim innym korzystającym z tej usługi fałszywe poczucie bezpieczeństwa.

Bez zachowania poufności przekazywania sesja może zostać zarchiwizowana przez nieokreślony czas, prywatny klucz uzyskany później (w jakikolwiek sposób; socjotechnika, kradzież, rząd), a twoja dawna sesja została odszyfrowana.

Dzięki tajemnicy przekazywania i kluczom efemerycznym, problem ten jest poważnie zmniejszony.

Kto może wymienić wady korzystania z połączenia SSL / TLS? Ktoś? :-)

Mogą wystąpić problemy z wydajnością, ale tak naprawdę tylko wtedy, gdy witryna jest źle zaprojektowana i wymaga wielu, wielu nowych połączeń, aby obsługiwać zawartość ze strony. Ten rodzaj projektu będzie miał również poważny negatywny wpływ na zwykłą niezabezpieczoną sesję HTTP.

Wpływ HTTPS na wydajność jest praktycznie w całości związany z uzgadnianiem połączenia, ponieważ zajmuje więcej podróży w obie strony i trochę intensywnego obliczeniowo szyfrowania asymetrycznego w celu uzyskania symetrycznego klucza sesji na serwerze i odszyfrowania go na kliencie (szyfrowanie asymetryczne jest naprawdę drogie w porównaniu z szyfrowaniem symetrycznym).

Koszt obliczeniowy szyfrowania i deszyfrowania rzeczywistego dane sesji z symetrycznym szyfrem po początkowej wymianie klucza są pomijalne.

Ile kosztuje sesja wymuszonego SSL / TLS ? Szczerze mówiąc, szczerze mówiąc, nie wierzę, że poniesiesz wymierne koszty.

Moim kosztem jest to, że może to być krok w kierunku egzekwowania TLS wszędzie. Nie lubię zbędnych warstw.
Z drugiej strony, wiele osób uważa, że ​​szersze stosowanie bezpiecznego protokołu HTTP jest dobrym pomysłem, lub innymi słowy, że SSL / TLS może być * niezbędną * warstwą. Za każdym razem, gdy jakakolwiek usługa wymaga poświadczeń, poświadczenia muszą być chronione za pomocą protokołu SSL / TLS. Jeśli uwierzytelnianie jest bezpieczne, cała sesja musi być bezpieczna (ataki MIM). Używanie SSL / TLS do ochrony uwierzytelniania, a następnie przekazywanie niezabezpieczonego tokena uwierzytelniania w tę iz powrotem to błąd. Dobrze, że Google przestało to robić. SSL / TLS jest już w Twojej przeglądarce. Korzystanie z bezpiecznej witryny nie komplikuje życia. Powinien stać się normą.
Certyfikaty w przeszłości kosztowały za dużo i po stronie serwera wymagana jest niewielka konfiguracja, ale wraz z rozwojem rynku cena spadnie. Nie jestem fanem karania ludzi, którzy nie zabezpieczają swoich serwerów, ale niezabezpieczony serwer jest szeroko otwarty na wszelkiego rodzaju spoofing i główne sytuacje, przed którymi zabezpieczony serwer w naturalny sposób chroni.
zdecydowanie konieczne na wielu stronach. Czy Google (lub ktokolwiek) powinien próbować wymusić to na * całym Internecie *? Prawie na pewno nie. Czy Google próbuje to zrobić? Nie wiem, ale jeśli tak, to jest to krok w tym kierunku. Istnieją dowody na to, że chcą wymusić to w całym Internecie - zobacz Chrome odrzucający połączenia bez TLS HTTP / 2.0. Może jestem po prostu zbyt paranoikiem.
z jakiegoś powodu witryna nie akceptuje @Craig w poprzednim komentarzu, więc oto kolejny ping.
@immibis Niekoniecznie ufam wszystkiemu, co robią, ale myślę, że w dużym stopniu Google (oraz Microsoft, Yahoo i inni) robią to w odpowiedzi na takie rzeczy, jak trwająca saga szpiegowska NSA i problemy związane z żądaniami FISA gdzie zostali zmuszeni do przekazania wielu danych bez pozwolenia na powiadamianie właścicieli danych. Oni, przynajmniej z nazwy, naciskają na większe bezpieczeństwo i prywatność dla niemytych mas. Niekoniecznie wydaje mi się, że * Google * naciska na „HTTPS wszędzie”, ale niektórzy członkowie rządu zdecydowanie to robią.
@immibis, są tam, aby dostać się do ciebie, kolego.
@immibis to nie tylko Google naciska, aby cały Internet był na TLS - tak samo jak EFF, Mozilla, Microsoft ... wiele innych dużych firm. w rzeczywistości IETF rozważa / rozważa uczynienie TLS wymaganą częścią specyfikacji HTTP / 2.0. Nigdy nie patrzyłem na wynik tego, ale ostatnio słyszałem, że mają zamiar dać mocną rekomendację i zalecają wyłączenie go tylko w znanych bezpiecznych środowiskach (np. Korporacyjne intranety).
również ogłoszenie o usłudze publicznej: TLS nie jest już kosztowny obliczeniowo. i to nie trwało długo. https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
@strugee prawda, jednak koszt obliczeniowy nie jest jedynym istotnym czynnikiem. Opóźnienie sieci to duży problem, który należy wziąć pod uwagę. HTTPS wymaga dwa razy więcej podróży w obie strony na sesję niż HTTP, aby nawiązać połączenie. Jeśli czas pingowania wynosi 50 ms, ustanowienie połączenia HTTPS zajmuje prawie ćwierć sekundy z powodu samego opóźnienia w obie strony. Dlatego tak ważne jest ponowne wykorzystanie połączeń, łączenie skryptów i plików css, używanie sprite'ów css zamiast wielu żądań małych obrazów i tak dalej. Wszystkie te metody znacznie przyspieszyłyby również działanie stron HTTP. Wygraj, wygraj.
oczywiście HTTP / 2.0, IIRC, mogą ponownie wykorzystywać połączenia TLS / TCP dla wielu żądań HTTP. dobrze? więc kwestia „wielu zasobów” tak naprawdę nie ma zastosowania. (Chociaż mogę się mylić co do ponownego wykorzystania. Nie jestem do końca pewien).
Wiele żądań nadal będzie Cię spowalniać. Gorsze jest jednak to, że żądania są pełne żądań do innych witryn (do kogokolwiek dołącza analityczny JavaScript?), Ponieważ każde z * tych * połączeń wymaga nowego połączenia HTTPS. To niedopuszczalne, aby ludzie przynajmniej nie ładowali tego rodzaju skryptów asynchronicznie.
@strugee To tylko spostrzeżenie, ale w tym artykule stwierdza się, że „nowoczesny” sprzęt może wykonać 1500 uścisków dłoni na sekundę na rdzeń, używając 1024-bitowych kluczy. Ale klucze 1024-bitowe nie tylko są obecnie uważane za zbyt słabe, nie można nawet uzyskać certyfikatów SSL / TLS z tak małymi kluczami. Większe klawisze = wolniejsze asymetryczne operacje. To nie unieważnia twojego argumentu; po prostu kolejny czynnik. http://www.networking4all.com/en/ssl+certificates/ssl+news/your+1024-bit+ssl+certificate+will+no+longer+work+after+october+1st+2013/, https: / /www.google.com/#newwindow=1&q=1024%20bit%20vs%202048%20bit%20certificates itp.
@Craig nie trzeba mnie przekonywać, doskonale zdaję sobie sprawę z przejścia na klucze 2048-bitowe. Z pewnością nie mogę twierdzić, że jestem ekspertem; Po prostu wskazuję inną stronę tematu.
@strugee Doceniam to - zdajesz sobie sprawę, że jestem zwolennikiem * na rzecz * SSL / TLS, prawda? :-) Mimo to, 2048-bitowe certyfikaty wymagają 4 razy więcej procesora niż 1024-bitowe certyfikaty. Tak więc 1500 uścisków dłoni na sekundę z 1024-bitowymi kluczami spada do 375 uścisków dłoni na sekundę z 2048-bitowymi kluczami. To nie jest nic. Tak, specyfikacja HTTP 2.0 zezwala na utrzymywanie HTTP przy życiu, ale to nie znaczy, że zawsze są używane, a wszystkie inne argumenty dotyczące konsolidacji CSS i zawartości skryptów, używania sprite'ów CSS i podejmowania innych kroków w celu zminimalizowania liczby żądań sprawiają, że prawdziwa różnica w stosunku do HTTP, * podwójnie * tak dla HTTPS.
@Craig tak, zdaję sobie z tego sprawę. ale lubię dobrą debatę techniczną tak samo jak następny gość: D. i tak, oczywiście, wszystko to powinno być zrobione. Jestem w pełni na pokładzie z minifikacją i tym wszystkim (o ile możesz zobaczyć źródło, dla copyleftistę we mnie).
@Craig mój czas pingowania do wielu serwerów (przetestowane stackoverflow.com, imgur.com, reddit.com, mit.edu, facebook.com, tvtropes.org, dropbox.com) wynosi od 200 do 400 ms. ~ 40 ms do google.com, prawdopodobnie dlatego, że korzysta z serwera znajdującego się blisko mnie, ale ogromnej większości witryn nie stać na posiadanie serwerów wszędzie.
Poza tym, poza problemem latencji, sprzeciwiam się TLS wszędzie z tego samego powodu, dla którego sprzeciwiam się wszelkim standardowym zmianom - na przykład Microsoft, który chce, aby deweloperzy przełączali się z GDI na GDI +, WinForms, WPF, HTML5 i Metro (jestem pewien, że ta sekwencja technologii jest źle, ale nie o to chodzi).
@immibis rzeczy się zmieniają - po prostu tak, jak jest. Jednak HTTPS nie różni się od protokołu HTTP. To tylko niewielka dodatkowa konfiguracja transportu na serwerze i nie jest to * nieuzasadniona * zmiana, a radykalnie poprawia bezpieczeństwo. Poza tym trzymam się moich myśli w kwestii opóźnienia, co ma poważny wpływ również na HTTP. Mam aplikacje działające przez HTTPS, które są szalenie szybkie w porównaniu do innych aplikacji, które widziałem działające przez HTTP. Myślę, że to opóźnienie to czerwony śledź i wymówka dla dalszego tolerowania złego projektu. Mówię tylko, że * jest * problemem, o którym należy pamiętać podczas projektowania.
Weź również pod uwagę zaawansowany sprzęt. Kiedy internet dopiero zaczynał stawać się rzeczą publiczną, * krzyczącą * nową, szybką maszyną był jednordzeniowy Pentium 60 lub 66 MHz. Szybkość zegara typowego procesora serwerowego jest co najmniej 40 razy większa niż obecnie, plus radykalne postępy w technologii procesora (super potoki, funkcje RISC itp.), Które umożliwiają dzisiejszym procesorom wykonywanie znacznie większej liczby instrukcji na cykl zegara, ** plus ** fakt, że wszystkie procesory są wielordzeniowe. Intel dostarcza teraz 12-rdzeniowe procesory Xeon z technologią wielowątkowości (24 wątki), a liczba ta tylko wzrośnie.
Ponadto masz możliwość korzystania z masowo równoległych procesorów graficznych lub niestandardowych układów ASIC na serwerach, aby ułatwić obliczenia kryptograficzne. Tak, najnowsze procesory Xeon są drogie, ale ludzie mogą coraz częściej hostować swoje aplikacje w usługach VPS, takich jak AWS lub Azure (i wiele innych), gdzie po prostu płacą za czas zamiast płacić za własny sprzęt (drogi i szybko przestarzały) oraz płacenie za kolokację (również nie tania). Wyobraź sobie 5000 USD za 25 miesięcy usługi VPS za 200 USD / miesiąc lub 5000 USD za solidny nowy serwer plus opłaty za kolokację lub dostawcę usług internetowych.
Teraz bezpieczeństwo usług w chmurze to osobny temat! :-)
Co by się stało, gdyby istniała klasa rekordów DNS określająca, czy protokół TLS powinien być zawsze używany w tej domenie?
Cóż, jest * * [HSTS] (https://www.owasp.org/index.php/HTTP_Strict_Transport_Security)
Guest dude
2014-03-26 05:24:28 UTC
view on stackexchange narkive permalink

To smutne, że pierwszą reakcją ludzi jest obrona Google za pomocą błędu „NIE MUSISZ tego używać”. Jeśli chodzi o transakcje pieniężne, czy nie uważasz, że Twoje dane osobowe, które sprzedają reklamodawcom, mają wartość finansową? Google nie jest darmowy, nadal wymaga płatności, której większość ludzi nawet nie zdaje sobie sprawy.

Odpowiadając na pytanie, nie sądzę, by przesadzali lub byli „źli” dla robiąc to. Co się stanie, jeśli wyszukasz informacje, które mogą zaszkodzić innym, jeśli zostaną ujawnione (np. Wyszukując w Google coś w rodzaju „jak mam leczyć opryszczkę mojej córki”) lub co, jeśli wysyłasz wiadomość e-mail do innej osoby, która chce być zabezpieczona. Czy powinno to zależeć od Ciebie, czy to, co wysyłają, jest szyfrowane po Twojej stronie? Możesz nie przejmować się bezpieczeństwem, ale inni to robią, a to tylko wtedy, gdy oba końce faktycznie wymuszają bezpieczeństwo. Wolałbym jednak, aby Google dał metodę korzystania z połączeń innych niż TLS, jeśli nadal istnieją urządzenia, które używają Google, ale które są zbyt pozbawione pamięci / zasobów / entropii, aby ustanowić bezpieczne połączenie.

+1 za wspomnienie, że nie, firmy produkujące oprogramowanie nie oferują bezpłatnych usług ze swojej natury i łagodnego serca. Chcą osiągnąć zysk, a ty nie jesteś im za to nic winien. Możesz żądać dowolnych żądań, nawet jeśli są one tak niedorzeczne, jak to, i mogą odmówić.
Jens Erat
2014-03-28 19:46:49 UTC
view on stackexchange narkive permalink

Google chroni nie tylko Ciebie i Twoje dane, ale także siebie.

Ogromna większość użytkowników internetu nie wie o bezpieczeństwie i nie dba o to. Oferując dowolną niezabezpieczoną ścieżkę jako rezerwową, użytkownik użyłby jej, a jeśli jest to pośrednik, który psuje wszystko inne.

Jeśli Twoje konto jest jest to problem nie tylko dla Ciebie i Twoich danych, ale także dla Google :

  • Spam może być wysyłany przy użyciu ich usług
  • wiarygodność Google uwierzytelnianie (logowanie jednokrotne) ucierpi
  • Osoba atakująca może nadużywać usług, co prowadzi do kosztów (dla Google), których może nie być w stanie uzyskać rekompensaty za
  • Odzyskanie konta wymagają ręcznej interakcji, która wiąże się z kosztami.

Bezpieczeństwo może być również kwestią oszczędności.

również możliwość pozwów sądowych, jak wspomniano w innych odpowiedziach.
The Spooniest
2014-03-27 17:50:18 UTC
view on stackexchange narkive permalink

Czy firma Google była zła, wymagając od Ciebie używania protokołu HTTP zamiast protokołu Gopher? Nie sądzę, by większość ludzi argumentowała, że ​​tak było. Ale jeśli wymaganie użycia jednego protokołu zamiast drugiego nie jest złe, to dlaczego miałoby to być złe w tym konkretnym przypadku: owijanie SSL wokół HTTP?

user42884
2014-03-27 22:38:28 UTC
view on stackexchange narkive permalink

Gogle mają związane ręce. Google nie robi tego tylko po to, by Cię chronić. Robią to, aby się chronić. Nie chcą, aby inni ludzie majstrowali przy twoich rzeczach, ponieważ noszą je dla ciebie, i mają wiele zobowiązań prawnych, które wiążą się z przyjmowaniem rzeczy innych ludzi. Są zobowiązani do zapobiegania używaniu konta w sposób, który mógłby stanowić problem dla innych.

Paŭlo Ebermann
2014-03-27 05:27:27 UTC
view on stackexchange narkive permalink

Jak mówią inni, zwykle nie masz nic do stracenia, używając szyfrowania zamiast braku szyfrowania, nawet jeśli uważasz, że nie potrzebujesz szyfrowania.

Ale jeśli naprawdę chcesz uzyskać do niego dostęp, nie zaszyfrowane (być może w celu udowodnienia komuś obserwującemu twoją linię, że nie robisz nic złego), możesz skonfigurować serwer HTTP, który sam łączy się z Google przez HTTPS i przekazywać wszystkie żądania i odpowiedzi (odpowiednio dostosowane).

Należy zmodyfikować logo i część tekstu, aby nie wyglądało na to, że bezpośrednio korzystasz z Google. Powinieneś pomyśleć o używaniu HTTPS przynajmniej do procedury logowania.

Powinno to działać na każdym „złym” serwerze, który obsługuje tylko HTTPS.

Lodewijk
2014-03-27 05:07:38 UTC
view on stackexchange narkive permalink

TL; DR: Jest lepiej, ale nie wystarczająco dobrze.

Szansa posiadania połączenia podsłuchowego w porównaniu z kosztami tego typu zabezpieczeń jest oczywista i nie wymaga dalszych rozważań niż „tak, to jest wymagane ”.

Ważne jest, aby pamiętać, że SSL może nie być doskonały, a implementacje prawdopodobnie nie będą wodoodporne. Dodatkowo, szczególnie w przypadku Google, twoja prywatność i tajemnica listu nie są zachowywane przez użycie SSL.

W rzeczywistości jedynym ryzykiem, któremu Google zapobiega, są formy szpiegostwa przez podmioty, które nie są wystarczająco silne, aby zniszczyć twój komputer, Google lub SSL. Może to również zwiększyć wysiłek innych aktorów.

Nie zapobiega to wszystkim rodzajom SSLStrip, ponieważ SSLstrip może to zrobić podczas przeróbki tranzytu lub nawet przekierowań. Zwykły użytkownik nie zauważy braku małej blokady SSL. Odrobina dodatkowej magii może nawet przywrócić nową blokadę bezpieczeństwa.

Nie jest jasne, czy (koszt połączenia z podsłuchem * szansa na połączenie z podsłuchem)> koszt TLS. Ale jeśli Google nie ma nic przeciwko płaceniu dodatkowych kosztów (jeśli taki istnieje), to ich wybór.
Powodem jest głównie to, że TLS jest tak bardzo tani w porównaniu z jakąkolwiek katastrofą ludzką. Może nawet ZAWSZE nie jest to prawda, ale to nie jest interesująca dyskusja. Mając wybór, ktoś niezmiennie wybierze tryb „Twórz mi problemy”.
Nie mówię, że to źle - przynajmniej nie z tego powodu. Kiedy mnożysz ogromną liczbę i małą liczbę, trudno jest stwierdzić, czy wynik jest ogromny, czy mały. Google po prostu błądzi po stronie ostrożności, co jest dobrą rzeczą.
Dokładnie! :) ________
Eric G
2014-03-26 01:51:24 UTC
view on stackexchange narkive permalink

Być może powinni w razie potrzeby zaoferować opcję wyłączenia SSL. Być może w niektórych krajach istnieją pewne ograniczenia szyfrowania lub wymagania sieciowe, które uniemożliwiają użytkownikom dostęp do usługi. Dostrzegam pewną wartość biznesową i użytkową w zapewnianiu niezabezpieczonych opcji, ale domyślne ustawienia powinny być bezpieczne.

Jednak Google prawdopodobnie podjął to jako decyzję biznesową i jesteś związany warunkami ich usług. Google zawsze szyfruje inne informacje, takie jak wyniki wyszukiwania, gdy jesteś zalogowany, aby serwery dziennika i statystyki nie mogły odczytać słów kluczowych wyszukiwania. Jeśli nie jesteś zadowolony ze świadczonej usługi (zbyt małe lub zbyt duże bezpieczeństwo), zawsze możesz zmienić dostawcę. W przypadku poczty e-mail korzystanie z protokołu IMAP w celu rzeczywistego pobrania danych i zaimportowania ich gdzie indziej jest trywialne.

Nie sądzę, aby od jakiegoś czasu zezwalali na dostęp IMAP / POP bez szyfrowania.

Nawet zezwolenie na połączenie z HTTP zamiast HTTPS otwiera drzwi do ataków typu man-in-the-middle. Nie jest to dobra opcja dla żadnego serwera, który zapewnia dostęp do krytycznych danych.
@Craig: proszę rozwinąć? Czy istnieje atak, w wyniku którego użytkownik myślałby, że korzysta z bezpiecznego połączenia, podczas gdy go nie ma?
@immibis dobrze, jeśli strona będzie działać przez HTTP lub HTTPS, to złośliwe oprogramowanie (widziałem to wiele razy) na samym komputerze może po cichu przekierować przeglądarkę do wersji HTTP witryn. Jeśli serwer nie działa przez HTTP, to oczywiście nie zadziała. Ponadto SSLSTRIP (i przez skojarzenie jego krewnych MIM) jest wspomniany przynajmniej raz w innych postach na tej stronie. :-)
@Craig Osoby, którym naprawdę zależy na bezpieczeństwie, z pewnością sprawdzą, czy używają https?
@immibis, bez wątpienia zdobyłeś trochę wcześniejszego wglądu w to, jak sprytni są większość „normalnych” ludzi w tych sprawach, prawda? :-) Po prostu o tym nie myślą, i to jest część problemu - fakt, że tak wiele osób po prostu nie wie, który koniec się kończy i są wykorzystywani, nawet nie rozumiejąc, co się z nimi dzieje. Naprawdę uważam, że dobrze jest mieć jakieś zabezpieczenia dla zwykłych, przeciętnych ludzi. Jedną z cech SSL / TLS na serwerze internetowym jest to, że przeglądarka internetowa będzie szczekać na ciebie, jeśli certyfikat nie pasuje do nazwy domeny. Jest tylko wyższy pasek z HTTPS.
A „zwykli przeciętni ludzie” nie są w żaden sposób pejoratywne. Niektórzy ludzie (a przez „niektórych” mam na myśli „większość”) zarabiają na życie będąc bardzo kompetentnymi w sprawach * innych * niż technologie komputerowe i komunikacyjne. Dla nich te rzeczy są środkiem do celu i nie powinny im przeszkadzać ani wyrządzać im krzywdy, będąc niebezpiecznymi, jeśli nie trzymają głowy dokładnie podczas jej używania.
@Craig Tak, mam wgląd w to, że akceptują http://www.google.com.evilhackervirusalert.co.za/ lub nawet tylko http://evilhackervirusalert.co.za/, więc nie ma sensu próbować oszczędzać Ci ludzie.
@immibis głównym problemem związanym ze sprawdzaniem protokołu HTTPS jest to, że jest to coś aktywnego, o czym musisz pamiętać. Uważam się za kompetentnego w bezpiecznym korzystaniu z Internetu i komputerów, ale nawet ja nie sprawdzam regularnie protokołu HTTPS. Wada w obecnych praktykach bezpieczeństwa polega na tym, że nie ma sposobu, aby stwierdzić, kiedy witryna jest zgodna z protokołem HTTP, a kiedy _ wymuszasz_ na HTTP - i z tego powodu przeglądarki nie mogą wyświetlać ostrzeżenia, gdy używany jest protokół HTTP. dlatego wskaźniki bezpieczeństwa są pasywne. gdyby cały internet korzystał z TLS, nie stanowiłoby to problemu.
i zauważ, że to, co właśnie powiedziałem, dotyczyło nie tyle bezpieczeństwa technicznego, ile doświadczenia użytkownika. jest praktycznie niemożliwe, aby pamiętać o sprawdzeniu wskaźnika pasywnego. aktywny wskaźnik jest łatwy do wykrycia; nie musisz nawet tego sprawdzać (z definicji).
@strugee, co byś zrobił z protokołem HTTPS z podpisem własnym?


To pytanie i odpowiedź zostało automatycznie przetłumaczone z języka angielskiego.Oryginalna treść jest dostępna na stackexchange, za co dziękujemy za licencję cc by-sa 3.0, w ramach której jest rozpowszechniana.
Loading...