Paweł Goleń, blog

Doprecyzujmy – w grubych klientach lub aplikacjach mobilnych. Normalnie, w przypadku aplikacji webowych, testowanie transport layer security polega na sprawdzeniu jakie protokoły/szyfry są oferowane przez serwer. W takim scenariuszu ma to trochę sensu, bo to ostatecznie serwer decyduje co zostanie wynegocjowane a przeglądarki, jeśli nie są za stare, nie używają archaicznych protokołów i szyfrów.

Inaczej sytuacja wygląda w przypadku aplikacji (mobilnych, desktopowych). Może okazać się, że klient jest skłonny zaakceptować wszystko co popadnie łącznie z czymś, co nie daje właściwie żadnego bezpieczeństwa (głównie aNULL). Coś takiego aż prosi się o MitM.

Kiedy coś takiego może się stać? Generalnie jeśli programiści używają funkcji wbudowanych w platformę nie powinno być tragicznie. Klient może być skłonny zaakceptować SSLv3 (teoretycznie powinien zacząć od czegoś lepszego, patrz: graceful degradation), może też akceptować szyfry słabsze (i tutaj wchodzi temat negocjacji z serwerem). Gorzej, jeśli programista używa bezpośrednio funkcji niskopoziomowych i, na przykład, nie do końca rozumie jak działają cipher listy w OpenSSL.

Jak to sprawdzić? Zawsze dobrze zrobić zrzut ruchu i zobaczyć co proponuje klient w Client Hello, wygląda to mniej więcej tak:

Cipher Suites (11 suites) Cipher Suite: TLSECDHEECDSAWITHAES128GCMSHA256 (0xc02b) Cipher Suite: TLSECDHERSAWITHAES128GCMSHA256 (0xc02f) Cipher Suite: TLSECDHEECDSAWITHAES256CBCSHA (0xc00a) Cipher Suite: TLSECDHEECDSAWITHAES128CBCSHA (0xc009) Cipher Suite: TLSECDHERSAWITHAES128CBCSHA (0xc013) Cipher Suite: TLSECDHERSAWITHAES256CBCSHA (0xc014) Cipher Suite: TLSDHERSAWITHAES128CBCSHA (0x0033) Cipher Suite: TLSDHERSAWITHAES256CBCSHA (0x0039) Cipher Suite: TLSRSAWITHAES128CBCSHA (0x002f) Cipher Suite: TLSRSAWITHAES256CBCSHA (0x0035) Cipher Suite: TLSRSAWITH3DESEDECBCSHA (0x000a)

I na większą skalę – jeśli ktoś ma możliwość monitorowania większego ruchu (ISP), to może być w stanie wychwycić ciekawe przypadki. Przez pewien czas monitorowałem z ciekawości swoją sieć i znalazłem takie kwiatki:

TLSDHEDSSEXPORTWITHDES40CBCSHA (0x0011) TLSDHERSAEXPORTWITHDES40CBCSHA (0x0014) TLSRSAEXPORTWITHDES40CBCSHA (0x0008) TLSRSAEXPORTWITHRC440MD5 (0x0003)

Na widok tych dwóch pierwszych tak mi się Logjam przypomniał...

Muszę spróbować ustalić, która aplikacja coś takiego wyprawia ;)

UPDATE:

Wygląda na to, że “winowajcą” jest telefon Samsung Galaxy S3. Większość, ale nie wszystkie, Client Hello wysyłane z niego zawierają te ciekawe szyfry wspomniane powyżej. Hosty, z którymi się łączy, przedstawiają się certyfikatami wystawionymi dla:

aax-us-east.amazon-adsystem.com api.accuweather.com api.amazon.com *.cloudfront.net cognito-identity.us-east-1.amazonaws.com *.crashlytics.com device-metrics-us.amazon.com *.googleapis.com mads.amazon.com *.manhattan.yahoo.com sns.us-east-1.amazonaws.com sts.amazonaws.com www.google.com *.yimg.com yql.yahooapis.com

Jak widać – nazwy można łatwo zmapować co najmniej z kilkoma różnymi aplikacji. Czyli wygląda na to, że w tym przypadku jednak platforma. Ktoś chętny do podsłuchania swojego smartfona?

P.S: Android 4.3 nie powinien mieć tych szyfrów włączonych, co innego staroć 2.3.7.

Oryginał tego wpisu dostępny jest pod adresem Transport layer security w aplikacjach

Autor: Paweł Goleń