Po co używać HTTPS w protokole DP-3T?

Oct 29 2020

Prowadzę dyskusję na temat przejrzystości protokołu HTTPS w odniesieniu do konkretnej aplikacji do wykrywania COVID-19. Przeciwnicy utrzymują, że używanie HTTPS maskuje aplikację, że aplikacja powinna zachowywać się transparentnie i przesyłać cały ruch przez HTTP, aby mogli zobaczyć, co wysyłają, ponieważ dane i tak są „anonimowe”.

Po pewnym dochodzeniu dowiedziałem się, że ta część jest ściśle zgodna z protokołem DP-3T , który stwierdza, że „aplikacja otwiera zaszyfrowane połączenie TLS do serwera i wysyła kod autoryzacji […]”. Wiem na pewno, że nie przeczytali całego protokołu (ja też nie, tylko niektóre jego części), ale nawet mając to na uwadze, powtarzają, że nie ma powodu, aby nie rozpoczynać używania zwykłego protokołu HTTP poprzez usunięcie HTTPS. Idą dalej i stwierdzają, że jeśli pojawia się w protokole, to jest źle zaprojektowany.

Więc jakie byłyby powody używania HTTPS w anonimowym protokole, takim jak DP-3T?

Odpowiedzi

19 Najkin Oct 29 2020 at 17:35

Połączenia TLS mają 3 ważne, odrębne właściwości:

prywatność, czyli ochrona przed podsłuchem
uwierzytelnianie, aby upewnić się, że komunikujące się strony są naprawdę tym, za kogo się podają
integralność, co oznacza, że dane nie mogą być modyfikowane podczas transmisji

Wygląda na to, że twoi przeciwnicy argumentują tylko przeciwko pierwszemu, ale pozostałe dwa są krytyczne dla większości zastosowań. W szczególności w przypadku DP-3T brak uwierzytelnienia oznaczałby, że atakujący mógłby przechwycić transmisję i porzucić ją, podczas gdy aplikacja pomyślałaby, że kod został pomyślnie przesłany.

Mówiąc bardziej ogólnie, TLS jest obecnie tani i łatwy w konfiguracji. Potrzebowałbyś bardzo dobrego powodu, aby go nie używać, a nie jednego, aby go użyć. W rzeczywistości przynajmniej w przypadku systemu iOS wyraźnie wymaga się, aby aplikacja korzystała z zabezpieczeń transportu , a wyjątki muszą być uzasadnione.

10 ximaera Oct 29 2020 at 17:16

Wraz z cyberprzestępcami, którzy chcą podsłuchiwać za pośrednictwem sieci bezprzewodowych, dzisiejsze skomplikowane sieci zwykle zawierają wiele różnych skrzynek pośrednich do monitoringu do różnych celów . Urządzenia te nie tylko podsłuchują, ale czasami mogą modyfikować przesyłane dane w dowolny sposób, celowo lub nieumyślnie.

Np. Sprzęt DPI zainstalowany przez dostawcę usług internetowych można skonfigurować w celu zastąpienia reklamy w witrynie internetowej reklamami dostawcy usług internetowych. W przypadku nieprawidłowej konfiguracji sprzęt ten zastąpiłby wówczas również niepowiązane części kodu Javascript lub XML w strumieniach danych przesyłanych przez aplikacje mobilne lub witryny sieci Web.

To tylko przykład.

Dlatego współczesny model zagrożeń dla witryn internetowych i aplikacji mobilnych zakłada po prostu szyfrowany HTTPS jako transport. HTTPS jest obecnie dość łatwy do skonfigurowania, jest dostępny za darmo i eliminuje tak dużą liczbę nieprzejrzystych i złożonych zagrożeń oraz potencjalnych błędów, że łatwiej i znacznie bardziej niezawodnie jest - z operacyjnego punktu widzenia - skonfigurować niż nie.

4 Kevin Oct 30 2020 at 05:21

Przeciwnicy twierdzą, że za pomocą protokołu HTTPS jest zaciemnianie aplikację, że aplikacja powinna zachowywać się w sposób przejrzysty i wysłać cały ruch przez HTTP więc oni mogą zobaczyć, co wysyłasz, ponieważ są to dane „anonimowy” i tak.

Zakładam, że pogrubione „oni” odnoszą się do użytkownika końcowego, a nie do programistów (ponieważ jeśli odnosi się do programistów, to jest to prosty problem polegający na niestosowaniu odpowiednich technik debugowania, takich jak logowanie po stronie serwera ).

Realistycznie, ilu użytkowników końcowych będzie korzystało z Wiresharka lub podobnego oprogramowania? Z tych, którzy są wystarczająco sprawni technicznie, aby uruchomić Wireshark, ilu poważnie uzna ruch HTTPS za podejrzany? Jest to prawdopodobnie drugi najpopularniejszy protokół (warstwa 7) na świecie (po SMTP, jak sobie wyobrażam) i, jak mówisz, protokół DP-3T wyraźnie wymaga jego użycia. Każdy, kto uznałby to za podejrzane, prawdopodobnie nie będzie wiedział wystarczająco dużo o technologii sieciowej, aby w ogóle korzystać z Wiresharka. Moim zdaniem korzystanie z niezabezpieczonego protokołu HTTP może wzbudzić podejrzenia z większym prawdopodobieństwem niż użycie protokołu HTTPS.

Z drugiej strony jest całkiem możliwe ukrycie danych w niezaszyfrowanych strumieniach sieciowych przy użyciu dowolnej liczby różnych form steganografii (w tym przypadku przez ukrycie niektórych danych w rzekomo „losowych” efemerycznych identyfikatorach używanych przez DP-3T i / lub w tajnym kluczu, gdy zostanie przesłany do raportu o infekcji; oba są nieprzezroczystymi plamami danych binarnych bez znaczącej struktury dla użytkownika do introspekcji). Tak więc fakt, że techniczny użytkownik końcowy jest w stanie monitorować ruch w Twojej aplikacji, i tak nie pomaga zbytnio z zaufaniem.

W każdym razie wyraźnie widzimy, że:

To niczego nie przekonuje nietechnicznych użytkowników.
Jest mało prawdopodobne, aby skutecznie przekonywał użytkowników technicznych, że Twoja aplikacja jest bezpieczna, i może ich przekonać, że jest niebezpieczna lub przynajmniej źle zaprojektowana.
Jak opisano w wielu innych odpowiedziach, TLS robi inne rzeczy poza poufnością, a to może zagrozić bezpieczeństwu implementacji w inny sposób.

4 BrianDrake Oct 30 2020 at 21:52

Oprócz doskonałych uwag przedstawionych w innych odpowiedziach, szyfrowanie tylko danych, w przypadku których prywatność ma znaczenie, mówi adwersarzom, że są to dane, których prywatność dotyczy, i pozwala im skupić się na odszyfrowaniu tych danych.

Innymi słowy, nawet jeśli Twoim jedynym zmartwieniem jest prywatność, powinieneś wszystko zaszyfrować, aby przeciwnicy nie wiedzieli, gdzie szukać. W stosownych przypadkach oznacza to używanie protokołu HTTPS zamiast HTTP.