security címkéhez tartozó bejegyzések

Hogyan nyerhetné vissza a BKK a bizalmamat?

Az elmúlt két hétben alig telt el nap anélkül, hogy ne derült volna ki valami újabb “érdekesség” a BKK új, online, elektronikus jegyértékesítési rendszerével kapcsolatban. Sokan, sokféleképpen elmondták már, hogy a rendszer fejlesztői milyen szakmai és kommunikációs hibákat követtek el, azt azonban egyetlen cikkben sem láttam vitatni, hogy elektronikus jegyértékesítési rendszerre szükség van.

Az elkövetett “bakik” azonban jelentősen megingatták a felhasználói bizalmat mind a szolgáltatóban, mind pedig az elkészült rendszerben, ami elég érdekes patthelyzethez vezetett: mind a szolgáltatónak, mind pedig a felhasználóknak érdekük lenne használni egy ilyen rendszert, de nem ezt.

Adott tehát a feladat, ki kell mászni erről a mélypontról, mindannyiunk érdekében. Te hogyan tennéd? Ha te lennél a BKK-nál az a most frissen kinevezett, új vezető, akinek sikerre kell vinnie az elektronikus jegyértékesítési rendszert, te mit csinálnál? Utasként, felhasználóként, mit várnál el a BKK-tól, hogy bátran használni merd a rendszert? Informatikusként, szoftverfejlesztőként, IT biztonsági szakemberként mi kellene neked ahhoz, hogy megbízz egy új rendszerben?

Eljátszottam a gondolattal, hogy ha én kerülnék ilyen kihívás elé, én milyen irányba vinném a projektet. Tettem mindezt úgy, hogy a mostani rendszerről a sajtóban megjelenteken kívül semmit sem tudok: nem ismerem a követelményeket, az anyagi kereteket, a jogi korlátokat, az integrációs igényeket, ezért ezeket figyelembe se tudtam venni. Minden döntésnek vannak hátrányai, az egyszerűség kedvéért itt csak az előnyökre térek ki.

További károk megelőzése

Felbontanám a szerződést a T-Systems-szel, és az erről szóló dokumentumokat nyilvánossá tenném. Miért? A mostani rendszer fabatkát sem ér, és a fejlesztő cég elveszítette szavahihetőségét: nincs az a felhasználó, aki szívesen használná, vagy aki elhinné, hogy a fejlesztő “megerősítette”, és most már biztonságos. Egy új, tiszta lappal induló projektben ez csak ballaszt.

Megsemmisíteném a jelenlegi adatbázist, méghozzá egy IT biztonsági cég felügyeletével, akiknek az igazolását nyilvánossá tenném. Miért? Egyrészt nincs rá szükség egy tiszta lappal induló új rendszernél, másrészt nagyjából 1 napnyi felhasználási adat van benne, amit simán hagynék veszni, de leginkább azért, hogy elejét vegyem azoknak a vádaknak, hogy továbbra is innen szivárog ki személyes adat. Meg aztán úgyis van róla backup a dark weben 🙂

Közreműködő IT biztonsági cégként egy olyat választanék, aki nem mamut és akit a hazai szakma elismer. Legalább három IT biztonsági konferencia van hazánkban minden évben, bőven lehet választani a felvonuló cégek közül.

Új alapok

Az új rendszert kezdettől fogva a Kerckhoff elvet követve fejleszteném. Miért? A Kerckhoff elv szerint a rendszer csak akkor lehet biztonságos, ha egy támadó a titkosítási kulcson kívül a rendszer összes paraméterét ismerheti. És miért ne ismerhetné bárki, hiszen ez egy közpénzből fejlesztett, nagyon érzékeny személyes adatokat kezelő, közérdekű rendszer.

Nyilvánossá tenném a forráskódot és minden dokumentációt. Miért? Egyrészt mert ebben az országban nagyon sokan tudnának értékesen hozzátenni a projekthez, másrészt mert a transzparencia hatalmas erő. Kockázatos, de bátor tett lenne, ha a fejlesztőcsapat kiállna, és azt mondaná: íme, erre költöttük a pénzeteket. Mi hiszünk abban, hogy ez így jó, de tessék, nézzétek meg minden részletét, és szóljatok hozzá, kíváncsiak vagyunk a véleményetekre. Fontos, hogy a nyílt forráskód, nem jelenti a demokratikus döntéshozatalt. A szakmai döntésekért valakiknek vállalniuk kell a felelősséget, nem lehet azt mondani, hogy a “tömeg megszavazta”. Viszont hiszek abban, hogy a jótanácsot meghallgatni illik, de megfogadni nem feltétlenül kell.

Egy szakmai műhelyre bíznám a fejlesztést, nem egy multira. Miért? Még ha feltételezzük is, hogy ugyanaz a szakmai kompetencia megvan mindkét esetben, a motiváció lényegesen eltérő a két esetben. Nagyon sokat számít, hogy a projekt résztvevői pontosan mit akarnak elérni: egy jól működő, általuk is használt, a felhasználók elégedettségére törekvő rendszert akarnak készíteni, vagy más az elsődleges cél.

Arcokat tennék a projekt mellé. Miért? Az összes sikeres projekt, amit eddig láttam, részben annak köszönheti az eredményeit, hogy valaki vagy valakik a saját gyereküknek érezték. Akinek ott a neve, az arca, az elérhetősége és a felelőssége, az teljesen máshogy áll a projekthez, mint egy sokadik, névtelen alvállalkozó. És természetesen a felhasználói oldal is máshogy áll hozzájuk.

Iteratívvá tenném a fejlesztést. Miért? Ma már nagyon maradi megközelítés azt gondolni, hogy egy szoftver projekt az átadásakor készen van. Mindig jönnek visszajelzések, mindig találunk hibákat, mindig lehet javítani az alkalmazáson.

Continuous integration, continuous delivery és automatizált tesztelés. Miért? Egyszerűen nélkülözhetetlen az iteratív fejlesztéshez, pont.

Publikálnám a roadmapet. Miért? A roadmap mutatja, hogy mit szeretne még elérni a csapat, mi mindenre gondoltak még, és milyen irányba megy a fejlesztés. Bár minden roadmap változik, a felhasználói oldal számára mégis tervezhetőséget biztosít. Különösen, ha ez egy valóban élő dokumentum, aminek a változásait a fejlesztők el is magyarázzák (akár szóban, online meeting formájában).

Operations

A kódot felhő szolgáltatónál, serverless alapokon futtatnám. Miért? A felhő mellett számos érv van, ennél a projektnél talán az a legfontosabb, hogy ne csak jól skálázódó és biztonságos legyen, de egyszerűen és olcsón üzemeltethető is. Erre ma szerintem a serverless a legjobb megoldás.

Ops a BKK-nál. Miért? A rendszer a BKK ügyfeleinek személyes adatait kezeli, tehát a BKK-nak kell felelnie értük. Fontos az is, hogy a rendszer zavartalan működése a BKK számára a legfontosabb, ezért a közvetlen üzemeltetés a legpraktikusabb. Serverless környezetben a szolgáltató számos monitorozási lehetőséget és automatikus skálázást ad, miközben nagyon jól definiálható, hogy ki férhet hozzá a tárolt adatokhoz.

Biztonság

Federált authentikáció. Miért? A felhasználók azonosítása nem kis feladat, ha nem kell megcsinálni, azzal csak nyer a projekt. Arról nem is beszélve, hogy nem egyszerű jól megcsinálni, komoly felelősség. Ráadásul, ha figyelembe vesszük a projekt célközönségét is, akkor az is elképzelhető, hogy egy magyarország.hu + Google + Facebook hármas szinte mindenkit lefed.

Activity log a saját tevékenységeimről. Miért? A rendszerben megvan, hogy ki, mikor, milyen tranzakciókat hajtott végre. Annak a lehetősége, hogy a felhasználók a saját tevékenységeiket így visszakövethetik, számos félreértést eloszlat.

GDPR megfelelőség. Miért? Nem csak azért, mert 2018. májusától úgyis kötelező, hanem azért is, mert egyszerűen tisztává teszi a képet: mindenki láthatja, hogy a rendszer milyen adatokat tárol róla és kérheti azok törlését.

Security review, nyilvános dokumentációval. Miért? Szinte minden security review-n kiderül valami, amire a fejlesztők nem gondoltak, és amivel jobbá lehet tenni a rendszert.

Béta teszt időszak. Miért? Nehéz elsőre jót alkotni, kellenek a korai visszajelzések, az életszerű adatok. Ez a teszt lehet akár zártkörű, meghívásos is, még az is jobb, mint azonnal nekifutni a nagyközönségnek.

Bug bounty program. Miért? Erről az utóbbi időben sokat írtak, nem szeretném ragozni: tiszta és megéri.

Felkutatnám a más országokban létező elektronikus jegy megoldásokat. Miért? Nem lepődnék meg, ha az derülne ki, hogy a létező megoldások sem garantálják, hogy az elektronikus jegyek biztosan nem hamisíthatóak. Lehet, hogy az is elég, ha nagyobb munka hamisítani, mint megvenni.

Ráadás

Közzétenném az adatokat anonimizált formában. Miért? Ebben a rendszerben nagy mennyiségű adat gyűlik össze, a hasonló rendszerek kutatásával foglalkozó szakemberek számára ez nagyon hasznos és értékes adatforrás. Ennek az adatbázisnak az elemzésével a közlekedést meghatározó döntések születhetnek.

 

Nektek ez így elég lenne, ilyen körülmények között ti bíznátok egy új rendszerben? Mit hagytam ki?

 

.

Miért gyengíted a jelszavamat?

Nem tudom, ki hogy van vele, én nem szeretem sűrűn változtatni a jelszavaimat. Egyszerűen azért, mert macerás, viszi az időmet. A szolgáltatásokat használni szeretem, nem a beállításaikkal bíbelődni. Ennek ellenére – részben az utóbbi időszakban közzétett ellopott jelszó adatbázisoknak köszönhetően – rászoktattam magam, hogy a korábbiaknál gyakrabban cseréljem a jelszavaimat.

Az ilyenkor szokásos ajánlás, hogy a jelszó legyen komplex, és ne használjuk több helyen. Számomra komplex az, ami elég hosszú, van benne kisbetű, nagybetű, szám és még valamilyen speciális karakter is. Csakhogy nem kevés olyan weboldal van, ami ezt nem engedi beállítani.

Íme az egyik:

Aegon

Én ezt nem értem, miért nem használhatok ékezetes karaktereket? Csak nem varchar van az adatbázisban nvarchar helyett? Miért nem használhatok extra karaktereket, talán SQL injectiontől féltek? Gondoltam megkérdezem:

Aegon-Twitter

Valószínűleg rossz csatornán tettem, a Twitter fiókjukat évek óta nem frissítették, és a jelek szerint nem is olvassák. Vagy csak fittyet hánynak rá.

Persze nem ők az egyetlenek, a Nemzeti Útdíjfizetési Szolgáltató is hasonló cipőben jár:

NemzetiUtdij-Twitter

Sőt! Ők nem mondják meg, hogy mit nem tartalmazhat a jelszó, egyszerűen csak “Nem megfelelő formátum” hibaüzenetet írnak ki. Twitteren nem találtam meg őket, de megírtam nekik a kérdésemet, és alig 17 nap alatt válaszoltak is egy 5 (!) oldalas levéllel, amiből a következőket tudtam meg:

“Tárgy: Autópálya használati díj fizetésének ellenőrzése”

Ajjaj, szerintem nem, de ezen lépjünk túl. Kaptam Iktatószámot is, úgy látszik azért komolyan vesznek.

“Tisztelt Balássy György!
Társaságunkhoz intézett megkeresését köszönjük.”

Eddig minden rendben, piros pont a két-s-ipszilonért.

“Tájékoztatjuk, hogy a jelszó csupán az angol abc kis- és nagybetűiből állhat, valamint számokból.”

Ezen pattogok én is.

“Fontos, hogy egységes karakterek legyenek megadhatóak, hiszen vannak külföldi ügyfeleink, akik nem feltétlen rendelkeznek magyar billentyűzettel, ezáltal pl.: ékezettel.
A belépést és regisztrációt mindenki számára elérhetővé kell tennünk, ami az angol abc használatával valósul meg.”

Álljunk meg egy szóra. Nem úgy van ez, hogy én választok magamnak jelszót, amit azután én a saját kezemmel, a saját billentyűzetemmel gépelek be? Amilyen karaktert nem tartalmaz a billentyűzetem, azt nyilván nem fogom és ezért nem is akarom beírni, de amit tartalmaz, azt nagyon szeretném. Orosz karakter például biztosan nem lesz a jelszavamban, de csak azért nem, mert én úgy akarom.

“Továbbá attól, hogy nem adható meg ékezet és speciális karakter, még nem lesz gyengébb a jelszó.”

Ez egyszerűen nem igaz (feltételezve, hogy ugyanazt értjük “gyengébb” alatt).  Fejtegethetnénk itt most a problématér méretét, ki is próbálhatnánk L0phtCrackkel vagy John the Ripperrel, hogy kinek van igaza, de mivel a levél írójától sem várom el, hogy ilyen eszközökkel rendelkezzen, nézzünk inkább néhány kevésbé tudományos eszközt a Google találati listájáról, amik megmondják, hogy szerintük a különböző jelszavakat mennyi ideig tart feltörni:

 

“almafa”

“álmáfá”

“álmáfá!”

https://howsecureismypassword.net/

8 ms

1 perc

5 óra

https://password.kaspersky.com/

9 perc

3 óra

2 nap

http://www.passwordmeter.com/

5% – Very Weak

45% – Good

60% – Strong

http://random-ize.com/how-long-to-hack-pass/

kevesebb, mint 1 másodperc

13 másodperc

12 perc 57 másodperc

http://password-checker.online-domain-tools.com/

3 másodperc

1 nap

2 év

A számok pontosak? Valószínűleg nem, sőt még az arányaik sem azonosak. Az viszont tisztán látszik, hogy nem azonos nagyságrendben mozognak az egyes oszlopokban szereplő értékek.

“Javasolhatjuk továbbá, hogy szíveskedjen nagybetűt használni, ez még inkább növeli a jelszó erősségét.”

Mihez képest? Az angol abc kis- és nagybetűihez, valamint a számokhoz képest? Azt már használok, köszönöm.

A levél további 4 és fél oldala arról szól, hogy a fogyasztóvédelmi törvény szerint mit tehetek és hova fordulhatok, ha nem vagyok elégedett: ügyfélszolgálat, e-ügyfélszolgálat, levelezési cím, személyes ügyintézés, békéltető testület, bíróság stb. Egyébként ISO 9001, ISO 14001, BS OHSAS 18001, Certified IQNet Management System minősítésekről árulkodik még a levél.

A jó hír az, hogy itt legalább hosszú jelszót be tudok írni, amivel azért van lehetőségem elfogadható erősségű jelszót megadni, még ha nem is használhatom azt, amelyiket én szeretném. Nagyságrenddel rosszabbak azok az oldalak, ahol a jelszó hossza korlátozott.

Ezzel együtt az ilyen korlátozások bennem azt a gyanút ébresztik, hogy valami nem stimmel az oldal jelszó kezelése környékén, hiszen a hash algoritmusoknak nem szokott problémát okozni pár ékezet, aposztróf vagy felkiáltójel.

Mit tegyünk ezekkel a weboldalakkal?

 

Technorati-címkék: ,

Chocolatey és a biztonság

Úgy döntöttem, hogy a Windows 10-zel frissen újratelepített gépemre Chocolatey-vel fogom feltelepíteni az alkalmazásokat. Valójában az első ötletem az volt, hogy OneGet-et fogok használni, ami a Windows 10-ben megjelent csomagkezelő-kezelő, és aminek van egy előzetes Chocolatey providere, de mivel ezzel rövid kísérletezés után nem sok sikerélményem volt, maradtam közvetlenül a Chocolatey-nél.

Az első lépés a Chocolatey telepítése, aminek legegyszerűbb módja admin parancssorban annak az egysoros szkriptnek a futtatása, ami megtalálható a chocolatey.org honlapon:

C:\> @powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((new-object net.webclient).DownloadString(‘https://chocolatey.org/install.ps1’))" && SET PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin

Ezzel a paranccsal három dolgot érünk el egy csapásra:

  1. Letöltünk egy PowerShell szkriptet.
  2. Futtatjuk a letöltött szkriptet a saját gépünkön rendszergazdai jogosultságokkal.
  3. Kiegészítjük a PATH környezeti változónkat.

Nem tudom, ki hogy van vele, a 2. lépéstől kiráz a hideg. És ha már itt tartunk, álljunk meg egy pillanatra és gondoljuk végig, mire vállalkozunk: gyakorlatilag ismeretlen forrásból származó alkalmazásokat fogunk telepíteni a gépünkre, hiszen amikor kiadjuk mondjuk a

choco install adobereader

parancsot, akkor fogalmunk sincs, hogy honnan mi fog letöltődni és települni a gépünkre.

Mit tehetünk?

Először is csak olyan choco csomagokat telepítsünk, amiket moderátorok jóváhagytak. A moderálás egy manuális folyamat, csúszhat bele hiba, de mégis egyfajta ellenőrzés. Egy moderált csomag, például az Adobe Reader oldalán ez jelenik meg felül nagy zöld keretben:

This package was approved by moderator gep13 on 6/11/2015.

Egy moderátori ellenőrzésen nem átesett csomag, például a Notepad2 esetén ugyanott piros keretben ezt találjuk:

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Ha már a csomag részletes oldalán vagyunk, érdemes elolvasni mindent, amit ott találunk. Például a 7-zip csomag oldalán ezzel a figyelmeztetéssel találkozhatunk:

NOTE: The installer for 7-Zip is known to close the explorer process. This means you may lose current work.

Ugyanitt találkozhatunk hasznos opciókkal is, például Firefox esetén megadhatjuk, milyen nyelvű verziót szeretnénk telepíteni:

choco install Firefox -packageParameters "l=en-US"

Ha pedig egy kicsit lejjebb görgetünk, a kommentek között találhatunk olyan utalásokat, amik eltántoríthatnak minket egy-egy csomag telepítésétől. A CDBurnerXP csomag kommentjei között megemlítik az OpenCandy nevű szemetet, amiről eszembe jutott, hogy bizony nem egy olyan telepítővel találkoztam már, amin ha ész nélkül next-next-finish-sel megyünk végig, kapunk “ajándékba” egyéb programokat is.

Az oldal közepe táján sok esetben megtaláljuk a telepítő PowerShell szkriptet, érdemes lehet átnézni, mert abból kiderülhet, hogy milyen telepítőcsomagot tölt le és honnan. Az Adobe Reader csomagjánál ez a szkript mindössze 6 sor, a közepén ott virít az URL és könnyen érthető, hogy mi történik. De ugyanezt nem lehet elmondani a Firefox csomag 117 soros szkriptjéről, vagy a Node.js csomag egyetlen soros szkriptjéről, ami két másik csomagra hivatkozik.

Összességében a Chocolatey használata véleményem szerint egy jókora lutri. Elvégezhetjük ezeket a manuális ellenőrzéseket, frissíthetjük az operációs rendszerünket, beüzemelhetünk egy víruskeresőt, kiszűrhetjük a csibész hostokat, de a végeredmény az, hogy ismeretlen szerző ismeretlen kódját futtatjuk a gépünkön, ami sehogy sem tűnik jó ötletnek.

Én ezeket a csomagokat telepítettem fel, egyelőre nem égett le a ház tőlük:

adobereader
7zip
emet
fiddler
filezilla
firefox -packageParameters "l=en-US"
gitextensions
google-chrome-x64
join.me
keepass
nodejs
paint.net
silverlight
skype
sysinternals
vlc

Ti mit gondoltok, használtok ilyet, meritek használni, és ha igen, milyen csomagokat szoktatok még feltenni?

 

Technorati-címkék: ,,

Bitlocker TPM nélkül

A közhiedelemmel ellentétben igenis használható a Windows beépített Bitlockere a merevlemez tartalmának titkosítására akkor is, ha nincs a gépünkben TPM chip. Azokat a meghajtókat, amik az adatainkat tartalmazzák, simán hagyja is a Windows titkosítani, mindössze egy jelszót kér, és felajánlja a recovery key mentését fájlba, USB meghajtóra, sőt akár a felhőbe is. Ha viszont a C: meghajtónkat akarjuk bebitlockerezni, akkor találkozhatunk ezzel a hibaüzenettel:

This device can’t use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at startup” policy for OS volumes.

bitlocker-1-tpm-error

Szerintem ez egy egészen jó hibaüzenet, mert megmondja, hogy mi a gond, és azt is, hogyan tudunk kimászni belőle. Ha még azt is megmondaná, hol keressük pontosan ezt a beállítást, egészen tökéletes lenne!

A “policy” szóra keresve ugyanis léptem nyomon a Local Security Policy-ba futhatunk bele, pedig nem az kell. A Group Policy Object Editorra van szükségünk még akkor is, ha workgroupban van az adott gép és nem tartományban. (A csoportházirendekről nekem mindig a címtár jut eszembe…)

Indítsunk tehát egy Microsoft Management Console-t (mmc), majd adjuk hozzá a Group Policy Object Editor snap-int (katt a teljes képért):

bitlocker-2-mmc-add-snapin

Ezen belül a Local Computer Policy –> Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives ág alatt találhatjuk meg a hibaüzenetben megjelölt beállítást:

bitlocker-3-policy-path

A beállításra duplán kattintva előbb válasszuk ki az Enabled lehetőséget, majd alul pipáljuk be az Allow Bitlocker without a compatible TPM jelölőnégyzetet:

bitlocker-4-policy-setting

Miután mindent leokéztunk még frissítenünk kell a házirendet, amit a gépünk újraindítása nélkül legegyszerűbben parancssorból a gpupdate parancs kiadásával tehetünk meg:

bitlocker-5-gpupdate

Ezután már gond nélkül titkosíthatjuk az operációs rendszert tartalmazó meghajtónkat is.

 

Technorati-címkék: ,,

E-mail címeket karácsonyra

Karácsony előtt megnövekszik azoknak a kéretlen leveleknek a száma, amik valamit rá akarnak sózni az emberre. Az alábbi egy kicsit kilóg a sorból:

email-lists-1

Igen, e-mail cím listákat árulnak, néhányszor tíz dollárért, országonkénti bontásban. Összesen 228 ország szerepel a listában, az árak 50 és 500 dollár között változnak, Tanzánia például az olcsóbb kategóriába esik, a legdrágább pedig az Egyesült Királyság. Az ár szempontjából Magyarország igen előkelő helyet foglal el:

email-lists-2

Alig több, mint 100 ezer forintért közel 423 ezer e-mail címet vásárolhatunk, azaz egyetlen címért körülbelül egynegyed forintot kell fizetnünk. Ennyit ér tehát a postaládánk a feketepiacon. (Talán itt érdemes egy pillanatra megállnunk és elgondolkodnunk, hogy nekünk mennyit ér.)

Nézzük, hogy ez mit jelent a többi országhoz képest, például tekintsük azokat, akik velünk egy árkategóriában ($400) vannak:

Ország Darabszám Egységár
Oroszország 2.006.321 0,05 Ft
Franciaország 1.393.935 0,07 Ft
Kanada 1.288.691 0,08 Ft
Csehország 1.236.800 0,08 Ft
Olaszország 1.207.026 0,09 Ft
Japán 1.170.301 0,09 Ft
Ausztrália 1.087.139 0,09 Ft
Lengyelország 796.495 0,13 Ft
Kína 604.476 0,17 Ft
Magyarország 422.919 0,24 Ft

A táblázat szerint nem csak a nagy országokéhoz, hanem a környező országok áraihoz képest is drága a magyar e-mail cím. Minőségi magyar termék 😉

Persze modern karácsonyról lévén szó, nem egyszerű termékről van szó, hanem SaaS ajánlatról, ami ezúttal Spam az a Service-t jelent:

email-lists-3

Ha ismét matekozunk egy kicsit, akkor az jön ki, hogy 5 fillérért küldhetünk ki egy kéretlen levelet bármelyik országba. Sokkal kedvezőbb, mint a hagyományos posta!

Ráadásul biztosak lehetünk abban, hogy a szolgáltatás működik, hiszen én is megkaptam ezt a kéretlen levelet. Ha nem érdekel, vajon kattintsak a levél végén található “Unsubscribe” linkre? 😉

 

Technorati Tags: ,,

HTTPS: rendesen vagy sehogy

Volt szerencsém Bolognába látogatni nyáron, és örömmel láttam, hogy a repülőtéren ingyenes wifi szolgáltatás van. Lehet, hogy már ekkor gyanakodnom kellett volna, de igazából akkor kezdett a dolog furcsa lenni, amikor a felkapcsolódás után ez az oldal fogadott a böngészőben:

airport-ssl-warning

A hibaüzenet szerint az oldalhoz tartozó SSL tanúsítvány “kicsit” hibás:

  • Nem megbízható a kiállítója.
  • Lejárt az érvényessége.
  • Másik weboldalra szól.

Valójában csak akkor lehetne hibásabb, ha már vissza is vonták volna a tanúsítványt.

Aki mégis továbblép, az ezzel az oldallal találkozhat a bolognai reptéren:

airport-webpage

Igazán eredeti dizájn. Oké, Bologna nem egy metropolisz, de a helyi egyetemen simán találhattak volna egy unatkozó diákot, aki egy hétvége alatt pofásabb weboldalt tud összedobni.

Ekkor már kíváncsi lettem és kis kísérletezéssel hamar kiderült, hogy a weboldalnak semmi köze ahhoz, hogy működik-e az internet hozzáférés, vagy sem.

Sok már itt a gyanús tényező:

  • Tanúsítvány
  • IP cím
  • Dizájn
  • Telefonszám gyűjtögetés

Ez volt az a pillanat, amikor konkrétan felálltam és körülnéztem, hátha ott ül valahol Troy Hunt az ő Pineapple-jével.

Egy rendes SSL tanúsítvány ezeket a kétségeimet könnyen eloszlathatta volna. De az ilyen, érvénytelen tanúsítvány semmire nem jó, mindössze annyit garantál, hogy az átlagfelhasználót idegesíteni fogja az oldal, a szakértőbb felhasználók pedig aggódni fognak az adataik biztonsága miatt. Aki HTTPS-re adja a fejét, csinálja rendesen, különben csak az ellenkezőjét éri el vele.

 

Technorati-címkék: ,

Mixed content warning

Szomorú, amikor így széthullik egy oldal a böngészőben, például Chrome-ban:

mixed content chrome

Hogy miért? Hát nem nyilvánvaló, ott van a magyarázat. Segítek:

mixed content chrome warning small

Úgy hívják, hogy mixed content warning, és warning, azaz figyelmeztetés létére nem éppen feltűnő. Lássuk ugyanezt Firefoxban:

mixed content FF

Megvan?

mixed content FF blocked small

Az Internet Explorer kevésbé finomkodik, azonnal a felhívja a felhasználó figyelmét:

mixed content warning

Bár itt nem egy pajzs ikont kell keresgélnünk (amit egyébként túl sokszor, túl sok mindenre használtak már), hanem rögtön kapunk egy szöveges üzenetet, semennyivel sem jobb a helyzet. Ezt az üzenetet, és úgy általában a problémát, ugyanis egy átlagos felhasználó nem érti. Sőt, nem csak hogy a felhasználók nem értik, de a fejlesztők sincsenek tisztában a biztonsági vonatkozásokkal, különben nem lennének ilyen problémás oldalak.

Pedig arra kellene csak figyelni, hogy ha az oldal https:// protokollon töltődik be, akkor az oldalra betöltődő összes (igen, az összes) tartalom is https-en jöjjön, ne legyen egyetlen http:// link sem az oldal kódjában. Ha külső domainről töltesz be tartalmat, és nem tudsz relatív URL-t használni, akkor kezdd az URL-t “//”-rel, és a böngésző azt a protokollt fogja használni, amit az oldal is használ. Ezt a hívják, hogy “protocol relative”, vagy “scheme relative” vagy “scheme-less relative” URL, és már az URI általános formáját leíró RFC 3986-ban is szerepel (2005. január), és természetesen a böngészők is értik.

Ideje lenne kijavítgatni az oldalainkat, a böngészőknek pedig előbb-utóbb teljesen blokkolni az ilyen defektes oldalakat.

 

Technorati-címkék: ,,