Wszystko zaczęło się od tego, że Wampiryczny blog zmienił sposób dostępu, wymuszając HTTPS. Skomentowałem pół żartem, pół serio. Dostałem odpowiedź w komentarzu, przeczytałem i trochę mi się włos zjeżył na głowie. Bo zdecydowanie o zużyciu energii ktoś nie pomyślał. Jak jestem zwolennikiem udostępniania treści po HTTPS i bardzo sobie ostrzę zęby na projekt letsencrypt.org, tak uważam, że wybór powinien być po stronie odbiorcy, a jedynie miejsca, gdzie są przesyłane wrażliwe dane (np. hasła) powinny mieć wymuszony HTTPS.
Postanowiłem zrobić mały test, czyli pobrać stronę po HTTP i zobaczyć, ile zostało pobranych bajtów (i w jakim czasie), a następnie to samo dla HTTPS. Jako system został użyty base system Debiana, uruchomiony w wirtualce (KVM), uruchomionej na laptopie. Jako stronę serwującą dokładnie to samo po HTTP i HTTPS dobrzy ludzie podrzucili stronę OVH. Google.com na ten przykład serwowało wgetowi nieidentyczną zawartość.
HTTP
$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - http://ovh.pl/ >> out_http.txt; done ; ifconfig eth0 | grep "RX bytes"RX bytes:11251203 (10.7 MiB) TX bytes:495042 (483.4 KiB)real 0m9.471suser 0m0.000ssys 0m0.772sRX bytes:14173253 (13.5 MiB) TX bytes:583042 (569.3 KiB)
Jak widać wysłano 88000 bajtów, odebrano 2922050.
HTTPS
$ ifconfig eth0 | grep "RX bytes" ; time for NUM in {1..20}; do wget --no-check-certificate -qO - https://ovh.pl/ >> out_https.txt; done ; ifconfig eth0 | grep "RX bytes"RX bytes:14173313 (13.5 MiB) TX bytes:583102 (569.4 KiB)real 0m13.938suser 0m0.000ssys 0m0.904sRX bytes:17387531 (16.5 MiB) TX bytes:739702 (722.3 KiB)
Z kolei tutaj wysłano 156600 bajtów, a odebrano 3214218.
Podsumowując: HTTPS w tym teście był wolniejszy o 46%, przy korzystaniu z niego wysłane zostało o 78% więcej danych, a odebrano o blisko 10% więcej danych. Efekt, czyli pobrana zawartość jest dokładnie taka sama. Oczywiście ww. narzut procentowy będzie się różnił w zależności od rozmiaru pliku wynikowego, ale jak widać narzuty są spore.
Do prędkości bym się zbytnio nie przywiązywał, bo o ile za brak ruchu na wirtualce ręczę, to na lapku różne rzeczy się dzieją, choć generalnie idluje, a sam lapek zapięty po wifi. Niemniej, pomiarów było kilka, także dla mojej strony ze stanem rowerów na stacjach Nextbike. Wyniki podobne – wolniej i więcej przesłanych danych po HTTPS.
Dlatego przerażają mnie zmiany planowane zmiany w Chromium powodujące, że strony po odwiedzane po HTTP będą oznaczone jako niezaufane. Podobnie robi Mozilla. Rozumiem, że jeśli wysyłamy dane, zwł. z kamery czy mikrofonu, ba, jeśli cokolwiek wprowadzamy na stronie czy wysyłamy pliki. Ale sam odbiór? Trochę przesada. Tym bardziej, że istnieją narzędzia, do wymuszania HTTPS, jeśli ktoś ma taką potrzebę – choćby HTTPS Everywhere.
Zupełnie nie rozumiem podejścia Google do wykorzystania HTTPS jako sygnału rankingowego. Zdobycie certyfikatu nie jest problemem, a jak ruszy Let’s Encrypt, to już w ogóle. Znaczy rozumiem ideę, ale do sprawdzenia autentyczności, wystarczyłoby np. pobierać po HTTPS sitemap.xml. Czy tam robots.txt. Czy stronę główną.
Trochę zastanawiam się, po co ta nagonka. I mam wrażenie, że nie tyle o bezpieczeństwo chodzi (dobry pretekst, fakt), a o pieniądze. O ile certyfikaty tanieją i będą za darmo (ale czy wszystkie?), o tyle pewnie jest to pretekst do kolejnego wzrostu narzutu na ruch, nowych usług (terminowanie SSL na proxy czy CDN), wymiany pudełek itp. Nawiasem, jest nawet strona zachwalająca, jaki to TSL jest szybki, na współczesnych procesorach i nowym oprogramowaniu. Tyle, że nie. Ale nie omieszkam sprawdzić (na najnowszym Debianie), jak tylko Let’s Encrypt ruszy…
Zachęcam do polemiki. Polecenia podałem wyżej, można samemu sprawdzić, podać kontrprzykłady, pochwalić się konfiguracją z minimalnym narzutem na wersję szyfrowaną.
UPDATE: Poprawione polecenia (było dwa razy HTTP, zamiast raz HTTP i raz HTTPS). Bug przy przeklejaniu, wyniki są i były prawidłowe. W sumie jestem rozczarowany, że tak długo nikt tego nie zauważył.
Do polemiki na ten temat jestem za słaby, aczkolwiek słyszałem już o planach oznaczania stron jako niezaufane już jakiś czas temu (chyba przy okazji szukania dlaczego niektóre certyfikaty oznaczane są jako niezaufane), w Chrome też tak będzie. Sam myślałem o HTTPS, no ale właśnie – w sumie po co mi to? Osób nie chcących wpisać prawdziwego e-maila w fomularzu komentarzy i tak nie przekonam do zostawienia paru własnych przemyśleń. Pomijam już, że nie każdy ma stronę jaką chce zabezpieczyć (czy bloga) w głównej domenie – bulenie setek złotych za wildcard to jakieś nieporozumienie.
Zrobiłem u siebie ten sam test 😉 Tylko jako adres podałem http://www.ovh.pl i http://www.ovh.pl (w celu uniknięcia dodatkowego przekierowania 301)
wyniki
http – 0m9.987s | 2900603 bajtów
https – 0m10.318s | 3148924 bajtów
O ile z ilością danych nie ma co dyskutować (całe 8% więcej ale jednak) tak czas jest na granicy błędu pomiarowego, tym bardziej że 20 pobrań to żadna statystyka. Pomiar wykonany na łączu 3/3Mbps (gwarantowanym w trakcie testu prędkość się wahała w okolicach 8/5Mbps)
Jeśli rozważamy łącze typu 3g to owszem narzut związany z szyfrowaniem może mieć jakieś znaczenie, jednak w dzisiejszych czasach gdzie standardem jest łącze ~10Mbps
to nie przesadzajmy 🙂 To nie czasy ISDNa. Owszem są miejsca gdzie jedynym „wyjściem na internety” jest telefon (lub tym podobne urządzenie) ale nawet i on na ogół łapie prędkość w okolicach 2Mbps (i to tylko po HSDPA/HSDPA+, a gdzie LTE?)
W codziennym użytkowaniu neta (czy to na puszce czy to przez telefon) nie odnotowałem jakiś strasznych utrudnień/spowolnień związanych z HTTPS.
IMHO „panikujesz” bez potrzeby 😉 HTTPS ma jeszcze jedną zaletę: o ile admin pamięta o odnowieniu certa to ciężko podmienić stronę docelową.
Jak dla mnie let’s encrypt nic nie zmienia jak sa darmowe certyfikaty od startssl.
Co do energii/procesora to słyszałem, ze najwięksi dostawcy zniwelowali to do +2%, ale wydaje mi się, że wynikają te wyniki z użycia specjalnych urządzeń do `terminowania` sesji ssl.
Co do samej kwestii sensu takiej operacji, to wolałbym dodać ten komentarz po ssl, aby open wifi do którego się podłączyłem nie został podsuchany przez sąsiada, aby uczelnia od której mam wifi nie poznała treści komentarza i tego jak wyzywam w nich wykładowców, aby ktoś z POZMAN nie podsłuchał komentarza i aby wszyscy z nich nie zmienili go w locie, nie podstawili spywaru na stronę, nie dokleili reklam swoich instalujących zestaw emotikonek tylko-uruchom-ten-plik-pdf.exe, nie zmodyfikowali treści, zablokowali obrazka z placu Tiananmen itp.,
I jeśli uznasz, że to wszystko jest mało realne, to pamiętaj, że z Firefoksa korzystają też ludzie w państwach reżimowych, gdzie celem są zwykli ludzie i takie ataki naprawdę mają miejsce. I wiem, wiele z nich ma swoje certyfikaty, ale Google i EFF ma przynajmniej jakąś szansę to wyłapać.
@Monter Dla użytkownika końcowego SSL staje się coraz bardziej darmowy. Certyfikat możesz wystawiać na subdomenę, nie musisz na główną. Możesz też mieć wiele certyfikatów jednocześnie. Ogólnie wildcard to raczej kwestia wygody w takim wypadku.
@winnetou Dzięki za test. Jak przesyłanych jest więcej danych, to i wolniej będzie – cudów nie ma. Pamiętajmy, że coraz więcej urządzeń korzysta z netu via GSM, a tam już transfer bardzo się liczy – pakiety danych wracają w wielkim stylu. I tu mały wtręt: z jednej strony zliczanie ilości danych jest w mobilkach, z drugiej – nigdy tak naprawdę nie zniknęły z hostingu.
I nie, to nie jest dramatyczna zmiana. Właśnie o to chodzi, że jest trochę wolniej i trochę więcej zasobów jest zużywanych. W skali pojedynczego żądania czy urządzenia pomijalne. Tak samo pewnie nie zauważysz, jak samochód zacznie palić 5% więcej. Patrząc globalnie, koszt użycia HTTPS wszędzie będzie znaczny – pojawią się dodatkowe urządzenia do jego obsługi, które trzeba zasilić. Końcówki zużyją parę procent więcej prądu. Wytworzymy trochę więcej ciepła.
Czy stronę ciężko podmienić? To już zależy komu ciężko. Malutkim – owszem (choć i tego nie jestem pewien, jeśli będą w stanie przechwycić ruch, a w szczególności żądania DNS to nie widzę większego problemu, szczególnie w dobie darmowych i automatycznie weryfikowanych certów SSL, jeśli dobrze zrozumiałem mechanizm Let’s Encrypt). Więksi nie będą mieli z tym żadnego problemu…
@nbb Wydaje mi się, że łatwiej będzie uzyskać taki certyfikat. I w sposób automatyczny.
Nie chodzi o skalę narzutu, tylko o sensowność stosowanie HTTPS wszędzie. Z jednej strony staramy się ograniczyć zużycie energii (efekt cieplarniany, te klimaty), wydłużyć czas działania urządzeń na bateriach, przyspieszyć działanie stron. Z drugiej przepalamy na wejściu kilka procent i pogarszamy wyniki.
Komentarz to input box, te mogłyby być szyfrowane. Tak, zaszyfrowanie wszystkiego jest proste, w porównaniu do selektywnego szyfrowania (było o tym w komentarzu do pierwotnego wpisie). Koniec zalet. 😉 Pewnie musiałby powstać standard, określający, które elementy szyfrować. Pewnie od „szyfruj tylko niezbędne” przez „szyfruj wszystkie wejścia” do „szyfruj wszystko”, podobnie jak z akceptacją cookies obecnie.
Przy czym, jak wspomniałem wyżej, ktoś ma kontrolę nad resztą sieci, zwł. DNS, to HTTPS Cię nie uratuje. Spyware na stronach też będzie, podmiana ruchu w locie jest szalenie nieefektywna, a przy włamaniu na konto hostingowe i „doklejce” HTTPS nic nie da. Reklamy i drive by download? Malware w reklamach był, bo atakujący po prostu wykupują je i kierują na swoją stronę, która może być po HTTPS. Blokowanie pojedynczego obrazka? Ktoś się w to bawił, w ogóle? Prościej całą stronę. Czy to ruch do IP, czy blokada na poziomie DNS.
Z rzeczy, które się skończą – transparentne proxy, obniżające jakość grafik na stronach (i psujące JS przy okazji, pozdrowienia dla Orange). Tylko po coś one były…
@rozie, czy mógłbyś sprawdzić, czy wget w trakcie twojego testu za każdym razem robi pełny handshake czy robi session id re-use?
Druga sprawa – jeśli chcesz rozważać narzut na szyfrowanie, powinieneś zwracać uwagę na wynegocjowany algorytm. Nie bez powodu Google pracuje nad wdrożeniem/upowszechnieniem ChaCha20 (googleonlinesecurity.blogspot.com/2014/04/speeding-up-and-strengthening-https.html).
A skoro już o tym mowa: tools.ietf.org/html/draft-mattsson-uta-tls-overhead-01. Tu masz dość dokładną analizę narzutu TLS zarówno na rozmiar przesyłanych danych, jak i na processing.
A po trzecie – wolę zużywać trochę więcej prądu na HTTPS niż na głupie reklamy flashowe 🙂
@rozie: co do szyfrowanie jedynie inputu, to jednak w przypadku, gdy reszta jest jawna, powiązanie komentującego z komentarzem jest banalne! Komentarz jest wyświetlany na stronie, a posiadane metadane jasno wskazują na autora.
Oczywiście, że można się włamać na serwer i podmienić stronę itp., ale w przypadku gdy masz jakąś sporą firmę zachodnią i jesteś watażką z Sudanu to jednak obywatel uzbrojony w dobrą przeglądarkę i kilka dodatków ułatwiających cert pinning może czuć się lepiej i bardziej komfortowo.
Tutaj masz artykuł arstechnica.com/business/2015/02/att-charges-29-more-for-gigabit-fiber-that-doesnt-watch-your-web-browsing/ o śledzeniu na codzień. Jak widać da się to zrobić. I musisz przyznać, że https wszędzie pozwoliłby ograniczyć takie praktyki.
W kwestii blokowania, to jeśli jest ono jawne i oczywiste to faktycznie można to zrobić na poziomie ip (chociaż wyciąć przy okazji wiele innych rzeczy), jednak śledzenie i próby zgadywania na podstawie IP co człowiek przegląda są obarczone moim zdaniem dużym błędem.
@winnetou Odnośnie „20 nie statystyka” i z www czy bez – uruchomiłem 200 razy (na innym, szybszym łączu). Wynik dla http bez www się zapodział przy wklejaniu, ale trend jest oczywisty:
ovh.pl/ – 0m58.064s
http://www.ovh.pl/ – 0m26.076s
http://www.ovh.pl/ – 0m7.506s
Bardziej zmierzałbym w stronę tego, o czym Paweł pisze, czyli że może ovh.pl nie jest najlepszym przykładem. Nie upieram się i użyłbym innej strony (Google.com), ale jak pisałem, nie zwraca identycznej zawartości wgetowi z i bez SSL. Czekam na propozycje stron. 🙂
@Paweł czy wget w trakcie twojego testu za każdym razem robi pełny handshake czy robi session id re-use
Trochę nie rozumiem pytania, tj. czy było re-use (nie było, wg narzędzia github.com/vincentbernat/rfc5077/blob/master/rfc5077-client.c ovh.pl nigdy nie robi reuse), czy wget tak odpalony jest w stanie robić re-use (nie wiem jak sprawdzić inaczej niż patrząc w dumpy ruchu a i tam nie wiem, czy będzie widać; to są osobne uruchomienia programu; w curlu można z tego co widzę łatwiej debugować).
powinieneś zwracać uwagę na wynegocjowany algorytm
I tak, i nie. To z założenia był mały test i na żywych danych, a wpis raczej ma być przyczynkiem do dyskusji. Chętnie potestuję na innych stronach. Poza tym, odpalając curla na top 25 najpopularniejszych stron (Alexa) widać głównie:
SSL connection using TLS1.2 / ECDHE_ECDSA_AES_128_GCM_SHA256 lub
SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 – ChaCha20 jakby nieobecny.
Dobry link, dzięki. Tylko troszkę czym innym jest teoria na papierze, a czym innym praktyka. I nie, nie twierdzę, że nagle będzie 20% narzutu. Trochę wiecej danych, trochę wolniej, trochę więcej prądu. Trochę.
Korzystanie (lub nie) z SSL nie ma związku z korzytaniem (lub nie) z Flasha czy (nie)blokowaniem reklam, więc pudło.
@nbb Cóż, zmartwię Cię, jeśli chcesz się bawić w powiązania/korelacje, to niestety szyfrowanie całości nic nie zmieni. Szczególnie że i IP, i timestamp są jawne. A admin sieci zapewne ma metadane o ruchu. Skoro może się oprzeć na nielegalnie zdobytych (podsłuch!) danych, to i takie poszlaki pewnie wystarczą, prawda?
Wróćmy do początku – ja nie mówię, żeby nie korzystać z SSL. Ba, jeśli użytkownik odczuwa taką potrzebę, to jak najbardziej niech ma możliwość włączenia wszędzie. Ale nie widzę sensu owijania w SSL wszystkiego i zawsze.
Tak, da się ingerować w ruch. Tylko to margines. I znowu – mając odpowiednie środki i kontrolę nad ruchem DNS – SSL przed niczym nie chroni.
Blokowanie po IP to oczywiście ekstremum (ale wykonalne, mieliśmy i w Polsce okazję oglądać, z niewinnymi ofiarami, u największego zdaje się operatora). Prościej i „celniej” po domenach.
Mnie to cieszy.
1) Za dużo obecnie jest miejsc gdzie powinno być pełne szyfrowanie a nie ma. IMO ochrona loginu i hasła to za mało, klucze sesji oraz dane teleadresowe również powinny być chronione przez cały czas. Znane polskie serwisy prezentuje podsumowanie zakupów gdzie są nasze pełne dane teleadresowe bez żadnej ochrony (i do tego pewnie sesja w ciasteczkach) Obecnie dużo serwisów nie oferuje żadnego poziomu bezpieczeństwa i poufności danych, jedyny wybór to korzystasz (i bierzesz na klatę problem braku poufności) albo nie korzystasz (i idziesz do serwisu zagranicznego, który nie ma w d. Twojego bezpieczeństwa).
2) Powiązanie IP to nadal dużo mniej niż czytanie treści żądań i odpowiedzi. Miejsc gdzie możliwy jest podsłuch nadal jest za dużo, a przynajmniej było za dużo (sieci uczelniana, darmowe hotspoty). Szyfrowanie od punktu początkowego do końcowego jest pewniejsze niż pokładanie zaufania w administratorze sieci lokalnej i *wszystkich* punktów pośrednich. Dostęp do urządzeń pośredniczących może mieć wścibski jegomość, któremu może zależeć nawet na najmniejszych duperelach (wredny sublokator).
3) Szyfrowanie zwiększy szum i ilość danych do przetworzenia ciężej będzie wykorzystać luki w algorytmach.
@Sebastian Ad. 1 Tak, rozwiązanie pt. „zaszyfrujmy wszystko” ma tę jedną zaletę, jaką jest prostota, o czym pisał Paweł. Tylko jakoś nie sądzę, że ludzie, którzy tworzą serwis i robią błędy tego rodzaju (a potem radośnie je ignorują, zapewne), nie popełnią innych błędów. Więc atakujący faktycznie nie podsłucha (oh, wait, SSL też można skopać/nie załatać…) danych, ale pobierze całą bazę (np. SQLI). Trochę nie tu leży problem.
Ad 2. Owszem korelacja ruchu to mniej, niż czytanie treści. Ale „służbom” wystarcza. Przykłady, które podałeś są świetnym argumentem, dlaczego należałoby szyfrować cały ruch do „bezpiecznego punktu” (if any…), a nie tylko zawartość żądań. To są świetne przykłady, gdzie pomógłby VPN, a nie SSL. Oczywiście chodzi o jawny ruch DNS (po raz kolejny o tym piszę). Możliwy do przechwycenia i zmanipulowania (skoro mówimy o atakującym kontrolującym infrastrukturę i wszystkie jej aspekty). Nie wiem, czemu wszyscy uparcie pomijają ten podstawowy (dosłownie) czynnik.
Ad 3. Rozwiń? Atakujący może przecież selektywnie wybierać dane, więc argument o zwiększeniu ilości nie ma znaczenia. W drugą stronę – większa ilość zaszyfrowanych danych (zwł. znanych) ułatwia niektóre rodzaje ataków. Co prawda AFAIK wg obecnej wiedzy nie ma to zastosowania przy współczesnych algorytmach, ale… 😉
Ad1 Błędy błędami, a skąpstwo skąpstwem. A przynajmniej nie wierzę, że np. takie Allegro nie szyfruje większej ilości rzeczy z innego powodu niż oszczędność mocy przerobowej. To jest klasyczny to nie błąd, to ficzer. Nie miałem także na myśli, że pełne szyfrowanie jest lekarstwem na całe zło, które na nas czyha w internecie nie ma 100% skutecznych metod zabezpieczeń, tym bardziej, że to tylko jeden z wielu elementów układanki. 😉
Ad2. Ze służbami jest ten problem, że one mają odpowiednie dojścia. Ktoś będzie potrzebował danych to je zdobędzie i to w świetle prawa. Co do DNS, z szyfrowaniem otrzymujesz także mechanizmy autoryzacji drugiej strony, przeprowadzenie skutecznego ataku pewnie jest możliwe ale trudniejsze brak mi wiedzy w tym zakresie. VPN eliminuje wiele przypadków ale nie wszytkie nie chroni transmisji pomiędzy każdym węzłem (chyba, że mowa o VPN na serwerze, z którym chcesz się komunikować).
Ad3. W sumie po zastanowieniu się argument bez sensu. Przy udanym ataku ilość danych nie utrudnia, a wręcz przeciwnie, tak jak mówisz, ułatwia sprawę Chociaż i tak nadal będę się upierał, że lepiej ukryć za dużo niż za mało.
@rozie: co do blokowania, w szczególności dns, to się chyba zgodzimy, że https nie ma chronić przed blokowaniem, tj. nie ma ukrywać samego faktu komunikacji z jakimś ip (od tego jest tor, vpn), a jedynie zapewnić poufność komunikacji. Samo blokowanie zawsze się uda. Blokowania ip się nie ominie bez czegoś takiego jak tor/vpn. Blokowanie dns to ciężko powiedzieć czy jest blokowaniem czy nie, IMO to jednak takie bardziej utrudnianie, bo o ile skromna wiedza mnie nie myli to jednak można sobie wejść na np. http://www.kloth.net/services/nslookup.php (szukałem czegoś takiego po https ale nie znalazłem! widzę tu niszę do zapełnienia :D) poznać ip i wrzucić do hosts.
Dla mnie najważniejszy aspekt https to jednak wiarygodność, że to co widzisz to faktycznie to, co wysłał ci serwer i fakt, że nikt ci tego nie przeanalizuje nie przemieli itp. I do tego najlepszym blokowaniem czegokolwiek byłoby podstawienie informacji o przerwie technicznej ;).
Kiedyś w pewnej sieci kom. przedłużałem umowę i mi powiedziano, że średni rachunek mam większy i mogę sobie pozwolić na większy abonament. Należę do osób, które nigdy się nie zgadzają na żadne marketingowe zgody i tak banalna analiza moich rachunków mnie poraziła. Jeżeli się to zrobi w skali wszystkich klientów można ich fajnie podzielić, stworzyć taryfy, które faktycznie będą pasować do ich profilu korzystania z sms/internetu/połączeń. To jest ta strona na +, na minus cały czas czekam, dopasowanie jakości usług do profilu użytkownika? Może to, o co walczy się w USA, czyli jak ktoś ogląda netflix (w temacie: arstechnica.com/security/2015/04/it-wasnt-easy-but-netflix-will-soon-use-https-to-secure-video-streams/) to zwalniamy mu połączenie? Dane to olbrzymie narzędzie, a ich zbieranie i analiza są coraz tańsze, więc coś takiego jak https jest bardzo ważne, bo pozwala ukryć dużo tych danych.
I myślę, że cały ten temat świetnie się wpasowuje w ten globalny trend. Odkrywamy, że tak naprawdę jesteśmy nadzy, ponieważ czy to rząd czy operatorzy mogą wiedzieć z kim rozmawiamy, a przez większość czasu mogą wiedzieć o czym rozmawiamy (jednak w kontaktach osobistych trudniej takie informacje zebrać). A czy to Snowdenowe wycieki czy informacje z rynku (link we wcześniejszym komentarzu) pokazują, że coraz łatwiej po to sięgać.
Więc jeśli o mnie chodzi, to uważam, że wszystko powinno działać po https. Cała komunikacja powinna zakładać, że po drodze wszystko przechodzi przez ręce złych i chciwych ludzi psujących i słuchających. I https to nie wszystko, musi być zadbanie po stronie użytkownika i jego klientów (nie tylko przeglądarki!), aby nie dały się zdegradować do http (HSTS i nie tylko), również cert pinning musi mieć miejsce i powinien być egzekwowany. Wtedy może nawet tor nie byłby straszny z podstawionymi exit nodami. Kiedyś sprawdzałem DNSSEC i TLSA, ze stron na które trafiłem, chyba tylko debian.org korzystał z obu. Wiele jeszcze mamy do zrobienia.
Przepraszam, ale jesteś niepoważny. Jeśli badasz curlem, 20 najpopularniejszych stron pod kątem Chacha20-Poly1305, to musisz mieć świadomość, że aby wynegocjować, to oprócz serwera musi obsługiwać je, łączący się klient. Jeżeli nim jest curl z jakiejś „stabilnej” Debianowej dystrybucji, to będziesz musiał ponowić test za 5-6 lat jak włączą najnowsze osiągnięcia do swoich narzędzi.
Chacha20, obsługuje GnuTLS od wersji 3.4.0, LibreSSL (od dawna), OpenSSL jeszcze nie.
Chacha20, to ogromny skok, ponieważ jest równie bezpieczny jak AES a przy tym dużo wydajniejszy. Szczególnie ma to znaczenie na smartfonach. Google już od dawna wykorzystuje go w komunikacji ze swoimi serwerami na Androidzie. Z dużych graczy, wykorzystuje go Cloudflare.
Z innych popularnych narzędzi, potrafi z niego korzystać OpenVPN.
@nbb Blokowanie dns to ciężko powiedzieć czy jest blokowaniem czy nie, IMO to jednak takie bardziej utrudnianie
Trochę inaczej rozumiemy blokowanie, zatem. Jaki procent odbiorców jest w stanie ominąć takie „utrudnienie”? Pewnie porównywalny z tym, którzy w razie czego odpalą sobie Tor/VPN. Przypomnę, że na filtrowaniu zapytań DNS właśnie opiera się filtrowanie treści w OpenDNS. Więc wyjdźmy z linuksiarskiej geekowni i spójrzmy na normalnych ludzi. 😉
Jeżeli się to zrobi w skali wszystkich klientów można ich fajnie podzielić, stworzyć taryfy, które faktycznie będą pasować do ich profilu korzystania z sms/internetu/połączeń. To jest ta strona na +
Jeśli sieć zrobi taki podział to nie po to, by klientom było lepiej, a po to, by średnio wyciągnąć dodatkowy 1 zł z klienta. 😉
Więc jeśli o mnie chodzi, to uważam, że wszystko powinno działać po https. Cała komunikacja powinna zakładać, że po drodze wszystko przechodzi przez ręce złych i chciwych ludzi psujących i słuchających.
Wracam do podstawowego postulatu: wersje HTTPS dostępne, kto chce, skorzysta z nich. HTTPS Everywhere i okolice. Decyzja w rękach użytkownika końcowego. OK, tu sobie sam trochę przeczę, bo tego typu dodatków użyją geeki, nie zwykli ludzie.
Kiedyś sprawdzałem DNSSEC i TLSA, ze stron na które trafiłem, chyba tylko debian.org korzystał z obu. Wiele jeszcze mamy do zrobienia.
Co niby miałby dawać DNSSEC użytkownikowi końcowemu?
@ano Przepraszam, ale jesteś niepoważny. Jeśli badasz curlem, 20 najpopularniejszych stron
Nie 20, tylko 25, trzymajmy się faktów. I jak pisałem, to jest mały, praktyczny test a nie poważne badania. W ogóle co to za statystyka z 25 stron?! 😉 Testowane strony są jakby podane, metoda – jak piszesz, wielce niedoskonała – też. Możesz przedstawić poważne badania, chętnie poznam wyniki.
Jeżeli nim jest curl z jakiejś „stabilnej” Debianowej dystrybucji
Ponownie zachęcam do trzymania się faktów, a nie gdybania. 🙂
curl -V
curl 7.43.0 (x86_64-pc-linux-gnu) libcurl/7.43.0 GnuTLS/3.3.16 zlib/1.2.8 libidn/1.31 libssh2/1.5.0 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP UnixSockets
Nooo, dajecie dalej – przynajmniej się czegoś dowiem.
Nie urywajcie dyskusji w takim miejscu, bo już kupiłem chipsy na ten seans ;o)
GnuTLS od wersji 3.4.0 obsługuje ChaCha. Musisz uaktualnić do najnowszej wersji lub skorzystać z LibreSSL lub BoringSSL.
—
curl 7.43.0 (x86_64-pc-linux-gnu) libcurl/7.43.0 LibreSSL/2.0.0 zlib/1.2.8
* Connected to encrypted.google.com (216.58.209.46) port 443 (#0)
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
—
Wszystkie połączenia z googlowymi serwerami realizowane są w pierwszej kolejności z pomocą chacha-poly. Możesz śmiało sprawdzać również na reddit, news.ycombinator.
@ano Dobra, do rzeczy, czyli praktyki: ile osób z tego faktycznie teraz skorzysta, skoro nawet niestabilny Debian ma za stare biblioteki? Spojrzałem na http://www.ssllabs.com/ssltest/ – faktycznie google.com, news.ycombinator.com oraz reddit.com mają obsługę ChaCha20. A potem jest smutna część pt. „handshake simulation” i tam ładnie widać, który klient skorzysta. No więc z symulowanych klientów skorzysta Android 5.0 i… tyle.
Każda aktualna dystrybucja korzystająca z najnowszej gałęzi gnutls – archlinux, fedora. Z przeglądarek www – u mnie korzysta choćby ELinks. Potrzebna była mała łatka.
openbsd-archive.7691.n7.nabble.com/elinks-creates-file-whose-name-is-the-contents-of-elinks-conf-td248838.html
Z tych bardziej wypasionych. Wszystkie korzystające z najnowszego gnutls, czyli całe grono opartych o webkitgtk, jak midori, dwb i setka innych. Chromium i Firefox korzystają z nss, a on podobnie jak openssl nie wspiera tego cipheru jeszcze.
W pierwszej kolejności nacisk jest kładziony na rozpowszechnienie chacha-poly wśród urządzeń mobilnych. To z nich jest obecnie generowany największy ruch i jego zastosowanie daje największe obustronne korzyści, serwerom i klientom.
blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
@ano Jeszcze raz: zejdź na ziemię. Nie interesuje mnie nisza niszy niszy (użytkownicy nieFirefox i nieChrome (nisza nr 1) na nietypowej wersji (nisza nr 2) platformy Linux/BSD, która jest niszą sama w sobie (nisza nr 3). To jakbyś twierdził, że DNS jest szyfrowany, bo przecież jest dnscrypt. 🙂
Największy ruch z urządzeń mobilnych? Ale masz jakieś wsparcie? Bo nawet YT twierdzi, że połowę odsłon ma z mobilków, ale do połowy ruchu to jeszcze długa droga (odsłona może mieć różną ilość przesłanych danych, a ta zależy od długości materiału i jego jakości).
BTW CloudFlare w linkowanym artykule podaje, jaki procent połączeń (znowu: nie przesłanych danych) korzysta z ChaCha20. Niecałe 10% (co i tak uważam za sukces tego algorytmu, biorąc pod uwagę jego nieobecność w mainstreamie). Serio chcesz dywagować nt. rzeczywistego, odczuwalnego przez użytkownika narzutu HTTPS na przykładzie mocno mniejszościowego algorytmu? Który i tak ma ok. 2% narzutu w optymistycznym wariancie teoretycznym?