Hlavní navigace

Vlákno názorů k článku Let's Encrypt zablokoval nebezpečnou validaci pomocí self-signed certifikátu od madloki - Za mne je tu zasadni problem s hysterii...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 1. 2018 16:16

    madloki (neregistrovaný) ---.net.upcbroadband.cz

    Za mne je tu zasadni problem s hysterii z posledni doby ohledne pouziti sifrovani vzdy a vsude.

    Jen protoze se par ichtylu snazi zviditelnit (bohuzel i u nas), sifruji se data, ktera jsou sifrovana uplne zbytecne, nici se zakladni predpoklady pro rychly beh web aplikaci (data nacitana in-paralel z vice zdroju), a jediny benefit z toho je, ze uzivatel cekajici na zelenou pizdu v adresnim okenku browseru ji duveruje stejne slepe, jako kdykoliv predtim.

    Sifrovat se maji vyhradne formulare, VPN provoz, osobni udaje, online bankovnictvi atp.
    Vubec nejlepsi by ale bylo na strane browseru v java aplikaci takova data zasifrovat pomoci OTP + klasickeho hesla, ktere jiz uzivatel zna.

    Tato cesta vse via https je zrudnost.

    Kdysi v browseru po kliknuti na tu zelenou ikonu videl uzivatel i udaje o certifikatu, a dnes by u vetsiny browseru musel slozite projit celou sekvenci kliknuti nebo klavesovych zkratek, aby mel vubec sanci neco o pouzitem certifikatu zjistit.

    Vysledek mu ale proste jen rika, ze nekdo pouzil pro browser duveryhodny certifikat.

    Ze mu ale nejaka apka do store naimportuje vlastni CA, a pomoci lokalniho DNS utoku ci proxy v browseru pak bude primo na pocitaci uzivatele provadet MITM, stejne jako ho provadeji ruzne komercni security produkty pouzivajici desifraci SSL (ktere svuj certifikat CA instaluji via domenovou politiku), to uz jaksi nezjisti.

    Takze klidne muze koukat dal na zelenou pizdu, jenze dokud na strane browseru nebude defaultne implementovan nezavisly mechanismus na overeni certifikatu CA, ktera podepsala certifikat serveru, ze jde opravdu o spravnou CA + certifikat serveru se spravnym serial number.

    Dejme stranou, ze takovy mechanismus zatim neexistuje a ze DNS ani DNSSEC takto pouzit nelze (protoze primo na pocitaci uzivatele mohu pro nej generovat vlastni DNS i DNSSEC).

    I tak porad jeste musite verit te ktere CA (protoze nejaka jedna nadrazena pro vsechny duveryhodna autorita proste vubec neexistuje).

  • 10. 1. 2018 16:35

    Petr Krčmář

    Mnohokrát bylo (i tady na Rootu) vysvětlováno, že to smysl má a stejně se pod každým článkem najde někdo, kdo se snaží ostatní přesvědčit o opaku. Ale nechci tady tu debatu zase opakovat.

    Obecně platí, že pokud útočník kompromituje můj systém tak, že je schopen mi vkládat CA, podvrhovat validaci DNSSEC a měnit nastavení DNS, pak nepomůže už vůbec nic. Tyhle technologie chrání proti kompromitované síti a dělají to velmi dobře, i když mají své mouchy.

  • 13. 1. 2018 10:22

    Kalvinista (neregistrovaný) ---.wia.cz

    Krčmáři, Krčmáři, přestaň si hrát na boha!

    To, že tady na rootu byla některá tvrzení opakována do úmoru ještě neznamená, že jsou jedinou svatou neomylnou pravdou...

  • 13. 1. 2018 10:32

    Filip Jirsák

    Raději vy přestaňte psát nesmysly. Do úmoru jsou tu opakována tvrzení Madlokiho, která jsou následně vyvrácena. To vyvrácení samozřejmě není jediná svatá neomylná pravda, ale v takovém případě by bylo rozumné na ta vyvracející tvrzení reagovat – buď poukázat na nějakou chybu, která v nich je, nebo poukázat na něco podstatného, co pomíjejí. Jenom zopakovat to původní mnohokrát vyvrácené tvrzení je k ničemu. Je pochopitelné, že Petr nemá chuť opakovat stále dokola ty samé argumenty, takže jenom poukáže na to, že už se to řešilo mnohokrát, a ať si to Madloki dohledá, když ho to zajímá.

  • 13. 1. 2018 10:44

    Miroslav Šilhavý

    Do úmoru jsou tu opakována tvrzení Madlokiho, která jsou následně vyvrácena. To vyvrácení samozřejmě není jediná svatá neomylná pravda, ale v takovém případě by bylo rozumné na ta vyvracející tvrzení reagovat – buď poukázat na nějakou chybu, která v nich je, nebo poukázat na něco podstatného, co pomíjejí.

    Jestli chcete něco podstatného, co se pomíjí, tak je to realita vývoje hrozeb. Zabezpečíme přenos šifrováním - to je bez diskuse krok k bezpečnosti. Co jsme ztratili? Devalvovali jsme získání a držení certifikátu jakožto instrumentu ověření identity výměnou za šifrování. To je jedna ztráta. Druhá ztráta je, že se hrozby přesunuly jen do jiných oblastí, které nejsou na SSL závislé - prostě programují jiné typy malware, ještě důmyslnější. Co jsme dál ztratili? To, že všichni plýtváme výkonem - jsou to nenávratně spálené tuny uhlí a uranu. No a nakonec, samotné vystavení DV certifkátu po ověření přes DNS (vůbec ACME), přesunulo ten nejslabší článek na zabezpečení DNS správy. Velcí hráči nemají DNS u Active24 apod., ale ti také měli vždy SSL pořešené. Malí, jednotlivci, ti SSL neuměli nasadit, ale zároveň se překrývají se skupinou, která tomu moc nerouzumí. Do DNS pak dobrovolně předávají přístupy kde komu, nehledě na to, že samotní registrátoři umožňují password recovery pomocí e-mailu - tedy nešifrovaným kanálem.

    Celé to úsilí mi připomíná snahy EU "zlepšovat naše životy za každou cenu", a to tak, že se nestačíme už divit, jak vysoké životní náklady máme na to, abychom ráno vstali, přes den pracovali a večer si šli v klidu a míru lehnout.

    Takže pokud existuje nějaký argument, tak je to globálně vynaložená energie - jak elektrická, tak úsilí lidí, aby byl přínos slepého zavádění "tak trochu" diskutabilní.

  • 13. 1. 2018 11:06

    Filip Jirsák

    Devalvovali jsme získání a držení certifikátu jakožto instrumentu ověření identity výměnou za šifrování.
    Nikoli, šifrování nijak hodnotu certifikátů nedevalvuje. Ostatně je standardizované řešení, které pro ověření domény důvěryhodnou certifikační autoritu vůbec nepotřebuje (DANE). Takže ta devalvace není nevyhnutelný důsledek šifrování.

    Druhá ztráta je, že se hrozby přesunuly jen do jiných oblastí, které nejsou na SSL závislé
    To ovšem není žádná ztráta, právě naopak. Proto se každé bezpečnostní opatření dělá, abychom předešli nějakému typu útoku – útočník pak musí použít jiné metody, které jsou nákladnější, takže se to méně vyplatí.

    To, že všichni plýtváme výkonem - jsou to nenávratně spálené tuny uhlí a uranu.
    To máte nějak změřené? Já si myslím, že výkon potřebný navíc je neměřitelný. Když už to budete porovnávat, nezapomeňte také započítat náklady na řešení následků toho, že je komunikace nešifrovaná, a někdo ji odposlechne nebo modifikuje. A také náklady na to, aby se ty útoky vůbec odhalily.

    No a nakonec, samotné vystavení DV certifkátu po ověření přes DNS (vůbec ACME), přesunulo ten nejslabší článek na zabezpečení DNS správy.
    Nikam se nic nepřesunulo, DNS bylo vždy součástí toho řetězce důvěry, už jen z toho prostého důvodu, že DNS je autoritativním zdrojem dat pro překlad jmen na IP adresy – při převodu jmen ho nemůžete vynechat. Naopak by bylo správně další články (jako ověření přes HTTP nebo e-mail) vynechat, protože ty přidávají do celého procesu jen další nejistotu.

    Celé to úsilí mi připomíná snahy EU "zlepšovat naše životy za každou cenu", a to tak, že se nestačíme už divit, jak vysoké životní náklady máme na to, abychom ráno vstali, přes den pracovali a večer si šli v klidu a míru lehnout.
    To vám sice připomíná hezky, ale nic takového reálně neexistuje. Akorát je v ČR módní být proti EU, bez ohledu na jakákoli fakta, tak to také opakujete. Všimněte si, že jste neuvedl jediný konkrétní argument – jen jakási obecné dojmy.

    aby byl přínos slepého zavádění "tak trochu" diskutabilní
    Nejde o žádné slepé zavádění. Je to jednoduchá úvaha – každá komunikace, která může být modifikována, je pro příjemce zcela zbytečná (když můžu dostat jakoukoli informaci, je úplně jedno, když nedostanu žádnou – pokud by mi chyběla, můžu si ji vytvořit třeba z /dev/random). Takže nezbytná komunikace musí být vždy šifrována.

  • 13. 1. 2018 11:18

    Miroslav Šilhavý

    Ostatně je standardizované řešení, které pro ověření domény důvěryhodnou certifikační autoritu vůbec nepotřebuje (DANE). Takže ta devalvace není nevyhnutelný důsledek šifrování.

    Ano, ale v praxi došlo k té devalvaci. V praxi bylo něco možná trohcu s horkou hlavou "vylepšeno", ale to druhé zavedeno se stejnou vehemencí nebylo.

    Proto se každé bezpečnostní opatření dělá, abychom předešli nějakému typu útoku – útočník pak musí použít jiné metody, které jsou nákladnější, takže se to méně vyplatí.

    Ano, a toto si myslím, že bylo špatně odhadnuto a vyhodnoceno. Přínos v praxi velký není (důležité služby už dávno SSL zavedly), nedůležité jsou přinucovány. Ale ten přesun útoků / útočníků jinam jim sebral méně energie, než si myslíte. Podobné je to s našimi zákony. Vždy něco zalátáme, abychom se nakonec dozvěděli, že gauneři našli další, a ještě méně odhalitelný a ještě méně řešitelný a postihnutelný způsob kradení. Viz např. kauza nehorázně drahého tisku jízdenek pro pražskou MHD - kdy soudy skončily na tom, že není s čím porovnat, jestli ta cena je při takové zakázce přiměřená, či není, a DPP neměl povinnost to lépe soutěžit.

    DNS bylo vždy součástí toho řetězce důvěry, už jen z toho prostého důvodu, že DNS je autoritativním zdrojem dat pro překlad jmen na IP adresy

    Rád uvádíte, že přínosem HTTPS je, že nikdo uprostřed, v kompromitované přenosové síti, nemůže podvrhnout obsah. Ale ono to tak úplně. Už jen tím, že můžete podvrhnout DNS odpovědi, máte v kompromotované síti obrovskou moc. Jediným řešením by byl 100% přechod na HTTPS a úplné vypnutí HTTP. To není v příštích, dovolím si tvrdit, patnácti letech reálné. Podívejte, že doposud jsme nevyřešili ani šifrovaný přenos pošty, který by byl jistě prospěšnější, nebo jsme se nezbavili prehistorického FTP.

    Buďte trochu realista. Já Vám přiznávám idealistické vnímání vývoje technologií, ale nejen nihilisté, ale i přílisní idealisté bývají zaseklí na stejném místě.

    To vám sice připomíná hezky, ale nic takového reálně neexistuje. Akorát je v ČR módní být proti EU

    Já vůbec nejsem proti EU! Jsem naopak příznivcem federalizace, sjednocení předpisů a zjednodušení a zefektivnění EU. Jsem jedině proti překomplikované EU, která vydává směrnice pro desítky států, které mají na tolik odlišnou kulturu - od Balkánu až po vlny Atlantiku -, žč nejdou v praxi implementovat bez většího výčtu výjimek, než je prvotní myšlenka samotné normy.

    Takže nezbytná komunikace musí být vždy šifrována.

    Nesouhlasím.

  • 13. 1. 2018 12:09

    Filip Jirsák

    Ano, ale v praxi došlo k té devalvaci.
    Akorát že ta devalvace není důsledkem šifrování. DV certifikáty se vydávají už mnoho let, dávno před tím, než přišel současný boom šifrování.

    V praxi bylo něco možná trohcu s horkou hlavou "vylepšeno"
    Proč s horkou hlavou, proč vylepšeno v uvozovkách? Máte snad lepší nápad, jak zvýšit bezpečnost na internetu?

    Přínos v praxi velký není (důležité služby už dávno SSL zavedly), nedůležité jsou přinucovány.
    Přece vás nikdo nenutí to šifrování používat. Ty nedůležité služby si klidně můžete číst /dev/random, šifrovat nic nemusíte, a na výsledek máte stejné spolehnutí, jako na ty nešifrované služby.

    Už jen tím, že můžete podvrhnout DNS odpovědi, máte v kompromotované síti obrovskou moc.
    Proti tomu se dá bránit pomocí DNSSEC. Nemůžete chtít, aby se mávnutím kouzelného proutku vyřešily všechny problémy najednou – problémy se řeší postupně, nezávisle na sobě.

    Jediným řešením by byl 100% přechod na HTTPS a úplné vypnutí HTTP.
    Ano, to je cíl. Jenže k tomu cíli se nedostaneme jinak, než postupným zvyšováním podílu HTTPS.

    To není v příštích, dovolím si tvrdit, patnácti letech reálné.
    Já si myslím, že na webu to půjde mnohem rychleji. Ale i kdyby to trvalo patnáct let, budeme mít od teď za 15 let veškerý web šifrovaný. Jak byste to řešil vy? Čekal byste deset let, za deset let bychom začali s tím samým, co se dělá dnes, řešili bychom stejné problémy, a pak by za dalších patnáct let by byl přechod dokončen? Jaký by byl rozdíl v tom, že bychom to celé udělal i úplně stejně, se stejnými problémy, akorát o deset let později?

    Podívejte, že doposud jsme nevyřešili ani šifrovaný přenos pošty, který by byl jistě prospěšnější, nebo jsme se nezbavili prehistorického FTP.
    I ten šifrovaný přenos pošty se v posledních letech zlepšuje, a řekl bych, že právě díky zavádění HTTPS. Ale i kdyby ne. Brání to nějak nasazování HTTPS? Nebo nasazování HTTPS naopak zpomaluje nasazování šifrování pošty nebo ukončování FTP? Mimochodem, je dost možné, že náhradou FTP bude WebDAV, protože SFTP je přeci jen trochu jiná technologie. A pro šifrovaný WebDAV potřebujete zase HTTPS.

    Buďte trochu realista. Já Vám přiznávám idealistické vnímání vývoje technologií, ale nejen nihilisté, ale i přílisní idealisté bývají zaseklí na stejném místě.
    Buďte trochu realista. Konzervativní postoj je užitečný, ale nejde se zaseknout na místě, ani tvrdit, že když něco nevyřeší všechny problémy světa, nemáme se vůbec snažit o zlepšení.

    Já vůbec nejsem proti EU!
    Taková deklarace nevypovídá vůbec o ničem. Miloš Zeman taky tvrdí, že nevede žádnou kampaň.

    Jsem jedině proti překomplikované EU, která vydává směrnice pro desítky států, které mají na tolik odlišnou kulturu - od Balkánu až po vlny Atlantiku -, žč nejdou v praxi implementovat bez většího výčtu výjimek, než je prvotní myšlenka samotné normy.
    Opět jen nicneříkající obecné tvrzení. Jak mám vědět, jaká směrnice je pro vás překomplikovaná, když neuvedete žádný příklad? Naopak takové tvrzení jenom vzbuzuje podezření, že o žádné takové směrnici nevíte a akorát něco papouškujete.

    Nesouhlasím.
    Pokud vám nevadí, že přenášený obsah může být změněn, čtěte si ta nešifrovaná data z /dev/random. Vždyť na tom přece podle vás nezáleží, jestli čtete to, co web server odeslal, nebo něco jiného.

  • 10. 1. 2018 16:36

    lojzak (neregistrovaný) 2a00:1298:8011:----:----:----:----:----

    @madloki

    Ale jdi ty rozumbrado.


    "sifruji se data, ktera jsou sifrovana uplne zbytecne"
    Možná je jen tvoje mylná představa, že se šifrují zbytečně. Mimo to, HTTPS není jen o utajení přenášené informace, zaručuje i ověření identity a důvěryhodnost komunikace - tj. že ti nikdo třetí do komunikace nic nepodstrčí (reklamy, malware...).


    "nici se zakladni predpoklady pro rychly beh web aplikaci (data nacitana in-paralel z vice zdroju)"
    HTTPS nebrání takovému způsobu načítání.


    "ze uzivatel cekajici na zelenou pizdu v adresnim okenku browseru ji duveruje stejne slepe, jako kdykoliv predtim"
    Což ale není chyba HTTPS, ale toho uživatele. Nehledě na to, že průměrný uživatel ani neví, co ta "zelená pizda" znamená.


    "Sifrovat se maji vyhradne formulare, VPN provoz, osobni udaje, online bankovnictvi atp."
    A jak poznáš, jaká data jsou citlivá a jaká ne? Jak to pozná browser?


    "Vubec nejlepsi by ale bylo na strane browseru v java aplikaci takova data zasifrovat pomoci OTP + klasickeho hesla, ktere jiz uzivatel zna."
    Ne, to by nebylo nejlepší. Jak budeš řešit distribusi OTP?


    "Kdysi v browseru po kliknuti na tu zelenou ikonu videl uzivatel i udaje o certifikatu, a dnes by u vetsiny browseru musel slozite projit celou sekvenci kliknuti nebo klavesovych zkratek, aby mel vubec sanci neco o pouzitem certifikatu zjistit."
    To je problém browseru, ne HTTPS samotného.


    S důvěryhodností CA máš pravdu. Ale pořád lepší než nezabezpečené HTTP.


    "Dejme stranou, ze takovy mechanismus zatim neexistuje"
    Ehm... DANE?


    "protoze primo na pocitaci uzivatele mohu pro nej generovat vlastni DNS i DNSSEC"
    DNSSEC asi těžko.

  • 10. 1. 2018 16:58

    Filip Jirsák

    Mne by zajímalo, proč sepisujete takhle dlouhý komentář, když je podle vás úplně jedno, jestli se odešle a lidem zobrazí ten váš komentář, nebo jestli místo něj bude napsáno: „Podporuji co nejrychlejší nasazení HTTPS na všech webech.“ Pokud to podle vás jedno není, potřebujete nějaký mechanismus, kterým zajistíte, že ten váš komentář nemůže nikdo změnit při odesílání na server, a také že jej nikdo nemůže změnit při jeho stahování ze serveru do prohlížeče.

  • 10. 1. 2018 18:51

    Petr M (neregistrovaný) 2001:470:5c0e:----:----:----:----:----

    Zpracováváš osobní nebo citlivý údaje? Šifrovat musíš.

    Žije tvoje stránka z reklamy (> 90% webů, co nemají nákupní košík)? Šifrovat musíš, jinak někdo (klidně ISPík) vymění odkazy na reklamu, máš v jeho síti 0 zobrazení a 0 Kč, i kdyby tam šlo 10% trafficu.

    Máš e-shop? Šifrovat musíš, aby se cestou nedostal zákazníkovi do objednávky někdo cizí. A udržovat dva stejný weby, jenom s tím rozdílem, že před vložením první položky do košíku nebude šifrování, a ejjich přepnutí, je zbytečná pakárna.

    Máš na webu diskuse s možností soukromých zpráv? Šifrovat musíš, pokud soukromá zpráva má být soukromá.

    Máš odbornou poradnu? No tak podle OZ za takovou radu právně ručíš a pokud někdo na web doktora vloží cestou nějakou nesmyslnou radu, má doktor minimálně co vysvětlovat, LE je v tomto případě pojistka skoro zadarmo.

    Atd.

  • 10. 1. 2018 19:21

    lojzak (neregistrovaný) 51.15.37.---

    Když provozuješ internetovou poradnu, tak ručíš za správnost odpovědí? Co je to za komouškej výmysl?

  • 10. 1. 2018 21:38

    Petr M (neregistrovaný) 2001:470:5c0e:----:----:----:----:----

    Občanský zákoník. A ten komoušský už naštěstí zrušili.

    Pokud máš z udělení rady rady prospěch (třeba takový, že dostaneš platbu za zobrazenou reklamu), a osoba, které takovou radu dáš, důvodně předpokládá, že jsi odborník, tak přebíráš zodpovědnost za správnost rady a zodpovídáš za takto způsobenou škodu v plné výši.

    No a když někdo pozmění tvůj web tak, že tě pasuje na odborníka, nebo tvým jménem něco pohnojí a někdo jiný na to skočí, máš problém. Jednodušší a rychlejší, než soudy s nepředvídatelným výsledkem je zařídit, že se za tebe nemůže nikdo vydávat.

  • 10. 1. 2018 21:48

    Miroslav Šilhavý

    Za prvé: na aplikaci § 2950 OZ nestačí, aby druhá strana důvodně předpokládala, že jste odborník, ale musíte se za něj aktivně prohlásit: "Kdo se hlásí jako příslušník určitého stavu nebo povolání k odbornému výkonu nebo jinak vystupuje jako odborník, nahradí škodu, způsobí-li ji neúplnou nebo nesprávnou informací nebo škodlivou radou danou za odměnu v záležitosti svého vědění nebo dovednosti. Jinak se hradí jen škoda, kterou někdo informací nebo radou způsobil vědomě."

    Za druhé: nikdo nepřebírá zodpovědnost, ale odpovědnost.

    Za třetí: pokud někdo žaluje o náhradu škody, je důkazní břemeno na žalobci. Pokud není přenos šifrovaný, naopak žalobce možná neunese důkazní břemeno o tom, že si mohl / měl myslet, s kým zrovna komunikuje.

    Rozhodně není pravdou, že někdo musí v uvedených případech šifrovat. Je to samozřejmě na výsost důležitá "slušnost". Pokud uniknou data po cestě, odpovědnost nese v první řadě ten, kdo jejich únik umožní - např. ISP, který je nechá odposlechnout. Poskytovatel obsahu samozřejmě ručí za to, že neuniknou data z jeho informačního systému, ale to už nemá nic společného s šifrováním přenosu.

    V uvedených případech lze šifrování jen doporučit, ale neměl byste strašit pojmy a tvrzeními, která nejsou pravdivá.

  • 10. 1. 2018 23:17

    lojzak (neregistrovaný) ---.dfri.se

    "Pokud máš z udělení rady rady prospěch"
    A když žádný prospěch z poskytnuté rady nemám třeba protože neprofituji z reklamy? Potom můžu dávat špatné rady?

    Co když jsou provozovatl webu a autor příspěvků dvě osoby. Kdo nese odpovědnost?

    A pokud tu špatnou radu učiním jinak (osobně, emailem, prostřednictvím tisku...) taky mi něco hrozí?

    Člověk by především neměl být ovce a obzvláště informace zjištěné na internetu dobře ověřovat.

  • 10. 1. 2018 19:44

    Vít Šesták

    > A udržovat dva
    stejný weby, jenom s tím rozdílem, že
    před vložením první položky do košíku
    nebude šifrování, a ejjich přepnutí, je
    zbytečná pakárna.

    Kdyby jen pakárna. Ono je to i dost rizikové. Nemůžete mít HSTS a v některých případech potenciálně děláte sami na svůj web downgrade "attack".

    A co by vlastně bylo na čistém HTTP? To, k čemu má přístup nepřihlášený uživatel? Zaprvé by někdo mohl teoreticky nepřihlášenému uživateli podstrčit třeba jiný popis výrobku. Zadruhé, co uděláte s tím, když na tuto stránku vleze přihlášený uživatel? Přesměrujete ho na HTTPS? Bude obsah košíku v iframe? (Hmm, tím se otevírá clickjacking...)

  • 10. 1. 2018 19:54

    Filip Jirsák

    On by byl problém i s tím zobrazováním produktů přes HTTP. Útočník pak třeba může změnit cenu – když ji zvýší, zákazník odejde a koupí jinde. Když ji sníží, bude mít zákazník web za podvodníky, když se po přidání do košíku cena zvýší – a taky nakoupí jinde.

    Navíc nevím, proč by měl kde kdo vědět, jaké zboží si v e-shopu prohlížím.

  • 11. 1. 2018 14:07

    Michal Stanke

    Problém by byl jak dostat zákazníka z HTTP na HTTPS, když si chce něco koupit. Netřeba měnit cenu, stačí 301 na vlastní e-shop. Chápu, že nějaké konkrétní informace šifrování nemusí potřebovat. Ale pak se nedá věřit žádnému obsahu, na který jsem přišel odkudkoliv linkem z HTTP, protože nemusím být tam, kde si myslím.

  • 11. 1. 2018 14:33

    Vít Šesták

    Děkuji oběma za další příklady. Změnit popisu je sice jedna možnost útoku, ale uznávám, přesměrování na jiný eshop může být účinnější :)