Názory k článku
SSL divočina aneb jak se chovají „důvěryhodné“ CA

Není čas udělat nějaký skript, který by smazal skoro všechny certifikáty všech pochybných CA ze systému a všech aplikací, které si to tahají ssebou samy? Já nechci mít nějakou pochybnou kompromitovanou pouštní CA a stovky dalších předinstalovaných - mně stačí, když mi pojede gmail a to je tak vše...

Nevím, jestli by nějaká CA nakonec zbyla.

Pro výrobce browserů je celkem problém CA odstranit. CA musí udělat dost velkej průšvih. Jinak výrobci hrozí celkem drahý soudní spor.

Další "drobnost" se týká cross-certifikací (kde jedna CA podpíše certifikáty jiné CA): např. kdyby se vyhodil root certifikát Comodo, existují pořád cross-certifikace Comoda od Entrust, AddTrust a GTE.

Kompromitace CA je poměrně "běžná", CA jsou "vysokoprofilové" cíle. Podstatnější je, jak rychle je odhalena a jak se CA postaví k zveřejnění. Případ Comoda byl odhalen pouze náhodou - v zdrojácích Chrome a Firefoxu se záhadně objevil blacklist několika certifikátů.

Soudni spor za to, ze vyhodim ze sveho programu nejakou CA? Oh...

Jedná se jenom o zisk. Pokud rozšířený browser zruší důvěru v CA, pro CA to značí pokles zákazníků (DigiNotar zbankrotoval).

CA musí splňovat požadavky vlastního Certification Practice Statement (CPS). Dodržování CPS hlídá nezávislý audit. Nicméně CA si může do CPS napsat cokoliv (třeba že bude vydávat MitM certifikáty pro kohokoliv, kdo přijde s albino medvědem s heterochromií; i když tato CA by se nejspíš nedostala do trust store) a audit projde.

CA/Browser forum (www.cabforum.org) vydalo nové striktnější požadavky na certifikáty vydávané od CA, začnou platit od 1.7.2012. Jedním z požadavků je např. minimální velikost RSA modulu 1024 bitů, 2048 pokud "not after" v certifikátě je v roku 2014 nebo později.

A komu vadí pokles zisků dané CA v konkurenčním prostředí? Uživatelé budou nespokojeni, že jim v prohlížeči nefunguje "jejich" web, a třeba si prohlížeč vymění.

Myslel jsem skript, který by si pustil paranoidní našinec, výrobce browseru bych do toho vůbec nezatahoval. Prostě něco, co bychom dali do kupy třeba tady na Rootu.

...představte CA, kam přijde exekutor a zabaví HSM s podepisovacími klíči. Podobný případ se skutečně stal a pak už nezbyl skutečně nikdo se schopností vydat CRL...

No to je fakt pecka ;-) Radost si to jenom predstavit ;-)

Tenhle problém se nejčastěji vyskytuje, pokud server neposílá všechny certifikáty mezilehlých CA až po důvěryhodnou CA. V takovém případě se certifikát jeví někde jako důvěryhodný, jinde jako nedůvěryhodný v závislosti na tom, zda došlo k zavlečení certifikátů mezilehlých CA do systémového uložiště (např. navštívením jiného místa s certifikátem od stejného vydavatele), nebo ne.

Napadá mě, že by to mohlo souviset se změnou přístupu k důvěryhodným kořenovým certifikátům ve Windows 7/Vista.

Windows XP si nainstaluje všechny kořenové certifikáty CA, které MS považuje za důvěryhodné, během update Windows.

Windows 7/Vista si kořenové důvěryhodné certifikáty stáhne ze stránek MS až v okamžiku, kdy se poprvé použijí. Důležité je, aby podepsaný dokument (kód/...) obsahoval všechny potřebné certifikáty, které jsou nutné k ověření, včetně kořenového.

Netuším ale, jestli Firefox pro ověřování pravosti používá CryptoAPI od Microsoftu, nebo jestli používá pouze vlastní řešení (NSS).

k prohlizecum
* IE bere certifikaty vzdy z WINDOWS uloziste cert. (windows update)
* FF a ostatni maji svoje VLASTNI uloziste certifikatu (FF update)

zkousel jsem stranku z debianu 6 stable s FF (3.5.16) a ukazuje mi untrusted

problem bude v tom, ze Vam v FF apod chybi intermediate cert od starcomu (v IE uz se o to postaral windows update) - zde je ke stazeni http://www.startssl.com/certs/class1/sha1/der/sub.class1.server.sha1.ca.crt - po jeho importu do FF to bude fungovat

otazka jestli vubec certum od tehle "postizenejch" CA duverovat...

A ještě přesný postup řešení - výše odkazovaný mezilehlý certifikát přilep (pomocí utility cat) k souboru certifikátem (nikoli privátním klíčem) pro apache. A ještě pro jistotu přilep certifikát kořenové autority (pro případ W7).

Správné chování ověř pomocí

openssl s_client -connect www.fitness14.cz:443

teď to vypisuje:

Certificate chain
 0 s:/description=546967-qzoGLMILu7453B3H/CN=demo11.diskety.cz/emailAddress=bibapub@gmail.com
   i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA

Později to bude vypisovat navíc toto:

1 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
  i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
2 s:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
  i:/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority

Ještě teď jsem si všiml, že používáš SNI a toto není výchozí virtualhost pro danou IP/port. Takže je potřeba přidat za openssl přepínač -servername www.fitness14.cz. Jinak dostanu certifikát pro demo11.diskety.cz :)

Protože používáte SNI, nebude certifikát důvěryhodný na platformách, kde SNI nefunguje, tj. WinXP + IE, Konqueror a dále spousta mobilů. Viz článek Petra Krčmáře z listopadu.

Navíc jak koukám, na diskety.cz je jen nějaké administrační rozhraní... V tom případě bude asi lepší přehodit pořadí virtualhostů v apache, aby na prvním místě bylo fitness24.

Problem je v tom, ze tam mas v ceste intermediate sub CA.

Postup ako na to je napr. tu:

http://kb.wisc.edu/page.php?id=18923

Problem je v tom, ze tam mas v ceste este intermediate sub CA.

Postup ako na to je napr. tu:

http://www.digicert.com/ssl-certificate-installation-apache.htm