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

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ů.

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.

Moc se v tématice v článku nevyznám (prakticky vůbec) ale chtěl bych se zeptat, možná dát podmět autorovi článku.

Nemění se podpora certifikátů u prohlížečů v čase?
Zdá se mi, že certifikát který dříve šel všude (všechny prohlížeče/os) již v nových verzích Firefoxu (na a to jen Windows Wista a lepších, XP stále jde) se označuje jako nedůvěryhodný.

Pokud se mění, lze napsat článek o tom jak a případně zahrnout informaci co navíc máme od certifikačních autorit dožadovat?
(více informací, včetně skutečné ukázky dodám případně emailem)

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.

Skutečně nevím, čím to je a jako začátečník netuším jak toto řešit. Prostě jsem v Apache ty klíče nahrál a o více se nestaral ;o)

Pokud se chcete podívat, nebo mi nevěříte, nebo Vás to jen zajímá tak adresa je: https://www.fitness14.cz/ - jak říkám, na kombinaci firefox+vista(w7) to bude hlásit nedůvěryhodný certifikát, přitom ostatní prohlížece (opera, chrome a IE) na stejném systému v pohodě, v ubuntu a debianu vše ok a to i se stejnou verzi Firefoxu.

_{(Každopádně platí, že najít dneska certifikační autoritu která umí všechny prohlížeče a není předražená, nebo zdarma, je téměř nemožné.)}

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

V řetězci, který zasílá server, chybí intermediate ("mezilehlý") certifikát pro "StartCom Class 1 Primary Intermediate Server CA". Ten by měl být v řetězci posílán za certifikátem serveru.

Důvod, proč na některých prohlížečích funguje a na jiných ne, je lokální cache intermediate certifikátů.

Malá demonstrace:

1. spustíme Firefox s novým čistým profilem: firefox -P -no-remote
2. naklikáme nový profil
3. jdeme na https://www.fitness14.cz/
4. FF zahlásí "The certificate is not trusted because no issuer chain was provided."
5. Jdeme na https://msw.companycrypt.com (nějaký náhodný web používající stejnou CA a stejný řetězec intermediate certifikátů)
6. vrátíme se na https://www.fitness14.cz/ a ověření certifikátu projde, protože FF mezitím nacachoval ten intermediate certifikát

Na vývojáře browserů je tlak, aby chyby v řetězci potichu "opravili", pokud je to možné. Výsledek je, že administrátoři pak neví, že mají něco špatně na straně serveru.

Různé triky při budování řetězce dělá každý známější TLS klient. Výsledek je, že dva browsery můžou vidět různé řetezce.