Vlákno názorů k článku
Turktrust subCA vydala falešné certifikáty k *.google.com, *.android.com a dalším
od mc - "...Chrome má předdefinovány klíče CA, kterými můžou být...
-
mc (neregistrovaný)
"...Chrome má předdefinovány klíče CA, kterými můžou být Google služby podepisovány..."
Mohl by mi někdo vysvětlit, proč už dávno nemají všechny prohlížeče možnost, aby si mohl uživatel definoval u vybraných domén jakými CA mohou být podepisovány. Respektive i naopak definovat u CA, které domény mohou být nimi podepsány. Velmi bych to přivítal jak u vlastních domén (které si podepisujeme sami) tak u bankovnictví (kde je pro mne důvěra také důležitá).
Případy, kdy se nějaká CA sekne, či ji přesvědčí nějaká vláda nepochybně budou přibývat.
U některých domén prostě vím, že je může podepsat jen konkrétní CA a pokud jsou podepsány jinou CA tak chci důrazné varování. Na druhé straně k některým CA nemám globální důvěru, ale jen důvěru pro nějaké domény.
-
Filip JirsákStříbrný podporovatelŘeší se to https://os3sec.org/technicalbackground.html - ale samozřejmě bude nějakou dobu trvat, než to bude implementované v prohlížečích, než do bude mít dost domén v DNS...
-
Filip JirsákStříbrný podporovatel
Omlouvám se. Hledal jsem to nejdřív u CZ.NICu, protože jsem si pamatoval, že nějaký takový plugin od vás byl. Ale na stránce DNSSEC Validátoru jsem našel jen kontrolu DNSSEC, takže jsme pokračoval Googlem – nenapadlo mne, že jsou ty pluginy dva. Tímto tedy doporučuji přidat na stránku o DNSSEC Validátoru nějakou reklamní vsuvku, že nabízíte i další plugin Dane Patrol, který umí kontrolovat HTTPS certifikáty. Já si to nějakou dobu pamatovat budu, ale někdo další může bloudit podobně, jako já :-)
-
Franta <xkucf03/> (neregistrovaný)
Zkus rozšíření CertificatePatrol – pokud se změní CA dané domény (kterou jsi dříve navštívil), dostaneš důrazné varování a zeptá se tě to, jestli si má novou CA pamatovat.
CA můžou mít omezenou působnost (domény, subdomény), ale hodilo by se, aby si takové omezení mohl přidat každý uživatel podle svého – to by se hodilo a napsat takové rozšíření není problém.
-
HisSinIsPride (neregistrovaný)
Shameless self-promo:
Napsal jsem fork Certificate Patrol, který jednak umí ukládat vícero certifikátů na doménu, což řeší mnoho problémů s CDN službama á la Google, a druhak umí o protokol více :-)
Viz: https://labs.nic.cz/page/1207/dane-patrol/ (DANE is optional)
BTW: root.cz, WTF is (still) wrong with your spam filter?
-
HisSinIsPride (neregistrovaný)
Bohuzel neimportuje zaznamy z CertPatrol DB. Schema DB je jina a DB je v jinem souboru. Nejspis existuje zpusob jak ten import nejak +/- rozumne udelat, ale i samotny CertPatrol ma v sobe dost kodu, ktery dela jen to, ze se diva, jestli neni DB schema z nejake stare verze a pak to preklapi.
-
Hmm, zajímavé, že mi to na SSL stránkách ještě nehodilo hlášku o novém certifikátu a neuložilo žádný certifikát.
Ale za to zobrazilo chyby jako třeba:
Timestamp: 01/05/2013 05:12:43 PM
Error: TypeError: this.plugin(...).checkDANE is not a function
Source File: chrome://danepatrol/content/DanePatrol.js
Line: 431(Zřejmě při jakémkoli neplatném cerfitikátu, např. https://invalid.v6ak.com/ )
-
HisSinIsPride (neregistrovaný)
> Error: TypeError: this.plugin(...).checkDANE is not a function
Hm, to vypada, ze se nenaloadoval nebo nekorektne inicializoval TLSAfetcher NPAPI plugin. Muzes to vyzkouset na cistem profilu Firefoxu? Spustenim 'firefox -no-remote -P', udelat novy profil, nainstalovat DANE Patrol a podivat se, jestli je 'DANE TLSAfetcher' plugin v seznamu pluginu: Tools->Addons neboli Ctrl+Shift+A, je to zalozka 'Plugins' nalevo. FF addony totiz sdili jmenny prostor a velmi casto si "lezou navzajem do zeli" via ruzne callbacky.
Vim treba, ze NoScript nebo nova funkce FF 'click_to_play' muze plugin zakazat, proto selze volani - jenze plugin nema zadnou viditelnou cast, na kterou by slo kliknout, tudiz bude zakazan navzdy, pokud je 'click_to_play' zapnuto.
Taky by pomohlo vedet verzi OS, architekturu (i686/x86_64), verzi FF.
Vypnutim kontroly DANE by to melo fungovat - v seznamu addonu je pri DANE Patrol button 'Preferences'. Zacne to fungovat, pokud se DANE vypne? Je to option 'Never check DANE TLSA records'.
Jednou mi uz nekdo hlasil, ze na Fedora 18 mu to nefungovalo, ale bug report byl na 2 veci a ani na live Fedora 18, ani nainstalovane Fedore 18 se mi to nepodarilo reprodukovat.
FF API pro addony je celkem silena vec, v lepsim pripade dokumentace +/- odpovida nebo chybi, v horsim je zavadejici a je nutno divat se rovnou do zdrojaku FF nebo NSS.
-
Mám Ubuntu LTS (12.04) x86_64, FF 17.0.1. Zákaz DANE pomohl.
Ať tu neplevelíme ve komentářích, přesunul bych debatu jinam. Bug tracker ani kontakt jsem nenašel, dávám sem tedy svůj kontakt: https://contact.v6ak.com/
-
HisSinIsPride (neregistrovaný)
Tak jsem zkusil https://invalid.v6ak.com/, certifikat se ulozi az po odkliknuti warningu a pridani (docasne) vyjimky - to je umyslna dizajnova vlastnost. Ta "invalid certificate" stranka se da obejit (override), pokud ma web v DNS TLSA zaznam "certificate usage" 2 nebo 3 a je to povoleno v preferencich DANE Patrol. Viz https://tools.ietf.org/html/rfc6698#section-2.1.1 pro detailni vysvetleni "certificate usage".
Priklad override pres certificate usage 3 by mel fungovat treba zde: https://dane.rd.nic.fr/
Zaznam TLSA pro dane.rd.nic.fr vypada takhle (trocha jsem zkratil vypis dig-u):
dig +dnssec -t type52 _443._tcp.dane.rd.nic.fr;; ANSWER SECTION:
_443._tcp.dane.rd.nic.fr. 1 IN TYPE52 \# 35 030001E781577C0EABB6701A0CAF287E48CEEBD3BA64B81792EF4970 5F0F5E1070331B
_443._tcp.dane.rd.nic.fr. 1 IN RRSIG TYPE52 5 6 1 20130525134037 20121126134037 47001 dane.rd.nic.fr. nwMq1WIb5fU9OS2HCDFCyZlfQ+E862I2FiFfwYHzw5AXGkepkXejdOI1 01GTgo9C6822v4PhewLUnMzTttPp/v6cEPRIBxZA2Fqum4Zc95mDeF4f nvA1yYWLoTmXvfVcHUWbOeCnT71Eea1KaQt6Xp9qTZdv1pjd8PUg3uD8 4TU=
-
> Mohl by mi někdo vysvětlit, proč už dávno nemají všechny prohlížeče možnost, aby si mohl uživatel definoval u vybraných domén jakými CA mohou být podepisovány.
Jmenuje se to technicky "certificate pinning" neboli "key pinning" neboli "SPKI pinning". Chrome to implementoval jako statický seznam, který trpí stejným problémem jehož důsledkem bylo vytvoření DNS (prostě od určitého množství domén je to neškálovatelné).
> Mohl by mi někdo vysvětlit, proč už dávno nemají všechny prohlížeče možnost, aby si mohl uživatel definoval u vybraných domén jakými CA mohou být podepisovány. Respektive i naopak definovat u CA, které domény mohou být nimi podepsány.
Já to sám neumím a to jsem napsal parser X.509 certifikátů, našel porovnávaním bugy v openssl, gnutls a NSS a analyzoval pár let >= 2M certifikátů (alias částečné řešení téhle instance halting problému; mám exploit, zatím absolutně nepraktický, ale útoky se jenom zlepšují, nikdy nezhoršují). Paradigma je, že nejlépe to ví operátor domény (ne moc překvapivé).
> Případy, kdy se nějaká CA sekne, či ji přesvědčí nějaká vláda nepochybně budou přibývat.
Ano. Zatím jsou dvě řešení, které vypadají alespoň trocha slibně - DANE a Certificate Transparency. DANE je již standardizováno (RFC 6698), Certificate Transparency se nedávno dostalo do IETF experimental track. Je za tím Ben Laurie z Google a AD sponsor je Stephen Farrel (moc chytrý člověk). Nicméně Google bude muset přesvědčit CA, aby jim dávali informace o vydávaných certifikátech. CA to nemají moc rády (opět nepřekvapivě), ale Google má dostatečne silnou pozici, aby jich k tomu "strongarm"-ovalo nebo "blackmail"-ovalo. Hodně mně zajímá, jak to dopadne (zatím flamewarmi kolem toho tančí v therightkey IETF WG).
-
Když jsme u toho, tak bychom do toho chtěli letos šlápnout a do těch prohlížečů napsat patche pro DANE a pak tlačit, tlačit a tlačit. Pokud si někdo myslíte, že by se vám taková práce líbila a máte na to potřebné znalosti (buď s psaním pro Firefox nebo s TLS/X.509/DANE)... tak email na mne je dostatečně známý...
