Niezaufanie pośredniego urzędu certyfikacji w systemie Linux?


18

Z tego bloga .

Pośrednie urzędy certyfikacji to certyfikaty podpisane przez główny urząd certyfikacji, które mogą podpisywać dowolne certyfikaty dla dowolnych witryn internetowych.

Są tak samo potężne jak główne urzędy certyfikacji, ale nie ma pełnej listy tych, którym ufa system, ponieważ główne urzędy certyfikacji mogą tworzyć dowolne nowe, a system będzie im ufał od pierwszego wejrzenia. TYSIĄCE zalogowane w CT.

W tym miesiącu pojawiła się interesująca, wygenerowana prawdopodobnie we wrześniu 2015 r .: „Blue Coat Public Services Intermediate CA”, podpisana przez firmę Symantec. (Jak dotąd żadne certyfikaty podpisane przez ten urząd certyfikacji nie dotarły do ​​dzienników CT ani Censys.)

Pomyślałem, że to dobra okazja, aby napisać, jak jawnie nie ufać pośredniemu urzędowi certyfikacji, który w innym przypadku byłby zaufany w OS X. Nie powstrzyma to głównego urzędu certyfikacji przed przekazaniem nowego pośrednika tej samej organizacji, ale lepiej niż nic.

Kiedy próbowałem wykonać kroki w blogu w Ubuntu, pobieram ten certyfikat https://crt.sh/?id=19538258 . Kiedy otwieram .crt, importuje się do Gnome Keyring, ale potem nie mogłem znaleźć sposobu, aby „zaufać” certyfikatowi po jego zaimportowaniu.

Odpowiedzi:


8

Aby utrudnić, Linux ma więcej niż jedną bibliotekę do pracy z certyfikatami.

Jeśli używasz Mozilli NSS, można aktywnie Nieufność (terminologia) zaświadczenie stosując Certutil „s -t trustargsopcję:

$ certutil -d <path to directory containing database> -M -t p -n "Blue Coat Public Services Intermediate CA"

Dla Firefoksa, <path to directory containing database>to zwykle ~/.mozilla/firefox/<???>.profile, gdzie <???>są pewne losowe szukający znaków. (certutil znajduje się np. w pakiecie libnss3-tools Ubuntu)

Podział jest następujący:

-M zmodyfikować bazę danych

-t p ustawić zaufanie na Zabronione

-n do przeprowadzenia operacji na wymienionym certyfikacie

Nawet w ramach NSS nie wszystkie aplikacje współużytkują tę samą bazę danych; więc może być konieczne powtórzenie tego procesu. Na przykład, aby zrobić to samo dla Chrome, zmienić -d <path>się -d sql:.pki/nssdb/.

$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"

Jednak nie wszystkie aplikacje używają NSS, więc nie jest to kompletne rozwiązanie. Na przykład nie sądzę, że można to zrobić za pomocą biblioteki OpenSSL.

W rezultacie każda aplikacja korzystająca z OpenSSL w celu zapewnienia budowania łańcucha certyfikatów (TLS, IPSec itp.) Ufa łańcuchowi z certyfikatem Blue Coat i nic nie można na to poradzić poza usunięciem głównego urzędu certyfikacji, który go podpisał Twój sklep z kotwicami zaufania (co byłoby głupie, biorąc pod uwagę, że jest to główny urząd certyfikacji firmy Symantec, ponieważ nie ufasz połowie Internetu), podczas gdy aplikacje korzystające z NSS można skonfigurować bardziej szczegółowo, aby nie ufały sieciom z certyfikatem Blue Coat .

Na przykład uważam, że OpenVPN używa OpenSSL jako biblioteki certyfikatów, dlatego starszy brat może nasłuchiwać ruchu OpenVPN bez Twojej wiedzy, jeśli łączysz się z komercyjnym dostawcą VPN, który korzysta z OpenVPN. Jeśli naprawdę się tym martwisz, sprawdź, kim jest główny urząd certyfikacji twojego komercyjnego dostawcy VPN - jeśli jest to Symantec / Verisign, to może czas porzucić je dla kogoś innego?

Pamiętaj, że SSH nie używa certyfikatów X509, dlatego możesz łączyć się i tunelować za pomocą SSH, nie martwiąc się atakami MITM firmy Blue Coat.


Zaktualizowałem pytanie, aby wskazać, że po dwukrotnym kliknięciu certyfikatu zostało ono zaimportowane do breloka gnome. Udało mi się znaleźć sposób na zaimportowanie go do Firefoksa w odpowiedzi poniżej.
raphael

Czy dla OpenSSL usunięcie certyfikatu nie byłoby tym samym, co nieufanie? Może sprawdzać tylko te certyfikaty, o których wie.
Bratchley

1
@Bratchley - Co jeśli podejrzany certyfikat został wysłany (tak jak powinien) w ramach uzgadniania TLS? Byłoby to po prostu zaufane, chyba że istnieje sposób (jak w przypadku Mozilla NSS, Windows i OS-X), aby twierdzić , że zawsze jest to niezaufane.
garethTheRed

@garethTheRed Być może coś mi brakuje, ale jeśli biblioteka wymaga sprawdzenia certyfikatu, to nie zrobiłby listy CRL ani nie usunął zaufanego głównego urzędu certyfikacji. Niezależnie od tego, czy jest to certyfikat klienta, czy serwer, nadal powinien wymagać weryfikacji.
Bratchley,

1
Tak. Bluecoat otrzymał certyfikat CA od Verisign do użytku w urządzeniach typu man-in-the-middle. OP pyta, jak nie ufać temu certyfikatowi. Chodzi więc o nieufanie do podrzędnego certyfikatu, którego przełożony wydający urząd certyfikacji (w tym przypadku root) nie odwoła, gdy, jak mówisz, nie chcesz cofnąć zaufania rootowi (Verisign).
garethTheRed

0

Nie mogę jeszcze komentować, więc będę musiał skomentować tutaj, że na Ubuntu Gnome 15.10, kiedy używam podejścia @ garethTheRed, otrzymuję:

~$ certutil -d ~/.mozilla/firefox/<directory>.default -M -t p -n "Blue Coat Public Services Intermediate CA" 
certutil: could not find certificate named "Blue Coat Public Services Intermediate CA": SEC_ERROR_BAD_DATABASE: security library: bad database.

~$ certutil -d sql:.pki/nssdb/ -M -t p -n "Blue Coat Public Services Intermediate CA"
certutil: could not find certificate named "Blue Coat Public Services Intermediate CA": SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.

„Blue Coat Systems, Inc.” też nie działa.

(Jest to certyfikat, który zaimportowałem: https://crt.sh/?id=19538258 )


Czy najpierw pobrałeś i zaimportowałeś certyfikat?
raphael

Tak, zaimportowałem ten: crt.sh/?id=19538258 . (Wygląda na to, że mogę teraz skomentować! :)
Diagon

Myślę, że możesz skomentować tylko własną odpowiedź. Nie próbowałem jeszcze tej procedury.
raphael

patrz moja odpowiedź poniżej
raphael

@ raphael - Próbowałem edytować poniżej, informując, że: Chociaż powyższy link opisuje „-t p” jako „zabronione (jawnie nieufne)”, strona podręcznika systemowego Ubuntu 15.10 opisuje go jako „p - Ważny peer”. Mam nadzieję, że nie zrobiłeś źle.
Przekątna
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.