MAV-START elvira vs https

https://elvira.mav-start.hu

nincs tobb kerdesem!

Tisztelt Utasunk!

A MÁVDIREKT részére küldött megkeresését köszönjük. Felvetésével kapcsolatban az alábbiakról tájékoztatjuk.

Levelét érintett munkatársainknak továbbítottuk. Visszajelzésük értelmében ELVIRA szolgáltatásunk csak http protokollon használható.

Megkeresését ismételten nagyon köszönjük. Jó utazást kívánunk járatainkon.

Üdvözlettel:

John Doe

Ügyfélszolgálati szakértő

cid:image002.jpg@01CEFD7D.F3174190
MÁV-START Vasúti Személyszállító Zrt.
ÜGYFÉLSZOLGÁLAT - MÁVDIREKT

Székhely: H - 1087 Budapest, Könyves Kálmán krt. 54-60.
MÁVDIREKT: +36 (1) 3 49 49 49, +36 (20/30/70) 499 49 99
Fax: +36 1 511 2093
E-mail: informacio@mav-start.hu
Web: www.mavcsoport.hu

( kovi | 2019. 08. 27., k – 17:42 )

Nekem sincs, csuda szep lett a blog menu, a spinnelt reszt le ne zard!

--
Vortex Rikers NC114-85EKLS

( goodbyte v | 2019. 08. 27., k – 17:53 )

Én azon akadok ki hogy a csodálatos telefonos alkalmazásfosuk képtelen mobilnet nélkül megmutatni a már megvett és letöltött jegyeket!

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Mobil alkalmazásban vásárolt jegy, robogó intercity , térerő nuku ... -> érvényes jegyek lista üres, kalauz mosolyogva vár :D Augusztus 17 -én és 20-án is.

------------------------------------------
“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

A "felhasználták-e már" jó kérdés - ahhoz első blikkre valóban online kell lenni az olvasó oldalán, hiszen az egyes olvasók egymással közvetlenül nem tudnak beszélgetni.
Mondjuk a többszörös felhasználás akkor merülhet fel, ha adott legyet másik telefonról bejelentkezve arra a készülékre _is_ leküldi a szerver - ilyet még nem próbáltam; én mondjuk a készülék egyedi azonosítóját (ahonnan rendelve lett a jegy) is belekombinálnám a dologba, és ezzel csak ott lenne valid az e-ticket/csak oda töltődne le, ahol/amelyik eszközön azt megvásárolták.

A jegyek jogilag személyekhez, technikailag felhasználói accounthoz és nem készülékhez tartoznak. Hivatalosan be kellene mutatnod egy személyazonosságot igazoló iratot, amikor bemutatsz egy e-jegyet, de a jegyvizsgálók ezt nem ellenőrzik. Azaz egy jegy két készülékre is letölthető.

nincs külön jegy az appban meg amit online veszel, technikailag ugyanaz a fajta cucc, ezétr nem csináltak két rendszert. a nyomtatósnál meg adott időtartamra szól, ha nem lenne központilag kezelve annyiszor mehetnél vele ameddig le nem jár. Ahogy a sima jeggyel is, ha nem ér oda a kalauz és nem kezeli. vagy vissza is lehet váltani ugye.

Mivel általában ugyanaz a kalauz van egy vonalon így simán tárolhatná offline a már felhasznált jegyeket. (vagy ha csere van, akkor átadják az eszközt)

De már az is minimális csalási lehetőséget adna ha úgy lenne megoldva, hogy ha van net, akkor megnézi online hogy felhasználták-e már korábban, ha nincs net, akkor meg átengedi. (esetleg queue-ba rakja és ellenőrzi, ha visszajön a net)
Innentől a csalónak arra kéne játszania, hogy akkor épp offline legyen amikor nála van az ellenőrzés ami már elég necces.

A screenshot-tal elég könnyű lenne visszaélni, ugyanis az e-jegyet a leolvasás nem "lukasztja ki", azaz nem lesz kezelt állapotú, ergo egy másik utas simán fel tudná mutatni teljes képernyőre kirakott képernyőképen.
A leolvasó szerintem az adattartalom alapján ellenőriz, amit -én így csinálnám- a kibocsátáskor a szerver elektronikusan aláír, és ezt az aláírt adathalmazt rakja bele a qr-kódba. Ha az aláírás valid, és az érvényességi idő, esetleg vonatszám, viszonylat rendben, akkor tekinteném a leolvasónál érvényesnek a jegyet.

https://apps.apple.com/hu/app/m%C3%A1v/id969467518

Version History
30 Aug 2019 Version 2.0.13
- Regisztrációs e-mail címben szereplő kis és nagybetűk nincsenek megkülönböztetve

- Az utolsó bejelentkezett felhasználó által letöltött jegyek megtekintése internet kapcsolat vagy a felhasználó hitelesítés nélkül is. Részletesebb információk a jegyek letöltöttségéről.

- Új felhasználó regisztrációs adatainak ellenőrzésének egységesítése.

- Mávinform képernyő egységesítése

- Hibajavítások: ideiglenes jelszókezelés, e-mail cím csere, regisztrációs problémák

-------

Az Androidos is frissult ahogy latom

??? Elég régóta működk nekem offline a jegyek bemutatása - a vásárlás után meg kell várni, hogy lejöjjön a jegy - még a hálózati kapcsolat aktív állapotában kell megnézni, és utána már ki lehet lépni az alkalmazásból, le lehet akadni a hálózatról - a jegy adathalmaza már ott lesz a telefonon.

( TCH | 2019. 08. 27., k – 17:58 )

Miért kéne letitkosítani valamit, ahol nincs login, kizárólag publikus információk közlekednek a csatornán? Hogy sokkal több erőforrást zabáljon fel feleslegesen, azért, hogy ne lehessen valamit esetlegesen lehallgatni, amit nincs is értelme lehallgatni?

Mindkettő védhető JS tiltásával. Egyébként meg felettébb érdekes, hogy a folyton biztonságoskodó böngészőgyártók erre még valahogy miért nem voltak képesek, hogy egy a NoScript-hez hasonló natív funkciót építsenek az úgyis minden szart magában hurcoló böngészőikbe? Miért nincs benne legalább valami alapszintű védelem a JS alapú SAM-ek ellen, akár úgy, hogy ha valami "gyanúsat" csinál egy script, akkor rákérdez, hogy tiltsa-e, vagy akár úgy, hogy valami "kód DB" alapján beazonosítgatja az ismertebbeket? Vagy bármi egyéb... Miért az overforced https a megoldás, amikor az csak az MITM módon elkövetett injektálások ellen jó? A kliens-oldalon jelenlévő SAM-ek által az oldalakba injektált szeméttel mi lesz?

"egy a NoScript-hez hasonló natív funkciót"

Nem a NoScript 1:1 újraimplementálásáról beszélek. Hanem egy ahhoz hasonló, részleges tiltást lehetővé tevő funkcióról. Kellene egy natív, flexibilis script blocker, ami képes az egyes scripteket tiltani, akár egy fájlról van szó, akár egy inline blokkról a HTML-ben. Olyasmi, mint a Classic Operáé volt. (Mondjuk inline script-et az sem tudott tiltani.) Nem hiszem, hogy ez akkora feladat lenne a böngészőgyártóknak. Valami minimális "heurisztikát" is kaphatna, ha pl. engedélyezi a felhasználó, de elkezdi felzabálni az erőforrásokat, vagy gyanúsan elkezd egy másik domain felé kacsingatni, akkor figyelmezteti a felhasználót. Ezt sem hinném, hogy akkora meló lenne.

És azt sem hiszem, hogy ez nekem jutott eszembe egyedül és azt sem, hogy nem szóltak nekik már erről.

A megerősítés/beállítás azért nem működik, mert az userek 99%-a annyit lát belőle, hogy "些错误信息 在某个地方?" [YES] [NO]

Azon meg dolgoznak, hogy felismerjék és blokkolják az irreálisan sok erőforrást zabáló js-t pl.: https://chromium-review.googlesource.com/c/chromium/src/+/1675916

Hát az a user, aki azt sem érti, hogy "Vigyázat, a weboldal egyik eleme veszélyes lehet! Letiltsuk?", azon nemhogy a https, de semmi sem fog segíteni. Nem lehet azt játszani, hogy semmit sem csinálunk, mert a hülyék úgy sem értik. A számítástechnikának a hülyék szintjéhez való igazítása vezetett oda, hogy egyre szarabb és használhatatlanabb minden.

Dolgoznak rajta? Hát nem tudom, hogy mit kell annyit dolgozni azon, hogy a program tudja, hogy egy adott JS szál mennyit eszik. Érdekes, hogy a suxploder már tizenöt éve is tudott valami ilyet a maga primitív módján, amikor közölte, hogy a parancsfájl lassítja az oldalt és mi legyen vele.

Az a baj, hogy nem ennyire egyszerű megállapítani, hogy mi a "gyanús" és mi nem. Pl. a cloudflare meg a google recaptcha is a gpu-t és a proof-of-work-ot használja a botok kiszűrésére.

De a coinminereket valószínű lehetne blokkolni és meg is teszik: https://www.coindesk.com/firefox-browser-adds-option-to-automatically-b…

Btw by default nincs tiltva a cryptominer és van egy olyan gyanúm, hogy domain lista alapján dolgozik, ami mitm nem a legideálisabb.

De igazából mindegy, mert a crypto miner csak 1 dolog, mellette sok más probléma forrása lehet, ha bárki beleinjektálhat bármit és igazából nincs valódi ok a https ellen.

Ha tényleg ennyire zavar a szerinted fölösleges cpu felhasználás és valami ellen nagyon harcolni akarsz, akkor a tömörítés ellen érdemesebb: gzip 100MB: 2.7s, AES-256 100MB: 0.01s

Csűrhetjük, csavarhatjuk, nem a https az univerzális megoldás. Nem egy jobb megoldást írtam le fentebb. Azok ellen sem volt "valódi ok". BTW, a felesleges titkosítás nem elég valódi ok?

Ki mondta, hogy én valami ellen nagyon harcolni akarok? Hol írtam ilyet? Kezdődik a személyeskedés? Amúgy, ha a tömörítés alatt azt érted, hogy pár byte-os HTML kódokat tömörítenek be, majd ki, feleslegesen, akkor egyetértünk.

Nem írtál jobb megoldást: a JS tiltás nem az.

Tegyük fel holnaptól opt-in lesz a JavaScript és ezzel együtt http-re vált a youtube.com meg az index.hu, hiszen semmi titkos nincs rajta. (Egyik site sem működik rendesen JavaScript nélkül)

Szerinted hányan fogják az oldal elhagyását választani és hányan fognak a JavaScript elfogadására nyomni?

Amúgy havi szinten jönnek ki Androidra a Media framework-ot érintő, critical RCE bugok (múlt hónapban épp 3 ilyen volt). Szóval a tiltáshoz hozzáadhatod a videó/hang fájlok lejátszását is. (és nem csak a böngészőbe, hanem oprendszer szinten)

Részleges JS tiltást írtam. Részlegeset. Többször is leírtam, hogy részleges tiltásról beszélünk.

A felhasználók nagyobbik fele el fogja fogadni a JS-eket, sőt az elején messze a többség. De előbb utóbb ki fog alakulni a szokás, hogy megnézik mit fogadnak el. Ez ilyen emberi jellemvonás. Te is megnézed mit sóznak rád, ha a szemed előtt van. De a JS-t elrejtik, hogy ne is szúrhasson szemet.

Sz*rk: A videók és hangok lejátszásának tiltására ugyanaz vonatkozik, mint anno a Flash-re, hogy block és majd engedélyezem, ha akarom. Automatikusan semmi ne induljon el. Semmi se.

> Részleges JS tiltást írtam. Részlegeset. Többször is leírtam, hogy részleges tiltásról beszélünk.

Oké, felmész youtube.com-ra kiírja, hogy kell az all.js az oldal működéséhez. Mi alapján fogod eldönteni, hogy engeded vagy nem?

> Automatikusan semmi ne induljon el. Semmi se.

Teljesen mindegy, hogy automatikus-e vagy nem. Meg akarja hallgatni a kedvenc zenéjét: felmegy YouTube-ra, rányom a play-re, elfogadja a videólejátszást, majd a malware-ezett wifi router a valódi mp4 helyett elküldi az exploittal dúsított változatot. Ez ellen nincs lehetséges védekezés, ha bárki módosíthatja az adatfolyamot.

Alapszabály, ha nem tudod, hogy mi az, akkor jobb kitiltani. Ha lerohad tőle az oldal, akkor meg lehet újraengedélyezni. Egyébként pont a youtube nagyon rossz példa, mert az még pont használható JS nélkül. Vagy úgy, hogy letiltod a JS-t, úgy navigálsz és amikor videót akarsz nézni, akkor URL Ctrl+C, terminálba 

mpv <url>

(vagy global hotkeybe ugyanez), vagy úgy, hogy custom klienst használsz hozzá; én is írtam magamnak egyet.

Amennyiben az sechole az összes létező codec-et egyszerre érinti, akkor igazad van, amúgy nincs: ha a browserben van a sechole, akkor már kikerüli, ha 

youtube-dl/mpv

kombót használ, meg akkor is, ha a droid "média frameworkjében". Ezért kell tiltani a videókat/zenéket tartalmazó HTML5 tag-ek automatikus indulását. Majd, ha akarom, akkor copyzom az URL-t és átadom a lejátszónak. (És normális lejátszót kell használni, nem azt, amit a mikiszoft, vagy a kugli ad, mert azok lesznek a fő célpontjai az ilyen jellegű exploitokra szakosodott SAM gyártóknak.)

Miért ne tudhatnám? Ez közönséges hisztériakeltés. Biztos feltörték a routeremet, meg a Digi hálózatát is. Ennyi erővel feltörték a célgépet is és még a https előtt injektálják be a szemetüket a stream-be, nemde?

Vagy esetleg arra gondolsz, hogy ül kint az ember valahol a városban és a mobilja felcsatlakozik egy közeli routerre, ami esetleg fertőzött? Ad 1. fentebb leírtam, hogy lehet ellene védekezni. Ad 2. lentebb leírtam, hogy a https sem bombabiztos védelem, ennyi erővel ott sem tudhatod, hogy azt kapod, amit kell. Ad 3. Miért nem opcionális a https? Oké, ha kint ül valahol és public routerre csatlakozik vezeték nélkül, akkor használja, ha akarja. De ha egy megbízható hálózaton ülök, akkor miért kéne?

A BGP a csomagok route-olását végzi, így akár eltéríthetnek egy teljes IP tartományt is. Onnantól teljesen mindegy milyen DNS-t használsz.

De, pont a https tud védeni ilyen támadások ellen, hiszen a támadónak nem lesz private key-je a domain-hez tartozó certben szereplő public key-hez.

Megallasi problema gondolom megvan, hogy egy akar rovidke kodrol meg azt sem tudod eldonteni, hogy vegtelen ciklusba fog-e kerulni. A https kizarasaval MITM johet barmi barhonnan, szoval akkor mi alapjan is dontse el a user, hogy fusson-e egy script?

Amugy meg, de, a https egy univerzalis megoldas, azt nyujtja, hogy legalabb tudod, hogy mi honnan jon es nem kell ad hoc heurisztikakra hagyatkoznod, legalabbis nem elso lepesben.

Ld. fentebb.

Nem, nem univerzális. Az RC4-es TLS kapcsolatokat pl. elég jól tudják már törni és ez csak egy cipher volt. És ez csak az egyik fele. A másik fele a certek. A cert alapú szarakodás az igazi achilles ina ennek az egész https illúziónak. Lejárt a cert, buktad a biztonságos kapcsolatot. Érvénytelen a cert, buktad a biztonságos kapcsolatot. Bug van a cert exchange algoritmusban, buktad az összes biztonságos kapcsolatot. És akkor még nem is beszéltünk arról, hogy miért is kellene, miért is lehetne megbízni mindenféle harmadik fél által kiállított certben, hogy az tuti biztonságos. Van erre valami garancia? Nincs. A cert akár self-signed is lehet. Na, ennyit a https univerzálisságáról és biztonságáról is.

A browserek, oprendszerek és egyéb runtime-ok gyártói adnak egy "megbízható" listát arról hogy melyik CA -k a megbízhatók - persze itt jön be a "szerintük" faktor. A self signedre nyilván minden pirosan fog villogni.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

> Megbízható.™

A root certek nélkül technikailag képtelenség megmondani, hogy a felkínált cert valóban a szervertől jön-e. Arról meg a cert transparency gondoskodik hogy a cert kibocsátók valóban megbízhatóak és csak valóban a szerver tulajától származó cert requesteket írják alá.

Egyrészt van újabb irománya is a témában (https://blog.okturtles.org/2017/02/coniks-vs-key-transparency-vs-certificate-transparency-vs-blockchains/), amelyben leírja, hogy azellennemvéd ("Previously, we reviewed Google’s Certificate Transparency efforts, and observed that while it does not prevent MITM attacks, it might detect at least some of them."), másfelől meg, idézem tőled (kiemelés tőlem): "ha rendesen van implementálva". Az a bizonyos nagy ha. Ez minden, csak nem biztos védelem. Megint csak elhisszük, hogy jól van implementálva.

Tehát a https nem biztonságos, mert a teljes képernyős, vörös felkiáltójeles figyelmeztetés, amit csak három dialógus mélyen, egy aprócska, "igen, felfogtam a veszélyt" gombbal lehet csak meghaladni, nem elég figyelemfelkeltő, de ugyanez a user gond nélkül képes minden egyes JS és html (és talán a CSS-ben is lehet 0-day) fájlt minden lapletöltéskor megbízhatóan auditálni.
Félreértés ne essék, engem is zavar az ótvar mennyiségű JS szemét mindenhol, de sajnos nem én döntöm el, hogy milyen legyen a web és addig is a https egy kiforrott darabkája a web jobbá tételének.
Nekem úgy tűnik, hogy csak fogalmatlanul szidod a https-t, mert CPU ciklusokat pazarol titkosításra.
És, hogy a felvetettekre is reagáljak, el lehet utasítani a RC4-et (pontosabban kliensként nem kell felkinálni) és magad configolhatod, hogy melyik cert-ekben bízol meg, ha akarod akár egyesével minden oldalhoz (és ezen felül lehet még NoScript is).

Szerk:
Szerintem máshogy értettük az univezálisat. Nálad a mindent megold szinonimája, erre valóban nem jó a https, én meg azt értettem alatta, hogy [a TLS] majd minden eszközön és környezetben elérhető, rengeteg protokolra ráhuzható, az implementációk aránylag könnyen cserélhetőek, rengetegen foglalkoznak a tesztelésével, auditálásával és ha kiderül valami gyengeség vagy turpisság, akkor hangolható, lehet cipher-t váltani, hosszabb kulcsokat használni, etc. Igen, a DH is csak egy lehetséges, algoritmus és kétszer akkora kulccsal használva már az NSA-nak is beletörhet a bicskája.

> Tehát a https nem biztonságos, mert a teljes képernyős, vörös felkiáltójeles figyelmeztetés, amit csak három dialógus mélyen, egy aprócska, "igen, felfogtam a veszélyt" gombbal lehet csak meghaladni, nem elég figyelemfelkeltő, de ugyanez a user gond nélkül képes minden egyes JS és html (és talán a CSS-ben is lehet 0-day) fájlt minden lapletöltéskor megbízhatóan auditálni.

Nem. A http-s azért nem biztonságos, mert egyfelől törhető, másfelől pedig egy megbízhatatlan cert rendszeren alapszik az egész, amiben hitalapon kellene megbízni. No way.

> addig is a https egy kiforrott darabkája a web jobbá tételének.

Azért sikerült eddig már húszféleképpen kibabrálni vele?

> Nekem úgy tűnik, hogy csak fogalmatlanul szidod a https-t, mert CPU ciklusokat pazarol titkosításra.

ROFL. Tehát ami műszaki érveket, cikkeket felhoztam ellene, hogy nem törhetetlen, meg a CT megbízhatatlan, az smafu. Mert én csak a CPU ciklusokon lovagolok...azt is fogalmatlanul. OK.

> És, hogy a felvetettekre is reagáljak, el lehet utasítani a RC4-et (pontosabban kliensként nem kell felkinálni) és magad configolhatod, hogy melyik cert-ekben bízol meg, ha akarod akár egyesével minden oldalhoz (és ezen felül lehet még NoScript is).

Akkor mégsem a csak CPU ciklusokon lovagoltam, mondtam mást is? Ja, csak nem olvastad el, vagy nem értetted meg: "A "megoldás" az lenne, hogy más chiphert használunk a TLS-hez, de ennek ellenére az RC4 még rengeteg helyen használatban van. Főleg a WiFi-capable routerek érintettek." Igen, el lehet utasítani. És előrébb vagy vele? Akkor nem netezel? Vagy tolod titkosítatlanul? Az átlagjúzer meg meg fogja kérdezni, hogy RC4? Azmiaz? A certek megbízhatóságának konfigolhatósága is vicces. Hány cert van a világon? Hány CA? Egyesével döntsem el mindegyikről? És az átlagjúzer is? Ez mennyivel jobb, mint az, hogy a JS-hez van egy flexibilis szűrőd?

> Igen, a DH is csak egy lehetséges, algoritmus és kétszer akkora kulccsal használva már az NSA-nak is beletörhet a bicskája.

"Beletörhet.". Het. Megint ez a fránya feltételes mód. Ami viszont nincs feltételes módban (max. múlt időben), hogy sikerrel seggbekúrták a fél világ https forgalmát. Biztonságos.™

Nincs feltörheteten protokoll. Tehát a holnaputáni titkosítás is sz@r, úgyhogy ne is használjunk semmit, ahogy minden zár kinyitható több-kevesebb idő alatt, ergo hagyjuk nyitva a lakást, autót mindent, mert úgyis be tudnak menni... Pertsze. Ha akarnak, akkor be lehet menni, és be is mennek, ha megéri.

A biztonságnak vannak szintjei - a plaintext protokollok gyakorlatilag sem a integritásra, sem az azonosíthatóságra nem adnak megoldást. Az ssl-be/tls-be csomagolt forgalmak a "csomagolás" minőségétől függő erősségű/megbízhatóságú megoldást adnak ezekre - még a leggyengébb (jó, a NULL cipher nem) algoritmusok is jobbak, mint a semmi - de hamis biztonságot elkerülendő az érintett adatoktől függően kell növelni a csomagolás "minőségét", erősségét, hogy a "csomagolást" észrevétlenül kibontani ne érje meg.

A cert rendszer miért megbízhatatlan? Ezt jó lenne, ha részleteznéd, mert így elég durva és nehezen elfogadható általánosítás csak. És ha már ennyire sarkos véleményed van róla, akkor gondolom megoldási javaslatod is van, úgyhogy azt is várjuk szeretettel :-)

Ne adj szavakat a számba. Azt mondtam, hogy legyen opcionális, hogy az érzékeny adatokra be lehessen kapcsolni.

Ezen már futottunk pár kört, fentebb, meg lentebb, én is leírtam, hogy nyilván van az, hogy avulási idő előtt nem tudják feltörni, tehát oké, de egy csomó helyen gyenge ciphereket használnak, te meg dönthetsz, hogy elfogadod, vagy nem csatlakozhatsz. Volt belinkelve egy eset, ahol 30 sec alatt törték meg a weboldal forgalmát.

Elolvastad a belinkelt cikket a témában? Ha nem, akkor tedd meg. Ha konkrétan a certrendszer helyett akarsz megoldást, akkor azt már leírtad te: PGP.

Definiáld, mi az érzékeny adat. És ezt tanítsd meg minden felhasználónak. Oké. Oldd meg, hogy a "nem érzékeny" adat ne befolyásolhassa a tls-en keresztül érkezett adatok megjelenését, tartalmát, értelmét.
"Volt belinkelve egy eset, ahol 30 sec alatt törték meg a weboldal forgalmát." - ssl nélkül gyakorlatilag azonnal ott van az ember "kezében" az adatfolyam, és azt tesz vele, amit akar.

Ezt már korábban letisztáztuk a topicban: azt a felhasználó dönti el, hogy neki mi érzékeny. Értsd meg: én nem betiltani akarom a https-t, hanem opcionálissá tenni.
Igen, SSL/TLS nélkül azonnal, vele 30 másodperc. Megérte? Tudom, nem kéne elbaszni. De elbasszák. Nyilván az elkúrás nem a https hibája; viszont az a https-t használók hibája, hogy azt hiszik, a https automatice megoldja minden gondjukat: nem, nem fogja.

Nem minden esetben a felhasználó kompetenciája, hogy az adott információ védendő vagy sem. Egy híroldalnál például pont, hogy az oldalon lévő tartalom gazdája az, akié a döntés, hiszen az ő adatairól van szó, arról, hogy harmadik fél ne piszkáljon bele.
"SSL/TLS nélkül azonnal, vele 30 másodperc" - ha valaki sperhatnival nyitható zárat rak az ajtójára, akkor ne csodálkozzon, hogy akkor is meglátogatják, amikor nincs otthon. Az a 30s ugyanilyen szélsőséges eset - kérnék valós példát egy qualys ssl teszten "A" vagy jobb minősítést kapott beállítással működő szerver forgalmának 30s, de üsse kavics, 30perc alatti feltörésére, és az adatfolyam módosítására. Hatvanszor annyi idő gondolom elég lesz.
Ha nem, akkor a "TLS/SSL 30s alatt törhető" kijelentésed nem más, mint FUD vagy egyszerű szakmai tudatlanság. Igen, ugyanúgy tudatlanság, mint az, hogy valaki nem képes jól használni egy biztonsági eszközt/megoldást, és igen, az nem a https hibája, ha rosszul használják.

> Nem minden esetben a felhasználó kompetenciája, hogy az adott információ védendő vagy sem.

Akkor legyen opt-out, de ne legyen kötelezően letolva mindenkinek a torkán.

> Egy híroldalnál például pont, hogy az oldalon lévő tartalom gazdája az, akié a döntés, hiszen az ő adatairól van szó, arról, hogy harmadik fél ne piszkáljon bele.

Nem egészen, egyetlen oldal sem felelős a felhasználói hibákért, az mindig a felhasználó felelőssége.

> ha valaki sperhatnival nyitható zárat rak az ajtójára, akkor ne csodálkozzon, hogy akkor is meglátogatják, amikor nincs otthon. Az a 30s ugyanilyen szélsőséges eset - kérnék valós példát egy qualys ssl teszten "A" vagy jobb minősítést kapott beállítással működő szerver forgalmának 30s, de üsse kavics, 30perc alatti feltörésére, és az adatfolyam módosítására. Hatvanszor annyi idő gondolom elég lesz.
> Ha nem, akkor a "TLS/SSL 30s alatt törhető" kijelentésed nem más, mint FUD vagy egyszerű szakmai tudatlanság. Igen, ugyanúgy tudatlanság, mint az, hogy valaki nem képes jól használni egy biztonsági eszközt/megoldást, és igen, az nem a https hibája, ha rosszul használják.

Ja értem, tehát, ha a PGP-nél az user elbassza a kulcsok átadását és feltörik, akkor szar a PGP, de ha a https-nél szarul csinálják meg az egészet és azt lehet feltörni, akkor az meg FUD.

"Nem egészen, egyetlen oldal sem felelős a felhasználói hibákért, az mindig a felhasználó felelőssége." - Ha egy független híroldal azt küldi a böngésző fel, hogy szrban vagyunk, és ezt út közben egy qrmányzat-fan átírja "minden qrvajó"-ra, akkor az kinek a hibája? Merthogy ssl nélkül csak azt hiszed, hogy azzal "beszélget" böngésződ, ami az adott címen van, közben meg ez egyáltalán nem biztos.

"https-nél szarul csinálják meg az egészet" - Mármint szerinted sz@r az egész, és a bizalmi háló sokkal jobb? Kértem, hogy a világ túlfelén lévő webshop iránti bizalom hogy jön ki a bizalmi hálóból? Hány kvázi ismeretlen, feléd semmilyen felelősséggel nem tartozó emberben kell megbíznod ahhoz, hogy a végén elfogadd igaznak azt, hogy a túloldal valóban az, akinek mondja magát, és amit mond, az valóban az, ami eljut hozzád.

Szóval tételesen mi a sz@r a csak a TLS1.0 fölötti protokollokat támogató webszerver titkosításával, és azzal, hogy azt a certet valóban ellenőrizve annak adták ki, aki az adott domainhez hasnzálati joggal bír. Igen, a doman-validated certek csak azt nézik, hogy az adott domain-en belül egy oldalt létre tud-e valaki hozni megfelelő tartalommal - ezek a hagyományos elzett cilinderzárakra hajazó megoldások - de ennél jóval komolyabb személyes ellenőrzés is akad a tanusítási folyamatokban: nemegy és nem két céges szerver certjét kellett megigényelnem/megújíttatnom - mondjuk úgy, hogy elég sok dokumentumot és azok valódiságát végignyálazta a tanusítványkiadó illetékese, mielőtt a cert.request-et aláírták volna. Volt, nem is egy eset, ahol a certhez tartozó privát kulcs HSM-ben csücsült, ergo ott még arra sem volt esély, hogy a kulcspárt lenyúlva és a forgalmat eltérítve valaki visszaéljen a certtel.

> Merthogy ssl nélkül csak azt hiszed, hogy azzal "beszélget" böngésződ, ami az adott címen van, közben meg ez egyáltalán nem biztos.

SSL-lel is, mert mint már be lett linkelve pár példa, a certet is lehet hamisítani.

> Mármint szerinted sz@r az egész, és a bizalmi háló sokkal jobb?

Te tényleg nem olvasod el amit írok, vagy csak ennyire nem érted? Én most rohadtul nem az egész https-ről beszéltem, hanem konkrétan arról az egy bizonyos elbaszottul konfigurált 30 másodperces töréssel seggbekúrt szerverről, azt állítottam párba azzal, hogy valaki elbassza a PGP key-exchange-t. A kettős mércédre világítottam rá, hogy amikor elkúrás miatt 30 másodperc alatt törik a https-t (mert senki nem mondta, hogy ez a default, arról volt szó, hogy balfasz felhasználás mellett megtörténhet (ahogyan meg is történt)), akkor az FUD, de ha a PGP kulcsokat rakja be a lábtörlő alá a balfasz júzer, akkor az a PGP hibája. Ez kettős mérce. És még unfair is, mert a PGP-nél (tudtommal) soha sem törekedtek semmiféle globális key-interchange ökoszisztéma kiépítésére, a felhasználókra van bízva, míg a https pontosan azt ígérte, hogy ezt megoldja helyettünk, csak éppen kurwára nem sikerült.

> Kértem, hogy a világ túlfelén lévő webshop iránti bizalom hogy jön ki a bizalmi hálóból? Hány kvázi ismeretlen, feléd semmilyen felelősséggel nem tartozó emberben kell megbíznod ahhoz, hogy a végén elfogadd igaznak azt, hogy a túloldal valóban az, akinek mondja magát, és amit mond, az valóban az, ami eljut hozzád.

Válaszoltam rá: visszakérdeztem, hogy https-nél milyen alapon bízol meg benne? A https-nél hány esetlegesen hamis cert fog az utadba kerülni, amiért megint nem lesz felelős? Ha a CT logokba becommitolt bogus certet nem szúrja ki a monitoros, akkor ki vállalja a felelősséget?

> Szóval tételesen mi a sz@r a csak a TLS1.0 fölötti protokollokat támogató webszerver titkosításával, és azzal, hogy azt a certet valóban ellenőrizve annak adták ki, aki az adott domainhez hasnzálati joggal bír.

Ha nem írtam le eddig ötvenszer...de akkor összeszedem neked tételesen, mi baj van vele:
- Hiába vannak biztonságosabb cipherek, a legtöbb helyen sérülékeny ciphereket használnak.
- A cert-exchange egy nagyon rossz vicc, semmi garancia nincs rá, hogy most nincs benne valami olyan sérülékenység, ami megint megdönti az egész rendszert.
- A certek validságának ellenőrzése is egy nagyon rossz vicc, ha hiba csúszik az implementációba, vagy nem szemfüles a monitoros, akkor megint dől az egész rendszer.

Certet lehet hamisítani. Oké, akkor tessen hamisítani monduk olyan certet, ami az e-személyin van. Az is X509, amögött is egy CA-lánc áll, tehát az is sz@r szerinted. Attól, hogy valamit valamikor egy elkefélt környezetben összehoztak, még nem sz@r az egész.

Két idézet tőled:

"másfelől pedig egy megbízhatatlan cert rendszeren alapszik az egész, amiben hitalapon kellene megbízni."

"nem az egész https-ről beszéltem, hanem konkrétan arról az egy bizonyos elbaszottul konfigurált 30 másodperces töréssel seggbekúrt szerverről"

Szóval az egész rendszer megbízhatatlan, vagy csak egys zerver, amin még tán a null cipher-t is engedték?!

"Válaszoltam rá: visszakérdeztem, hogy https-nél milyen alapon bízol meg benne" - azaz nem válaszoltál, kitértél a neked kellemetlen válasz elől. HTTPS-nél azon az alapon bízok meg benne, hogy az a CA, amelyik kibocsátotta a certet, számomra megbízható-e. Nem 123456 ember (összesen), hanem egy szervezet, aki a cert kibocsátásával felelősséget is vállal azért, hogy az a cert annak lett kiadva, akié az adott entitás, például domain.

"Ha nem írtam le eddig ötvenszer...de akkor összeszedem neked tételesen, mi baj van vele:" - nem idézném a továbbiakat, inkább röviden összefoglalom, mit írtál: mivel a https-t lehet sz@rul is hasnzálni, így sz@r az egész. Ha máshonnan nézzük, tényleg az, mert elég, ha valaki kijön egy matematikai felfedezéssel arra, hogy hogyan lehet irdatlan nagy számokat prímtényezőkre bontani, akkor ugyanis tényleg borul az egész, de a kvantumszámítógépek világánal elérkeztekor is hasonló probléma fog adódni.

> Certet lehet hamisítani. Oké, akkor tessen hamisítani monduk olyan certet, ami az e-személyin van.

Én hamisítsak? Könyörgöm még az általad belinkelt PGP "kritika" is azzal volt tele, hogy így cert hamisítás, meg úgy cert injektálás...

> Az is X509, amögött is egy CA-lánc áll, tehát az is sz@r szerinted. Attól, hogy valamit valamikor egy elkefélt környezetben összehoztak, még nem sz@r az egész.

Amíg a certek mögött csak a vakbizalom marad, addig az.

A két idézetet meg szépen összemostad, csak éppen semmi közük egymáshoz, mert az egyiket arra írtam, hogy mi a baj a cert rendszerrel, a másikat meg a PGP-vel kapcsolatos kettős mércédre. Kérdésedre a válasz: az egész rendszer megbízhatatlan, nem csak az az egy szerver, de azt a szervert törték meg 30 sec alatt, nem a többit. Nem tudom mi nem világos.

> azaz nem válaszoltál, kitértél a neked kellemetlen válasz elől.

Nem tértem ki, ugyanabban a posztban egy sorral lejjebb ott van a konkrét válasz is, csak ahogy nézem egyáltalán nem olvastad el a posztot.

> HTTPS-nél azon az alapon bízok meg benne, hogy az a CA, amelyik kibocsátotta a certet, számomra megbízható-e. Nem 123456 ember (összesen), hanem egy szervezet, aki a cert kibocsátásával felelősséget is vállal azért, hogy az a cert annak lett kiadva, akié az adott entitás, például domain.

Kettős mérce v2.0. Miben különbözik ez akkor a PGP bizalmi hálójától, ha nem az összes CA-ban bízol meg, csak abban, amelyiket tényleg ismered? (Hozzáteszem, ezzel konkrétan nincs baj, csak ez így párhuzamba állítva több, mint visszás...)

> mivel a https-t lehet sz@rul is hasnzálni, így sz@r az egész.

Nem ezt írtam. A válaszaimat nem olvasod el, szavakat adsz a számba; te most az én válaszaimra reagálsz, vagy elképzeled, hogy mit válaszolok és arra? Nem azért szar, mert lehet szarul használni. Világosan leírtam, hogy az nem a https hibája, ha sérülékeny cipherrel használják. Az a https hibája, hogy elhiteti a felhasználóival, hogy ez a globális certhálózat megbízható, miközben nem az.

Hajbi, te vagy az?! Kritizálod az X509-et, de amikor tényszerűen számon kérik rajtad, hogy a jól használt/konfigurált láncon találj fogást, akkro hárítás és mellébeszélés jön.

"Miben különbözik ez akkor a PGP bizalmi hálójától, ha nem az összes CA-ban bízol meg, csak abban, amelyiket tényleg ismered" - Mert mondjuk CA jóval kevesebb van, mint ember, akiben tényleg vakon meg kéne bízni, csak azért, mert a megbízható ismerősöm által megbízhatónak jelölt egyén megbízik olyanban, aki megbízik valakiben, aki... satöbbi, aki megbízik abban, aki megbízhatónak tekinti a világ túlsó felén lévő webshop-ot.
Ja, és ebben a hálóban senkinek, ismétlem senkinek nincs felelőssége a többiek felé - maximum a saját, kis hatással bíró reputcióját veszítheti el, míg egy CA simán kikerülhet a megbízhatónak tekintett körből, ami gyakorlatilag a "rolló le" a számukra.

> Hajbi, te vagy az?! Kritizálod az X509-et, de amikor tényszerűen számon kérik rajtad, hogy a jól használt/konfigurált láncon találj fogást, akkro hárítás és mellébeszélés jön.

Az a mellébeszélés, hogy én találjak egy jól használt/konfigurált láncon fogást, mert ha én nem tudok, akkor nyilván más se és mindezt úgy, hogy volt már a topicban belinkelve cikk, hogy hogyan kúrta seggbe a fél világ https forgalmát az NSA, anélkül, hogy konkrétan bármelyik rohadt láncon fogást talált volna, mert nem a titkosítást törte fel, hanem simán összeszedegethette a kulcsokat a szar key-exchange algoritmusnak köszönhetően. Hárítás meg az, hogy konzekvensen nem válaszoltál egy csomó kérdésre (pl. arra, hogy mégis mi van, ha bogus certet commitolnak be és nem szúrja ki a monitoros), hanem kikerülted a kérdéseket és lovagolsz valami máson. (Amúgy meg komolyan: reductio ad hajbazerum? Ennyire futja? Csak mert személyeskedni akkor szoktak, ha elfogytak az érvek, vagy ha fáj valami...)

> Mert mondjuk CA jóval kevesebb van, mint ember, akiben tényleg vakon meg kéne bízni, csak azért, mert a megbízható ismerősöm által megbízhatónak jelölt egyén megbízik olyanban, aki megbízik valakiben, aki... satöbbi, aki megbízik abban, aki megbízhatónak tekinti a világ túlsó felén lévő webshop-ot.

ROFL, olvasd már el, amit írsz: a CA-k pontosan ezt próbálják megcsinálni helyetted (feltételezve részükről a jóindulatot).

> Ja, és ebben a hálóban senkinek, ismétlem senkinek nincs felelőssége a többiek felé - maximum a saját, kis hatással bíró reputcióját veszítheti el, míg egy CA simán kikerülhet a megbízhatónak tekintett körből, ami gyakorlatilag a "rolló le" a számukra.

Aha és ha egy CA-t épp azért hoznak létre ideiglenesen, hogy bogus certeket commitoljon be, annak kurwa nagy veszteség lesz, ha "rolló le" (sic!). És ez még a kisebbik baj, de a lebukás után mégis mennyi idő után lesz leeresztve az a bizonyos roló? Majd' egy év, mint a múltkor? (Pl. a WoSign 2016 augusztusában bukott le, de ténylegesen teljes blokkolásra csak közel egy év után került.) Mennyi kárt tudnak ezek még addig okozni?

De amúgy is: honnan tudod ránézésre, hogy egy CA az megbízható-e, vagy - ronda "szakszóval" - rogue? Pontosan ezért létezik a Certificate Patrol is, mert annyira kurwára megbízható egy rendszer ez, meg mert ennyire bevált a tévedhetetlen (nem) és azonnal reagáló (nem) Certificate Transparency szisztéma is. Ezt is linkeltem már, de ezt sem kommentáltad. Olyan szelektíven reagálsz, hogy hihetetlen.

Az megvan, hogy a google is megszívta a fake certekkel? Erről mi a véleményed? És arról, hogy mostanra már annyian mutattak rá, hogy az egész rendszer gyenge pontjai a CA-k, hogy a google-nek is lépnie kellett, hogy megszabaduljon a third-party CA-któl? Az megvan, hogy van, hogy driverek kúrnak fel a gépedre olyan cert-et, amit nem kértél és amiben nem bízol meg? Szívta már meg a fake cert-es faszt a mikiszoft is.

Na, most aztán kaptál egy valag linket, ahol certhamisítás történt, de kereshetsz még többet is, mert tele a padlás - meg a net - ilyen sztorikkal és nálam okosabb szakemberek ezrei elemezgetik és fejtegetik, hogy miért katasztrófa ez a cert rendszer úgy ahogy van. Korábban is adtam linket, nem egyet, de leszartad, te ragaszkodsz hozzá, hogy én találjak fogást egy jól használt/konfigurált láncon. Én? Hát értek én az ilyesmihez? Majd talál fogást az, aki tudja, hogy kell, légy egészen nyugodt.

Már egymilliószor meg lett válaszolva: bullcrap. Publikus read-only infókat hiába hallgatnak le MITM-en keresztül, a rekláminjektálást meg baszhatják, ha JS tiltva, sütik tiltva, képek tiltva, redirect tiltva, reklámszerverek tiltva, stb. Ennek csak ott van értelme, ahol valami érzékeny adat közlekedik.

Azokat meg előbb utóbb akkor is megtörik, ha https is van, mert minden szarra rákattintanak. Nem MITM-en keresztül tolják illegálisan a reklámot elsősorban az egységsugarúak arcába, hanem a mindenféle SAM-eken keresztül, amiket ők maguk tesznek fel, miközben minden szart feltesznek. Halottnak a csók nekik a https.

Nem lehallgatni, hanem meghamisítani.
Például van egy jogszabályokat megjelenítő oldal. Teljesen publikus információkat osztasz meg, mondhatod rá, hogy le van szarva a HTTPS, nem érdekes. Viszont így bárki MITM módon beékelődhet a fogyasztó elé, és olyan tartalmat szolgáltathat neki a jogszabályok szövegében, ami nincs ott. Akár reklámot is. Akár malware-t is injektálhat. Sőt, akár fals jogszabályszöveget is, ami félrevezetheti az embert.
És ez igaz egy olyan, nagyon gyakran látogatott oldallal is, mint az elvira. Mivel HTTPS-en nem érhető el, bárki proxyzhatja feléd úgy, hogy közben olyan tartalmat ágyaz az oldalba, amit te valójában nem akartál.
A TLS ezt a problémát megelőzi.

Csak épp MITM-re marginális esély van, helyileg jelenlévő SAM-re meg meglehetősen magas.
A reklámot és a malware-t egyébként ki lehet szűrni a megfelelő védelmi mechanizmusokkal, fentebb már kitrágyaltuk. A fals jogszabályszöveget ugyan nem, na de azt meg megnézem. Ez annyira specifikus, hogy csillagászatian kicsi rá az esély.
Egyébként ezeket a problémákat már az SSL is "megelőzte" (SSL sérülékenységek ebben az esetben nem játszanak: az esetleges feltörés ideje a sokszorosa az információ elavulási idejének); a latest TLS kötelezővé tétele a régebbi, már nem fejlesztett böngészőknek a netről való végleges letiltását szolgálja, nem a szaros MITM támadások kivédését. (Már csak azért is, mert legjobb tudomásom szerint a korábbi TLS-ekben nem fogtak még semmilyen sérülékenységet.)

Az, hogy korábban volt egy hiba nem ok azt feltételezni, hogy a mostani megoldás is hibás. A cert-ben meg azért kell megbízni, mert jelenleg nincs jobb megoldás és jelenleg nincs rá bizonyíték, hogy sérült volna a cert transparency (a self-signed szinte a titkosítás mentes kapcsolattal ér fel, szóval az semmiképpen nem alternatíva)

> Az, hogy korábban volt egy hiba nem ok azt feltételezni, hogy a mostani megoldás is hibás.

Ok azt feltételezni, hogy lehet hibás. Egyébként a szóban forgó hibát nem javították, mert nem is lehet, mert ez nem bug volt, hanem maga az a cipher sérülékeny. A "megoldás" az lenne, hogy más chiphert használunk a TLS-hez, de ennek ellenére az RC4 még rengeteg helyen használatban van. Főleg a WiFi-capable routerek érintettek. Tehát sokszoros erőforrásért letitkosítottuk a stream-et, de legalább ugyanúgy lehet injektálni. (Max. megnehezítik a támadó dolgát.)

> A cert-ben meg azért kell megbízni, mert jelenleg nincs jobb megoldás és jelenleg nincs rá bizonyíték, hogy sérült volna a cert transparency

"Kell?" Nem, nem kell. Onnantól, hogy valamit el kell hinni, mert valaki azt mondta, onnantól az nem műszaki megközelítés, hanem vallásos. Nincs jobb megoldás? Ez egyáltalán nem megoldás, ez önámítás. (Egyébként egyet fentebb te is említettél: Tor.) Bizonyíték? Arra talán van, hogy nem sérült? A lehetőség is elég: biztonságról beszélünk. Ennyi erővel semmilyen óvintézkedésre, vagy elővigyázatosságra nincsen szükség, mert esetleg nincs bizonyíték arra, hogy kell. Ha random emberekről feltételezzük (joggal), hogy MITM-mel próbálkoznak, akkor más random emberekről miért feltételezzük, hogy őket nem lehet megvenni, vagy megfenyegetni, megzsarolni, egyszóval bármilyen módon kompromittálni? (Vagy a rendszereiket, a frameworkjüket?) Mert azt mondták és punktum. Bizonyíték erre sincs, de azért higgyük el. Ennyi erővel azt is el lehet hinni, hogy tényleg át akarják utalni Nigéria készpénzállományát.

> Onnantól, hogy valamit el kell hinni, mert valaki azt mondta, onnantól az nem műszaki megközelítés, hanem vallásos.

Amennyiben van némi kriptográfiai tudásod, akkor tudnod kell, hogy egyik titkosítás sem nyújt 100%-os biztonságot, csak olyat, ami a tudomásunk szerint a mai technológia használatával, emberi léptékű idő felhasználásával megfelelően alacsony eséllyel kompromittálható.

> Egyébként egyet fentebb te is említettél: Tor.

A Tor/onion is csak azért működik, mert nincsenek domain nevek. DNS esetén már ismét ugyanazok a bizalmi kérdések vetődnének fel, mint a self-signed cert esetében: miért bízzak a válaszban?

> más random emberekről miért feltételezzük, hogy őket nem lehet megvenni, vagy megfenyegetni, megzsarolni, egyszóval bármilyen módon kompromittálni?

Erre nyújt megoldást a cert transparency: egy nyilvános, write-only adatbázis, amiben szerepel az összes kiadott certificate. Így a root certek korrupciója azonnal kiderül. (A CT bevezetése óta tudtommal nem volt ilyen eset)

> Amennyiben van némi kriptográfiai tudásod, akkor tudnod kell, hogy egyik titkosítás sem nyújt 100%-os biztonságot, csak olyat, ami a tudomásunk szerint a mai technológia használatával, emberi léptékű idő felhasználásával megfelelően alacsony eséllyel kompromittálható.

És az RC4 pont ilyen, amit az avulási idő előtt tudnak törni.

> A Tor/onion is csak azért működik, mert nincsenek domain nevek. DNS esetén már ismét ugyanazok a bizalmi kérdések vetődnének fel, mint a self-signed cert esetében: miért bízzak a válaszban?

Ebben igazad van. De ez nem érv a https mellett.

> Erre nyújt megoldást a cert transparency: egy nyilvános, write-only adatbázis, amiben szerepel az összes kiadott certificate. Így a root certek korrupciója azonnal kiderül. (A CT bevezetése óta tudtommal nem volt ilyen eset)

Nem, nem derül ki azonnal: a kiderülés a monitorozókon múlik: ha egy CA beküld egy fos certet a logba, amit a monitoros nem szúr ki, akkor cumi van. A CT nem garancia semmire; fentebb belinkeltem egy cikket, azt elolvastad? Mert válaszolni nem válaszoltál rá.

Én nem azt mondtam, hogy ne legyen https. Azt mondtam, hogy csak az érzékeny adatoknál van értelme bekapcsolni. Hogy mi az érzékeny adat? Na, ez pedig a júzerre van bízva. Ezért mondtam, hogy legyen opcionális. Ha neked érzékeny adat, hogy lekéred a menetrendet (lehet, hogy igazad van), akkor bekapcsolod. De ne legyen kötelező, főleg ne ezzel a megbízhatatlan cert rendszerrel.

"Hogy sokkal több erőforrást zabáljon fel feleslegesen" - szerinted mennyivel eszik több erőforrást (tényszerűen CPU-t,mert más nem kell neki pluszban) egy korszerű CPU-n adott oldal https-en, mint http-n? És egy korszerű cpu-val szerelt gép gyors diszkről olvasva/oda írva mekkroa sávszélességet tud szerinted kitömni titkosított adatfolyammal? Másképp fogalmazva ha van egy gigabites uplinked, akkor azt hány CPU-mag felhasználásával tudod 100%-ban kitömni ssl/tls titkosított adatfolyammal?

A kérdés jogos, úgyhogy kimértem:

root@Csabi:~# time for i in {0..999}; do wget "http://oscomp.hu/?games/all/p/0/c/0/s//sh/-/" -O - 2>/dev/null 1>/dev/null; done

real    2m1,440s
user    0m7,364s
sys     0m8,080s
root@Csabi:~# time for i in {0..999}; do wget --no-check-certificate "https://oscomp.hu/?games/all/p/0/c/0/s//sh/-/" -O - 2>/dev/null 1>/dev/null; done

real    2m38,135s
user    0m28,920s
sys     0m10,456s

Időben kb. 1/3-addal tartott több ideig az 1000 lekérés https-en, mint http-n. Ez azért nem elhanyagolható különbség.

Ami pedig a load-ot illeti, menetközben fotóztam a taskkezelőt:
http://oscomp.hu/depot/wget_http_oscomp.hu_load.png
http://oscomp.hu/depot/wget_https_oscomp.hu_load.png

Ami a lényeg, az a legalsó sorban a harmadik mérő, ami az elmúlt 1 perc összesített átlag CPU loadját mutatja (lebegőpontosan). 9% vs. 45%, azaz a https 5x annyi CPU időt eszik. Az azért már meglehetősen kardinális különbség. A CPU-m 8 magos FX-8350@4.0GHz, ami ugyan nem egy latest darab, de nem is özönvíz előtti. (Mondjuk úgy: tegnapi.) Nem hinném, hogy egy Ryzen sokkal kisebb ollót produkálna, de ami viszont sokkal fontosabb: a különféle low-consumption ARM CPU-k, amik a smart-device-okban és az SBC-kben vannak, azok még ennél is rosszabb eredményt hoznának, márpedig ugye főleg a mobileszközöknél érdekes az MITM elleni védelemnek kikiáltott https. De ha egy non-security jellegű gyakorlati érvet is akarsz, hogy miért is rossz ez: ez a sokszoros CPU igénybevétel drasztikusan csökkentheti az okostelefonok és tabletek akkumulátoridejét a böngészés alatt.

Ami pedig a "kitömést" illeti: irtózatosan rossz megközelítés, hogy ha van még erőforrás, akkor nem baj, ha felzabálja valami. Az erőforrás azért van, hogy legyen, ha kell, nem azért, hogy mindenképpen felzabáltassuk, akkor is, ha indokolatlan.

SSL handshake draga. Ezzel foleg ping timedotat demostraltad az oldalhoz (SSL handsake dragabb localhoston is).
Egy browser vagy valamivel komolyabb alkalmazas nem fog 1000 uj kapcsoloatot nyitni,
hanem hasznal ~5 allandot -t parhuzamosan, vagy HTTP/2 ..

aes-256-cbc (1 core -on)
laptop: 125MB/sec (-evp 949MB/sec)
desktop: 302MB/sec (-evp 1157MB/sec)
https://calomel.org/aesni_ssl_performance.html

En sem vagyok nagy rajongoja a felesleges titkositasnak,
de legalbb jo szamokat mutass.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

És a handshake ideje az nem ér, vagy mi? A browser csak egy domain felé nem nyitogat újat (bár ez sem igaz, pl. multi-threaded download, etc.), de mi van, ha össze-vissza mászkálsz a neten? Az bizony domainenkénti handshake-et jelent.
Arról nem is beszélve, hogy az 5x-ös CPU idő az nem a handshake miatt volt, csak azt szépen ignoráltad.

Szóval jó számok voltak ezek.

wget https -el nekem is balyom van.
kb 2 szer lassabb mint a curl.

Legutobb cert lookup korul volt nemi gebasz.

A curl idejebol is legalabb 5ms az ssl-el kapcsolatos fileok benyalazasa,
ami-t egy futo alkalmazasnak nem feltetlen kell megismetelnie.

Az 'ab' nevu tool, a valosaghoz kozelebbi dolgokat mutat '-k' -val.

szerk:
1k url '-k' -val, kb. 1 sec -el tobb CPU time.
Valami rosz szervert talaltam, ugyhogy 4 - 4 minute real time volt

user 0m0.050s
user 0m1.308s

$ ab -k -n 1000 <URL>

Mondhatod hogy ~25 szor tobb CPU ido, de a valos ido majdnem ugyan az.

Es 1000 url nel, nem +21 sec elegetes van , hanem csak +1 sec.

Sok/ keves/ maradhat, mindenki dontse el maganak.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> wget https -el nekem is balyom van.
> kb 2 szer lassabb mint a curl.

> Legutobb cert lookup korul volt nemi gebasz.

> A curl idejebol is legalabb 5ms az ssl-el kapcsolatos fileok benyalazasa,
> ami-t egy futo alkalmazasnak nem feltetlen kell megismetelnie.

Milyen "kapcsolatos fájlok"? A certek? És? Az akkor nem számít? Ezt már kérdeztem az előbb is, csak nem válaszoltál. Full időt nézünk, nem veszegetünk ki önkényesen a https mért idejéből.

> Az 'ab' nevu tool, a valosaghoz kozelebbi dolgokat mutat '-k' -val.

> szerk:
> 1k url '-k' -val, kb. 1 sec -el tobb CPU time.
> Valami rosz szervert talaltam, ugyhogy 4 - 4 minute real time volt

> user 0m0.050s
> user 0m1.308s

> $ ab -k -n 1000 <URL>

> Mondhatod hogy ~25 szor tobb CPU ido, de a valos ido majdnem ugyan az.

> Es 1000 url nel, nem +21 sec elegetes van , hanem csak +1 sec.

Ember, erre is válaszoltam, hogy keepalive egy domain felé mehet, de az emberek szoktak úgy mindenfele mászkálni a neten. Az jó sok domain. Erre sem válaszoltál.
Ami meg az időt illeti, a különbségek lekérésenként összeadódnak. És ez vonatkozik a terhelésre is.

H awget-tel méred, akkor sz@r, igen, köszönjükemese - kérnénk seleniumos böngészős tesztet, mert az jóval közelebb van a valós helyzethez.

Apropo, ha már titkosítás erőforrásigénye nagy... Ugye nem használsz ssh-t sem? Mert az is igencsak sok cpu-t meg tud zabálni - pl. rsync ssh-n keresztül egy cpu-magot felzabált, miközben a dróton csak csordogáltak az adatok...

A másik meg az, hogy a tls okozta plusz idő messze eltörpül a teljes (kattint - megjelenik az oldal) időhöz képest.

Mert a júzerek Seleniumot használnak, ugye? Köszönjük Emese. A 

wget

egy populáris letöltőeszköz, én meg real-life tesztet csináltam. Ha nem tetszik, akkor lehet ellenmérést csinálni valami másik letöltővel, vagy bugrókával, vagy amivel akarsz, de olyannal, amit a jónép használ és úgy ahogy használja. Laborkörülmények között, direkt a feladatra kihegyezett teszteszközökkel lefaragni a különbségeket elviselhető szintre, az minden csak nem értékelhető teszt.

Ha nem muszáj, mert biztonságos a hálózat, akkor nem. Egy korábbi topicban ezt ki is veséztük.

Nem az időn volt elsősorban a hangsúly, hanem a terhelésen.

A wget egy parancssoros eszköz, ami marginális a hasnzálatban a böngészős forgalomhoz képest.

"Laborkörülmények között, direkt a feladatra kihegyezett teszteszközökkel lefaragni a különbségeket elviselhető szintre, az minden csak nem értékelhető teszt" - mint ahogy az sem, hogy fogsz egy elhanyagolható mértékben hasnzált eszközt, és azt is olyan módon, hogy minél távolabb legyen a döntően használt eszközök működésétől, nos az is minden, csak nem reprezentatív és értékelhető teszt.
Tudok olyan tesztet mutatni, ahol a trabank 601s sz@rrá veri a felspécézett ültetett bömöst, de attól még a Trabi nem lesz jobb, mint a bömös.
A terhelésen volt a hangsúly, valóban, de megkérdezem: az a +x% user idő a CPU-nál az minek a terhére jelent meg? Mert ha az idle csökkent, akkor irreleváns a cpu-terhelése szempontjából.

Tagadhatatlan tény, de még mindig ezerszer több 

wget

-es letöltögetés van, mint Seleniumos benchmark. A lehetőség adott: válassz böngészőt és mérd ki, hogy 1000 random URL esetén mi lesz az eredmény http és https használata mellett. Azt mondjuk nem tudom, hogy honnan fogsz összelapátolni 1000 olyan szervert, ami mind a kettőt támogatja. Mondjuk simán megoldható lenne, hogy ugyanazt az URL-t bombázzuk meg 1000-1000 lekéréssel, de nem bírtok elszakadni a keepalive-tól, ami itt irreleváns...

Hát az 1000 fel-lekapcsolódásnak több köze van a valósághoz, mint a Seleniumos benchmarknak. Az lehet, hogy a 

wget

nem a jó eszköz a demonstrációra, de tessék, akkor csinálj ellenmérést másik tool-lal. Azt el tudom fogadni, hogy esetleg sikerült rossz eszközt választani, de a metodikában nem volt hiba: az nem valós, hogy szándékosan ugyanarra a domainre kapcsolódok fel keepalive-val, hogy addig mérjek, amíg minimálisra redukálódik a https time-overheadje. A random URL-ekre való felkapcsolódások alkalmával a handshake ugyanúgy beletartozik a protokollba; azt arbitrálisan kivenni a mérésből iszonyatos torzítás.
Nem értek egyet azzal sem, hogy irreleváns lenne a CPU terhelése, ha az idle csökkent és azt már le is írtam, hogy miért: az, hogy van még rendelkezésre álló erőforrás, az nem jelenti azt, hogy akkor azt azonnali hatállyal fel is kell zabáltatni; főleg a mobileszközökön számít ez: pusztul az akkuidő. Hiába nem érzékelsz belassulást, a sebesség nem minden.

https://www.keycdn.com/blog/https-performance-overhead

Itt +%2 CPU a legnagyobb pillanatnyi elteres, (nem atlagos, hanem peak.)

Ha lattal mar browser-t CPU-t enni, nem csodalkozol.

Unalmas random 1000 URL-eket talalni,
localhost-ton siman lehet 1000 ip-n 1000 hostod, es nem varsz az internyetre.
CPU egetes-t ugyan anyit fog mutatni, csak gyorsabb.

De ha jol mersz, eleg egy progi 1-2 ssl handshakkel, ugyan ahhoz az oldolhoz.
Csak akkor kezd el merni a handshake arat miutan:
- ssl config/ elfogadott certek be lettek olvasva (magas szintu libek eseten az elso kapcsolat)
- TCP kapcsolat letrejott

Mutatam neked valamit ahol 25* dragabb volt az SSL,
mit hamisitsak neked meg ? ;-)

szerk:
Van egy gepen dualport QDR kartyval, 4 core (Q9300) cpu-val.
~150MB/sec/core AES teljesitmeny.
SSL -eselytelen a dolog hasznalata...
(~ 10 eves gep ..)

Van itt egy DC:
https://www.arubacloud.com/infrastructures/czech-republic-dc-cz1.aspx

30 Gbit/sec internet eleressel,
5000 szerver fer be.

Mennyi az egy szerverre atlagosan juto SSL ovehead in CPU percentage?
(tippeld a hianyzo adatokat..)

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Off: Biztos velem van a baj, de néha alig bírom dekódolni amiket írsz.

> Itt +%2 CPU a legnagyobb pillanatnyi elteres, (nem atlagos, hanem peak.)

> Ha lattal mar browser-t CPU-t enni, nem csodalkozol.

Persze, mert a browserek szarul vannak megírva és annyit zabálnak, hogy az SSL/TLS már eltörpül mellette. Ilyenkor a százalékolás nagyon csalóka. Tegnap elittunk százmillió Forintot. Ma százegyet. Nincs jelentős növekedés, egy százalékkal ittunk többet. Hogy közben az egy egymilliós összeget takar, az nem fontos.
Kevésbé éhes browserben (pl. classic Opera), jobban kijön a különbség.

> De ha jol mersz, eleg egy progi 1-2 ssl handshakkel, ugyan ahhoz az oldolhoz.
> Csak akkor kezd el merni a handshake arat miutan:
> - ssl config/ elfogadott certek be lettek olvasva (magas szintu libek eseten az elso kapcsolat)
> - TCP kapcsolat letrejott

Miért, ezek talán nem tartoznak bele a felkapcsolódásba?

> Mutatam neked valamit ahol 25* dragabb volt az SSL,
> mit hamisitsak neked meg ? ;-)

Egy kis pénzt ha tudnál nekem hamisítani, azért hálás lennék, mert az mindig jól jön. (Esküszöm képtelen voltam dekódolni, hogy mit szeretnél. Mit hamisítsál meg, vagy mit hamisítsál még?)

> Mennyi az egy szerverre atlagosan juto SSL ovehead in CPU percentage?

Gondolom nem annyi, hogy hanyattvágjuk magunkat tőle, de ettől még ami felesleges pazarlás, az felesleges. Még egyszer, nem http-only, hanem opcionális https, amit szeretnék. Akkora baj?

"Miért, ezek talán nem tartoznak bele a felkapcsolódásba?"

Ha az a kerdes mennyivel dragabb a masodik(nth) ssl kapcsolat, mint egy egy masodik nem ssl.
Akkor nem.

"(Esküszöm képtelen voltam dekódolni, hogy mit szeretnél. Mit hamisítsál meg, vagy mit hamisítsál még?)"

Hanyas szorozot szeretnel latni SSL cpu zabalasra, ha 25 nem volt eleg ?

"Még egyszer, nem http-only, hanem opcionális https, amit szeretnék. Akkora baj?"

Mar miert volna baj ?
Ahogy itt https://hup.hu/node/165558#comment-2381972 is irtak, egy dolog megtoresenel szamit
a befektett energia es nyerseg.

Szerintem sok olyan dolog van, amibe nem akkar senki energiat olni, meg ha egy 's' -el konyebb is
a protocol.

Ill. gep-gep kozvetlen kabel kapcsolat-nal sem szeretem az SSL-t. Akramilyen security expert mondja,
hogy hiaba vagyok a 3-meter kabel melett egy AK-47 -essel egy learnyekol szobaban,
oda titkositas kell, akkor elmehet a ..

Manapsag eleg sok dolog elszaladt a loval es `kenyszeriti` a HTTPS hasznalatat.
Ami nem teszi kenyelmessebbe a debuggolast, nagyon nem szeretem dev envben..

Amit meg jobban utalok, folosleges HTTPS -tol, a rosz certes HTTPS -et.
Ha en https -et javaslok vagy csinalok, az https -lesz, nem felig megicsinalt szar,
mert attol mar http is jobb .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Ha az a kerdes mennyivel dragabb a masodik(nth) ssl kapcsolat, mint egy egy masodik nem ssl.
> Akkor nem.

De ez csak azonos domain-re való többszöri felcsatlakozáskor van így; ezt magyarázom, ha össze vissza mászkálsz, az annyi handshake.

> Hanyas szorozot szeretnel latni SSL cpu zabalasra, ha 25 nem volt eleg ?

Nekem? Nekem még sok is volt. Elvesztettem a fonalat, mit szerettél volna kihozni?

> Szerintem sok olyan dolog van, amibe nem akkar senki energiat olni, meg ha egy 's' -el konyebb is
> a protocol.

Ez nem érv a https mellett, csak rávilágít az emberi lustaságra.

A többiben egyetértünk.

"Ezerszer több wget mint seleniumos benchmark..." - erre azért ne vegyél mérget... Idéznék a seleniumhq oldalról, mert szerintem nem igazán tudod, miről is van szó: "What is Selenium? Selenium automates browsers." - bizony ám, webes alklamazások tesztelésére, úgy funkcionális- mint terheléses tesztre szokás használni - és használják is szerte a világban a webes fejlesztéseknél. És nem egyszer-kétszer, hanem a felület "stabil" állapota után kvázi folyamatosan, a dev környezteben minden buildre.
Szóval de, a wget-tel felcuppanni n-szer valahova az pont, hogy messze van a valós használati mintázattól.

"hogy van még rendelkezésre álló erőforrás, az nem jelenti azt, hogy akkor azt azonnali hatállyal fel is kell zabáltatni" - na akkro mi a pékpöcsre való az erőforrás, ha nem arra, hogy ha kell, használjuk?! Az akkuidőre a CPU fogyasztásánál jóval nagyobb hatása van a kijelző, illetve a rádiós modulok (wifi, lte, bt) aktivitásának.

- En zokom veszem, ha bekesen rebuildem a vilagot es kozben a bengeszo tobbet eszik, mint kene a feldata elvegzesere.
- Zokon veszem, ha valami felesleges dolog miatt az informacio akkar 0.1 ns -el lassabban jut el hozem, vagy tolem.

Nincs legkondim es az aram sem lesz olcsobb.
Par fokkal most is melegebb van szobamba, mint a tobbibe ;-) Nem az SSL az oka. Legalabbis nincs a toppon.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> Idéznék a seleniumhq oldalról, mert szerintem nem igazán tudod, miről is van szó: "What is Selenium? Selenium automates browsers." - bizony ám, webes alklamazások tesztelésére, úgy funkcionális- mint terheléses tesztre szokás használni - és használják is szerte a világban a webes fejlesztéseknél. És nem egyszer-kétszer, hanem a felület "stabil" állapota után kvázi folyamatosan, a dev környezteben minden buildre.

Hát ez aztán pontosan úgy hangzik, mint amit a többmilliárd egységsugarú egyfolytában csinál. Ehhez képest még a 

wget

-es letöltés jobban hasonlít egy felkapcsolódásra, pláne mivel ahogy nézem ezeket a teszt-automatizálós izéket, nem sok közük van a valósághoz, csak félrevezetik a tesztelőt. (#1, #2, #3, #4)

De ha annyira érdekel, hogy a Selenium mit hozna ki egy ilyen tesztben, hajrá. Csinálj ellenmérést, csak oszd meg, hogy mit csináltál.

> na akkro mi a pékpöcsre való az erőforrás, ha nem arra, hogy ha kell, használjuk?! Az akkuidőre a CPU fogyasztásánál jóval nagyobb hatása van a kijelző, illetve a rádiós modulok (wifi, lte, bt) aktivitásának.

Elolvasnád végre, amit írok? Ha kell, akkor használjuk, de ha nem kell, akkor ne pocsékoljuk feleslegesen.

E3-1231 v3, ~3000 conn, mp4 static fajlok, ssdrol. ssl 13Gbit, nossl >20Gbit.

komoly penzekbe kerul ez a mindentitkositas, de csak azert nehogy megtudja a telekom, hogy micike megnezte a legujabb macskas videot :(

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Tehát az általánosan használt csigabitet több, mint egytucatszor ki lehet tömni ssl-lel. És nem _csak_ azért, hoyg a szolgáltató ne lássa, mit néz Micike, hanem azért is, hogy a szolgáltató vagy más harmadik fél ne tudjon belepiszkálni abba,ami a szerverről elindult Micike felé.

A saját motyóm next-next-finish hoz a Qualys teszten A+ minősítést, amivel minden érdemi részesedéssel bírő kliens szót tud érteni. Az, hogy valaki derékig érő léckerítést csinál (ami tényleg csak jelzésértékű), még a kerítés maga hasznos eszköz a terület illetéktelenekkel szembeni védelmére - ha jól van a kerítés megcsinálva. Persze ha a léckerítés mögött nincs más, mint ugyanolyan "természetes gyep", mint kívül, akkor nem fogja megérni átlépni rajta - és a gyoda-val megerősített, sok méter magas kerítésen is át fognak mászni, ha a ráfordítás arányos a kerítésen történő átjutással elérhető haszonnal.
jelenleg még az a helyzet, hogy egy jól konfigurált https-es kiszolgálónál az tls-adatfolyam kibontása/megpiszkálása jóval nagyobb ráfordítást igényel, mint amekkora haszonnal kecsegtet az adatfolyam módosítása vagy épp lehallgatása.

A cert rendszer bizalmi alapon működik, úgy, mint a való életben a közjegyzők - nem tudom, hogy a kommunikáló felek közötti bizalom kialakítására a bizalmi alapon kívül van-e más mód? Ha van, akkor hajrá, állj elő vele. Nem, a pgp/gpg hálós modellje, az X509 "fa" struktúrájához képest ilyen téren semmivel sem különb: bizalomra épül. Igen, tudom, a bizalmi hálóban azok, akikben megbízol közvetlen bizalmat jelentenek, egy CA-ban meg csak közvetetten tudsz megbízni - ahogy egy közjegyzőben is csak az alapján bízhatsz meg, hogy... Szóval mi alapján is? Közjegyzőnek adja ki magát, van megfelelő szárazbélyegzője, illetve egy közhiteles (mitől lesz közhiteles?) nyilvántartás is vantalán, amit megnézhetsz...
A bizalmi háló jó dolog, de bizonyos mérten felül már gyakorlatilag vadidegenekben kéne megbíznod ahhoz, hogy valaki ismeretlennek az identitását valósnak fogadd el.

Ebben sok igazság van, de ha a kerítésen túl nincs semmi, csak a gyep, meg egy olyan tábla, aminek a tartalma kívülről is látszik, akkor nincs értelme a kerítésre pazarolni a fát, csak azért, mert így valaki más odatehet a tábla elé egy másikat; majd odamegyek és kikerülöm a hamis táblát.

Pedig pont a PGP a jó megoldás és éppen a közvetlen bizalom miatt. Az SSL/TLS esetén abból indulunk ki, hogy minden egyes certet kibocsájtó entitás megbízható, ami egy rettenetesen naív feltételezés, meg abból, hogy a CT majd megoldja helyettünk az intézményesített szabályzásával; hát nem, ha a monitorosok nem szúrják ki a becommitolt bogus certet, akkor beszoptuk. És különben is, miféle titkosítási ökoszisztéma az, amit intézményesítetten szabályoznak? (És miért van az, hogy a PGP-t magát még nem törték meg soha?)

A pgp erre nem alkalmas - például egy ausztráliai webshop-ban mi alapján bíznál meg? Az ismerősöd-ismerősének az ismerőse ismer olyat, aki ismer valakit, aki ismerőse annak, aki már bízik olyanban, aki bizalmába fogadott három olyan embert, aki bízik a webshop-ban.
De erről érdemes ezt elolvasni: https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.h…
Tehát közvetlen bizalom nuku. A sokszorosan közvetett meg semmivel sem jobb, mintha n darab CA-ban bíznál meg. Apropo, ha valakivel f2f üzeletet kötsz, akkor előbb keresel közös ismerősöket, akik tanusítják neked, hogy az üzleti partnered az, akinek mondja magát? Mert ugye az okmányokat is központilag bocsátják ki, azaz az államigazgatás mindja meg valakiről, hogy ő kicsoda.
A pgp/gpg bizalmi hálójában egy dolog nincs: felelősség. felelősség abból a szempontból, hogy az "igen, megbízható/igen, ismerem/igen, megbízok benne" kijelentéshez nem kapcsolódik semmilyen olyan jellegű felelősség, mint ami az x509-es fában elvárt és létező dolog.

A PGP/GPG-t is lehet rosszul használni, és ha rosszul, vagy akár bárhogy(!) hasnzálják, lehet törni, illetve rengeteg információt kinyerni például a pgp/gpg levelezésből.

Meg egy másik olvasnivaló...: https://secushare.org/PGP

Miért, amúgy mi alapján bízol meg benne? Ennyi erővel a https sem alkalmas rá. https://www.kaspersky.com/blog/https-does-not-mean-safe/20725/ A linkelt levélre annyit tudok mondani, hogy kulcsot sokféleképpen lehet cserélni. Az amúgy megvan, hogy a felhozott példában a gyenge láncszem egy kompromittált https cert volt? És a fickó egyébként a levele végén mindjárt ajánl is pár megoldást a felhozott problémákra.
Nem tudom, hogy pontosan mi lenne az univerzális megoldás PGP-vel, az is lehet, hogy nincsen, de a PGP-ről nem is állítottak ilyet, míg a "túlparton" meg azt állítják, hogy a https mindenre megoldás, mindentől véd. A httpsnél el kell hinni, hogy a CA-kban és a certjeikben vakon meg lehet bízni. Ezt már eddig tízszer írtam le, hogy nem, mert hamis certet lehet produkálni, a CT-nél meg bullshit, hogy automatice kiszúrják, a monitorosokon múlik és azok is emberek. A PGP-nél meg nem kell elhinni semmit, jól kell csinálni. Ha nem tudod a kulcsot biztonságosan átvenni/átadni, akkor megszívtad, ez igaz. De akkor a https-nél is.

És igen, ha szarul csinálják, akkor az is törhető, de csak simán magát a PGP-t még nem bírták megtörni úgy, hogy nem felhasználói hiba, vagy szar implementáció, vagy egy megtört keyserver volt a gyenge láncszem.

A cikkre:

1. Ha zavarod a kommunikációt, akkor az minden protokollt szétbasz; ha átbillented azt a bizonyos bitet, akkor a https stream nem baszódik el talán? Egyébként a PGP az adatok integritásának ellenőrzésére is alkalmas, tehát egy mezei bithiba kiszúrható vele, hogy valami nem kóser.

2. Ha jól értem az interchange volt fos; bocs, ez megint nem a PGP hibája.

3. Itt is interchange probléma és a gyenge láncszem itt is a kamu TLS cert volt. Te elolvastad ezt a cikket, vagy csak belinkelted? Ebből még jobban kiviláglik, hogy mennyire sok baj van ezekkel a certekkel. Különben nem is létezne pl. a cikkben belinkelt Certificate Patrol. (Your web browser trusts a lot of certification authorities and chained sub-authorities, and it does so blindly.) Mégsem elég a CT? Egyébként a cikk egyik mellékszála végig az, hogy mekkora kamu a cert-ökoszisztéma.

4. Az megint nem a PGP hibája, hogy az emberek szarnak frissíteni a subkey-eket. A PGP nem akarja helyetted megoldani a gondolkodást, mint teszi azt az SSL/TLS.

5. Majd visszatérünk rá, ha tényleg sikerült. Addig FUD.

6. Ez megint az interchange kritikája: a PGP-nél nincs kitalálva, hogy cserélsz kulcsot. (Egyébként ad is pár tippet a fickó.)

7. Ki mondta, hogy kötelező keyservert használni?

8. Nem is volt cél bármit bizonyítani, kettejük közötti üzenetváltásról volt szó.

9. Ez most komoly? Statisztikai analízist bármire rá lehet húzni...

10. És?

11. User error. Még azt is leírja, hogy mit kéne csinálni.

12. Itt is a https certekkel van igazából baj.

13. Interchange, user error, keyserver és megint a TLS certen bukott el a dolog. (the TLS and HTTPS certification standard that makes us need certificates, signed by an authority, and then can be fooled and broken anyway)

14. Ebben igaza van...de mi köze ennek ahhoz, hogy miért ne használjon valaki PGP-t?

15. Tehát summa-summárum, azért ne, mert úgysem tudják használni? Ez nem érv.

Szóval nekem úgy tűnik, hogy itt gizike-gőzeke: a PGP-nél rajtad áll, hogy kezeled a kulcsaidat, nem próbálja meg helyetted megoldani a rendszer. A TLS/SSL megpróbálta. Eredményét láthatjuk.

kliens oldalrol nezve igen, eleg nehez kitomni 1G-t, mondjuk egy mondjuk egy multi tuzfal proxyja mar megizzad. es szolgaltato oldalrol nezve meg van egy >30%-os teljesitmeny eses.

igazabol azt nem ertem hogy ha a fooldal https-en terjed, akkor abban miert nem lehet megadni hogy "X, Y, es Z fajlok kodolatlanul jonnek, ne vedd mixed kontentnek lecci".

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( trey | 2019. 08. 27., k – 18:03 )

Elvira-val egyszer kerültem kapcsolatba, amikor egy szerverteremben dolgoztam és egy romhalmazra rá volt írva "elvira" vagy ilyesmi. Kérdeztem, "ez lenne az az Elvira"? A szerveren döglött diszk LED világított. Az ipse, aki ott volt, elkezdett magyarázkodni, hogy "ez, ez", de hogy a múltkori több napos kieséshez semmi köze, azt más baszta el, más hibájából volt.

Akkor egy kicsit csalódtam, mert kívülről valami komolyabb holmit vártam volna.

--
trey @ gépház

( uid_4263 v | 2019. 08. 28., sze – 10:30 )

Szerintem szarul zárted le a kódot, alattad minden szarul néz ki a blogszekcióban

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

( NewC | 2019. 08. 28., sze – 16:13 )

Ez a kemény, nem a Tarzan sarka...
--
"Csak webfejlesztést ne..." -ismeretlen eredetű szállóige-

( tibyke | 2019. 08. 30., p – 11:12 )

update:

Az ELVIRA szolgáltatásunk egy kifutó rendszer, fejlesztéseket nem tervezünk már. A szolgáltatás HTTP protokollon működik továbbra is. A banki fizetést és felhasználóink nyilvántartását végző modulok https protokollt használnak.

Hat itt rontotad el, https -el gepelted be ;-)

Nezem az elvirt, de nem latom mi valtotta le.
https://www.mavcsoport.hu/ (elvirara megy at, a bongeszo sirt hogy a form nem secure).

https://menetrendek.hu/
szinten arra figyelmeztet a browser, hogy kepek nem HTTPS.

Akkor mit fejlesztenek ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

( ggtamas | 2019. 08. 30., p – 20:15 )

A fentebb már leírtakon kívül:

* hogy ne tudják, mikor és hova utazom
* hogy ne lehessen megváltoztatni a kliens által visszakapott tartalmat
  * például malware injektálásával

stb...