Apple Remote Desktop i szyfrowanie, które miało być, ale go nie było

Kochamy rozwiązania, w których najpierw można zaznaczyć opcję zapewniającą bezpieczeństwo, a następnie opcja ta jest całkowicie ignorowana. Takiej rozrywki  w w usłudze zdalnego pulpitu jeszcze do niedawna dostarczał swoim użytkownikom Apple.

Dwa dni temu Apple ogłosił, że klient usługi Apple Remote Desktop nie działał zgodnie z oczekiwaniami użytkownika. Przy podłączaniu się do zdalnego pulpitu na zewnętrznym serwerze VNC można było wybrać opcję „Encrypt all network data”. Niestety, nawet po wybraniu tej opcji transmisja nie była szyfrowana. Co gorsza, użytkownik nie był o tym fakcie informowany.

Apple Remote Desktop

Błąd, zgłoszony przez amerykańskiego studenta, występował w wersjach Apple Remote Desktop od 3.5.2 do 3.6.0 włącznie i został naprawiony w wersji 3.6.1. Oznacza to, że od lutego tego roku, kiedy to Apple wypuściło wersję 3.5.2, użytkownicy VNC korzystający z klienta Apple mogli nieświadomie przesyłać swoje dane bez szyfrowania.

Apple rozwiązało problem, dodając funkcjonalność zestawienia tunelu SSH gdy aktywna jest opcja „Encrypt all network data” oraz odmawiając zestawienia połączenia, w razie, gdy nie udało się skonfigurować bezpiecznego tunelu.

Wpadkę o podobnym charakterze zaliczyła niedawno firma SandForce, jeden z największych dostawców kontrolerów dysków SSD. Ich kontroler, który miał za zadanie szyfrować dane w locie algorytmem AES z kluczem o długości 256 bitów, w rzeczywistości z powodu błędu programistycznego szyfrował jedynie kluczem 128 bitów. Przyznać jednak należy, że ciągle – w przeciwieństwie do Apple – szyfrował.