Popíšeme útok na klienta C a serverem S , které umožňují výměnu klíčů RSA a podporovat i obnovení a sjednání. Server je ochoten akceptovat připojení od klientů, které jsou zpočátku neověřený, ale následně ověřování na základě certifikátu použít v průběhu vyjednávání. (Další varianty níže útoku platí v případě, že klient a použití serveru DHE nebo vždy vynutit ověřování klienta.)
Útok probíhá ve třech krocích.
V kroku 1 (uvedeno v protokolu obrázku níže), TLS klient C úmyslně připojí k serveru A , nevěda, že je škodlivý. Pak se připojí jako klient, aby S použitím stejného klienta náhodné ( cr ), a předává S serveru "s random ( sr ) a SID na C . Navíc, síly, C a S použít výměnu klíčů RSA by pouze nabízet odpovídající ciphersuites ve dvou potřesení rukou. Potom se šifrované PMS zaslané C a reencrypts do S . To dokončí oba stisky rukou, aby získali novou relaci na každé připojení, tyto dvě relace sdílejí stejné klíčové materiály a parametry relace ( SID , ms , cr , sr ), ale mají různé certifikáty serveru a hotové zprávy ( verify_data ).
V kroku 2, C připojí k A a žádá, aby pokračovala v předchozí relaci. , zase připojí k S a obnoví jeho předchozí relaci stejně. Vzhledem k tomu, všechny relevantní parametry na dvou zasedáních jsou stejné, může ve skutečnosti prostě předal zkrácené handshake zprávy beze změny mezi C a S . Po skončení zkráceného handshake, dva spoje opět mají stejné klávesy, ale nyní mají také stejné hotové zprávy ( verify_data ). zná nové klíče připojení, takže můžete pokračovat v odesílání dat na obou připojení k C nebo S .
V tomto bodě, C stále věří, že má spojení s A , a S stále věří, že to má souvislost s nějakým anonymním klientem, takže ani jeden z nich byl ještě vydával. Nicméně, protože klientské a serverové verify_data jsou nyní stejné na obou připojení, rozšíření Opětovné projednání Indikace pro příštích potřesení rukou na těchto spojení bude mít stejné hodnoty. Pozoruhodně, tls-jedinečný kanál vázání na dvě připojení je také nyní stejné, v rozporu svou zamýšlenou definici.
V kroku 3, S vyžaduje sjednání s ověřování klienta na jeho spojení s A , případně v reakci na A žádost je pro některé omezené zdroje. Poté předá požadavek na opakované vyjednávání na C , a C souhlasí s tím, k ověření jeho klientského certifikátu na A . Nyní obě spojení zapojit v plné sjednání nové dohody handshake s ověřování klienta. prostě dopředu všechny zprávy z C na S a zpět. Handshake úspěšně dokončí, protože očekávané Opětovné projednání Indikační prodlužovací hodnoty na obou připojení jsou stejné.
Na konci roku k novému projednání, již zná klíče připojení nebo hlavní tajemství, jsou známy pouze na C aS . V důsledku toho nemůže číst nebo posílat zprávy na těchto spojů víc. Nicméně, jeho dřívější zprávy na obou spojů může dobře být předponou do zpráv odeslaných po vyjednávání. Navíc, jak ukážeme dále na webu využít, vůle může být stále schopen číst a zapisovat data na těchto spojů, opíraje se o stejnou politiku původu.
Během opětovné projednání, handshake, C obdrží certifikát S , i když to bylo očekával, které mají být připojeny k A . Původně jsme věřili, že C by odmítl tuto změnu certifikátu, ale my jsme byli překvapeni, když zjistili, že řada TLS klientských aplikací, včetně populárních webových prohlížečů, tiše, aby certifikát serveru mohou změnit bez poskytnutí jakéhokoli varování svým uživatelům. Konstrukce Důvodem pro to je, pravděpodobně, aby server vyjednat jiný ciphersuite (např. ECDSA po RSA), nebo aby server nahradit jeho prošlý certifikát v long-running TLS relaci, nebo jednoduše nahradit obecný (slabý) certifikát s určitým (silný) jeden. V dalších scénářích soukromí-vědomé, klienti mohou chtít, aby server vyjednat počáteční handshake s anonymními pověření a poskytovat skutečnou certifikát serveru během vyjednávání. Přesto ve většině případů, a to zejména v internetových scénářích, věříme, že klienti TLS by při sjednání nové dohody odmítnout všechny změny certifikátu serveru.