+- Kanciapa: historie nieprawdziwe (//kanciapa.pbf.net.pl)
+-- Dział: Kanciapa (//kanciapa.pbf.net.pl/forum-3.html)
+--- Dział: Sprawy techniczno-organizacyjne (//kanciapa.pbf.net.pl/forum-7.html)
+--- Wątek: Kanciapa - wersja szyfrowana (/thread-272.html)
Kanciapa - wersja szyfrowana - Czerwony - 14.07.2014
Tl;dr: od tej pory można opcjonalnie przeglądać całe forum lub jego części za pomocą szyfrowanego protokołu HTTPS. Wystarczy w pasku adresu zamiast "kanciapa.pbf.net.pl" lub "http://kanciapa.pbf.net.pl" wpisać "https://kanciapa.pbf.net.pl" i zaakceptować na stałe certyfikat SSL o który zapyta przeglądarka.WAŻNE: jeśli po poprawnym dodaniu certyfikatu do zaufanych, bez informacji z mojej strony zostaniecie ponownie zapytani o akceptację, nie róbcie tego i zgłoście problem, np. w tym temacie.
UWAGA: długa, nudna ściana tekstu naszpikowana językiem technicznym.
Od dawna cierniem w boku siedział mi fakt, że wszystkie nasze loginy, hasła, id sesji i inne krytyczne rzeczy latają sobie nieszyfrowane do serwera i z powrotem. Wprawdzie jest małe ryzyko, że ktoś będzie próbował ataku man-in-the-middle na forum z niespełna trzydziestoma użytkownikami, ale w dobie masowej inwigilacji warto się zabezpieczać na zaś.
Po co to w ogóle?
Formularze zawierające nasze hasła nie są przecież danymi naszych kont bankowych... Zwykle. Prawda jest taka, że ludzie często używają tych samych haseł w wielu miejscach i jeśli nawet nie wszystkie grożą nam wyczyszczeniem konta, to przeglądanie naszej korespondencji przez osobę niepożądaną chyba też nie jest miłe i fajne, co nie? Dlatego szyfrowanie stron z formularzami haseł jest już od jakiegoś czasu praktyką znaną i zalecaną.
No dobrze, a po co szyfrować całe forum? Otóż może to być paranoja związana z czasami, w jakich żyjemy, ale różni ludzie podnoszą, że gdy tylko część ruchu sieciowego jest szyfrowana, dane potencjalnie wrażliwe wyróżniają się na tle pozostałych. Nie istnieje szyfrowanie którego nie można złamać, zależy to tylko od siły obliczeniowej jaką dysponuje atakujący i czasu jaki jest gotów poświęcić. Znów: prawdopodobnie nikomu nie zależy na hasłach i loginach, jakich używamy na tym forum, ale na wszelki wypadek... Jest jeszcze jedno, bardziej przyziemne tłumaczenie: aby nie trzeba było logować się przy każdym połączeniu z serwerem, skrypt ustawia w waszych przeglądarkach id sesji. Jest ono po jakimś czasie wygaszane, ale póki to nie nastąpi, atakujący może je przechwycić i podszyć się pod was w komunikacji z serwerem, uzyskując dostęp do wszystkiego, do czego dostęp macie wy.
Przeglądarka mówi mi, żeby nie ufać twojemu certyfikatowi!
Aby to wyjaśnić, musimy przez chwilę skupić się na samym działaniu szyfrowania HTTPS. Nie wchodząc w szczegóły techniczne należy podkreślić, że szyfrowanie stron internetowych jest zintegrowane z uwierzytelnianiem, czyli potwierdzaniem tożsamości. Ma to swoje uzasadnienie w kontekście wspomnianego ataku man-in-the-middle. Ruch w internecie, zanim z waszych komputerów osiągnie serwer docelowy (i wróci z powrotem) przechodzi przez wiele wysokowydajnych routerów. Jedne z nich są zabezpieczone lepiej, inne gorzej. Próby shackowania ich zabezpieczeń odbywają się cały czas w różnych punktach globu. W swej najprostszej postaci, atak man-in-the-middle polega więc na złamaniu zabezpieczeń jednego z routerów i przechwytywaniu pakietów, jakie przezeń przechodzą. Samo szyfrowanie nie naprawia tej luki, bowiem atakujący wciąż może stwierdzić, jakiego algorytmu szyfrowania używamy i odpowiadać w ten sam sposób. Z naszej perspektywy nie dostrzeżemy różnicy między atakującym a prawdziwym serwerem, z którym chcieliśmy się połączyć.
Z tego powodu stworzono mechanizm weryfikacji tożsamości zdalnych komputerów (serwerów), z którymi komunikujemy się w sieci. Oparty jest on na dodaniu do komunikacji trzeciej strony, która weryfikuje tożsamość strony, z którą rozmawiamy. Mechanizm ten jest silnie sprywatyzowany: owe "trzecie strony" to najczęściej prywatne przedsiębiorstwa, które za opłatą podpisują (certyfikują) klucze kryptograficzne, używane do szyfrowania HTTPS. Listę takich "zaufanych" firm dostarcza producent twojej przeglądarki, która przy łączeniu za pomocą szyfrowania automatycznie porównuje taki podpis z tym, jaki posiada w swojej bazie.
Jeśli podpis nie pasuje do żadnego z "zaufanych" lub klucz kryptograficzny nie jest podpisany wcale, przeglądarki wyświetlają monity. W ostatnich latach istnieje tendencja, by monity te były coraz wyraźniejsze i coraz bardziej zniechęcające użytkownika do bezmyślnego kliknięcia odpowiednika "dalej".
To czemu nie możesz uzyskać takiego podpisu, żeby przeglądarka się nie oburzała?
Pierwszym, ale nie jedynym powodem, jest wyżej wspomniana cena. W obecnym modelu szyfrowania "zaufanie" stało się dochodowym biznesem, ceny certyfikatów zaczynają się od 100 zł rocznie i nie jestem chętny, by wydawać na ten cel prawie połowę tego, ile wynoszą koszty całego serwera, domeny itp. Być może kiedyś zacznę zbierać datki, jak już pbf.net.pl będzie, he he, wielkie i znane, ale nawet wtedy wydaje mi się, że są lepsze rzeczy na które można wydać pieniądze.
Przeświadczenie to wynika z drugiego powodu, który można w skrócie przedstawić tak: system nie jest idealny. Założenie jest takie, że aby uzyskać zaufanie do serwera z którym się łączysz, prosisz o potwierdzenie zaufaną stronę trzecią, że to faktycznie ten serwer. Klucz to termin "zaufana strona trzecia": czy faktycznie im ufasz? Czy mówią ci coś nazwy Thawte, VeriSign, DigiCert? Większości ludzi nie mówią nic, firmom tym ufają producenci przeglądarek a od ciebie oczekuje się, że będziesz ufać producentom. W modelu tym nie ma miejsca na strony, którym ufasz ty sam(a), a nie ufają producenci. W przypadku np. Microsoftu, producenta przeglądarki Internet Explorer, zaufanie jest wynikiem wpłacenia firmie określonej kwoty w dolarach. W 2011 roku zabezpieczenia "zaufanych" firm Comodo oraz DigiNotar zostały złamane przez nieznanych sprawców.
Więc skąd mam wiedzieć, że twoje szyfrowanie jest bezpieczne?
W mechanizmie szyfrowania wszystko opiera się na zaufaniu. Akceptując certyfikat mówisz: "ok, ufam osobie wystawiającej ten certyfikat". Certyfikat na tej stronie jest podpisany przeze mnie, akceptacja go jest równoznaczna ze stwierdzeniem, że ufasz mi bardziej niż przesyłając te same dane w sposób niezabezpieczony. Jeśli nie ufasz, to nie ma problemu - wersja nieszyfrowana jest nadal dostępna jako domyślna i będzie nadal, w dającej się przewidzieć przyszłości.
Ponieważ tożsamość weryfikujesz "na oko" - nie będziesz przecież za każdym razem porównywać sum kryptograficznych - atak man-in-the-middle nadal jest możliwy. Atakujący może jednakże podrobić tylko moją tożsamość (tzn. przedstawić się jako Czerwony) ale jego podpis cyfrowy będzie różnił się od mojego. Dlatego w przypadku tego ataku otrzymasz ponownie od przeglądarki monit o zaakceptowanie certyfikatu. Jeśli nie ma na forum informacji o zmianie certyfikatu, nie akceptuj go. Certyfikat jest wymieniany raz do roku, wtedy za każdym razem będę o tym informował.
RE: Kanciapa - wersja szyfrowana - Szmer - 14.07.2014
10/10 pr0hax0r
Założę się, że są na forum osoby, które używają tego samego hasła np. do konta poczty. A mając konto poczty, można pozmieniać hasła do wszystkiego przez opcje "zapomniałem hasła". To tak dorzucę do czerwonych strachów.
IMO jeszcze jak bawimy się w paranoję, to przydałoby się, żeby hasła przy logowaniu były haszowane w przeglądarce, a nie na serwerze (wcześniej przelatując sobie przez pół świata protokołem POST). Nie wiem, jak jest w MyBB i czy ew. jest jakiś plugin do tego.
Aha, i mi na httpsie shoutbox nie działa
RE: Kanciapa - wersja szyfrowana - Ruski - 14.07.2014
Na Eufi też mieli z tym problemy (czat + htpps) ale jakoś to rozwiązali (nie wiem jak :c może przez wypieprzenie https).
RE: Kanciapa - wersja szyfrowana - Czerwony - 14.07.2014
Tak dodając: pisałem że ataki są mało prawdopodobne, ale to nie znaczy, że są w 100% w sferze fantazji. Mój domowy router, na którym mam wypasione oprogramowanie z firewallem, rejestruje 2-3 próby włamania dziennie (najczęściej z IP chińskich i rosyjskich
). Może się okazać, że jakiemuś hackerowi zechce się powyławiać hasła użytkowników niszowego forum - byłoby to odpowiednio trudniejsze, ale też niewykrywalne od strony serwera, bo cały włam odbywa się gdzieś na serwerze pośredniczącym.Co do haszowania to jest to niewykonalne, jedyny używalny mechanizm takiej autoryzacji to HTTP Digest który używa starego MD5, przesyłanie tym haseł nie daje żadnego realnego zwiększenia bezpieczeństwa. Też wolałbym jakieś rozwinięcie tego modelu niż skomercjalizowany, scentralizowany SSL/TLS ale póki nie ma alternatyw wydaje mi się, że opcjonalne szyfrowanie własnym certyfikatem to najlepsze wyjście.
Na shouta spróbuję poradzić coś później.