Zbliża się dzień, gdy strony korzystające z HTTP będą w przeglądarkach oznaczane jako niezabezpieczone. Jakby tego było mało, Chrome i Firefox przestają ufać certyfikatom Symanteca. Administratorzy, pora wziąć się do pracy!
„Strona nam nie działa” nie jest zdaniem, które chce usłyszeć osoba zarządzająca serwerem WWW od szefa. „Klienci się skarżą, że jest niebezpieczna” też do tych zdań nie należy. Przeczytajcie i sprawdźcie swoje serwisy, bo wiele dużych polskich firm nadal nie jest przygotowanych do zmian nadchodzących wkrótce w przeglądarkach. Szczególnie dotyczy to stron, które korzystają z certyfikatów wystawionych przez firmę Symantec, prowadzącą do niedawna działalność także pod markami Thawte, GeoTrust i RapidSSL. Zarówno Chrome, jak i Firefox już za miesiąc zaczną traktować te certyfikaty jako niezaufane.
Jak do tego doszło, czyli 30 tys. błędnie wydanych certyfikatów
Zaczęło się w styczniu zeszłego roku od wiadomości na jednej z grup dyskusyjnych Mozilli. Andrew Ayer opisał w niej szereg nieprawidłowości w certyfikatach wydanych przez Symanteca. Sprawą zainteresował się Google. Trzy miesiące później na forum deweloperskim Chromium opublikowano wyniki dochodzenia i wstępny plan działań. W toku przeprowadzonego przez firmę śledztwa znaleziono co najmniej 30 tys. błędnie wystawionych certyfikatów SSL/TLS, również tych o rozszerzonej weryfikacji (Extended Validation, EV). Najczęściej powtarzanym zarzutem było wydanie certyfikatu na domenę bez zgody jej właściciela, co otwierało drogę do ataków phishingowych, umożliwiając podszycie się pod zaufany serwis lub usługę.
Jak mogło dojść do takiej sytuacji? Ryan Sleevi z Google’a poinformował, że Symantec autoryzował kilka firm do przeprowadzania weryfikacji wniosków certyfikacyjnych. Były to CrossCert (Korea Electronic Certificate Authority), Certisign Certificatadora Digital, Certsuperior S. de R. L. de C.V. oraz Certisur S.A. Jak łatwo się domyślić, wymienione firmy działały z naruszeniem standardów wytyczonych przez branżę w ramach CA/Browser Forum. Zgodnie z obowiązującymi regułami pełną odpowiedzialnością za ich błędy został obarczony Symantec.
Zapowiedziane przez Google’a obniżenie wiarygodności certyfikatów Symanteca i wyłączenie dla nich rozszerzonej weryfikacji, rzecz jasna, nie przypadło firmie do gustu. Nie obyło się bez publikacji oświadczenia, w którym zarzuciła ona twórcom Chrome’a wyolbrzymianie i wprowadzanie w błąd. Jej zdaniem nieprawidłowo wydano tylko 127 certyfikatów i nie odnotowano żadnych związanych z tym naruszeń bezpieczeństwa. Od początku jednak w tym sporze Symantec stał na straconej pozycji, choćby dlatego, że nie był to pierwszy incydent z jego udziałem.
W październiku 2015 r. firmę przyłapano na wystawianiu testowych certyfikatów bez zgody właścicieli domen (w tym także Google’a) oraz dla domen, które nie zostały zarejestrowane. Wymuszono wtedy na Symantecu, by każdy wydany przez niego certyfikat trafiał do bazy Certificate Transparency (CT). Innym wymogiem było przeprowadzenie audytu, ale jak widać, zastosowane środki nie zapobiegły jeszcze większym nieprawidłowościom. Można się było spodziewać, że za drugim razem Google zareaguje bardziej radykalnie i tak się stało.
Konsekwencje, czyli Chrome przestaje ufać certyfikatom Symanteca
Pierwotny plan zakładał, że wybrana przez Symanteca firma pokieruje infrastrukturą jego partnerów, do czasu aż Symantec dostosuje się do obowiązujących w branży standardów. Do akcji wkroczył jednak DigiCert, który odkupił od niego cały biznes związany z certyfikatami za 950 mln dolarów. Przechodzenie na nową infrastrukturę zarządzaną przez tę firmę zakończyło się 1 grudnia 2017 r. Zgodnie z przedstawionym przez Google’a harmonogramem to oznacza, że Chrome nie będzie ufał certyfikatom wydanym po tej dacie przy użyciu starej infrastruktury Symanteca.
Co czeka certyfikaty SSL/TLS wystawione wcześniej? Muszą zostać wymienione. Wymóg ten dotyczy wszystkich marek, pod którymi je wydawano, takich jak RapidSSL, GeoTrust, Thawte i oczywiście Symantec. Administratorzy planujący ich wymianę powinni wziąć pod uwagę następujące terminy:
- Certyfikaty wystawione przed 1 czerwca 2016 r.
- 15 marca 2018 r. zostanie wydana wersja beta przeglądarki Chrome 66, która zacznie wyświetlać ostrzeżenie o planowanym usunięciu zaufania do starej infrastruktury Symanteca.
- 17 kwietnia 2018 r. ukaże się stabilna wersja Chrome 66, która przestanie ufać certyfikatom wydanym przez starą infrastrukturę przed 1 czerwca 2016 r.
- Certyfikaty wystawione między 1 czerwca 2016 r. a 30 listopada 2017 r.
- 13 września 2018 r. pojawi się wersja beta Chrome 70, która będzie wyświetlać stosowne ostrzeżenie.
- 23 października 2018 r. będzie można zainstalować stabilną wersję Chrome 70, która usuwa zaufanie do starej infrastruktury Symanteca i wszelkich wydanych przez nią certyfikatów.
Jak wynika z informacji podawanych przez DigiCert, wymiana będzie bezpłatna i wiąże się z ponowną weryfikacją zależną od klasy certyfikatu – DV, OV lub EV (odpowiednio Domain Validation, Organization Validation i wspomniana wcześniej Extended Validation). Podstawowy, darmowy certyfikat można zresztą uzyskać dzięki projektowi Let’s Encrypt, który sponsorują m.in. Google, Mozilla, Electronic Frontier Foundation, Cisco i Akamai.
Eksperci z SSL24 rozwiążą Twój problem z certyfikatem SSL
Apokalipsa kontrolowana, czyli jaka jest skala problemu
Zamiast wierzyć klikbajtowym tytułom (typu Beware the looming Google Chrome HTTPS certificate apocalypse!), postanowiliśmy sami zbadać sytuację. Zaczęliśmy od pobrania przeglądarki Chrome Canary, w której zapowiadane zmiany pojawiają się ze znacznym wyprzedzeniem. Skorzystaliśmy też z wyszukiwarki Censys – naszym celem było znalezienie ciekawych przykładów polskich stron, których administratorzy muszą pilnie pomyśleć o wymianie certyfikatu.
Wyszukiwarka certyfikatów dobrze się spisała
Oto kilkanaście wyszukanych przez nas perełek:
- https://ingservicespolska.pl
- https://www.prepaid.pekao24.pl
- https://owa.warta.pl
- https://www.link4.pl
- https://kontomierz.pl
- https://www.wydawajioszczedzaj.pl
- https://sms.orange.pl
- https://www.njumobile.pl
- https://edoktor24.pl
- https://agorait.pl
- https://www.swiatksiazki.pl
- http://www.ikomornik.pl
- https://akademiabezpieczenstwa.pl
Weźmy jedną z nich i sprawdźmy, jak wygląda w aktualnej wersji Chrome’a, a jak w Canary – pozwoli nam to rzucić okiem w przyszłość i przekonać się, czy warto zawracać sobie głowę wymianą certyfikatu.
Strona wyświetlona w aktualnej wersji Google Chrome
Strona wyświetlona przy użyciu Chrome Canary
Cóż, różnicę widać gołym okiem. Jak już wspomnieliśmy, po cichu podobne zmiany planuje wprowadzić także Mozilla. Należy się ich spodziewać w przeglądarce Firefox 60, która zostanie wydana 9 maja br. (wersję beta można będzie testować od 12 marca).
Przy okazji warto wspomnieć o bardziej kompleksowych badaniach, które przeprowadził Arkadiy Tetelman, ekspert od bezpieczeństwa pracujący obecnie w Airbnb. Skorzystał on z listy 1 mln najczęściej odwiedzanych stron, sporządzonej przez serwis Alexa. Uzupełnił ją o wersje z www (bo dla Google’a są to dwa różne hosty) i przeskanował, wykorzystując skrypt napisany w języku Ruby. Okazało się, że 11,5 tys. stron, czyli 0,6% z ich ogólnej liczby, może mieć problem z certyfikatem już 17 kwietnia, gdy ukaże się Chrome 66. Parę miesięcy później, po aktualizacji przeglądarki do wersji 70, taki sam los czeka 91,6 tys. stron (4,6%). Niby nie tak dużo, ale nie chcielibyście znaleźć się na miejscu administratorów i właścicieli serwisów, którym to się przytrafi.
Sprawdźcie więc, czy problem Was dotyczy. Możecie zacząć od przejrzenia zestawień felernych domen, które Tetelman udostępnił na GitHubie (bad_m66 oraz bad_m70). Nie warto tego odkładać na ostatnią chwilę. Pośpieszyć się radzimy także tym, którzy nie wdrożyli na swojej stronie protokołu HTTPS.
To jeszcze HTTPS
Prawdopodobnie słyszeliście, że Google Chrome od wersji 68, która ukaże się w lipcu tego roku, utrudni życie właścicielom i administratorom serwisów, którzy dotychczas nie wdrożyli protokołu HTTPS. W trosce o użytkowników strony takie będą oznaczane jako niezabezpieczone (ang. not secure), o czym Google poinformował na swoim blogu.
Nie jest to nowy pomysł – pierwsze propozycje dotyczące planowanych zmian pojawiły się pod koniec 2014 r. Kilka miesięcy później podobne deklaracje padły ze strony twórców konkurencyjnego Firefoksa. Deweloperzy obu przeglądarek długo zwlekali z wprowadzeniem widocznych dla użytkownika modyfikacji. Opublikowana przez Google’a grafika pozwala jednak sądzić, że za kilka miesięcy to się zmieni, przynajmniej w jego przeglądarce:
Porównanie oznaczeń w aktualnej i przyszłej wersji Google Chrome
Nie ma zatem na co czekać i jeśli Wasi użytkownicy oczekują choćby minimum bezpieczeństwa na Waszej stronie, to lepiej już teraz zaplanować jej migrację do HTTPS.
- Tel. 68 457 00 00
- [email protected]
Dla zachowania pełnej przejrzystości – artykuł zawiera treści sponsorowane.
Komentarze
Jadę często na Canary i od wersji 68 zderzam się z tymi komunikatami. Stron nie jest dużo, ale niestety zdarzają się i mam tu pewne obawy, czy aby na pewno wybrano dobry sposób.
Chodzi tu o to, że gdy Chrome przejdzie na wydanie stabilne, to wydaje się, że nadal część witryn będzie mogło mieć stare certyfikaty i tym samym Chrome nie wpuści usera na taką stronę.
To może wyrobić nieładny nawyk omijania wszelkich kłódeczek, ostrzeżeń itp., a dopiero przedwczoraj pisaliście o czytelniczce, która właśnie tego typu ostrzeżenie zignorowała i ominęła.
Większa ilość takich sytuacji może nauczyć userów, że to tylko „głupie utrudnienie” Chrome.
Nie wiem, mam wrażenie, że o ile jest zagrożenie, to przesadzono z reakcją i każdy z już wystawionych certyfikatów powinien być honorowany do jego wygaśnięcia. Ale pewnie się nie znam…
Może się przyda?
Skanowanie strony pod kątem SSL oraz application security
https://observatory.mozilla.org/
Generator konfiguracji TLS
https://wiki.mozilla.org/Security/Server_Side_TLS
Moim zdaniem zmiana jest bez sensu. Jeżeli mamy statyczny tekst i użytkownik nie ma opcji wpisać czegokolwiek to o ile treść nie jest jakaś arcywrażliwa to dokładanie szyfrowanego połączenia jest tylko niepotrzebnym narzutem. Powinna być opcja typu „nie wyświetlaj ostrzeżeń dot protokołu” albo coś takiego bo inaczej…
„Powinna być opcja typu „nie wyświetlaj ostrzeżeń dot protokołu” albo coś takiego bo inaczej…”
bo inaczej… nic wielkiego się nie stanie. Po prostu pojawi się ostrzeżenie w pasku adresu, że strona jest niebezpieczna, ale będzie można korzystać.
Czyli strona musiałaby nie mieć formularza oraz nie mieć Javascriptu, bo JS może np odczekać trochę czasu lub reagować na najechanie myszką i dodać element do wprowadzania tekstu. Niewiele jest stron, które w ogóle nie mają Javascriptu.
Powtórzę: Strony bez TLS nie przestaną działać – po prostu wyświetli się komunikat o tym, że jest niebezpieczna i zniechęci użytkownika do wprowadzania danych, ale będzie można ją bez problemu przeglądać a nawet wpisywać dane do formularza.
Tylko właśnie w tym problem, że przeglądarka wprowadza w błąd. Taka strona wcale nie musi być niebezpieczna. Taki błędny komunikat jest mylący dla użytkowników. Wyrobi się u nich nawyk olewania takich komunikatów, i tyle to da.
I to jest właśnie wprowadzanie w błąd, bo jak taka statyczna strona, gdzie nie ma żadnych pól do wpisywania, gdzie nic nie kupujesz, gdzie nie podajesz danych osobowych/wrażliwych ma być niebezpieczna? :)
HTTPS gwarantuje że strona którą pobrała przeglądarka, nie została zmieniona po drodze, że nikt nie wcisnął niczego w stronę. Jest to jeden z wielu elementów układanki bezpieczeństwa.
Np zmiana nr tel albo adresu, który ma być wyświetlony tylko w twojej przeglądarce, albo wrzucenie JS lub czegokolwiek mniej lub bardziej szkodliwego przez osobę siedzącą 3 stoliki dalej w popularnej kawiarni z darmowym niezabezpieczonym wifi.
HTTPS zmniejsza ryzyko że zostaniesz ofiarą trywialnego MITM.
Po drodze do komputera, ale już niekoniecznie w komputerze przed jej wyświetleniem…
jak będą wszystkie strony miały https to użytkownik przestanie zwracać uwagę na content w którym może być co tylko autor sobie wymyśli i nie chodzi tu o podmianę a już o same źródło
> HTTPS gwarantuje że strona którą pobrała przeglądarka, nie została zmieniona po drodze, że nikt nie wcisnął niczego w stronę. Jest to jeden z wielu elementów układanki bezpieczeństwa.
Chyba że ktoś korzysta z zewnętrznego CDN jak cloudflare z flexible ssl (a nawet full ssl). Albo pracuje w firmie za firewallem rozszywającym ruch. Albo ma jedno zaufane CA za dużo (superfish?). Albo mieszka w ameryce i jego ISP wpadło na pomysł injectowania reklam w ramach „usługi”. I pewnie jeszcze kilka ;].
(Ale no, generalnie myśl prawdziwa).
Piszesz o tym, że nie ma formularza, ale formularz może się pojawić w każdej chwili w drzewie DOM, jeśli jest Javascript. Trzeba by zastosować jakąś bardzo skomplikowaną metodę przewidywanie czy Javascript doda formularz do drzewa DOM, a i tak nie wiadomo czy by to działało w 100%.
A stron, które nie mają nawet linijki Javascriptu ze świecą szukać. Sam używam NoScripta i wiele stron jest użytecznych bez JS, ale i tak ma trochę JSa.
HTTPS na wszystkie strony, to jest zwyczajny skok na kasę. Każda strona na świecie będzie teraz płaciła nowy bezsensowny podatek. Serwery będą bezsensownie spalały prąd na szyfrowanie.
Oczywiście, zacieramy rączki – bo na tym zarobimy. Ale to zwykłe dziadostwo.
Wyolbrzymiasz problem.
Poza tym w dzisiejszych czasach szyfrowanie to konieczność, a nie ekstrawagancja. A podpieranie się kosztem prądu (!!!) to mniej więcej tak jak zakaz wjazdu dla rowerów ze względu na zwiększone zużycie asfaltu
Nie spalajmy prądu na podobne komentarze.
Więc czemu nie stosuje się podpisywania strony (i ew. szyfrowania podzbioru przesyłanych treści) w przypadku serwisów mniej krytycznych? Za dużo roboty w stosunku do szyfrowania wszystkiego jak leci? A niestety wraz z czasem przynajmnniej klucze muszą się wydłużać i głupi obrazek linijki podziału strony będzie tak samo mocno zaszyfrowany co dane wrażliwe.
To bardzo zależy od treści…
To, że np. czytujesz Exploit-DB może być istotną informacją.
A może strony o Bliskim Wschodzie / dzikim zachodzie?
Z3S?
Interesujesz się TORem / sieciami mieszającymi?
A może ściągnąłeś hashcata?
Niby pentester, a tu dowody pokazują, że SZPION ;)
Na szczęscie jest darmowy Let’s Encrypt, z którym problemów przeglądarki nie mają. Polecam wszystkim.
Biedacy, którzy są zmuszeni korzystać ze znanego wszystkim hostingu w home mogą co najwyżej pogwizdać, jeżeli chodzi o Let’s Encrypt.
W rzeczy samej, firma udaje, że LE nie istnieje, zaś na ichniejszym forum opisali temat jako „trudny technicznie do wdrożenia” (śmiech na sali). Temat nie dotyczy tylko home, bo z tego co wiem póki co LE nie uświadczymy także w nazwie.pl i innych pseudohostingach dla mas.
Pozostaje się cieszyć, że będą mieli dodatkowy powód do poszukania sensownych hostingów. LE jest darmowe, obciążenie generowane przez SSL to pojedyncze procenty CPU, a utrudni/uniemożliwi podrzucanie wirusów przez niezabezpieczone WiFi, czy reklam (i skryptów śledzących) przez dostawców Internetu.
Nie do końca jest tak źle jak piszesz.
W kei wygenerowałem LE w panelu i działa bez zarzutu.
Ale pomysł z 'wymuszaniem’ szyfrowania faktycznie bez sensu.
Na stronie mam tylko obrazki i treść statyczną.. odwiedzającemu może grozić straszne niebezpieczeństwo.
„Na stronie mam tylko obrazki i treść statyczną.. odwiedzającemu może grozić straszne niebezpieczeństwo.”
Nie w tym problem co masz na stronie, tylko co może się do niej po drodze „przykleić”.
Do listy hostingodawców udających, że Let’s Encrypt nie istnieje, dopisuję prohost.pl – jakiś czas temu wysłałem im zapytanie w tej sprawie przez BOK, efekt? Obsługują tylko i wyłącznie certyfikaty zakupione u nich. Najtańszy certyfikat, już po doliczeniu VAT-u, kosztuje 92,50 zł.
Ogólnie hostingodawcy mają teraz raj z powodu tych zmian. Mniej świadomy klient nie będzie przecież szukał innego hostingu i babrał się z przenoszeniem strony, tylko po prostu wykupi SSL’a tam, gdzie aktualnie hostuje swoje strony. A biznes się kręci…
O ile wiem hosting w ovh (też dla mas) wspiera LE.
Być może jak sprawa stanie się bardziej powszechna (i w związku z tym problem) ovh zacznie się reklamować darmowymi certyfikatami i home, nazwa itd pójdą ich śladem
O co wam chodzi z tym hostingiem dla mas? Home, nazwa zgodzę się ale ovh? To który niby nie jest dla mas (a właściwie chodzi wam chyba o mainstream bo serwery chyba z założenia są dla mas)? Że niby co? AWS? Gcloud? Czy może trzeba mieć własnego RAC’a żeby być cool? Pytam bo mam vps’a w ovh.
@Mad Snack Nie do konca.
Home pozwala na instalacje certyfikatu wygenerowanego na zewnatrz. Fakt. Musisz umiec to ogarnac i pamietac zeby co 3 miesiace odnawiac, ale sie da.
Z biedahostingow np. zenbox wspiera LE lacznie z tym, ze automatycznie za ciebie odnawiaja.
Osobna kwestia jest to ze home jest drogim i slabym hostingiem jezeli brac pod uwage cene do jakosci.
Niestety uważam to za głupotę. Ktoś sobie prowadzi stronę o swoich zwierzątkach i opisuje co dzisiaj zjadły. I musi kupować (sam tego nie zrobi) certyfikat, bo jego jadłospis ma uszkodzić komuś komputer?
Brak SSL to przeżytek. Dzięki LE na sensownych hostingach SSL nic nie kosztuje (poza czasem na skonfigurowanie). Bez SSL można śledzić, podstawiać wirusy i reklamy.
Zaczynamy myśleć o bezpieczeństwie, co jest korzystne dla ogółu.
Podobnie komputery należy zabezpieczać przed wirusami, nie tylko dlatego, że nam będzie wolniej działać i próbować wykradać dane, ale posłuży do rozsyłania SPAM-u i ataków DDOS.
kazdy porxzadnyh hosting ( czyli poza home / wp i h88 ) oferuje darmowe letsencryypt do uruchomienia zwyklejednym kliknieciem – wprowadzenie sssl jest obecnie banalnie posrte od strony infrastruktury
Nie jest banalnie proste. Trzeba napisać swój soft do autoryzacji zleceń, generowania certyfikatów, puszczania requestów do letsencrypt, pilnowania odnowień, mieszczenia się w narzuconych limitach. Żaden większy hosting nie będzie do tego używał badziewnego certbota czy podobnej złomiastej aplikacji.
Przeczytaj wyżej o MITM.
Poza tym nawet ten ktoś wprowadzający te jadłospisy może ujawnić w ten sposób login.hasło do swojego wordpressa i ktoś może używać jego serwera do rozsyłania spamu i/albo jego strony do instalowania wirusa na obcych komputerach itd itp.
Czy ktoś się orientuje co z Amazon CloudFront.
Bo dostaję ostrzeżenia:
The SSL certificate used to load resources from https://xxxxx.cloudfront.net/ will be distrusted in M70.
Co znaczy 'Zamiast wierzyć klikbajtowym tytułom’? Konkretnie co to są 'klikbajty’? Jeśli już musicie używać obcych słów to może by to robić poprawnie i ze zrozumieniem? 'ckick bait’ nie jest od klikania w bajty (jednostki pamięci) tylko od 'przynęty’ do kliknięcia.
Sprawdź, czy poczucie humoru nie wpadło Ci za kanapę…
Według językoznawców z Uniwersytetu Warszawskiego i tworzonego przez nich słownika takie słowo jak najbardziej istnieje ;-)
http://nowewyrazy.uw.edu.pl/haslo/klikbajtowy.html
do kompletu: http://nowewyrazy.uw.edu.pl/haslo/klikbajt.html
A teraz może coś bardziej merytorycznego?
Miało być merytorycznie to postaram się zaspokoić wszystkich ™ Czepiasz się waść klikbajtów które są poprawnym słowem a sam słowo za przecinkiem bez spacji stawiasz. Eh. Takie to młodzieży chowanie.
Czemu nie daliście linka do tego wyszukiwania w censys? Dajcie.
…bo możesz sam to zrobić jeżeli tylko przeczytałeś artykuł.
Przecież to nie może być aż takie trudne, prawda…?
W 2014 roku Symantec zaczął współpracować z niemiecką prywatną wywiadownią gospodarczą, pracującą również jako wywiad paramilitarny prywatnej armii Black Water. Wywiadownia niejakiego Krolla znajduje się w dawnym Data Center HP w Reutlingen w Niemczech. Lewe certyfikaty były wykorzystywane w celu zdalnej instalacji nieautoryzowanych zmodyfikowanych BIOS w komputerach korporacyjnych firmy Dell (poprzez ATM). Prowadziłem to śledztwo jakiś czas, póki zdalnie nie zniszczono mi kilku obiektów badań, nie miałem siły już na zabawy z nimi, doszło do tego że miałem zainfekowane wszystkie komputery i nie miałem gdzie podłączyć programatora pamięci. Polska jest w „czarnej d*pie”… nasz wywiad, ABW, CBŚ, i kontrwywiad jest totalnie inwigilowany przez Niemieckie służby. Dotarłem do tego że gra toczy się o nielegalne wydobycie metali szlachetnych na dolnym śląsku które jest moim zdaniem wykorzystywane przez obce służby jako źródło „czarnego dochodu”. Siedzą w tym dawni oficerowie WOP i WSI, emerytowani pułkownicy, wystarczy rozejrzeć się by zobaczyć jak wielu z nich posiada koncesje na wydobycie „żwiru” czy „kruszywa drogowego” … a do tego zaawansowane płuczki, odwadniacze czy nawet flotowniki. Niedługo KGHM będzie sprzedawać stare flotowniki, obserwujcie kto je zakupi. Wszystko to kręci się gównie wokół rzeki i dorzecza Bobru, być może biorą w tym udział np. dawne zakłady wzbogacania uranu (teraz prywatna spółka), refinerie metali szlachetnych na dolnym śląsku i cała masa małych prywaciarzy posiadająca coś w rodzaju „złotych ferm” polega to na „uprawianiu złota” za pomocą bakterii Midasa (Delftia acidovorans) w stawach przepływowych zasilanych wodą ze starych dolnośląskich kopalń kruszcowych. Ale to wszystko jest tylko czubkiem góry lodowej którą odkryłem, od lat wszyscy dookoła robią nas w ch*ja. Polska śpi na złocie, platynie czy srebrze. Niemcy za pomocą dotowania Parków Narodowych, lobbowania nowych stref Natura 2000 mocno poblokowali działalność nie tylko górniczą, lecz również badawczą! Prawo obecnie zabrania Wam wykonania badania zawartości złota w garści ziemi z Waszego ogródka. Nie wolno NIC BADAĆ bez koncesji i pozwoleń, a te kosztują MILIONY.
Dlaczego mam się przejmować TLS jeśli serwuję wyłącznie statyczny content i nie biorę nic od userów?
1. Masz panel logowania po HTTPS?
szybka ocena ryzyka – znacznie łatwiej znaleźć dowolny web-attack na drupala czy wordpressa i dostać prawa admina niż robić MIiTM
2. Ktoś może wstrzyknąć Javascript lub dodać/usunąć coś z headerów przez MiTM
header znika i nagle mamy buga. Header mówi 302 strona_z_expoitem. Content ładuje jakiś ciekawy Javascript
Znacznie łatwiej dostać prawa admina i tam zamieścić redirect do redirecta do redirecta do exploitu (hi, KNF!!)
3. Bo to nie jest niczyj biznes którą stronę oglądam
Jeśli aż tak się obawiam, żeby ktoś się dowiedział, co dokładnie na tej stronie oglądałem, to pewnie sam kontakt z domeną mnie pogrąży
Jeśli jestem na tyle ciekawy, żeby mi robić MiTM, to pewnie moim komputerem zarządza FBI a ja się dowiem ostatni ;)
IMHO model zagrożenia słaby, ale jako że można pewne klasy ataków tanio wyłączyć, to czemu nie.
(Jeśli w Twojej organizacji wygeneruje to ogromne koszty, to masz inny i większy problem).
„Jeśli aż tak się obawiam, żeby ktoś się dowiedział, co dokładnie na tej stronie oglądałem, to pewnie sam kontakt z domeną mnie pogrąży”
Jestem w stanie sobie wyobrazić wiele sytuacji, w których sama domena nie wzbudza podejrzeń, ale już wiedza o tym co ktoś czyta na tej stronie może wzbudzać podejrzenia. W szczególności, gdy wewnątrz witryny jest mnóstwo artykułów na różne tematy.
W rozwiązaniach korpo to teraz będzie trzeba drastycznie rozbudować clustry FW.
Jak cały ruch webowy zostanie przymuszony do https to narzędzia do HTTPS inspection będą strasznie dociążać zasoby sprzętowe.
Czyli jak zwykle cały koszt poniosą Ci co serwują kontent webowy i Ci co odpowiadają za bezpieczeństwo sieci korporacyjnej.
A wszystko przez młotkowatych deweloperów. Nic nowego
Jak do tej pory masz sprzęt, który nie oferuje wsparcia sprzętowego dla szyfrowania, to i tak już od dawna jest pora na jego wymianę ;)
Według dawnej prezentacji Google’a zastosowanie HTTPS zwiększyło obciążenie CPU zaledwie o kilka procent. To nie jest tak dużo.
Zresztą filtrowanie ruchu nie jest aż tak skuteczną metodą ochrony przed szkodliwym oprogramowaniem jak skanowanie real-time uruchamiania i wykonywania programów przez antywirusy z heurystyką, HIPSem i analizą behawioralną aplikacji lub ochronę next-gen’ami (ochrona na podobnym poziomie jak AV przed atakami masowymi, ale lepsza przed celowanymi). Inna sprawa, że to wszystko da się też obejść i trzeba szkolić, uświadamiać pracowników.
A jak jest z poddomenami, jak mam certyfikat podpięty na sklep.domena.pl to na domena.pl muszę mieć osobny? Czy mogę podpiąć ten sam i obejmie on wszystkie podstrony?
Jeśli masz wildcarda, to certyfikat z domeny głównej możesz podpinać również pod subdomeny.