Hlavní navigace

Google bude prohlašovat certifikáty s SHA-1 za nebezpečné

9. 9. 2014

Sdílet

Hlavní problém hashovacích funkcí je v případě nalezení kolize. Pokud se útočníkovi podaří najít kolizi vhodného tvaru, může vytvořit certifikát tvářící se jako legitimní, i když bude pro úplně jinou doménu. Z pohledu uživatele bude internetová stránka vypadat, že patří například pod nějakou světoznámou společnost.

V minulosti se již několikrát povedlo prolomit hashovací funkci MD5. Ta už se nepovažuje za bezpečnou a neměla by se používat. Z důvodů částečného překonání i funkce SHA-1 v roce 2005 se společnost Google rozhodla skoncovat i s ní a bude nově označovat X.509 certifikáty využívající tuto hashovací funkci v prohlížečích Chrome za nebezpečnou. Data kdy budou certifikáty označeny jako „neutral, lacking security“, “affirmatively insecure" apod. záleží na konkrétních verzích internetového prohlížeče Chrome a najdete je na blogu Google.

(Zdroj: Google)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 9. 9. 2014 21:40

    Petr Stehlík

    takže nejsem sám, na koho snad každé pondělí Gajim v práci při připojování na google talk server zařve, že jsem zcela nedůvěryhodný a ať se zastřelím? Nemohl jsem uvěřit tomu, že by ty certifikáty měnili tak často...

  • 10. 9. 2014 11:20

    Filip Jirsák

    Záleží na době platnosti certifikátu. Pokud konec jeho platnosti je až v roce 2017 nebo později, zobrazí se u ikony HTTPS žlutý trojúhelník jako výstraha, že vše není v pořádku. S dalšími verzemi se bude přitvrzovat – hraniční datum se bude posouvat blíž k dnešku a varování se změní na červený křížek „nezabezpečené spojení“.
    GMail má certifikáty s platností pár měsíců, takže toho se to dnes nedotkne. Ale doufám, že se Google pochlapí, a přejde sám na SHA-2 certifikáty. Ale vzhledem k tomu, že SHA-1 jsou i certifikáty jejich CA, a spousta dalších CA má SHA-1 certifikáty, je ten harmonogram docela drsný.
    Obávám se, že z toho bude docela zmatek. Aby zůstaly platné stávající certifikáty, dělají to CA tak, že vydají svůj nový certifikát s SHA-2, ale se stejným veřejným klíčem. Takže od serverového certifikátu vedou dvě různé certifikační cesty ke dvěma různým kořenovým certifikátům. To jsem zvědav, jak si s tím který software poradí.

  • 10. 9. 2014 15:17

    Kolemjdouci (neregistrovaný)

    Mohl byste nam trosku priblizit metodu "vydají svůj nový certifikát s SHA-2, ale se stejným veřejným klíčem"?

  • 10. 9. 2014 17:50

    Filip Jirsák

    CA vydává klientům certifikáty podepsané privátním klíčem. Veřejný klíč k tomuto privátnímu klíči se spojí s identifikačními údaji, udělá se SHA-1 hash těchto dat a ten podepíše CA svým kořenovým certifikátem – takhle vznikne intermediate certifikát. Když bude chtít CA posílit vazbu mezi údaji a klíčem toho intermediate certifikátu (zmenšit pravděpodobnost, že se někomu podaří vyrobit stejný certifikát, ale se svým klíčem), vezme ten samý veřejný klíč, připojí k němu pokud možno stejné identifikační údaje (musí ukazovat na toho samého vlastníka), a z těchto dat spočítá tentokrát SHA-256 hash, a ten opět podepíše svým kořenovým certifikátem. Takže klientské certifikáty podepsané tím privátním klíčem pak jdou ověřit přes oba ty intermediate certifikáty.
    Např. tady máte dva starší kořenové certifikáty Thawte, oba dva jsou ke stejné dvojici klíčů, ale u jednoho je podepsáno MD5, druhý už má v podpisu SHA-1:

    -----BEGIN CERTIFICATE-----
    MIIDEzCCAnygAwIBAgIBATANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx
    FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD
    VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv
    biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm
    MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTYwODAx
    MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjCBxDELMAkGA1UEBhMCWkExFTATBgNVBAgT
    DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYDVQQKExRUaGF3
    dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNl
    cyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEmMCQGCSqGSIb3
    DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD
    gY0AMIGJAoGBANOkUG7I/1Zr5s9dtuoMaHVHoqrC2oQl/Kj0R1HahbUgdJSGHg91
    yekIYfUGbTBuFRkC6VLAYttNmZ7iagxEOM3+vuNkCXDF/rFrKbYvScg71CcEJRCX
    L+eQbcAoQpnXTEPew/UhbVSfXcNY4cDk2VuwuNy0e982OsK1ZiIS1ocNAgMBAAGj
    EzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAB/pMaVz7lcxG
    7oWDTSEwjsrZqG9JGubaUeNgcGyEYRGhGshIPllDfU+VPaGLtwtimHp1it2ITk6e
    QNuozDJ0uW8NxuOzRAvZim+aKZuZGCg70eNAKJpaPNW15yAbi8qkq43pUdniTCxZ
    qdq5snUb9kLy78fyGPmJvKP/iiMucEc=
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    MIIDIjCCAougAwIBAgIQNKT/9jCvTKU8MxdCoZRmdTANBgkqhkiG9w0BAQUFADCB
    xDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJ
    Q2FwZSBUb3duMR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UE
    CxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhh
    d3RlIFNlcnZlciBDQTEmMCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0
    ZS5jb20wHhcNOTYwODAxMDAwMDAwWhcNMjEwMTAxMjM1OTU5WjCBxDELMAkGA1UE
    BhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du
    MR0wGwYDVQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlm
    aWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZl
    ciBDQTEmMCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wgZ8w
    DQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANOkUG7I/1Zr5s9dtuoMaHVHoqrC2oQl
    /Kj0R1HahbUgdJSGHg91yekIYfUGbTBuFRkC6VLAYttNmZ7iagxEOM3+vuNkCXDF
    /rFrKbYvScg71CcEJRCXL+eQbcAoQpnXTEPew/UhbVSfXcNY4cDk2VuwuNy0e982
    OsK1ZiIS1ocNAgMBAAGjEzARMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEF
    BQADgYEAvkBpQW/G28GnvwfAReTQtUMeTJUzNelewj4o9qgNUNX/4gwP/FACjq6R
    ua00io2fJ3GqGcxL6ATK1BdrEhrWxl/WzV7/iXa/2EjYWb0IiokdV81FHlK6EpqE
    +hiJX+j5MDVqAWC5mYCDhQpu2vTJj15zLTFKY6B08h+LItIpPus=
    -----END CERTIFICATE-----

    (Variantu s SHA-1 a SHA-2 jsem teď rychle nenašel.) Týká se to algoritmu podpisu, nebo je takhle možné před self-signed certifikát předřadit jiný kořenový certifikát, velikost klíče takhle samozřejmě změnit nelze.

  • 11. 9. 2014 11:17

    Kolemjdouci (neregistrovaný)

    Nezlobte se, ale Vas popis tvorby intermediate certifikatu je celkem zhuleny.

    Kazdopadne vidim dve moznosti:

    1) server poskytne chain s novym intermediate certifikatem a validace probehne proti nemu. To bych ostatne doporucil, protoze starsi browsery nektere intemediate certifikaty stejne neznaji. Treba zrovna thawti "C=US, O=Thawte, Inc., CN=Thawte SSL CA".

    2) v systemovem keystore se nahradi stary SHA1 certifikat novym se SHA2, takze bude jenom jedna cesta, jak certifikat validovat.

    Jinak treba openssl hleda certifikaty pres hash symlinky a ty jsou u obou Vami zminenych certifikatu samozrejme stejne. Hadam, ze kdyz zvaliduje proti 6cc3c4c3.0, uz se nebude obtezovat 6cc3c4c3.1.

  • 11. 9. 2014 12:41

    Filip Jirsák

    Pokud je podle vás na popisu tvorby certifikátu něco špatně, neměl by pro vás být problém napsat, co konkrétně. Samozřejmě jsem to zjednodušil a napsal jsem jenom to, co je pro tuto diskusi podstatné.
    Těch možností je spousta, přičemž problém je v tom, že klient zpravidla nemůže ovlivnit, jaké certifikáty bude posílat server, a server zase neovlivní, jaké certifikáty považuje za důvěryhodné klient. Takže jde o to, jak se budou chovat různé implementace. Ale vzhledem k tomu, že už se to samé řešilo při přechodu z MD5 na SHA1, je spolu snad většina používaného softwaru kompatibilní. Na druhou stranu, tenkrát se certifikáty používaly mnohem méně, a také od té doby vznikl nový software.

Byl pro vás článek přínosný?