it-swarm-eu.dev

Thawte / GeoTrust / VeriSign 2048 Bit Root migrace a zprostředkující SSL certifikáty

Thawte, GeoTrust, VeriSign a další certifikační autority jsou v současné době v procesu přechodu z 1024 bitového kořenového certifikátu MD5 na kořenový systém založený na 2048 bit SHA-1 na „ držet se v souladu s osvědčené postupy v obor ". Kromě toho budou všechny certifikáty nyní vyžadovat Zprostředkovatelské certifikační autority , což vytvoří certifikát Chained Root namísto jednotlivých kořenových certifikátů, které byly dříve vydány preferovanými poskytovateli. Po nedávném absolvování této aktualizace na jednom z našich webů si nyní uvědomuji, že plně nerozumím tomu, jak SSL funguje a že potřebuji určitá vysvětlení.

Otázka 1: Jak se liší 1024 bitový root od 2048 bitového root? Rozumím přechodu z MD5 na SHA1, protože se ukázalo, že MD5 je zranitelný vůči kolize, ale moje otázka je, jakou výhodu dává 2048 bitový root nad 1024 bitovým rootem? Zvyšuje sílu šifrování SSL mezi klientem a serverem nebo pouze ztěžuje kompromitování kořenového certifikátu?

Otázka 2: Jak fungují střednědobé certifikáty a jaké výhody/nevýhody mají? Po aktualizaci našeho webu všechno fungovalo dobře, kromě případů, kdy byl web přístupný starší prohlížeč (konkrétně Windows Mobile). Byl jsem trochu zmatený, protože Thawte SSL123 2048bitový testovací server fungoval dobře na zařízení, kde náš web vyzval varovnou zprávu týkající se „nedůvěryhodného kořenového certifikátu“. Oba weby měly přesně stejný řetěz certifikátů, z čehož zařízení nedůvěřovalo kořenovým ani prostředním certifikátům. Ještě divnější bylo, že po návštěvě testovacího webu by náš web magicky začal fungovat bez varování.

O problému se obracím s Thawte a oni řekli, že náš SSL certifikát nebyl nainstalován správně. Řekli, že potřebujeme stáhnout ​​a nainstalovat ​​přechodný certifikát do důvěryhodného úložiště certifikátů serveru a že bychom mohli použít jejich kontrola instalace = ověřit výsledky. Certifikát byl nainstalován poskytovatelem hostingu (pravděpodobně pomocí automatizované konfigurace skriptu pro certifikáty s jedním kořenovým adresářem), ale jakmile jsme postupovali podle jeho pokynů, náš web začal pracovat na starších prohlížečích, aniž by bylo třeba instalovat nebo schválit nový kořenový nebo přechodný certifikát na serveru přístroj.

Jak to, že instalace přechodného certifikátu na server způsobí, že starší prohlížeče akceptují certifikát jako platný?

6
Greg Bray

Po nedávném absolvování této aktualizace na jednom z našich webů si nyní uvědomuji, že plně nerozumím tomu, jak SSL funguje a že potřebuji určitá vysvětlení.

Jednoduše řečeno, klíče SSL (libovolného pořadí) jsou řadou klíčů v řetězci. Existuje metoda handshaking, která prochází procesem PUBLIC-PRIVATE (řetěz) vynásobením velmi velkých prvočísel (klíčů).

Otázka 1: Jak se liší 1024 bitový root od 2048 bitového root?

Za prvé, klíč je dvakrát větší. Pokud jde o výpočetní „praskání“, způsobuje to a exponenciálně více času. Poslední, co jsem slyšel, (takže jsem se mohl mýlit), masivní multisharing, jako je Seti @ home, dokázal rozbít 256bitový klíč za méně než 6 měsíců. Klíč dvojnásobek této velikosti však trvá 4krát tak dlouho, minimálně. Je to Bachmann – Landauova notace . Klíč 1024 bitů přirozeně trvá 16krát a 2048 32krát.

Vzhledem k tomu, že hrubá síla na klíč 512b byla považována za dobu 1,2 bilionu zpracovatelských let při rychlosti XYZ MhZ najednou, bylo šílené myslet si, že bychom potřebovali upgradovat velikost klíče vůbec.

Ale bohužel, máme.

Nyní s cenou „P versus NP“ jako cenou tisíciletí se více lidí dívá na filtrování odhadů při faktoringu velkých velkých velkých prvočísel.

Otázka 2: Jak fungují zprostředkující certifikáty a jaké výhody/nevýhody mají?

...

Jak to, že instalace přechodného certifikátu na server způsobí, že starší prohlížeče akceptují certifikát jako platný?

Je možné, že různé prohlížeče mají různé rutiny nebo poskytovatele rozšířeného ověření . (možná žádný!)

Je také možné, že různé webové servery mají různé rutiny nebo poskytovatele rozšířeného ověření . (možná žádný? ne tak pravděpodobný!)

Příkladem codebase, která skutečně provádí SSL, je OpenSSL pro PHP.

Existuje mnoho typů takových knihoven pro různé servery a různé kódové základny. Servery, sestavení knihovny nebo dokonce samotné klíče mohou mít problémy se starým kódem.

Protože bezpečnost internetu prochází aktualizacemi a změnami v průběhu procesu, řekl bych, že je bezpečné říci, že novější 2048bitové klíče mají více klíčů a/nebo více řetězců. Ve velmi reálném aspektu to může způsobit neobvyklé chování v tom, co je považováno za odpisovanou rutinu.

Proto důvod, proč prostřední certifikát opravuje problém, opravuje nekompatibilitu s volitelným zpětně kompatibilním certifikátem .

2
Talvi Watia