Strona domowa GDR!a Tor Hidden Service

V 3.8



Why not DANE in browsers

(19. 01. 2015)

Kiedy czytam wpisy takie jak ten, ciężko mi nie odnieść wrażenia że są mocno sponsorowane. Wiadomo przecież że Langley głupi nie jest, a już na pewno mądrzejszy ode mnie. Tym bardziej dziwi jak pisze takie artykuły.

W skrócie, argumentuje że DANE dla HTTP nie ma sensu i że Chrome nie będzie go obsługiwało. (DANE w skrócie to z kolei umieszczenie fingerprinta certyfikatu w rekordzie DNS, co w połaczeniu z DNSSEC mogłoby zastąpić CA - przynajmniej tam, gdzie w tej chwili nie używa się SSL z powodów finansowych. Nie eliminuje głównych problemów CA, czyli centralizacji zaufania.)

Pierwsze z zastosowań, dodatkowa weryfikacja certyfikatu podpisanego przez CA, nie ma według Langleya sensu ponieważ według ich eksperymentów około 5% użytkowników internetu używa wadliwych resolverów, które nie umieją czytać rekordów TXT i w związku z tym nie mogłyby wyświetlać stron używających HTTPS. To jest ogólnie dobry argument, tylko że nie w ustach kogoś kto ogłasza zamiar wycofania certyfikatów podpisanych SHA-1 niecały miesiąc przed wypuszczeniem przeglądarki wyświetlającej ostrzeżenia przy takich certyfikatach. Jeśli używają logiki "wieziemy na czołgu kaganek oświaty psując po drodze pół internetu, a inni niech po nas posprzątają", dlaczego nie włączyć DANE i nie zmusić tych 5% do naprawienia swoich DNS-ów? Ale OK, ten argument jestem w stanie przyjąć.

Drugie, moim zdaniem ważniejsze zastosowanie, to publikowanie fingerprintów certyfikatów self-signed. Tutaj logika jest wyjątkowo pokrętna bo zasłania się szczegółami implementacyjnymi: że musieliby parsować rekordy poza sandboxem (kogo to obchodzi? niech sobie odpalą osobny proces, odbiorą mu wszystkie prawa i komunikują się z nim po IPC) oraz że obecnie DNSSEC używa 1024-bitowego RSA za którym nie przepadają. OK, pewnie że 1024 bity muszą powoli odejść do lamusa, ale przecież 1) prędzej czy później główne strefy DNSSEC zaczną używać dłuższych kluczy - dlaczego odwlekać adopcję DANE aż do wtedy? 2) teoretycznie-możliwe-do-złamania-w-niedalekiej-przyszłości klucze 1024-bitowe ciągle są lepsze od czystego tekstu który większość stron serwuje obecnie. Jest jeszcze argument o tym że Google bardzo chciałoby żeby Certificate Transparency spowodowało, że wszyscy na nowo zaufają CA.

DANE powoli staje się standardem dla serwerów SMTP, nie widzę powodu dla którego nie miałoby być używane również dla HTTP, i moim zdaniem sabotowanie tego typu przedsięwzięć to sabotowanie zdecentralizowanego internetu. Nie można też pominąć tego jak wielkim przemysłem są CA sprzedające iluzję bezpieczeństwa - można z dużym prawdopodobieństwem przyjąć że po wprowadzeniu DANE do przeglądarej ich rynek skurczyłby się jedynie do klientów którzy obecnie używają certyfikatów EV.

(komentarzy: 6, ostatni: 03. 02. 2015 - 18:55:56 - GDR!) Skomentuj
Wyswietlen: 5052, komentarzy: 6 Feed z komentarzami


Imię: fj (20. 01. 2015 - 23:21:52)

Treść:
Korporacja wprowadzi, a ludzie i firmy (prawie wszystkie "consultingowe" działają na narzędziach od Google) się przystosują. Kolektywizm pełną gębą, a kto ma inne zdanie niech biznes zwija. Czyż nie? ;-)



Imię: GDR! (21. 01. 2015 - 09:15:02)

Treść:
Pewnie że tak. Chociaż i tak jest lepiej niż za hegemonii Microsoftu.



Imię: fj (22. 01. 2015 - 22:55:45)

Treść:
Ano, Google przynajmniej stara się implementować, rozwijać i narzucać otwarte, standaryzowane rozwiązania; jeżeli pamięć mnie nie myli, to Microsoft "zawsze" miał jakieś własne "alternatywne" zamknięte lub maksymalnie złożone, skomplikowane i niedoprecyzowane rozwiązanie do istniejącego, otwartego i standaryzowanego (przykład: DOC versus ODT).



Imię: GDR! (22. 01. 2015 - 23:08:48)

Treść:
No, na dodatek często tworzyli jakieś zupełnie nieprzemyślane standardy które wydawały się stworzone na szybko na kolanie żeby obejść problem. Jest lepiej, ale "don't be evil" już dawno nie obowiązuje.



Imię: Kornel (24. 01. 2015 - 03:28:20)

Treść:
IMHO przyszłość TLS wygląda całkiem nieźle, więc nie widzę powodu, żeby się użerać z DNSSEC z archaiczną kryptografią i jednym CA na całe .com, który spokojnie może być tak bardzo niekompetentny i niegodny zaufania jak tylko chce, bo przecież żadna przeglądarka nie wyłączy otwierania .com.

Let's Encrypt będzie dawało certyfikaty przez darmowe publiczne API. Idea jest, żeby wszystkie serwery konfigurowały HTTPS do wszystkiego automatycznie (w najgorszym przypadku `apt-get letsencrypt` i już masz HTTPS z DV certyfikatem za darmo).

Te same certyfikaty działają z SMTP i EFF pracuje nad publiczną listą serwerów wymagających walidacji certyfikatów.

Sceptycznie podchodzę co do technikaliów Certificate Transparency, ale ogólnie idea przyłapywania CA na lewych certyfikatach, choćby przez pinning, wydaje się dobra. Z HPKP masz bezpieczeństwo podobne do SSH. To działa odstraszająco na 3-literowe agencje, bo muszą się liczyć z tym, że będzie skandal w gazetach jak przeglądarka ofiary zgłosi lewy cert.

CA są przynajmniej jakotako zdecentralizowane i da się dodać do tego dodatkowe poziomy bezpieczeństwa (np. TACK).

TLS jest wreszcie jest uaktualniany. HTTP/2 jest marchewką na adopcję TLS 1.2 + PFS + EC.



Imię: GDR! (03. 02. 2015 - 18:55:55)

Treść:
Jeśli chodzi o jednego CA na jedną TLD: nie ufam ani obecnym CA ani tym od DNSSEC, nadają się co najwyżej do sprawdzenia połączenia do banku, więc tutaj nie mam żadnych argumentów.

Let's Encrypt chyba centralizuje darmowy SSL jeszcze bardziej niż DANE, tutaj mamy jednego CA na wszystkie domeny. Nie podoba mi się uzależnienie od jednej instytucji która na dodatek sama jest zależna od instytucji która podpisała jej roota. Nie ma żadnej pewności że to przetrwa próbę czasu. To jest darmowa, a nie wolna usługa, że tak ze Stallmana polecę. Poza chyba jest przeznaczona dla blogów i tym podobnych stron, nie będzie wildcardów i tak dalej. Porównaj konfigurowanie certyfikatu dla każdej domeny z osobna z wygodą konfiguracji kiedy masz jeden klucz na serwer i domenom ustawiasz tylko odpowiednie rekordy DNS. Jak ktoś się włamie, zmieniasz jeden klucz a nie setkę.

Z SMTP mówisz o starttls-everywhere? Twój Exim i mój Postfix realnie mogą się tam znaleźć? To jest kolejne scentralizowane rozwiązanie, EFF może zadecydować że nie chce rozdymać pliku przechowując tam serwery na których jest raptem 5 kont. Nawet jeśli to nie będzie problemem, admin serwera pocztowego może wrzucić listę EFF raz i nigdy jej nie zaktualizować. Z DANE problem nie istnieje.

Co nie znaczy że starttls-everywhere nie ma sensu, korzystam z listy serwerów z podobnego projektu. Ale to jest dobre do połączeń z dużymi dostawcami, nie z indywidualnymi/firmowymi serwerami.

HPKP jest moim zdaniem spoko pomysłem, TACK też. Oba nie są przywiązane do idei CA i tak samo dobrze działałyby bez nich.

Żeby nie było że tylko neguję: idealnie widziałbym fingerprinty w blockchainie typu Namecoin, bardziej realistycznie - Perspectives/Convergence wbudowane w przeglądarkę, a kolejnym jeszcze dalszym od ideału ale jeszcze łatwiejszym do zaimplementowania kompromisem jest dla mnie DANE.

Sblam! Antyspam
URL encoded in QR Code Statystyki:

Email
Comments