SSL - je vaše bezpečné připojení opravdu zabezpečené?

15. 6. 2006 | Tomáš Bartoň | Bezpečnost | 21164×

"Nějaký bezpečnostní klíče mi můžou bejt ukradený" řekne si průměrný uživatel počítače a zvesela odklikne firefoxí varování o neověřeném klíči a odešle nevědomky svá data prvnímu snifferovi na lince. Bylo to opravdu nutné? Stačilo pouze kliknout o jediné tlačítko vedle a jeho data by zůstala v bezpečí...

V tomto případě tkví problém v nevědomosti uživatelů, kteří většinou netuší, že připojení zabezpečené pomocí SSL je možné obejít několika docela jednoduchými triky. Ten nejjednodušší bych v modelové scéně popsal.

Mějme situaci, kdy se útočník dostane na router, firewall (či nějaký jiný průchozí stroj). Může pomocí sniffování získat veškerá data procházející počítačem, pokud nejsou zašifrována. Když ale vidí, že se někteří uživatelé připojují na služby zabezpečené pomocí SSL, má v zásadě dvě možnosti. A to vykašlat se na to, nebo 'přepojit' uživatele přes svůj vlastní rádoby SSL server. A jak teď na to? Více napoví následující vyobrazení (berme v potaz https připojení):

Nákres zpracoval Richard "Ricardo" Szlachta

Jak je vidět, uživatel si pouze myslí, že se připojuje k serveru, zatímco je napojen na záškodnické zařízení, kde je jsou jeho data rozšifrována, přečtena, znovu zašifrována a odeslána na server.

Nejdříve je tedy potřeba uživatelskou komunikaci přesměrovat někam, kde se s ní dá pracovat. Třeba na localhost routeru. To provedeme jednoduchou změnou netfilteru:

iptables -t nat -I PREROUTING -d server -p tcp --dport 443 \
         -j DNAT --to 192.168.100.1:1111

Nyní pokaždé, když se uživatel připojí na server, bude cesta jeho dat končit na portu 1111 v routeru. Sem musíme připojit koncové zařízení SSL, ke kterému bychom napojili uživatele. To uděláme pomocí programu stunnel, který se používá k 'obalování' nešifrovaného toku dat SSL vrstvou. Vytváří něco jako tunel, jehož jedna strana je šifrovaná a druhá ne. Jeho použití:

stunnel [-d [ip:]port -r [ip:]port -c]

     -d [ip:]port    port k naslouchání na localhostu. Parametr ip,
                     pokud není uvedeno jinak, je localhost.
     -r [ip:]port    port a ip, na které se má stunnel připojit,
                     pokud mu přijde spojení na naslouchací port
                     (uvedený parametrem -d). Ip, pokud není
                     uvedeno jinak, je nastavena na localhost.
     -c       stunnel se bude chovat jako klient. Určuje,
                     na které straně bude spojení šifrované pomocí SSL.
                     Pokud je uvedené, bude šifrovaná strana vzdálená
                     (určená parametrem -r), výchozí je spojení
                     šifrované na straně naslouchací (-d).

Pozn. Já používám verzi 3.26., protože nová verze používá místo klasického nastavení pomocí konfiguračních parametrů jakési soubory, které jsou podle mne zdlouhavé na tvorbu. Nicméně, pokud by někdo chtěl použít novou verzi, tak ho mohu odkázat na manuál k stunnel ;-).

Pro správné fungování stunnel jako serveru je ještě nutné vlastnit podepsaný certifikát. Je možné vytvořit vlastní, nicméně to má docela velkou chybu, o které ale až ke konci článku. Ať už někde certifikát seženeme, či si vytvoříme vlastní, je potřeba ho programu stunnel představit. A to buď nahrát do výchozího umístění (u mne /etc/ssl/certs/stunnel.pem) nebo určit pomocí parametru -p.

Pro naše účely tedy použijeme:

stunnel -d 1111 -r 1112

Nyní máme na portu 1112 nešifrovaná data. Ta je potřeba ale zase zašifrovat a poslat k serveru:

stunnel -c -d 1112 -r server:443

Toto lze použít pouze v případě, kdy má router stejnou IP adresu, jako by měla data před naším zásahem -> tzn. je routerem. Pokud to tak není, je třeba ještě správně nastavit zdrojovou adresu, aby to na serveru nevypadalo moc podezřele...:

iptables -t nat -I POSTROUTING -p tcp --dport 443 \
         -d server -j SNAT --to client

Nyní už stačí jen spustit sniffer na portu 1112 a máme veškerá data uložena na disku.

Má to ale celé jeden háček. Pokud nepoužijeme v stunnel certifikát podepsaný nějakou autoritou, bude uživatel upozorněn a vybídnut k odmítnutí spojení a proto touto technikou nedokážeme ošálit pozorného uživatele, který nebude zbrkle klikat ve svém prohlížeči na "Přesto přijmout" a námi podvržený certifikát odmítne.

A jak se proti něčemu takovému bránit? Velice jednoduše. Ať už SSL používáme pro cokoli, je vždy vhodné si zkontrolovat informace o použitém certifikátu, nebo se alespoň nechat upozorňovat na změnu v certifikátu a cokoliv podezřelého odmítnout!

Závěr

Doufám, že článek dal někomu potřebné informace k udržení svého soukromí v hlubokých vodách internetu plných zrádných mělčin a dravých žraloků. Důležitost SSL není vhodné opomíjet, pokud nám na našich datech záleží...

       

Komentáře

[washeck]

Když už někdo píše o SSL, měl by si zjistit, jaký je rozdíl mezi šifrováním a kódováním. Klidně se vsadím, že kódováná jsou i data uživatelů, kteří na bezpečnost kašlou :)

[camlost]

Přesně tak.

Mimochodem, dosud jsem žil v domění, že abclinuxu.cz už vyrostlo z období, kdy bylo jen pro pár pubescentů, u nichž lze vazby ve stylu "může se na to vykašlat" tolerovat. Ale asi se pletu. Mizerný článek.

[Robert Krátký]

Vítám konkrétní připomínky k článkům. Jenže v tvém příspěvku vidím spíše všeobecné plivnutí než rozumnou kritiku. Pokud tvému jemnocitu nesedí použití hovorové mluvy, je mi to líto a beru to na vědomí, ale přesto jsem přesvědčen, že se nejedná o nic nehorázného. Pokud se však ozve více lidí, příště autorům podobnou věc v článku neponechám.

Máš nějaké další výtky, které by vysvětlovaly tvé tvrzení, že jde o "mizerný článek"?

[Tomáš]

Přimlouvám se za nahrazení kódování -> šifrování. Přeci jenom jsou to dvě odlišné věci a i člověk neznalý věci zná slovo 'šifrování'.

[hwsoft]

Z meho pohedu dobry clankek pro normalni ctenare, guru ho nepotrebuje, guru vi.

Nektere fakticke postrehy tu jsou, ale je pravda, ze obcas je dobre dat nektere vyrazy do uvozovek, aby nektere lidi nedrazdily.

[camlost]

Roberte, promiň, ale pokud někdo napíše, že je článek mizerný, objeví se pod tímto komentářem tvá reakce ve stylu "vítám konkrétní přípomínky, ale u tebe vidím jen plivnutí" (tohle není první případ - a ne, skutečně nebudu procházet diskuse a hledat, kde jinde jsi to napsal).

Co ti připadá nekonkrétního nebo příliš obecného?

Jednak jsem neopakoval obsah příspěvku, na který jsem reagoval, místo toho jsem s ním vyjádřil souhlas. To mi připadá poměrně konkrétní.

Co se týče těch výrazů... tobě se to líbí, mně ne. S pocitem, že máš jiný vkus, dokážu žít docela dobře.

A k vlastnímu článku... když někdo popisuje man-in-the-middle attack, resp. postup, jak ho provést, pro koho je tento článek určen? Pro běžného uživatele? Nebo pro admina, čili člověka s poměrně hlubokými znalostmi v oboru? Já jsem tam čekal něco pro toho admina. No... a z článku jsem si odnesl jen to, že když chci použít stunnel, mám se mrknout do manuálu na parametry. Hmmm. Promiň, ale to je málo.

Mno, takže když vezmu v úvahu obsah a formu, výsledný dojem je špatný. Ale je to jen můj názor, se kterým samozřejmě nemusí nikdo další souhlasit. Ostatní reakce jsem zatím nečetl, tak nevím, jestli jsem jediný.

Koneckonců, jsi šéfredaktor (?), takže pokud chceš jen oslavné komentáře, tak mi administrativně zakaž přispívat, nebo diskuse moderuj a nevhodné příspěvky maž.

[Robert Krátký]

V tomto tvém komentáři se dozvídám důvody toho, proč jsi článek označil za mizerný. Máš pochopitelně možnost i právo o článku napsat jen to, že ti připadá mizerný a dál to nerozvádět, ale pak mi to přijde vůči autorovi nefér. Nemyslíš, že by bylo lepší napsat ty důvody rovnou do prvního komentáře?

pokud někdo napíše, že je článek mizerný, objeví se pod tímto komentářem tvá reakce ve stylu "vítám konkrétní přípomínky, ale u tebe vidím jen plivnutí"

Ano, pokud se skutečně jedná o pouhé plivnutí. Reaguji tak tehdy, když někdo vloží pod článek komentář, ve kterém není kritika, nýbrž pouhé odsouzení - aniž by připojil, co ho k takovému hodnocení vede. Kdyby sis přeci jen chtěl dát tu práci s prohledáváním diskuzí, objevil bys také spoustu kritických komentářů, ke kterým jsem se nijak nevyjadřoval. To proto, že v nich bylo řečeno, co je na článku špatného. Pak nemám důvod se autora zastávat, protože je na něm, aby svůj výtvor obhájil.

Koneckonců, jsi šéfredaktor (?), takže pokud chceš jen oslavné komentáře, tak mi administrativně zakaž přispívat, nebo diskuse moderuj a nevhodné příspěvky maž.

Připadáš si ukřivděně, že jsem se ozval proti tvému komentáři, a proto teď vymýšlíš podobné nesmysly? Ty jsi plivl na článek, mně se to nelíbilo; tak nebuď ublížený a nepodsouvej mi nějakou administrátorskou zvůli.

[camlost]

Ale vubec ne (dnes pro zmenu bez diakritiky). Uz jsem absolvoval tolik flamewars (LianeBBS napr., board czflames ), ze si ublizene oprvdu nepripadam. Ber to jako uprimny navrh, jak lze resit nastalou situaci.

Mimochodem, uz jsme hodne daleko od tematu, navrhuju, abych v pripade potreby pokracovali jinde (mail na me mas, takze treba tak).

[tommz]

Omlouvám se Vám, že jsem se snažil článek trochu zdramatizovat, příště se to rozhodně už nestane.

ad. kódovaní x šifrování : Pro normálního člověka jsou tato dvě slova stejného výrazu. Pro mne taktéž. Zakódovat nějaký text x Zašifrovat nějaký text. Jaký je mezitím rozdíl ? Prakticky žádný ... A navíc nemám rád, když se jedno slovo v textu přílišně opakuje.

[Robert Krátký]

Jaký je mezitím rozdíl ? Prakticky žádný ...

To bohužel není příliš šťastný přístup, protože ačkoliv je v kontextu článku zřetelně patrné, co je tím myšleno, přesto nejde o synonyma.

[Petr Tomášek]

Právě, že o synonyma jde. Ukazuje to, že jazyk je závislý na svém kontextu a nelze jej zakonzervovat do nějakého oficiálního slovníku!

[Hynek (Pichi) Vychodil]

Argument by nebyl. Dokud to nepodložíte nějakým argumentem, tak si to tu můžete napsat třeba stokrát. šifrovat a kódovat synonyma nejsou i kdyby jste se na hlavu postavil a argumentem je libovolná učebnice teorie informace.

[Sionex]

A co takle "Šifra mistra Leonarda" vs. "The Da Vinci Code" ... hm :) ?

[Martin Ždila]

napr.:

• text sa koduje pomocou ASCII tabulky do postupnosti bitov
• postupnost bitov sa sifruje pomocou SSL kluca

[Jan Kundrát (jkt)]

Omlouvám se Vám, že jsem se snažil článek trochu zdramatizovat, příště se to rozhodně už nestane.

Pokud narazis na ty hovorove vyrazy, smele v nich pokracuj.

[Petr Tomášek]

+1

[Filip Jirsák]

kódování = převod do nějakého systému znaků – např. kódování iso-8859-2, UTF-8, ASCII, quoted-printable, BASE64 atd.

šifrování = skrytí obsahu, utajení, s možností následného rozšifrování se znalosí správného klíče, hesla apod.

Každé je to něco úplně jiného, jaký je mezi nimi rozdíl rozumně popsat nedokážu, je to jako popisovat rozdíl mezi jablkem a krumpáčem

[Praedo]

Kódování a šifrování je naprosto stejná činnost, pouze se v různém kontextu pro tuto činnost používá různé označení, aby bylo zřejmé, za jakým účelem se tato činnost provádí. Kódování je převod symbolu na jiný symbol např. znak 'A' na 0x41. Stejně tak šifrování je převod symbolu na jiný symbol např. 'A' -> F#%.

[MaT]

Tak to prr, kódování a šifrování je opravdu něco jiného - a to dost podstatně. Pro laika může mít obojí podobný důsledek - že si to nepřečte. Ale v takovémto článku by se toto rozlišovat mělo - chcete poučovat laiky? Tak to snad neznamená, že musíte prznit terminologii...

Btw: "slova stejného výrazu" - považujete "výraz" za synonymum k "význam"? Já tedy ne. :o)

[Petr (DotaZ) Jakubec]

Nesmysl,

clanek je zajimavy. Sloh se treba da i vylepsit, ale necetl jsem to kvuli cestine. A kodovani/sifrovani? - nu tady to asi neokecame, to je treba opravit.

Clanek me tudiz zaujal. Jednoduchou pochopitelnou formou mi sdeluje, ze mam dbat na ty podivne okynka co mi vyskakuji pri pripojovani do banky

Jen mi tam chybi jak se da rucne overit certifikat, resp. proste vice rozvest ochranu proti tomuto "vylepsenemu" pripojovani.

[jacobs]

No to je prave problem vetisny podobnych clanku. Clanek jsem necetl cely (neprisel mi zajimavy), ale snad kazdy clanek se "sokujicim" odhalenim, ze i na SSL se da delat MIM konci v lepsim pripade s radou, ze mate kontrolovat fingerprint certifikatu nebo si nechat hlasit zmeny (coz v prostredi kde od zacatku pouzivani prohlizce nekdo dela MIM neni moc platne).

Ona asi ani lepsi obrana neni (nebo nekdo o necem vite?), ale za poslednich par mesicu jsem cetl par podobnych clanku a vsechny mely nadech reportazi z TV nova - odhaleni neceho sokujiciho, co tu s nami ale uz je vlastne od zacatku celeho SSL. Dokonce jsem byl cca pred pul rokem na nejake konferenci o bezpecnosti, kde neco podobneho na zaver predvadeli jako "hackovaci perlicku"

[Michal Kubeček]

Přesto to má smysl. Z vlastní pedagogické zkušenosti vím, jak podstatný rozdíl je například mezi tím, když někomu řeknete, že komunikace pomocí POP3/FTP/HTTP/… není bezpečná, protože se dá všechno snadno odposlechnout, a tím, když jim názorně ukážete to heslo pomocí etherealu nebo podobného standardního nástroje, který je prakticky v každé distribuci. Je to sice jen demonstrace, ale psychologický efekt je velmi výrazný.

[Jan Kundrát (jkt)]

Nesouhlasim, podobne vazby naopak velmi hezky ozivuji text.

[Espinosa]

Připojuji se k podpoře. Pokud se to nepřežene, a autor to nepřehnal, odlehčí to trochu jinak komplikovanou problematiku. Články na e-zinu jsou trochu něco jiného než manuál, úřední listina, nebo litera zákona.

[Jan Přech]

Taky si myslím. Jenom si vzpomínám, že se jednu dobu v Chipu (ještě v minulém tisíciletí, kdy jsem ten časopis četl), proměnily "Digitální fotoaparáty" v "Digitální foťáky", což byl posun, který už mi opravdu vadil. Ale v tomto případě úplně souhlasím s tím, že to autor nepřehnal a přijatelnou formou přistrčil svůj článek tam, kam svým zaměřením patří (na zem).

Mně se to líbilo.

[Mikos]

Také se připojuji k podpoře, článek napsaný hovorovou řečí se mi často líbí víc než suchý technický článek (ale nesmí v něm být faktické chyby... to šifrování/kódování by se mělo opravit).

Btw. vzkaz všem sucharům: Jděte do háje!

[shimmi]

I já se připojuji. I když vše bylo jinde již několikrát řečeno, článek je zajímavý. Jediná chyba je, že ža autor si popletl šifrování a kódování.

Jinak nemám rád navlékání se do kvádra a mluvení spisovně květnatě, za účelem zvýšení "profesionality" dotyčného. Ta je někde jinde.

[jacobs]

Ja naopak souhlasim. V tomhle kontextu mi prislo, ze to tam neplni ani tak ucel odlehceni jako spis ze to pak bude znit vic "cool". Just my 2 cents.

[Ricardo]

pubescentů

není člověk mezi 15 a 18 rokem života adolescent?

buď ty nebo já, jeden z nás dvou si plete pojmy a průjmy

[camlost]

PUBESCENT = klient ve vývojové fázi puberty. v jiném slovníku najdeš význam dospívající.

[Robert Krátký]

Dík, opraveno.

[Valoun]

Občas je částečně na vině i software. Vemte si třeba takový thunderbird. Používám v něm 4 různé IMAPy přes SSL. Ani jeden ovšem nemá nastvený SSL certifikát správně, a tak každé spuštění Thunderbirdu má za následek nutnost odklepnout 4 otravné dialogy.

Kdybych měl možnost zatrhnout - "přesto tomuto certifikátu věř, a zařvi teprve až se změní", tak bych třeba byl ochoten nad tím uvažovat. Takto prostě nemám zájem jakékoli SSL na vyšší úrovni používat (tj. kontrolovat certifikáty). Citlivá data zašifruji pomocí GPG a je vymalováno.

[Honza Jaroš]

Kdybych měl možnost zatrhnout - "přesto tomuto certifikátu věř, a zařvi teprve až se změní",

To jako něco takového (Thunderbird 1.5.0.4, ale chovalo se to tak i v 1.0.x)?

[Valoun]

Nikoli. Tohle když zatrhnete, tak to na Vás bude řvát dál, a to proto: certificate indicates to be coming from "nejaka.domena" but the server is "jina.domena", a proto musíš dát OK, nebo Cancel. Ale možnost "Neotravuj, už jsi mi to řekl 100000x" tam není.

[Honza Jaroš]

Jo tohle. To se kdyžtak nechá obejít, stačí se připojovat k názvu počítače, který je v tom certifikátu (v tomto případě je CN nastaveno na imap.jaros.org a v nastavení účtu mám jako IMAP server také imap.jaros.org). Pokud ten počítač nemá takový záznam v DNS, nastavte si příšlušný alias v hosts - ale v tom případě jde opravdu v první řadě o lajdáctví správce IMAP serveru.

[Honza Jaroš]

Aha, teď jsem se podíval na ten obrázek, localhost si asi opravdu pro něj jako alias v hosts nenastavíte...

Správce toho serveru je evidentně prase...

[Valoun]

Souhlasím, já samozřejmě vím, v čem je problém. Tady jde o to, že já jako uživatel to neovlivním, a TB mě s tím dál otravuje. Ačkoli by bylo možné říci "ručně", že daný certifikát k danému serveru opravdu patří.

Je to jak kdyby mi firefox nadával při každém zobrazení nevalidní stránky. Otravuje to život a k ničemu mi to dobré není.

PS: Sám ani mail server nastavit neumím, natož abych věděl, jak je možné nastavit jej tak, aby pro každou doménu posílal jiný certifikát (častý problém u hostingů)

[Honza Jaroš]

PS: Sám ani mail server nastavit neumím, natož abych věděl, jak je možné nastavit jej tak, aby pro každou doménu posílal jiný certifikát (častý problém u hostingů)

Nevím, já sice doma provozuju na jednom IMAP serveru více domén, ale všichni (tři ) klienti se připojují na imap.jaros.org a název domény je až v uživatelském jménu. Neřeší to hostingy také tak? Že by něco jako virtuální servery na jedné IP adrese, jaké jsou např. u HTTP, fungovalo i u IMAP nevím, na druhou stranu příslušné specifikace jsem nijak zvlášť nezkoumal.

Na každý pád jak oni, tak já používáme Courier-Imap, oni očividně používají automaticky generovaný certifikát aniž by se obtěžovali změnit před jeho vygenerováním výchozí hodnoty. Také jsem tam tohle po instalaci měl; pokud si dobře pamatuju, stačilo poeditovat /etc/courier-imap/imapd.cnf a spustit mkimapdcert (pod Gentoo). Samozřejmě profi hosting by podle mého soudu měl mít certifikáty podepsané někým důvěryhodným...

[michich]

Vadi to vice lidem, a proto nekdo vytvoril rozsireni Remember Mismatched Domains

[jacobs]

Haleluja! Tak neco takoveho jsem si uz dlouho pral :) Diky za tip...

[Pavel Janousek]

A k cemu potom trapite sve elektrony k SSL?!

[Zdeněk Štěpánek]

Nene, me to taky stvalo. Screenshot nemam, ale jde o to, ze TB krici, ze certifikat je vydan pro "ssl.atlas.cz", ale server, ke kteremu se ma pripojit je "imap.atlas.cz".

A tahle hlaska sama o sobe vypnout nejde, avsak resenim je proste zmenit adresu serveru na tu spravnou (ssl.atlas.cz).

Zdenek

[Zdeněk Štěpánek]

Tak koukam, ze uz me ostatni predbehli.

Ovsem pokud je adresa schvaleneho serveru "localhost", tak pak je kazda rada draha.

Ja tohle resil u svy domeny, pouzil jsem skripty dodany k cyrus-imap a to mi vygenerovalo klice pro "gavanet.org". Asi by to slo zmenit na ssl.gavanet.org, ale nevadi mi to, stejnak jsme asi jedinej kdo to SSL pouziva.

Zdenek

[David Jež]

On je totiž problém ještě někde jinde. Obluda, Fretka i Hromový Pták pracují s certifikáty značně nešťastně. V certifikátu je možno uvést více záznamů, např. více E, CN apod. Jenže Obluda bere pouze první CN záznam a na ostatní už se nedívá. Proto pokud používám jeden certifikát pro moje.domena.tld i www.domena.tld tak Obluda bude vždycky na www hystericky ječet. A Fretky si zase od jisté verze usmyslely, aby v tom byl ještě větší bordel, že nejinteligentnější bude brát pro změnu poslední certifikát . Řešením je oželet veškeré aliasy a nechat pouze jeden CN záznam a doufat, že to bude fungovat. V opačném případě si stěžuje vždy jiná část uživatelů a já se divím proč, když mi to funguje...

Další zrada v SSL tkví v tom (viz prý ,,zázračný`` m$ firewall, který sleduje i SSL spojení a jiné), že v prohlížeči je default napráskána tuna naprosto pofidérních autorit, které jsou v zápalu bakšiše schopny podepsat naprosto cokoliv. Může se tedy lehce stát, když bude někdo hodně neodbytný a trpělivý, že mu některá z ,,autorit`` podepíše i evil certifikát. Zde je řešením nechat si v prohlížeči pouze autoritu vlastní, případně pár dalších, kterým důvěřujeme a jinak si raději ukládat certifikáty serverů. Pokud se potom změní, je to vidět. Jinak by ale došlo k tomu, že při změně za nějaký bordel, který je ale podepsán, ale někým úplně jiným, by mu prohlížeč bezmezně věřil dál.
-djz

[muffin]

Vsichni tu plivou na clanek, ale mne se libil. Diky.

[Ricardo]

řekl bych, že neplivou, nýbrž sdělují své názory. a to především formou konstruktivní kritiky, což není imho plivání

[Radek Hladik]

Nedá mi to, abych nenapsal můj postřeh k článku. Článek je po technické stránce správně, až na to kódování/šifrování samozřejmě. Ale očekával bych ho jen jako praktickou ukázku pro doplnění článku, který bude víc podrobný. Hodnota celého článku jde shrnout do pár vět typu "SSL/TLS je náchylné na man-in-the-middle útok, pokud si obě strany neověří certifikáty důvěryhodným způsobem. Dá se to udělat například pomocí iptables, DNATu a stunnelu..."

Človek znalý věci se usměje, že tohle přeci dávno zná a člověk neznalý by ocenil navíc i popis, co to je man-in-the-middle, proč se certifikáty podepisují, jak je důvěryhodně ověřit a tak, jinak tento článěk zůstává plácnutím do vody na populárně zajímavé téma...

Radek

[Peto2]

Priatelia, predpokladam, ze sa tu najdu odbornici. Mohli by ste mi poradit otvorenu technologiu digitalneho podpisu pre autentifikaciu PC voci webovej stranke a zabezpecene spojenie? Alebo aj viacej technologii.

[Filip Jirsák]

SSL Zabezpečené spojení na bázi SSL/TLS certifikátů implementuje protokol https, volitelnou součástí je autentizace klienta klientským certifikátem. Příslušná implementace závisí na tom, o jaký webový server se jedná a o jaký klientský prohlížeč – např. Firefox, Mozilla, MSIE autentizaci klientským certifikátem umí a přepdokládám, že ot samé platí i pro ostatní rozšířené prohlížeče. Ohledně serverů, vím, že to určitě umí Jetty, Apache na to předpokládám taky bude mít nějaký modul…