Dlaczego SSL / TLS nie jest wbudowany w nowoczesne systemy operacyjne?

Wiele podstawowych protokołów sieciowych tworzących infrastrukturę Internetu jest wbudowanych w większość głównych systemów operacyjnych. Na przykład, TCP, UDP i DNS są wbudowane w Linux, UNIX i Windows i są udostępniane programiście za pośrednictwem interfejsów API niskiego poziomu.

Ale jeśli chodzi o SSL lub TLS, należy zwrócić się do biblioteki innej firmy, takiej jak OpenSSL lub Mozilla NSS.

SSL jest stosunkowo starym protokołem i jest w zasadzie standardem branżowym tak powszechnym jak TCP / IP, więc dlaczego nie jest wbudowany w większość systemów operacyjnych?

Myślę, że zależy to głównie od tego, co postrzegasz jako „system operacyjny”. Jeśli jest to jądro, moja odpowiedź brzmiałaby: dlaczego? Mogę się mylić, ale czy DNS nie jest częścią glibc w systemach Linux, która jest biblioteką stron trzecich?

Jeśli nie chodzi o przestrzeń jądra lub użytkownika, prawie każdy system operacyjny / platforma ma stos SSL / TLS, niektóre mogą mieć więcej niż jeden.

Można to nawet uznać za zaletę. Gdyby nie było OpenSSL, musiałbyś dostosować się do API Windows, Mac i Linux (i ...). TLS nie będący częścią systemu operacyjnego pozwala pisać wieloplatformowe aplikacje TLS. Wystarczy wybrać bibliotekę TLS, która obsługuje platformy docelowe.

Dla mnie prawdziwym problemem związanym z TLS jest to, że nie można po prostu „włączyć”. Zamiast tego musisz zarządzać zestawem zaufanych certyfikatów, list odwołania certyfikatów, certyfikatów z podpisem własnym i tak dalej. Wszystko to wymaga dużej interakcji użytkownika.

Niestety bezpieczeństwo nigdy nie przychodzi za darmo. Jest to wysiłek dla programistów i niedogodności dla użytkowników.

Istnieje problem prawny. Niektóre kraje umieszczają kryptografię w tej samej grupie co broń. Umieszczenie kodu kryptograficznego w jądrze utrudnia następnie eksport dowolnego kodu jądra.

Istnieją oczywiste korzyści z wbudowania TCP w system operacyjny. TCP wymaga precyzyjnego pomiaru czasu i szybkiej reakcji na pakiety sieciowe, nawet jeśli nie są w to zaangażowane żadne dane aplikacji. Gdybyś próbował zaimplementować TCP w przestrzeni użytkownika na ogólnym interfejsie API IP, byłoby znacznie gorzej. Nie ma podobnych korzyści jak integracja SSL w jądrze.

Z drugiej strony istnieje kilka wad. Na przykład SSL wymaga manipulowania breloczkami i listami certyfikatów itp. Wykonanie tego przez jądro lub interfejs API systemu operacyjnego byłoby nieeleganckie. Więc nawet jeśli przyszedłby z systemem operacyjnym, byłby to po prostu biblioteka (tak jak w Windows). Te biblioteki i tak są już dostępne, więc ostatecznie jest to tylko zmiana opakowania.

Istnieje wiele powodów, ale chyba najbardziej przekonujące jest to, że kryptografia jest bardzo, bardzo trudne do rzeczywiście dostać prawo . Rozsądne jest wdrażanie go samodzielnie, chyba że można przeznaczyć znaczne zasoby na sprawdzenie, czy jest on poprawny i silny. Większość ludzi, którzy pracują z oprogramowaniem kryptograficznym, nie ma czasu, wiedzy ani chęci zagłębiania się w to; ufają bibliotekom stron trzecich, aby ich deweloperzy mogli poradzić sobie z tą częścią pracy, a twórcy aplikacji mogą wrócić do robienia tego, co chcą.

Programiści systemów operacyjnych nie różnią się tak bardzo. Czasami istnieje nadrzędny interes - na przykład twój model biznesowy lub prawnicy wymagają, aby kod był zamknięty - a więc nie masz dużego wyboru w tej sprawie: jeśli nie możesz znaleźć kogoś, kto ci na to pozwoli co musisz, to musisz rzucić własne. Inni wspominali już, jak to robi Microsoft. Ale ogólnie rzecz biorąc, programiści systemów operacyjnych, którzy mogą korzystać z bibliotek firm trzecich, wolą to robić w ten sam sposób, z tych samych powodów, co twórcy aplikacji.

Jestem programistą Windows, więc nie mogę mówić o innych systemach operacyjnych, ale w systemie Windows miały wbudowany protokół SSL od bardzo dawna. Nazywają go SChannel i chociaż jest obsługiwany, jest to jeden z bardziej tajemniczych interfejsów API, z których należałoby się kiedykolwiek dowiedzieć.

SSL to warstwa nad protokołem niższego poziomu. Na przykład protokół SSL działa na szczycie TCP (który jest na szczycie IP).

Gdzie kończy się system operacyjny?

Bardzo łatwo jest argumentować, że system operacyjny zapewnia podstawowe usługi, takie jak tworzenie sieci, aż do momentu, w którym klient systemu operacyjnego „robi rzeczy”. A te rzeczy mogą być czymkolwiek chcesz.

Jest mało prawdopodobne, że SSL w jądrze doprowadzi do znacznego wzrostu wydajności, więc po co się tym przejmować?

Współczesne jądra systemu operacyjnego obsługują miliony wierszy kodu, a dodanie ich tylko zwiększa złożoność i wydłuża czas debugowania. Pozostawienie rzeczy takich jak protokół wyższej warstwy poza systemem operacyjnym ułatwia tworzenie systemu operacyjnego i ostatecznie nie ma większego znaczenia dla funkcji lub wydajności aplikacji końcowej. (Może to sprawić, że praca programistów dla aplikacji końcowej będzie nieco bardziej bolesna).

Istnieje pewne wsparcie jądra dla Crypto i SSL. Ma to sens, ponieważ jądro może bardziej efektywnie łączyć się ze sprzętem, a także zapewnia ochronę poświadczeń przed dowolną aplikacją. Dobrym przykładem jest kssl, serwer proxy odwrotnego SSL na poziomie jądra w Solarisie lub różne biblioteki kryptograficzne w jądrze (używane na przykład dla VPN). Typowy przyspieszany sprzętowo silnik kryptograficzny ma również moduł jądra (i jest dostępny przez interfejsy kryptograficzne specyficzne dla PKCS # 11).

Niektóre powody, dla których nie widzisz tego częściej, to fakt, że niektóre protokoły aplikacji nie są odpowiednio warstwowe (pomyśl STARTLS) lub wymagają decyzji aplikacji podczas uzgadniania (pomyśl certyfikat klienta i sprawdzanie listy CRL) lub po prostu są w regularnej ewolucji.