it-swarm-eu.dev

Znamená navázané připojení HTTPS, že linka je opravdu bezpečná?

Z pohledu někoho, kdo nabízí webovou aplikaci, když se někdo připojí k TLS (https) k naší službě a odešle správná autentizační data, je bezpečné přenášet všechna citlivá data přes tuto linku, nebo je možné, že stále odposlouchává?

Tato otázka byla IT bezpečnostní otázka týdne.
Přečtěte si 29. července 2011 položka blog pro více informací nebo vložte svůj vlastní Otázka týdne.

112
Peter Smit

Je důležité pochopit, co SSL dělá a nedělá, zejména proto, že se jedná o velmi častý zdroj nedorozumění.

  • Šifruje kanál
  • Aplikuje kontrolu integrity
  • Poskytuje autentizaci

Rychlá odpověď by tedy měla znít: „Ano, je dostatečně bezpečný pro přenos citlivých dat“. Věci však nejsou tak jednoduché.

  • Nejnovější verze SSL - verze 3 nebo ještě lepší: TLS, dokonce TLS 1.2, jsou rozhodně lepší než předchozí verze. Např. SSL 2 bylo relativně snadné MITM (Muž uprostřed). Nejprve to záleží na verzi protokolu.
  • Šifrování kanálů i kontrola integrity jsou konfigurovatelné v protokolu, tj. Můžete si vybrat, které algoritmy použijete (sada šifry). Samozřejmě, pokud používáte RSA1024/SHA512, jste mnohem lépe mimo ... SSL však dokonce podporuje režim šifrování NULL - tj. Vůbec žádné šifrování, stačí zabalit požadavky až do tunelu přes protokol SSL. I.e., žádná ochrana. (Toto je konfigurovatelné jak na klientovi, tak na serveru, vybraná sada šifry je první shodnou sadou podle nakonfigurovaného pořadí).
  • Ověřování v SSL má dva režimy: pouze serverové ověřování a vzájemné ověřování (klientské certifikáty). V obou případech je zabezpečení zajištěné kryptografickými certifikáty rozhodně dost silné, ale platnost skutečné autentizace je pouze tak dobrá jako vaše kontroly platnosti: Obtěžujete kontrolu certifikátu? Zajišťujete jeho platnost? Důvěryhodný řetěz? Kdo to vydal? Atd.
  • Toto poslední ověření totožnosti je mnohem snazší na webu aplikace, kde klient může snadno zobrazit certifikát serveru, ikonu zámku lze snadno zobrazit atd. S webem Služby, obvykle musíte být explicitnější při kontrole jeho platnosti (v závislosti na vašem výběru platformy). Všimněte si, že tentýž bod zaznamenal tolik mobilních aplikací - i když si vývojář aplikace pamatoval, že mezi telefonem a serverem používá pouze TLS, pokud aplikace výslovně neověřuje certifikáty, pak se TLS rozbije.
  • Zatímco na kryptografii SSL existují některé většinou teoretické útoky, z mého PoV je stále dost silná pro téměř všechny účely a bude trvat dlouhou dobu.
  • Co se vlastně s daty děje na druhém konci? Např. pokud je to supercitlivé nebo dokonce údaje o kreditní kartě, nechcete to v mezipaměti prohlížečů, historii atd.
  • Cookies (a tedy autentizace) lze sdílet mezi zabezpečeným kanálem SSL a nezabezpečeným kanálem HTTP - pokud není výslovně označen atributem „secure“.

Takže kratší odpověď? Ano, SSL může být dostatečně bezpečný, ale (stejně jako u většiny věcí) záleží na tom, jak jej používáte. :)

94
AviD

Je zde několik problémů, z nichž hlavní je autentizace. Oba cíle si musí být jisty, že mluví se správnou osobou nebo institucí, aby zmařily útoky typu člověk-uprostřed. Nakonec je důležité, abyste použili certifikát SSL, kterému uživatelský prohlížeč důvěřuje. Prohlížeč uživatele tak může mít jistotu, že skutečně mluví se správným webem. Jakmile je připojení navázáno, můžete si být jisti, že s tímto uživatelem neustále mluvíte, a připojení je šifrováno, tj. Zabezpečeno proti odposlechu.

Ověřování v opačném směru (tj. Ujistěte se, že mluvíte se skutečným uživatelem) se obvykle provádí mimo SSL protokol na aplikační úrovni, např. Uživatelským jménem/heslem, openID nebo nějakou jinou formou pověření.

Jako poslední poznámku je třeba zmínit, že během SSL připojení handshake se klient a server dohodli na Cipher suite a klient mohl předstírat, že provádí pouze „nulové šifrování“, tj. Nešifrovat žádná data . Pokud váš server s touto možností souhlasí, připojení používá SSL, ale data stále nejsou šifrována. To v praxi není problém, protože implementace serverů obvykle nenabízejí nulovou šifru.

23
Tronic

Kromě toho, co AviD uvádí, je SSL pouze tak bezpečná jako infrastruktura DNS, která vás přesměrovala na tento server, a všechny firemní servery proxy v komunikační cestě.

Pokud je infrastruktura DNS napadena (otrava mezipaměti atd.), Může útočník vystavit uživatele mnoha útokům.

Kromě toho, pokud klient prochází softwarem jako Fiddler nebo firemní proxy, může tento software uvolnit vaši konverzaci SSL.

Chcete-li to zmírnit, podívejte se na „vydavatele“ certifikátu SSL. Pokud SSL připojení prochází přes proxy, bude vydavatelem proxy. Pokud procházíte přímým připojením, uvidíte příslušnou veřejně důvěryhodnou certifikační autoritu.

[Další informace]

Firemní proxy HTTPS je něco, co řídí spojení mezi webovým prohlížečem a serverem proxy (jehož IP adresa se zobrazuje v protokolech webového serveru). V takovém případě je webový obsah (také heslo HTTPS) dešifrován a později znovu zašifrován na podnikovém serveru proxy a prezentován na váš server.

V závislosti na tom, kdo spravuje proxy, a jak se používají jeho protokoly, může být toto z vašeho pohledu přijatelné nebo špatné.

Další informace o tom, jak se provádí zachytávání SSL, najdete v tomto link :

Když SSL Proxy zachytí připojení SSL, předloží klientskému prohlížeči emulovaný certifikát serveru. Klientský prohlížeč vydá vyskakovací okno zabezpečení koncovému uživateli, protože prohlížeč nedůvěřuje emitentovi použitému serverem ProxySG. Toto vyskakovací okno nenastane, pokud je vydavatelský certifikát používaný SSL Proxy importován jako důvěryhodný kořen v úložišti certifikátů prohlížeče klienta.

ProxySG zpřístupňuje všechny konfigurované certifikáty ke stažení prostřednictvím konzoly pro správu. Můžete požádat koncových uživatelů, aby si certifikát vydavatele stáhli prostřednictvím aplikace Internet Explorer nebo Firefox a nainstalovali jej jako důvěryhodnou certifikační autoritu do svého vybraného prohlížeče. Tím se eliminuje vyskakovací okno certifikátů pro emulované certifikáty ...

Některé společnosti obcházejí výše uvedený problém s vyskakováním certifikátů nasazením kořenových certifikátů (proxy) na každou pracovní stanici pomocí GPO. To však ovlivní pouze software, který používá úložiště certifikátů Microsoft. Software jako Firefox a Chrome) je třeba aktualizovat odlišně.

20

Protože se SSL spoléhá na certifikační autority (CA) a v podstatě se z něj může stát jakákoli organizace, mohou být vždy možné útoky typu „člověk uprostřed“ s falešnými certifikáty podepsanými CA. I když SSL je stále velkým vylepšením oproti nešifrování, jeho zabezpečení je kvůli nefunkčnímu CA systému přeceňováno. V tomto ohledu by certifikáty s vlastním podpisem byly stejně bezpečné jako jakýkoli certifikát podepsaný CA, ale prohlížeče je označují jako podezřelé.

11
Jörn Zaefferer

SSL je velmi bezpečný, i když někdo může ukrást něčí cookie cookie relace, pokud spustíte jakoukoli stránku přes nešifrovanou linku. Kdybys mohl, udělal bych z webu all-SSL. Nebo může mít cookie odesílat pouze pro šifrovaná připojení a mít nezabezpečené veřejné stránky, které nejsou specifické pro daného uživatele.

10
James T

Stále existuje možnost útoku typu „muž uprostřed“, kterým by ve vašem případě byl uživatel, který se připojí k třetí straně, která prohlašuje, že je váš web, a poté žádost předá. Důvěrný uživatel by si samozřejmě měl všimnout chybějícího připojení SSL nebo nesprávného certifikátu, ale většina uživatelů to není zapnutá a duplikuje se favicon visacího zámku.

To není problém se samotným SSL, ale jen něco, o čem je třeba si uvědomit. Můžete bezpečně předpokládat, že nikdo nemůže odposlouchávat spojení SSL mezi vaším webem a zdrojem připojení. Nemůžete si však být jisti, že zdrojem připojení je skutečně uživatel.

9
Magnus

Protože SSL šifruje přenos, nelze odposlouchávat žádná data (protože certifikát je důvěryhodný).

Přestože problém spočívá v tom, kde (a kolik) používáte SSL ve svém webappu: řekněme například, potřebujete připojení SSL pouze k ověření vašeho uživatele (nechat je poslat zašifrované páry uživatelů/předat na váš server) , při odesílání souboru cookie byste si měli být vědomi, že jej lze snadno zachytit (například pokud je váš uživatel na nechráněném bezdrátovém připojení).

Nedávné drama FireSheep je o tom.

9
gbr

Ne. Analýza provoz může někomu ještě hodně říci.

Analýza provozu je proces zachycování a zkoumání zpráv s cílem odvodit informace ze vzorců v komunikaci. Lze to provést i v případě, že jsou zprávy šifrovány a nelze je dešifrovat. Obecně platí, že čím větší je počet pozorovaných nebo dokonce zachycených a uložených zpráv, tím více lze z provozu odvodit.


TLS se obvykle používá k zachování důvěrnosti - útočník by neměl dosáhnout vysoké úrovně důvěry v obsah komunikace.

Za předpokladu,

  1. útočník zná váš protokol,
  2. útočník ví, kdo s kým komunikuje
  3. útočník nemůže dešifrovat zprávy.
  4. nezakrýváte svůj skutečný provoz v mnoha nesmyslných provozech (plevách)

Útočník pravděpodobně zjistí, kdy jste vzhůru a kdy spíte bez ohledu na protokol, a může být schopen říci mnohem více v závislosti na povaze používaného protokolu.


Pokud je váš protokol velmi jednoduchý:

  1. Když chcete vystřelit z nuků, pošlete zprávu „střílejte na nukes na ...“
  2. Když nechcete střílet žádné jaderné zbraně, neodešlete zprávu.

Odposlouchávač, který nemůže dešifrovat vaše data, může zjistit pouhou přítomností zprávy, kterou chcete vystřelit, ale možná ne na koho.


Pokud je váš protokol složitější:

  1. Žádáte o knihu.
  2. Posílám vám obsah.

Útočník nemusí být schopen říct, kdo čte „Válka a mír“ vs „Atlas pokrčil rameny“ , ale dokáže rozlišovat, čistě na velikosti zprávy, zda čtou jednu z 55 stránkový román „Proměna“.

7
Mike Samuel

SSL provádí dva základní úkoly: autentizaci a šifrování.

Ověřování se provádí prostřednictvím certifikačních autorit (CA). Prohlížeče přicházejí se seznamem certifikátů SSL pro podpisové klíče certifikačních autorit. Certifikační autority podepisují certifikáty, které popisují veřejný klíč entity. Například, pokud jsem vlastnil Google.com, dokázal bych to společnosti Verisign a oni by nějakou dobu podepsali můj certifikát. Problémy se vynoří s CA podepíše certifikát, který by neměl podepsat. K tomu může dojít, když někdo předstírá, že vlastní jinou doménu, získá divokou kartu, která je příliš široká nebo prostě prostá XKCD CA, aby vydala něco nebezpečného (možná vlády?). Viděli jsme, jak se všechno výše uvedené stalo, ale je to docela vzácné.

Pokud je certifikát pro web správně podepsán a ve vašem řetězci důvěry neexistuje žádný falešný cert, můžete se při připojení k webu přesvědčit, že certifikát odpovídá (pro účely diskuse). Za normálních okolností je toto připojení šifrováno. To brání každému ve čtení vašich dat.

SSL certifikáty jsou velmi složité a proti implementacím SSL existuje řada útoků. Co SSL dokáže efektivně udělat, je, že mi zabráním sledovat váš provoz v místních Starbucks, když zkontrolujete svůj e-mail na GMail. To, co nedokáže, je zabránit mi v použití útoku MITM, kde vám předávám všechno bez SSL a váš klient není nastaven, aby vás obtěžoval skutečností, že nikdy nezačala šifrovanou relaci.

6
Jeff Ferland

Pokud nepočítáte různé odpovědi ostatních o jiných potenciálních problémech, za předpokladu, že používáte SSL 3.0 a silné šifrování, mělo by to být bezpečné.

Použití starších protokolů ssl (2.0) nebo použití slabého šifrovacího klíče by vás mohlo otevřít zranitelnostem.

4
Doozer Blake

SSL obecně zvyšuje zabezpečení poskytováním:

  1. Ověření serveru (uživatel ví, že mluví se správným webem)
  2. Integrita dat (uživatel a server vědí, že provoz se na cestě nemění)
  3. (volitelně, ale obvykle) Ochrana osobních údajů (uživatel a server vědí, že přenos není na cestě zachycen)
  4. (volitelně, ale vzácně) Ověření klienta, pokud má klient také certifikát

V zásadě existují pouze dva typy certifikátů SSL, serverový certifikát (který je vždy zapojen) a klientský certifikát (který je volitelný).

Je to jen skica a existuje mnoho ifs, ands a buts. V nejtypičtějším scénáři, SSL založeném na prohlížeči, se schéma může v mnoha případech rozbít, aniž by došlo k porušení kryptografie nebo protokolu, ale jednoduše tím, že se uživatel spoléhal na to, že udělal špatnou věc (tj. Ignoruje varování prohlížeče a přesto se připojuje). Phishingové útoky mohou také fungovat tak, že pošlou uživatele na falešný web chráněný SSL, vytvořený tak, aby vypadal jako ten skutečný ve všech ohledech kromě URL.

Jak již bylo řečeno, SSL a jeho bratranec TLS jsou stále velmi užitečné, protože přinejmenším umožňují bezpečnou komunikaci, i když daleko od spolehlivosti.

4
frankodwyer

@ Vladimir má pravdu, že http://en.wikipedia.org/wiki/Forward_secrecy je žádoucí, ale má nesprávné údaje. Server si vybral tento šifru z těch nabízených prohlížečem. „šifrováno pomocí RC4_128 pomocí SHA1 pro ověřování zpráv“ používá 128bitové šifrování RC4 a kontrolu integrity HMAC-SHA-1. (Názvy Ciphersuite v SSL/TLS donedávna říkají SHA, ale znamenají SHA-1 a vlastně HMAC-SHA-1.) „ECDHE_ECDSA jako mechanismus výměny klíčů“ se nevztahuje na jednotlivé zprávy , je to část (většina) handshake, která se objeví jednou na začátku relace: ECDHE používá variantu eliptické křivky Diffie-Hellman v efemérním režimu (plus některé další kroky zde nejsou důležité) k vytvoření relace klíče používané pro šifrování a HMAC a výměna klíčů ECDHE (pouze) je podepsána variantou Elliptic Curve v algoritmu digitálního podpisu (nikdy nelze šifrovat nic přímo pomocí DH nebo ECDH, dělají pouze klíč nebo jinou malou tajnou dohodu.)

2

Pokud nepoužíváte SSL, veškerá komunikace může být snadno zachycena - jediná věc, kterou musíte udělat, je spustit sniffer paketů (tj. Wireshark).
SSL tomu brání, všechny pakety jsou šifrovány, takže neexistuje způsob, jak zjistit, co odesíláte. V zásadě se používá k ochraně hesel a soukromého obsahu před zachycením. Samozřejmě nechcete, aby někdo jiný četl vaše soukromé e-maily, že?
Pokud jde o vyhledávání Google, jednoduše udělali, aby skryli to, co lidé požadují. Je to proto, že některé vlády jsou na to příliš zvědavé.

Jak SSL zvyšuje zabezpečení? To samo o sobě není. Co je kombinace šifrování (SSL klíč) a PKI (Infrastruktura veřejného klíče) - hlavně Certifikáty. Dobře, otázkou bylo jak. Na jedné straně zajišťuje váš komunikační kanál (viz výše), na druhé straně zajišťuje, že mluvíte s legitimním obchodně ověřovacím serverem. Kanál je tedy bezpečný a důvěryhodný.

Existuje poměrně málo SSL certifikátů, protože existuje docela málo PKI Services . V podstatě jiná služba vyžaduje jiný typ certifikátu SSL. Existují tedy certifikáty pro podepisování kódu, šifrování a podepisování e-mailů, ty, které se týkají např. Autentizace serveru atd.

2
Paweł Dyda

Když se někdo připojí k naší službě pomocí protokolu SSL (https) a odešle správná autentizační data, je bezpečné přenášet všechna citlivá data přes tuto linku, nebo může dojít k odposlouchávání?

Slabým článkem v tomto řetězci je téměř jistě SSL, ale uživatel, který může být obvykle podveden k připojení k falešnému mezilehlému webu buď pomocí webového spoofingu/hyperlinkového spoofingu, nebo předložením neplatného certifikátu a odmítnutím varování prohlížeče a pokračováním k přesto se připojit.

Systém, který popisujete, je v každém případě osvědčeným postupem, ale není nic jiného, ​​co můžete udělat (kromě vychovávání uživatelů, aby brali varování SSL vážně, pokud můžete).

2
frankodwyer

Krátká odpověď zní ne. Delší odpověď: sbírka odpovědí výše plus: Pokud vyřešíme autentizaci, tedy man-in-the-middle, která by s tradičním připojením SSL mohla někdo, který by se mohl do seznamu zasílat, ještě dešifrovat, pokud získá tajný klíč serveru (myslím of NSA a dopisy o národní bezpečnosti). V protokolu TLS je možné použít protokol Diffie-Helman k zajištění důvěrného propojení. Při přístupu k serveru gmail.com pomocí prohlížeče Chrome postupujte podle následujícího obrázku. connection security

Podívejte se na text RC4_128 s SHA1 pro ověření zprávy ECDHE_ECDSA. Toto zní:

  1. Server nabízel SSL kanál RC4_128b s SHA digest)
  2. Uvnitř tohoto tunelu je každá zpráva šifrována pomocí Ecliptic křivek, kde je klíč odvozen pomocí funkce Diffie-Helman, a je podepsána šifrovací Ecliptic Curves pomocí algoritmu Digital Signature Algorithm

Jinými slovy, i když má někdo soukromý klíč serveru SSL, zprávy byly šifrovány dočasnými klíči, které budou brzy po použití vyřazeny z paměti. Hodně štěstí NSA!

2
Vladimir Jirasek

Je to bezpečné pro uživatele nebo je to pro vás bezpečné? Předpokládej útok člověka uprostřed. Útočník dokáže zachytit provoz uživatele, předstírá, že jste uživateli, a předstírá, že je pro vás uživatelem. Takový útok by obvykle selhal, protože certifikát daný uživateli by nebyl správný. Útočník například dá uživateli certifikát podepsaný sebou pro váš web. Pokud se však uživatel chová hloupě, může tento certifikát podepsaný sám sebou přijmout. Útočník nyní může číst a upravovat veškerý provoz mezi uživatelem a vámi, a pokud vím, neexistuje žádný způsob, jak to zjistit.

Takže pokud snooping a modifikace provozu bolí uživatele, je to vlastně jejich chyba a vlastní problém. A nemůžete tomu úplně zabránit, protože MITM vás může úplně vyříznout a mluvit s uživatelem a předstírat, že jste vy. Ale pokud vás bolí snooping a modifikace provozu, pak musíte důvěřovat uživateli, aby nebyl hloupý, nebo lépe ověřil uživatele (uživatel by potřeboval certifikát, a můžete to ověřit způsobem, který MITM nemůže) falešný).

2
gnasher729

Dokonce i nejmodernější verze HTTPS používající TLS lze snadno zachytit pomocí MitM (např. Juniper zařízení nakonfigurováno pro tento účel), pokud klient důvěřuje CA. V tomto konkrétním případě to není bezpečné.

1
user3260912

Myslím, že tady lidé nerozumí otázce:

Pokud máte nebezpečnou linku a provedete úspěšné připojení SSH/SSL přes tuto linku, nyní se zeptá, zda je bezpečné zajistit, že linka je „bezpečná“ a že nešifrovaná data mohou být předána ALONGSIDE pomocí šifrovaného připojení ( např. v očích, ne uvnitř šifrovaného připojení SSL/SSH).

Řekl bych ne. V tomto případě by mohl existovat pasivní odposlouchávač, který jednoduše ignoruje šifrovaná data a ukládá nešifrovaná data.

ALE si můžete být jisti, že neexistuje žádný aktivní odposlouchávač (MITM), což znamená, že můžete bezpečně navázat neověřené připojení SSL/SSH se stejným zdrojem/cílem jako ověřená linka. To neposkytuje žádné selektivní odposlech, který MITM určité konektory, ale odposlouchávač však nemůže vědět, zda se chystáte ověřit připojení, nebo ne, takže nemůže vědět, které připojení k MITM se vyhnout detekci. MITMer by, pokud MITM, MITM, všechna připojení a doufal, že lidé jednoduše kliknou skrz všechny autentizační dialogy.

Tedy: Pokud se připojíte k ověřené službě SSL od řekněme 123.123.123.123 do 24.24.24.24, můžete také bezpečně připojit klienta SSH od 123.123.123.123 do 24.24.24.24 bez vzájemné autentizace otisků prstů SSH za předpokladu, že můžete důvěřovat všemu za na druhé straně směrovač nebo brána NAT).

Ale i když to obecně znamená bezpečné, existuje IS malé riziko, že odposlouchávač jednoduše náhodně připojí MITM a doufá, že nebude detekován, takže protože již máte ověřené připojení k cílové IP, proč nepoužívat toto ověřené připojení k vzájemnému ověření otisků prstů SSH? Je to jednoduché jako zveřejnění správných otisků prstů SSH na webu zabezpečeném pomocí SSL!

1