Paweł Goleń, blog

Tak tylko informacyjnie jeśli ktoś tego nie zauważył:

XTS-AES encryption algorithm. BitLocker now supports the XTS-AES encryption algorithm. XTS-AES provides additional protection from a class of attacks on encryption that rely on manipulating cipher text to cause predictable changes in plain text. BitLocker supports both 128-bit and 256-bit XTS-AES keys.

Więcej: What's new in BitLocker?

P.S: A piszę o tym dlatego, że w końcu zebrałem się w sobie by zmienić AES-CBC na XTS-AES i jestem pod wielkim wrażeniem tego, jak mój szybko laptop poradził sobie z ponad 100GB danych.

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.

Właśnie skończyłem czytać/słuchać (no dobrze, bardziej słuchać) REAMDE. Miałem ochotę przeczytać tę książkę wkrótce po tym, jak się ukazała, ale zniechęciła mnie ta recenzja Gwoździa: Dwie powieści o graniu serio:

Niestety lektura książki okazała się sporym zawodem, bo zamiast tego wszystkiego, dostałem tysiąc stron banalnej opowieści o terrorystach (zwykłych, islamskich, a także szlachetnych, dwuwymiarowych cyber-terrorystach), zaś przedstawiona w książce gra T’Rain wydała się być zupełnie niegrywalną.

Jakiś czas temu temat tej książki pojawił się po raz kolejny, tym razem w kontekście Cybersecurity Canon, a konkretnie na temat tej książki więcej jest tutaj: The Cybersecurity Canon: Reamde.

Szczerze? Czytało mi się dość ciężko, słuchało (Audible) zdecydowanie lepiej. Ogólnie - ocena na plus.

Zauważyłem, że synchronizacja czasu coś nie do końca mi działa tak jak powinna. I nie chodziło o kilka sekund, ale o kilka dni różnicy między czasem na urządzeniu, a tym rzeczywistym. Trochę dziwne, bo urządzenie ma na sobie ntpd i powinno się synchronizować z pool.ntp.org. Po sprawdzeniu logów okazało się, że nie ma odpowiedzi od serwerów. Dziwne...

By skrócić potencjalnie długą historię - jeśli pakiet ma ustawiony port źródłowy na 123 to nie ma odpowiedzi od serwera. Jeśli natomiast port źródłowy jest inny (np. ntpdate -u), wówczas wszystko działa jak należy. Zapewne ISP blokuje takie pakiety...

Oczywiście opcja masquerade nie zmienia portu 123 na inny, więc trzeba było dorobić dodatkową regułę src-nat i wszystko zaczęło działać prawidłowo. Nie zmienia to faktu, że jestem nieco zirytowany zaistniałą sytuacją. Przy okazji - niestety, nie mam możliwości zainstalowania OpenNTPD, tam tego problemu nie ma bo usługa nie jest przywiązana do portu 123 (źródło).

A teraz pytanie - dlaczego? Zgaduję - zapewne dlatego: Understanding and mitigating NTP-based DDoS attacks.

DZIĘ-KU-JE-MY!

Wpadłem na pomysł pobawienia się skryptami w OWASP ZAP i już tego żałuję. Tak, uwielbiam przeglądać kod OWASP ZAP tylko po to, by dowiedzieć się jak coś zrobić w skrypcie, bo na przykład to, co jest w template dołączonym do ZAP już jest nieaktualne....