Názory k článku Věříte opravdu jen důvěryhodným certifikačním autoritám?

Pro Operu je to popsane v clanku.

Pro Firefox: Z menu Edit (ve windows je to pod Tools)-Preferences-tab Advanced-View Certificates zobrazi seznam certifikatu. Zajimave jsou ty, ktere jsou oznaceny jako ‚Builtin Object Token‘, to jsou defaultne predinstalovane certifikaty. Neni nutne je mazat, certifikat lze „zneduveryhodnit“ tlacidlem Edit a odznacit vsechny checkboxy v dialogu (duvera v identifikaci web serveru, mail uzivatelu a vyrobcu software).

Windows: lze se k nemu preklikat pres Internet Options, nebo rychleji prikazem „certmgr.msc“ v konzoli. Zrovna ted jsem nasel clanek, ze nelze jednoduse odstranit nebo oznacit jako neduveryhodne predinstalovane certifikaty, ale nemel jsem to moznost overit – http://www.proper.com/root-cert-problem/ .

Android: stahnout certifikate s Android SDK pres adb pull /system/etc/security/cacerts.bks . Manipulace se dela s javovym keytool nastrojem, pro ulozeni se pouzije adb push, push funguje jenom na rootnutem telefonu (vyzaduje root prava). Priklad extrakce certifikatu pres keytool:

keytool -list -keystore cacerts.bks -storetype BKS \
    -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
    -providerpath bcprov-jdk16-141.jar -storepass changeit > cert_list
#v nasledovnich dvou prikazech ve for cyklu doplnit pocet certifikatu, jak to zobrazil
#predchozi prikaz ve vyslednim souboru cert_list
for I in {0..53}; do \
    keytool -export -keystore cacerts.bks -storetype BKS \
        -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
        -providerpath bcprov-jdk16-141.jar -storepass changeit \
        -file $I.cer -alias $I; \
done
for I in {0..53}; do \
    echo $I; openssl x509 -in $I.cer -noout -text -inform DER | grep 'Subject';\
done
#Smazani konkretniho certifikatu pres keystore -delete, certifikat ke
#smazani se urcuje pres -alias, cislo aliasu viz vystup predchoziho prikazu
keytool -delete -keystore cacerts.bks -storetype BKS \
        -provider org.bouncycastle.jce.provider.BouncyCastleProvider \
        -providerpath bcprov-jdk16-141.jar -storepass changeit -alias 13

KDE 4 (pro Konqueror, Kopete atd): klikaci podpora zatim neni dokoncena, je nutne to udelat rucne (https://bugs.kde.org/show_bug.cgi?id=162485)

Jine systemy: v navode pro import cacert.org CA (http://wiki.cacert.org/ImportRootCert) lze vysledovat nastroje, ktere se pro ten-ktery system pouzivaji, mely by umet certifikat i odstranit. Navic kazda aplikace muze pouzivat vlastni certstore nebo muze pouzivat systemovy (napr. Firefox a Opera i pod windows pouzivaji vlastni certstore misto systemoveho).

Update k windows (vyzkouseno na XP SP3): smazat certifikat z Trusted Root Certificate Authorities-Certificates skutencne nelze, objevi se za chvili zpatky. Nicmene lze certifikatu odebrat duveru. Postup:

1. Spustit „certmgr.msc“ via Start-Run
2. V levem framu rozkliknout v strome Trusted Root Certificate Authorities-Certificates
3. Najit certifikat, ktery chceme zmenit v pravo (napr. GTE CyberTrust Global Root), pravy klik a Properties
4. Pod „Certificate purposes“ vybrat radio button „Disable all purposes for this certificate“
5. V aplikacich, ktere tento keystore pouzivaji (jako Internet Explorer), bude tento certifikat neduveryhodny
6. lze to overit napr. na https://customercenter.verizonbusiness.com/ (Verizon vlastni GTE CyberTrust Global Root)

%PROGRAMFILES%\Mozilla Firefox\nss\certutil.exe
Ale certstore u Firefoxu je v uživatelském profilu, takže je třeba udělat zásah u každého uživatele zvlášť, nejlíp pomocí logon skriptu. Nenašel jsem možnost, jak změnit „systémový“ seznam CA pro Firefox. Možná ani takový není, a ty výchozí se nakopírují do profilu při jeho vytvoření. Nevím, proč FF nevyužívá na Windows systémové úložiště, které je řešené poměrně dobře.
Jinak je dobře, že takový článek vyšel. Sice je popsaný problém známý už dlouho, ale pořád se bezpečnost současné implementace SSL důvěryhodných autorit přeceňuje. Jestliže nějaký ISP může udělat MITM útok, který je pro většinu lidí nedetekovatelný, bezpečné to není.
Věřím v tomto směru v budoucnost technologie DNSSEC, kdy momentálně probíhají diskuse o možnostech využití právě pro ukládání informací o SSL certifikátech.
Pokud bude existovat standard, jak pomocí záznamu v DNS pro danou doménu např. zakázat všechny implicitně důvěryhodné certifikáty a povolit jen určitou CA, nebo do DNS rovnou dát CA certifikát, je šance, že prohlížeče to začnou během několika nových verzí podporovat. Na straně správců serverů by to také nemusel být problém – pro klienty bez podpory toho standardu by se nic nezměnilo.

Odstraneni pro vsechny uzivatele z Firefoxu vyzaduje rebuild Firefoxu, presneji jeho soucasti NSS, certifikaty jsou zadratovany natvrdo v libsoftokn3.so, resp. softokn3.dll. Zavisi od balickovaciho systemu, jestli je tento soubor primo soucasti Firefoxu nebo nss/libnss (windows verze bude obsahovat softokn3.dll nejspis primo v instalatoru FF).

V uzivatelskem profilu se nachazi soubor cert8.db, v nastaveni ktereho lze „overridnout“ nastaveni duvery CA v NSS. Soucasti NSS je nastroj certutil, kterym lze manipulovat s timhle souborem, napr. certutil -d adresar_kde_je_cert8.db_soubor -L vylistuje uzivatelske nastaveni CA.

V NSS se nachazi predinstalovane certifikaty v tomhle souboru:
nss-3.12.6/mozilla/security/nss/lib/ckfw/builtins/certdata.txt

Ahoj,
rad bych pridal do diskuze pohled z druhe strany.


Zatim jsme se bavili ze nejaka Intermediate CA muze delat neplechu.
Ono to muze zafungovat i obracene – pokud mate Intermediate CA podepsanou nejakou verejnou „trusted“ CA muze vam to zpusobit stejne problemy.


Vyhazeni neduveryhodnych CA na klientovi vubec nemusi pomoci.


1) Rekneme ze banka ABC je tak velka ze se rozhodne si udelat vlastni certifikacni autoritu.


2) Protoze „zakaznik nas pan“ – rozhodne se svoji certifikacni autoritu podepsat nejakou znamou certifikacni autoritou – rekneme Verisign.
Hlavni vidinou je moznost podepsat si z pohledu zakaznika „duveryhodnym“ certifikatem webove stranky jako www.bankabc.com


3) Udela si SSL certifikat – napriklad pro infrastrukturni LDAPS server ldap.bankabc.com


4) Nakonfiguruje klienta aby veril prislusnemu retezci (chain) certifikacnich autorit.
Verisign ROOT CA + Banka ABC CA


5) Prijde hacker Franta a vygeneruje si certifikat pro stejny LDAPS server ldap.bankabc.com primo od Verisign
- LDAP klientovi bude stacit ze certifikat konci duveryhodnym podpisem od Verisign a nerekne ani popel


6) Prijde hacker Pepa, zaplati o neco vic a dostane od Verisign certifikat pro vlastni certifikacni autoritu – pak uz si bez kontroly Verisign muze (jak je popsano v clanku) vydat jakykoli certifikat tedy i certifikat pro ldap.bankabc.com
- LDAPS server bude poskytovat cely certificate chain
- LDAP klientovi bude stacit ze certifikat konci duveryhodnym podpisem od Verisign a nerekne ani popel


Zaver:
- pokud uz si chci delat vlastni CA, stoji za zvazeni jestli pro me ucely neni vhodnejsi pouzit pro root moji CA radeji self-signed certificate nez certificate podepsany nejakou jinou „trusted“ stranou.


Zdroj:
- http://files.cloudprivacy.net/ssl-mitm.pdf

Nesmysly? Mozna. A mozna ze ne.
ad 2) … nepochopil jste zadani – banka si poridi opravdu vlastni CA, tedy certifikat od XXXXsignu samozrejme bude mit CA flag.
Ze to stoji $$$ banku nestve – za love dostava falesny pocit bezpeci pro sebe a sve klienty. Bavime se o rozhodnuti jestli banka bude mit svuj vlastni CA root self signed nebo podepsany od nejake renomovane autority.
ad 6) Pepa je uspesny hacker a muze zaplatit $$$ aby vydelal $,$$$,$$$.
Viz napriklad
http://www.wired.com/threatlevel/2010/03/packet-forensics/
http://www.packetforensics.com/products.safe

Vsechno zavisi od threat modelu. Dostatecne bohaty/vlivny utocnik (vlada US) umi 5) i 6), pro nekoho jineho je velmi obtizny triknout Verisign aby podepsal neco co nema.

Kdyby banka udelala vlastni CA (bez podpisu CA s predinstalovanym certifikatem), nauci svoje klienty akorat tak klikat OK na warningy, tudiz to ma utocnik mnohem jednodussi.

BTW banky maji nejlepsi zkusenosti v risk assessment – tady nejde o to, aby system byl neproniknutelny, ale aby ztraty nebyly vyssi nez cena pro dodatecne zabezpeceni.

Banky do IT nevidi. Jejich uroven zabezpeceni je obvykle dost tragicka a to mam 25 let praxe v IT. Podivejte se kolik bank v CR mate s EV certifikatem. Management ani pravdepodobne nevi co to je.
Banka resi vsechno pomoci penez, protoze si penize muze vytvaret z niceho a logika jejiho managementu je cim drazsi tim kvalitnejsi a risky presunout na pojistovnu. Kdyz mame pak spatne PR no tak si koupime lepsi.
Jediny co banky dobre chrani jsou mainframy protoze ty jsou tak obskurni system ze si na nich utocnik vylame zuby pokud nenin mainframe expert a ti nehackuji banky pres net. Neznam pripad ze by nekdo procrackoval mainframe.
Armada, FBI, CIA, vlada ty zabezpeceni maji dost dobry. Ale banky? To je tragedie. Banka jenom vytvari zdani bezpecnosti. Ono to staci protoze lidi vi o bezpecnosti taky kulovy.
Zejmena ale nemam rad FRS banking protoze je to bezesporu nejuspesnejsi podvod v dejinach lidstva.

Banky do IT nevidi. […] Banka resi vsechno pomoci penez

Ale to je presne ono – banka nebude zavadet zadne dalsi opatreni, pokud ji to bude stat vic nez ztraty pres podvody. Existuji spousty ATM (v US), ktere jsou napadnutelne insiderem, ale bankam se to nevyplati menit (zatim).

EV certifikaty jsou jenom „naplast“.

Nedokáže náhodou nějaká vláda přesvědčit třeba i zmiňovaný Verisign, aby jí vytvořil certifikát „na míru“? 

Ano, dokaze. Zavisi od threat modelu, nejvetsi problem mate, kdyz vase data chce US (ponevadz tam je nejvic „zavedenych“ CA).

Certificate Patrol (ktery byl zminen i v clanku) to resi, pokud odposlouchavani je technicky reseno zmenou certifikatu (a CertPatrol ma ulozen puvodni certifikat).