Názory k článku Odpočúvanie šifrovaných spojení
-
jariq (neregistrovaný)Myslim, ze clanok je zbytocne prilis nazorny.. Po troske trapenia zacne presmerovavat spojenie kazda lama s pristupom k routeru. Clovek, ktory si nesedi na vedeni o tom aj tak davno vie.. Takze mi nejako unika zmysel clanku.. Je to pre nevzdelanych uzivatelov? Nie kliknu kludne OK aj nadalej.. Je to pre ostrielanych adminov? Nie nic nove.. Takze si myslim, ze je to zbytocne howto pre wannaBhackerov..
-
S vasi reakci mam trochu asociaci s pstrosem s hlavou v pisku ... Schovam ji, a budu doufat, ze me nikdo ritku nenakopne, kdyz nejsem na ocich :-)
Kdo chce, ten si to najde a alespon to prinese rozcarovani lidem, co tomu duveruji a verim, ze takovi jsou, nemalo.
I nazorna ukazka je treba, aby si clovek uvedomil, jak lehke to je i pro Frantika a co riskuje.
Ciste muj nazor, prosim, zadny flame ... jen clanek hodnotim pozitivne. -
W/R (neregistrovaný)Rad bych se pripojil ke kladnemu hodnoceni clanku. Je dulezite ukazovat "wannaBadminum", ze ani na SSL neni 100% spolehnuti, kdyz se clovek nechova dostatecne paranoidne:)
Kdyby v clanku bylo napsane pouze neco ve smyslu "Pokud se Vam objevi na strance hlaseni 'Certifikat nelze overit', tak byste meli prekontrolovat HASH", tak to bude kazdej ignorovat, ze tohle napsal paranoidni maniak:) Kdyz ale ukazu na prikladu, ze to je fakt jednoduchy, tak wannaBadmini budou vedet, ze na svoji siti maji uzivatele nejakym zpusobem zaucit, aby predesli treba prave zavirovani/backdoorovani svoji site a pocitacu, a taky ze se maji neco vic naucit, pokud tohle neznali. -
realista (neregistrovaný)Sorry a odkud jsi se o technice odposlechu SSL spojeni dozvedel ty? Bud jsi na to prisel sam, nebo jsi to nekde cetl. Rekl bych, ze b) je spravne. Povazuji za dulezite IT verejnost informovat o technikach utocniku. Dik za clanek, jsem rad, ze lidi co problematice rozumi, najdou cas napsat o tom clanek.
-
anonymníLidi, ktery maji alespon zakladni povedomi o fungovani SSL/TLS a certifikatu, by na tohle meli prijit sami. Nepamatuji se ze bych to nekde cetl, zaroven mi clanek nic noveho neprinesl. Presto se mi libil.
V clanku to bylo naservirovano pekne polopaticky a je to prave ta "option b" :-). Snad nam pribyde zase par uvedomelych. -
jariq (neregistrovaný)Ja si myslim ze frantik aj tak nepochopi o co tu ide, resp. ak pochopi, pochopil by aj bez prikladu.. A pstros s hlavou v piesku.. Neviem ako by sa Vam pacilo sediet vecer doma za pocitacom s vierou, ze si idete v klude zaplatit faktury cez e-banking a tu na Vas zrazu vyskoci error certifikatu.. Potom mozete trace-ovat pricinu.. V takych pripadoch volim radsej strategiu pstrosa :)
-
V případě špatného certifikátu na stránku pro e-banking jej okamžitě odmítnu a volám helpdesk. Naivně jsem předpokládal, že tak učiní každý.
Zvlášť s Wi-Fi není žádný problém najet někam před hotel, pustit AP s nepovoleným zesilovačem signálu a směrovou anténou, nastavit stejné ESSID jako má hotelová síť. Ti, co zvolí strategii pštrosa, mají smůlu.
Názorný článek pro Frantíka by mohl být pouze sérií screenshotů:
1) Přijde mail "od banky". Prý je nutné změnit heslo. Máte prý odklepnout OK na okno, které přitom vyskočí.
2) Frantík klepe na okno s varováním o neplatném certifikátu.
3) Frantík zadává číslo účtu, čislo smlouvy, heslo na homebanking, číslo karty, PIN, CVC.
4) Frantík čte výpis z účtu. -
noob (neregistrovaný)tak tak.. takovyto clanek muze jen uskodit.. nerozumim k cemu je to tady pro slusne a rozumne lidi (rozumni to davno vedi, a slusni to nedelaji), takze tohle je totalne na nic!!
kravatakovsky napsany howto o problematice pri slozitosti urovne 1337 lameruu !!
nic noveho, nic dobreho!! promin -
michal_sjx (neregistrovaný)Zdravim. Tohle asi nezna kazdej user, ale kazdej admin a programator to uz vi ... jak uz nekdo napsal. Ocekaval sjem slozitejsi tema, kde se bude hovorit o tom, ze certifikaty s md5 fingerprintem jsou v dnesni dobe zfalsovatelne ... vyplyva to z jiz znamych rychlich algoritmu na vytvoreni kolizni dvou md5 hashu, ktere budou kolidovat. V tom pripade totiz browser, nebo jiny klient, klidne pusti komunikaci dal bez dotazu na usera :)).
-
Marian Kechlibar (neregistrovaný)K falsovani certifikatu byste potreboval nikoliv "najit dva ruzne texty, ktere vedou ke kolizi", ale "najit k danemu, urcitym zpusobem zformatovanemu textu jiny text zformatovany podle teze logiky, ale zmeneny dle Vaseho prani tak, aby hashe byly porad jeste stejne".
Rozdil je dosti znacny.
Je to asi jako rozdil mezi ulohou "najdete dva lidi, kteri se narodili ve stejny den" a "najdi dalsiho cloveka, ktery se narodil v ten samy den a hodinu co ja, bydli v prvnim patre, studuje obor XXX a pred tydnem ho vylili z druheho terminu zkousky". Na to prvni Vam staci par desitek pokusu, na to druhe abyste prosel peknou radku lidi, mozna i celou zapadni civilizaci :-) -
michal_sjx (neregistrovaný)Pokud jsem to spravne pochopil, tak kolizi lze najit pro jakoukoli vstupni hodnotu.
Zde jsou vytazky ze studii:
Metoda pracuje projakoukoli zvolenou inicializační hodnotu a je celkově rychlejší než původní čínská metoda[1].
http://cryptography.hyperlink.cz/md5/MD5_kolize.pdf.
Ukazujeme také dva kolidující certifikáty klíčů RSA a další souvislosti hledání kolizí MD5.
http://cryptography.hyperlink.cz/2005/ST_2005_08_14_15.pdf
A i kdyby platilo jen Vase tvrzeni tak,
kdyz si zalozim nejakou platebni spolecnost a umyslene vytvorim kolidujici par certifikatu a pak druhy certifikat prodam hackerovi, ktery ho vyuzije... tak vysledne na tom lidi ztrati duveru a penize. A ja jako utocnik budu jeste zahrabany v penezich. Ale tohle je myslim uz "nepopiratelnost" :) -
Marian Kechlibar (neregistrovaný)Dobrý den,
druhý jmenovaný link nefunguje (404 not found). Nemáte soubor na disku? Ocenil bych jeho zaslání na inglor at seznam.cz.
Pod pojmem inicializační hodnota není myšlena hodnota výsledného MD5, ale hodnota, na niž
se inicializuji buffery hashovací funkce. Viz RFC 1321, definující standard MD5:
3.3 Step 3. Initialize MD Buffer
A four-word buffer (A,B,C,D) is used to compute the message digest.
Here each of A, B, C, D is a 32-bit register. These registers are
initialized to the following values in hexadecimal, low-order bytes
first):
word A: 01 23 45 67
word B: 89 ab cd ef
word C: fe dc ba 98
word D: 76 54 32 10
Naráží se na ni proto, že v původním čínském článku převrátili pořadí bajtů v těchto čtyřech integerech. -
Marabu (neregistrovaný)To že je metoda rychlejší vám mnoho nepomůže. Cílem není najití kolize, ale najití kolize pro takový řetězec, kterým můžete původní nahradit. Jistě se shodneme na tom, že pokud najdete kolizi pro zprávu "Setkání provedeme v Praze, Čínské čajovně v Dejvicích v 14:30" ve znění "*h7{'y ░«]"§ 2wUj║:", pak jste si moc nepomohl ;) A to ani v případě, že tuto kolizi najdete o dvě hodiny dřív.
-
nobody (neregistrovaný)Ale pomuze Vam to v pripade, ze staci puvodni text zamenit za "Setkani provedeme v Brne, U soudku v 11:00. Komentar ktery se nezobrazi %*@*&DJU@%SJ55&$%!".
Problem pak nastane ve chvili, kdy zprava se dale formatuje (HTML, PDF, DOC,...) a komentare ci jiny balast se nezobrazi. V takovem pripade nema obycejny uzivatel sanci zjistit, ze se nejedna o puvodni zpravu. -
Objevil se tu názor, komu že je ten článek určen: "Ti, co to ví, to nepotřebují a ti, co to neví, si nezaslouží, aby to věděli." Omlouvám se za poněkud hrubé zjednodušení, ale podstatu to odráží. V tomto i v jiných případech je nejvyšším rozhodcem uživatel. On a jedině on, nikoli administrátor nebo hacker, rozhoduje o tom, jestli stiskne tlačítko OK. To, že je to největší "blbec" v řetězci zainteresovaných techniků, administrátorů, hackerů a jiných, kteří siť vybudovali, spravují a hackují, je úplně jedno. On musí rozhodnout. A k tomu musí mít možnost se někde něco dozvědět, co že to vlastně tím podivným "velkým červeným tlačítkem" spouští, když ho stiskne. Kdyby tam to tlačítko nebylo, tak bychom ty uživatele vlastně už nepotřebovali. Takže závěrem: je to potřebná a navíc velmi dobře podaná informace. Ondro, je to pěkné, těším se na další články, Vlastimil Klíma.
-
anonymníSpojeni SSL je bezpecne natolik, nakolik jsou bezpecne obe strany retezce (!).
Typicka situace je se SSH, kdyz uzivatel (a nemusi to byt nutne uplny d*ebil) mavne rukou nad zmenou serveroveho fingerprintu a zli hosi maji lokalni account.
Man-In-The-Middle rulez.
Z toho plyne moralni ponauceni: OSVETY NENI NIKDY DOST -
JD (neregistrovaný)Nebo alespon ukazat nejakym smerem. Jak to vyresit bez self-signed certifikatu tam, kde zaplaceni komercniho certifikatu nema opodstatneni (napr. pristup do redakcniho systemu, ktery vyuziva omezeny a vicemene predem definovany okruh lidi)
Jedine reseni ktere me napada je vytvoriv vlastni CA a jeji verejny klic dat kazdemu komu davam pristup pres https dat na diskete/CD. Ale to jde pouze pokud pripustim premisu pouze omezeneho poctu uzivatelu a ne public pristup.
PS: mimochodem stejny utok je mozno provest na SSH. Kdo si kontrolujete fingerprint klice pri prvni prihlaseni na SSH? -
ventyl (neregistrovaný)1) aj ked som uz o tejto problematike cital, hodnotim tento clanok pozitivne, je dobre, ze sa podobne informacie objavuju aj mimo vysoko specializovanych kanalov.
2) osobne by som povedal, ze certifikaty https ma velmi nezaujimaju a odklikavam ich vacsinou s odpovedou "akceptuj pre toto sedenie", kedze okruh serverov s SSL, ktore navstevujem nepredstavuje nijako zavazne zalezitosti (ziadny e-banking, ziadne citlive udaje), naproti tomu SSH mam zabezpecene klucami, ktore mi doniesli majitelia serverov osobne na usb klucoch. V pripade, ze kluc nesedi, okamzite daneho administatora kontaktujem.
Takyto clanok je dobry hlavne na to, ze z bezneho bezpecne sa citiaceho uzivatela vytvori dostatocneho paranoika :) Svet bude bezpecnejsi :)))) -
Neda mi to, abych neupozornil na zajimavou situaci a to presne v duchu tohoto clanku ...
Pokud se totiz chcete podivat na mnou doporuceny clanek v dnesni zpravicce (Neudělení víza prof. Wangové neuchrání americký národní standard SHA-1 od pohromy ...), kter je na adrese :
https://www.financialcryptography.com/mt/archives/000533.html
SHA1 attack updated at Crypto, US responds by stifling research
na Financial Cryptography,
pak pri sestaveni SSL komunikace se objevi:
a) Nejsou k dispozici informace o odvolani certifikatu..
b) Název uvedený v certifikátu zasbezpečení není platný nebo neodpovídá názvu serveru.
c) A navic použitá hašovací funkce je MD5
Docela pekna ukazka ruznych moznych problemu, ze ... -
Bilbo (neregistrovaný)> b) Název uvedený v certifikátu zasbezpečení není platný nebo neodpovídá názvu serveru.
Jo, nazev serveru je financialcryptography.com (bez toho www) a pokus o pristup je na www.financialcryptography.com
Kdyz odtipnu www tak tohle varovani zmizi (pak uz mi to hlasi jen neco o neduveryhodne autorite)
Coz je bohuzel problem SSL ze tak nejak nepocita s virtualnimi servery, protoze v momentu navazovani spojeni nevi jestli pristupuji na www.financialcryptography.com nebo financialcryptography.com (dns ukazuje na jednu IP adresu a Host hlavicku jeste klient neposlal pac teprve navazuje spojeni) No a server nevi ktery certifikat mu predhodit ... tak zkusi financialcryptography.com ... a tesne vedle :O)
Bohuzel diky tomuhle nedostatku v navrhu SSL pak je potreba mit pro kazdy virtual vlastni IPcko .... a pokud mam stranky typu treba (cokoliv).firma.cz a tech ruznycxh cokolivu je treba 100 tak abych mel 100 ipcek a 100 certifikatu ... skoda ze nejde vydat certifikat i pro nejaky wildcard nebo regularni vyraz :o) -
sss (neregistrovaný)Ako ale vytvorit certifikat, ktory moze pouzit server s virtual hostami, ked sa kazdy vola inak? Ak sa prida novy virtual host, treba nanovo vydat certifikat, kde je tento zahrnuty?
Lebo neda sa zabezpecit, aby mal kazdy host samostatny certifikat, lebo server dopredu nevie, ktory host je pozadovany pocas vytvarania spojenia ale az v HTTP requeste. -
Jarek (neregistrovaný)Na to musis myslet pri vytvareni certifikatu a zahrnout do certifikatu vsechny potrebne Aliasy.
Pokud pridas novy Virtual, ktery tam neni, musis proste vymenit certifikat. Pokud maji klienti naimportovanou certifikacni autoritu, kterou jsou tve certifikaty podepsany, tak to ani neni velky problem a klienti to skousnou. -
Bilbo (neregistrovaný)No, to je pravda, taky reseni, akoratze u hostovani vetsiho poctu stranek je to fura jmen ... takze server posle treba 30Kb velky certifikat nez se vubec navaze spojeni :O)
Ono vsechny reseni tohohle problemu maj nejakou slabinu (velky certifikat, samostatne ipcko ...) ... nejlepsi by bylo asi zmenit trochu HTTPS aby se posilal host pred certifikatem, ale to asi neprojde :o) Uz aby tu bylo ipv6 ..... -
m (neregistrovaný)urcite by sa oplatilo kopiu clanku poslat do VUB banky. uz riadne dlhu dobu ma irituje to, ze na internet bankingu pouzivaju vlastu CA, ktora samozrejme nie je v browseroch importnuta by default. tazko verit organizacii, ktora nema certifikat podpisany nejakou trusted CA.... hlavne, ked ide o banku a moje peniaze.. je to smutne :( (pozrite www.vub.sk -> internet banking)
a este by snad stalo za to spomenut aj nejake revocation listy, pre ujasnenie toho, ze neplatne/ukradnute certifikaty je samozrejme mozne aj blokovat a rusit.
ale jak uz bolo niekde spomenute, osveta je velmi dolezita. clanok pekne vystihuje najdolezitejsie veci. -
IMS (neregistrovaný)Dovolim si polemizovat s tymto nazorom. Na com sa zaklada doveryhodnost CA importnutych ako default? Na tom, ze si niekto raz niekde v USA povedal, ze toto su tie prave a ine nie, lebo takto si primarne zabezpecia svoj obchod? Samozrejme nepopieram, ze CA importnute ako default maju svoju tradiciu, doveryhodnost a bezpecne procedury na vydavanie certifikatov. Primarne je to vsak len a len o obchode a peniazoch.
Keby si VUB zaplatila u Mrkvosoftu import svojej root CA ako default, potom by u Vas zavladla spokojnost?
Podla mna je to len o lenivosti pouzivatelov. Osobne v tomto pripade viac doverujem certifikatu, ktory vydala banka, ktora je pod kontrolou regulacnych organov a musela svoju CA postavit podla zakona. Inak nic Vam nebrani importnut si root certifikat CA VUB do svojho browsera podla navodu na strankach banky (http://www.vub.sk/Show.asp?category=607) a overit si tam aj fingerprint. Skoda len, ze fingerprint nezverejnila aj inym sposobom, aby sa dal overit z viacerych zdrojov.
Este jedna poznamka na zaver. Preco sa buduju pre potreby zaruceneho elektronickeho podpisu akreditovane CA? Podla Vasej logiky by nam mali stacit tie CA co su default vo Vasom browseri a netreba nic budovat. -
m (neregistrovaný)nic v zlom, ale CA vub nie je akreditovana a vobec jej samozrejme neverim, pokial som jej certifikat stiahol z webu (to mi odporucaju aj na vami zmienovanej stranke).
takze urcite viac verim autoritam, ktore mam importnute by-default vo viacerych browseroch, pouzivanych world-wide ako nejakemu certifikatu, ktory si mozem overit akurat niekde na webe, z ktoreho bol stiahnuty..
podla mna toto nie je spravne pouzivanie ssl a pki. pokial by mi pri podpise zmluvy dali usb klucik alebo disketu s certifikatom, nepovedal by so o bezpecnosti ani slovo, len o "pohodli", ale v tomto pripade, nehnevajte sa na mna, sa o bezpecnosti zdaleka neda hovorit. -
IMS (neregistrovaný)Fingerprint sa da overit aj telefonicky v call centre (je to napisane na webe VUB).
Neviem aky je momentalny stav, ale pokial viem, tak klient mohol poziadat aj o vydanie certifikatu na cipovej karte, ktoru dostane od banky. Tak to robia aj ine banky.
Inak vseobecne k IB bank. VUB nie je jedina v SR a CR, co pouziva vlastnu certifikacnu autoritu.
Ak jej tak neverite, tak si mozete vybrat inu banku, ktora ma certifikat od default CA.
Ja sa len cudujem odkial beriete tak skalopevnu doveru v tie default CA, lebo princip hry je stale rovnaky.
Skusali ste si niekedy poziadat o firemny certifikat napr. od VeriSgn a zistili postup ako funguje overenie Vasej identity?
CA postavene u nas podla zakona museli vsetky prejst auditom NBU.
Viete kto overuje dodrziavanie procesov u default autorit?
Osobne si myslim, ze bezpecnost internej bankovej CA a CA, ktoru mate default je na rovnakej urovni. Urcite by som vask neveril certifikatom, ktore vydala CA postavena na MS Windows.
V konecnom dosledku najpodstatnejsie z tohto celeho je, kde si Vy ako klient generujete privatny kluc. To uz ale nie je primarne o SSL, aj ked to s tym suvisi. -
haremheb (neregistrovaný)ja som klient VUB a tiez ma to stve.
Rad vam poviem odkial beriem skalopevnu doveru v default CA: su zabudovane v browseri. Ak ste citali clanok, je vam jasne, ze sice "CA postavene u nas podla zakona museli vsetky prejst auditom NBU." ale ak sa prihlasujete ku el. bankovnictvu prvy krat a este nemate importnuty certifikat, tak aku mi date zaruku ze web stranka VUB CA neni sfalsovana ??? jedina zaruka je naozaj zavolat do VUB a overit si fingerprinty. A ak ste citali pozorne, vacsina userov klikne na OK bez rozmyslania, a o overovani HASH sa im ani nesnivalo. Coz dava potencialnemu utocnikovi poriadne sance. Takze ani nahodou neplati, podla mna, ze "Osobne si myslim, ze bezpecnost internej bankovej CA a CA, ktoru mate default je na rovnakej urovni." - z hladiska certifikatu ano, z hladiska mozneho utoku NIE.
Samozrejme, bolo by mozne zmenit vstavane certifikaty browsera alebo nanutit userovi pozmenenu verziu na stiahnutie, ale toto ma podstatne mensie vyhliadky na uspech. Vacsina userov pouzije bez rozmyslania vstavany browser v OS a hotovo.
Takze preto. -
Marian Kechlibar (neregistrovaný)Vážený pane Stworo, nastavení, které popisujete, se týká protokolů SSL/TLS. Jsou to protokoly, umožňující bezpečně prohlížet WWW stránky. Kdykoliv přistoupíte na stránku začínající https://, používá se SSL či TLS (jeho nástupce). V rámci protokolu SSL či TLS se server autentizuje klientovi, který na něj přistupuje, tím, že mu zašle certifikát serveru. To se děje při každém spojení, a tak se běžně SSL/TLS používá. Server tedy musí mít certifikát, mít ochotu jej vydat klientovi, a klient musí mít schopnost tento certifikát nějak zkontrolovat. Naproti tomu naprostá většina WWW serverů nepožaduje, aby se klient autentizoval rovněž. Klient tedy nemusí mít certifikát, a zůstává v relativní anonymitě - je známa jeho IP adresa apod., ale není jisté, kdo to přesně je. V rámci definice protokolu SSL/TLS je pomýšleno i na možnost, že server bude chtít po klientovi, aby se autentizoval certifikátem. Může tomu tak být například, přistupujete-li přes WWW do databáze svého zaměstnavatele, k níž se nesmějí dostat nepovolané osoby (tento přístup se většinou ale stejně řeší jinak - heslem; toto je teoretický příklad!). V takovém případě musíte i Vy mít na svém počítači certifikát, který počítač v rámci "handshake" zašle serveru, a který Vás identifikuje. Tato možnost je jen málo využívaná v "lidském světě", neboť na rozdíl od jiných možností kontroly přístupu (hesla, kódy zasílané přes SMS) je dost nepružná a zajišťuje spíše identitu počítače než člověka, který u něj sedí. Z tohoto důvodu ji pravděpodobně nebudete nikdy v životě potřebovat. Jak je to mezi servery, to nevím. V případě, že by přeci jen nastala situace, kdy byste certifikát potřeboval, vydá Vám jej organizace, která jej bude potom požadovat k autentizaci. Pokud si jej vygenerujete sám, oprávněně mu druhé strany nemusejí důvěřovat (samopodepsaný certifikát má asi stejnou výpovědní váhu jako tvrzení "já jsem já, protože to říkám já").
-
pokud si jej vygenerujete sam ... Jenom doplneni: klic pro dany certifikat si snad generujete vzdycky, certifikat je o tom ze vam ten klic nekdo podepise. Neduveryhodny certifikat je takovy, ktery neni podepsany nekym duveryhodnym, nikoliv takovy, ktery je podepsany sam sebou. Takze i kdyz si udelate bezny self-signed certifikat, porad muzete zvysit jeho duveru tak, ze si ho nechate dodatecne podepsat. Pochopitelne pokud presvedcite CA, aby ho podepsala - predpokladam, ze to bude o neco tezsi nez standartni postup.
V PGP/GPG je to jednodussi ... tam je self-sign automaticky. Jenze v PGP/GPG nejsou ty prachy, protoze kazdy klic jde vyuzit ke vsemu, zatimco v SSL si CA necha zaplatit co vam s tim klicem povoli delat. -
Teddy (neregistrovaný)Dakujem autorovi za tento clanok, uzaj posielam linku do VUB-cky. Ich internet banking je totiz krasny priklad na to, co autor nazval "takmer self-signed certifikát" (vydane akousi "1 CA VUB", cize VUB vydala sama sebe certifikat ze je VUB).
Hovoril som s niekolkymi "expertmi na bezpecnost" z VUB, ale ani po niekolkych hodinach rozhovoru som ich nebol schopny presvedcit o tom, ze ten ich internet-banking predstavuje "vdaka" tomu ich self-made certifikatu bezpecnostne riziko. Dufam, ze ked si ti ich "experti" precitaju tento clanok, tak konecne pochopia, o co ide... -
IMS (neregistrovaný)Polozim kacirsku otazku?
Kto podisal certifikat Root CA napr. VeriSign?
Root CA si vzdy podpisuje certifikat sama sebe.
VUB ma postavenu vlastnu RootCA, ktora podpisala certifikat pre podriadenu CA, ktora podpisala certifikat pre SSL.
Takze nie je to jeden self-sign certifikat.
Ked uz som pritom VeriSign, tak v clanku je pekny priklad jednej default "doveryhodnej" CA, ktorej certifikacne a overovacie procesy akosi nezafungovali, ked chlapik ziskal pár certifikátov od VeriSignu ako fiktivny clovak z MS. -
haremheb (neregistrovaný)Akurat to ma hacek:
1. Certifikaty VeriSign su zabudovane do browsera, a silne pochybujem, ze by ich vedel niekto zmenit cez nevybudovane SSL spojenie....
2. certifikat VUB je podpisany certifikatom VUB CA. no a pr**er je v tom ze certifikat VUB CA je SELF-SIGNED. takze bezpecnost certifikatu VUB je ekvivalentna typu self-signed.
3. A okrem toho, poznate postup VeriSign pri overovani ziadatela ??? To nie je "vyplnim formular na webe a poslem". Chlapik mohol byt sice vtipalek, ale podla mna musel mat velmi dobre kontakty v Microsofte alebo priamo vo VeriSign, aby sa dostal k potrebnym udajom, pripadne je extremne nadany v tzv. socialnom inzinierstve :-)))). -
ivan (neregistrovaný)ad3.
A ako sa potom stalo, ze Verisign vydal neprave (nie na zaklade Microsoftu) certifikaty Microsoftu, Microsoft to potom riesil v XP tak, ze doplnil ulozisko Untrusted publishers, kde tieto falosne certifikaty zaradil (mozete si overit) aj je k nim nastavene Fraudulent, NOT Microsoft Friendly Name, je to ulozisko CryptoAPI, takze si to pozriete len v IE, ostatne prehliadace (nepouzivajue MS CryptoAPI) toto nenimplementovali.
Spravna otazka znie: "Ako su chranene CA kluce, ktorymi sa podpisuju certifikaty?" a to na vsetkych urovniach (min. Cipova karta / token, lepsie HSM modul s FIPS).
Zalistovanie CA do IE si moze zaplatit kazdy, je to komercna zalezitost a u distribucii s otvorenym kodom moze byt upravena distribucia tak, aby tam ten ca certifikat bol (a kde je tu zaruka doveryhodnosti).
Co ak sa nejakym trojanom do uloziska CA certifikatov naimportuje falosny certifikat ? Kontroloval si niekto niekedy ci certifikaty z uloziska su naozaj prave ? A to nemusi byt ani trojan, niektory chronicky klikaci si improtnu CA certifikat ani nevedia ako. Takze argument "je to bezpecne lebo CA certifikat je zabudovany do browsera" stoji na vode. To uz si radsej vyhadzem vsetky CA certifikaty a dam si tam len tie, ktore potrebujem a z casu na cas si skontrolujem ich hashe. -
Inak sorry, ze som sa o den oneskoril, ale vcera mi net trucoval a neslo mi postnut prispevok.
Vlastne na vsetky otazky uz v podstate odpovede zazneli, tak to zhrniem (hromadna odpoved ;-)).
Komu je clanok urceny:
Pytal som sa pred napisanim niekolkych ludi (programatorov), ci o takom vedeli. Myslim, ze cela technika nie je nijak extra svetoborna, kazdy, kto si precita manual iptables a stunnelu, na to pride. Ale prave preto som tam nedal priamo zdrovoje kody (parriadkove skripty), len obrazok. Kto to chape, ten to vie zrekonstruovat. Myslim si, ze pri bezpecnosti clovek musi vediet techniky utocnikov - "know your enemy", pozrite aj Sun Tzu security strategies, co su spominane vo vcerajsich (22.8.) bezpecnostnych stripkoch.
Inteligentne riesenie bez komercneho certifikatu:
Zavisi od konkretneho pripadu. Ked mam server, kde bude pouzivat SSL len par ludi (napr. pomocni admini), tak by som si vytvoril vlastnu certifikacnu autoritu a kazdemu cloveku jej korenovy certifikat donesiem osobne.
Ak je urceny pre viac ludi a stale nechcem platit za komercny certifikat, na hlavnej stranke uvediem, kde sa da certifikat zohnat a jeho fingerprint. Najidealnejsie, ked je korenovy certifikat na fyzicky jednom serveri a fingerprint zverejneny fyzicky na druhom serveri - je tazsie zautocit na dva servery sucasne a zmenit aj certifikat aj fingerprint.
Ako postupovat pri prvom pripojeni na ssh/ssl, ked kluc/certifikat nemozem overit:
Toto je dost tazke, az skoro nemozne. Ale vzdy je lepsie vediet o nebezpecenstve ako mat pocit falosnej bezpecnosti. Takze situacia:
Logujeme sa prvy krat cez ssh na server a nevieme overit jeho kluc, pretoze sme ho este nikdy nevideli a nikde nie je zverejneny jeho fingerprint. Najlepsie je samozrejme vypytat fingerprint kluca od admina. Ina moznost na znizenie rizika (ked nejde hned zohnat fingerprint):
1. iniciujeme spojenie na server, pozrieme sa na fingerprint kluca, zrusime spojenie
2. nalogujeme sa cez ssh na uplne iny server (ktoreho kluc uz pozname) a z neho tiez iniciujeme spojenie na server s neznamym klucom, pozrieme fingerprint kluca. Podmienka je, aby iny server bol na uplne inej trase (prechod paketov inymi routermi).
3. ak v oboch pripadoch je fingerprint kluca rovnaky, je velka pravdepodobnost, ze tam ziadny man-in-the-middle nesedi (ak nesedi na poslednych hopoch, ktore su pre obe cesty rovnake). Je mozne pre istotu opakovat s viacerymi pocitacmi.
4. fingerprint kluca si niekde ulozime. Pokial to zrovna nepotrebujeme, tak sa na server s neznamym klucom nelogujeme, inak tam aspon neposielame citlive informacie. Za par dni (opakovane) skontrolujeme, ci sa fingerprint nezmenil. Ak sa zmenil, je to dost podozrive.
5. pokusime sa fingerprint kluca od admina vypytat (a porovnat), lepsie je to samozrejme pred prvym pripojenim, ale nie vzdy to ide
6. je dobre nosit known_hosts subor napr. na usb klucenke
Tento popisovany sposob tiez nie je samozrejme 100% bullet-proof, ale je sanca utocnika odhalit, takze vieme, ze napr. treba zmenit heslo alebo ze informacie, ktore sme na server poslali, mozu byt kompromitovane. Inak kludne skritizujte, ale zatial to je asi najlepsi sposob, co poznam, ked sa neda zohnat fingerprint kluca. Obdobne sa to da spravit so SSL. -
JCC (neregistrovaný)Vsetko je jasne.
Ale.
Nerozumiem ako sa overuj fingerprint dakeho certifikatu?
1. Prihlasujem sa do banky
2. Browser otvori stranku, dole vidim zamocek.
3. Poklikam po nom a mam info o certifikate a je MD5 a SHA1 fingerprint. Ale s cim ho mam porovnat? Kde ho mam porovnat? Pozeral som stranku VeriSign a nikde som tam nenasiel zoznam fingerprintov.
A ked uz bude daky utocnik odchytavat moju komunikaciu na routeri, nebude pravdepodobne, ze mi podstrci aj stranku www.verisign.com?
Pytam sa preto, lebo velke nebezpecenstvo utokov je na Wifi hotelovych sietach. Kde daky dobrodinec - dalsi host podstrkuje pakety a tvari sa ako AP. -
haremheb (neregistrovaný)Presne to iste sa stalo mne ako Teddymu.
Mam ucet vo VUB, a stale ma to ***ie, aj som im posielal konkretne maily v ktorych som im povedal ze ich el. bankovnictvo je zranitelne voci utoku typu "phishing" (ok nie je to asi phishing ale podstata je podobna), no samozrejme ma zmietli zo stola so siahodlhym emailom o phishingu a pharmingu a pod...... skratka "odbornici" (je problem v tom ze sa stale vyjadrujem ako student a nie Pan Inzinier ???)
co dodat. si nemaju 200 Eur (alebo kolko to treba) na certifikovanie svojej pos****ej CA. Ale s vedomim ze bezia kompletne na M$ "produktoch" ma to vobec neprekvapuje.
ČLÁNKY DO MAILU