Недовірливий проміжний CA в Linux?

З цього блогу .

Проміжні CA - це сертифікати, підписані кореневим CA, які можуть підписувати довільні сертифікати для будь-яких веб-сайтів.

Вони настільки ж потужні, як і кореневі ЦС, але не існує повного переліку тих, яким система довіряє, оскільки кореневі ЦО можуть створювати нові за бажанням, і ваша система буде довіряти їм з першого погляду. Є тисячі, зареєстровані в КТ.

Цього місяця з’явився цікавий, який, очевидно, у вересні 2015 року: «Blue Coat Public Services Intermediate CA», підписаний Symantec. (Жодні сертифікати, підписані цим ЦА, поки не дійшли до журналів CT або Censys.)

Я подумав, що це буде гарним приводом написати, як явно не довіряти проміжному ЦС, якому інакше довірятимуть OS X. Це не перешкодить кореневому ЦА передавати новий проміжний продукт тій же організації, але краще, ніж нічого.

Коли я спробував кроки в блозі в Ubuntu, я завантажую цей сертифікат https://crt.sh/?id=19538258 . Коли я відкриваю .crt, він імпортує в Gnome Keyring, але тоді я не зміг знайти спосіб "не довірити" сертифікат після імпорту.

Просто для того, щоб зробити це важким, Linux має більше однієї бібліотеки для роботи з сертифікатами.

Якщо ви використовуєте Mozilla NSS, ви можете активно Недовіра (їх термінологія) довідка з використанням CertUtil «s -t trustargsваріанти:

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

Для Firefox, <path to directory containing database>як правило, ~/.mozilla/firefox/<???>.profileде <???>знаходяться кілька випадкових персонажів. (certutil, наприклад, у пакеті інструментів libuns3-ubuntu)

Розбивка така:

-M для зміни бази даних

-t p встановити довіру забороненим

-n провести операцію за названим сертифікатом

Навіть у межах NSS не всі програми мають однакову базу даних; тому, можливо, доведеться повторити цей процес. Наприклад, щоб зробити те ж саме для Chrome, змініть -d <path>на -d sql:.pki/nssdb/.

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

Однак не всі програми використовують NSS, тому це не повне рішення. Наприклад, я не вірю, що це можливо зробити з бібліотекою OpenSSL.

Як наслідок, будь-яка програма, яка використовує OpenSSL, щоб забезпечити її створення ланцюгів сертифікатів (TLS, IPSec тощо), довірила б ланцюжку з сертифікатом Blue Coat, і нічого не можна зробити для цього, крім видалення Root CA, який його підписав ваш довірений магазин прив'язки (що було б нерозумно, вважаючи, що це Symantec Root CA, оскільки ви, нарешті, не довіряєте половині Інтернету), тоді як програми, які покладаються на NSS, можуть бути налаштовані більш детально, щоб довіряти будь-якій мережі, що має сертифікат Blue Coat в ній .

Наприклад, я вважаю, що OpenVPN використовує OpenSSL як бібліотеку для сертифікатів, тому старший брат може слухати ваш трафік OpenVPN без вашого відома, якщо ви підключаєтесь до комерційного постачальника VPN, який використовує OpenVPN. Якщо ви насправді переймаєтесь цим, тоді перевірте, хто такий корінний центр вашого комерційного постачальника VPN - якщо це Symantec / Verisign, то, можливо, настав час виривати їх за когось іншого?

Зауважте, що SSH не використовує сертифікати X509, тому ви можете підключати та тунелювати за допомогою SSH, не турбуючись про атаки Blue Coat MITM.

Я поки не можу коментувати, тому мені доведеться тут коментувати, що в Ubuntu Gnome 15.10, коли я використовую підхід @ garethTheRed, я отримую:

~$ 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." теж не працює.

(Це імпорт, який я імпортував: https://crt.sh/?id=19538258 )