SMTP TLS nélkül

Forrás?

Kutatások a témában, majd egyszer megint megkeresem, ha épp ráérek, pár hónapja olvastam. Egyébként KEMTLS az egyik kulcsszó, érdekes téma, ajánlom olvasgatni.

Zseniális ötlet, csak mi akadályozza meg a mitm támadót, hogy az ebben a tag-ben utazó string-et kicserélje egy olyanra ami annak a tartalomnak a checksum-jával egyezik, amire hamisitotta az oldalt?

Ah, ezzel részben lehülyézted a W3C-t, másrészt meg az oldal, amin a checksum van, az lehet SSL/TLS mögött, mert valószínűleg nem egy egymilliárdszor letöltött publikus library/kép/CSS/whatever, ha igen, akkor meg már egy megbízható checksum hivatkozás tölti be. Tudod, ki van ez találva, csak kevesen használják, mert jönnek ezekkel a fasz kérdésekkel, mert nem értik az egészet. És ahelyett, hogy leülnének egy csendes sarokba és átolvasnák a témában a szakirodalmat, nekiállnak random faszságokat kérdezni, amit már mások is ezerszer megkérdeztek, mert ők se ültek le egy csendes sarokba átolvasni a szakirodalmat. Ami szakirodalom amúgy megválaszolja a random faszságokat, amit feltesztek kérdésként.

Azért, mert valamit 15-20 éve "így szoktunk", az nem jelenti azt, hogy fenntartható és skálázható dolog. Időnként érdemes a dobozon kívül gondolkodni.

Viszont ha maga a checksum nem TLS-en át jut el a klienshez, akkor nem véd az MITM ellen, tehát TLS kell. Esetenként checksum is.

Jelentősen kevesebb, mint a TLS/SSL.

ez nem igaz. TLS eseten altalaban AES-t hasznalnak amit a mai cpu-k de meg a jobb halokartyak is tudnak hardverbol szamolni/gyorsitani. ezzel szemben a checksum szamolashoz sha256 illene minimum, amire ez nem igaz. persze ha neked egy egy crc32 akkor nem szoltam...

És mivel meg hogyan kényszeríted ki, hogy a checksum-ot ellenőrizze a kliens? Hogyan küldöd el neki azt a "parancsot", hogy a checksum ellenőrzése szükséges?

Khm. Olvass. Khm. https://www.w3.org/TR/sri-2/

Ja, és a dinamikus tartalmakkal, a menet közben "streaming" jelleggel tolt adatokkal mi lesz? Vagy mindent "is" cache-be rak a webszerver, checksum-ot számol, majd utána küldi el a kliensnek? 

Idéznéd, hogy hol a lófaszban írtam olyat, hogy semmihez nem szabad SSL/TLS-t használni?

Segítek, innen indultunk: "Erre van a checksum ellenőrzés, az SSL egy erőforrásigényes dolog, égetjük a pénzt a semmiért, amikor egy csomó statikus és publikus dolgot SSL csatornán küldünk át."

Ti meg ahelyett, hogy ebben a kontextusban maradnátok vagyis "statikus és publikus", egész szalmabáb hadsereget építetek fel és már azon vered a nyálad, hogy dinamikus tartalmakkal mi van, és a többi.

Mivel az már így mixed-content lesz, ezért azt a böngészőnek blokkolnia KELL a szabvány szerint.

Az egész Subregsource integrity feltételezi, hogy HTTPS-t használsz amúgy, a bevezetőben le van írva, hogy a kapcsolat biztonságáért (tényleg azzal beszélsz, akivel akarsz) és a MitM támadások ellen véd a HTTPS, de kell még a tartalom biztonsága is. Azaz a SRI az a HTTPS mellett van, nem helyett, mivel más aspektusát biztostja a tartalomnak.

Ez bullshit.

De, meg tudod különböztetni, mert egy certben a DN mező az strukturált, nem csak egy szabad szöveges érték. Egy texasi meg egy Rhode Island-i cég számára már DN-re szól a certificate, akkor is, ha a cég neve tök ugyanaz a Fiszfasz Ltd.

Idézem magam, én annyit állítottam két tökéletesen külön szálban, hogy

a, az SSL adta biztonság jelentősen csökken azzal, hogy bárki kap SSL cert-et, ami szuperzöld az összes böngészőben,

b, a publikus és statikus tartalmak integritása védhető más módszerekkel is, mint hogy átküldjük SSL/TLS csatornán.

Ezt a kettőt nem kellene összemosni és ezekkel kellene vitázni, ha akartok. Annak sok értelme nincs, hogy szalmabábokat építetek fel és nem is szeretnék azokra reagálni.

Nem csökken. Ha a user hülye és rossz oldalra megy, akkor igy jár. 

De, ezért csökken, ez ellen védene az EV cert és amúgy az egész PKI erre van kitalálva alapvetően. Nem azért van, hogy titkosítva legyen a tartalom, hanem azért van, hogy tudjuk, az adott domain validálva van valami bürokrata pecsétje által, hogy a való világban is az, akinek mondja magát. Ezt a funkcionalitást elvesztettük azzal, amikor a Google elkezdte nyomni, hogy https kell mindenhova és az ingyen DV cert ugyanazt a böngészőbeli visszajelzést adta, mint az EV cert és bárki kap DV certet bármire, ingyen.

A nem pénzügyi dolgokat kezelő oldalaknak tökéletesen megfelel a DV.

Lófaszt, nehogy már. De már értem, hogy nálad hol megy félre az egész sztori.

Hogy a böngészők a lakat szinezését levették, az valóban hülyeség, de ennek semmi köze az TLS (amit századszorra nevezel tévesen SSL-nek, de ez a legkisebb szakmai tévképzeted a témában) biztonságához.

És szinte mindenhol azt írtam, hogy TLS/SSL, ahol ennek volt értelme. Amúgy BTW, a TLS1.0 az nagyrészt a SSLv3.1.

Senki nem vitatta, hogy lehetne. Hogy ennek bármi haszna lenne, na AZT nem sikerült még nyomokban sem bizonyitanod.

De, vitatva volt, most, hogy linkeltem is, hogy mi a lófaszról volt szó, most kicsit összement az arcod, de szerintem továbbra se olvastál semmit a KEMTLS-ről, mert akkor még mindig olvasnád és nem itt írogatnál faszságokat.

Akkor még mindig nem érted, hogy mit is bizonyit a "lakat". Nem csak annyit, hogy titkositott a forgalom, hanem azt is, hogy nincs beékelődve egy támadó közéd és a szerver közé és amit az oldalon látsz, az van azon a webszerveren aminek a cimét beirtad. Kurva nagy különbség.

Nem, ez pont nem tudod így ennyire biztosra, de ez leírtam már párszor, annyiban lehetsz biztos, hogy a másik oldalon van egy DV cert, ami az adott domain-hez van kötve. Pont. Az DV így, ebben a formában, kb. titkosításra jó, ha rosszarcú lenyúlja a DNS-t, akár csak a DV validálás idejére beékelődik a http forgalomban, simán csinál magának DV cert, tolja tovább az egészet, amit egy EV cert esetén nem tudna, te meg azt hiszed, hogy minden oké. Hogy tudod validálni, hogy máshoz került a domain egy támadás miatt? Ugyanaz a Let's Encrypt cert van rajta, szóval sehogy. Tele van a világ DV cert adta visszaélésekkel, csak most még rövidzárban van az agyad, én nem fogja át a tudatod, hogy mit is írok. 

Az megvan, ugye, hogy a DV cert validálása http-n történik? Egy utolsó molyfing ISP rosszarcú alkalmazottja képes web based DV certet csinálni azokról a domain-ekről, amelyek rajta mennek keresztül, ha akar. Te pedig ebből semmit nem veszel majd észre, szuperzöld minden. Technikai szinten minden fasza, csak épp átbasznak a támadók.

Mondjuk szerintem a "titkosítás" pont az jelenti, hogy "nincs beékelődve egy támadó közéd és a szerver közé"

Nálam az otpbank.hu-t cert kibocsátója az ESET.

Akkor mit is bizonyít? (tudom, ez rossz példa).

+1. Ráadásul leírtam, hogy az kaphat xyz domainre DV certet, aki tudja prezentálni http-n a megfelelő választ. Igen, ha ez egy rosszindulatú támadó, és sikerül folyamatosan magára irányítania a forgalmat(!), akkor működ_het_ a dolog a webszerveren elhelyezett "response fájl" alapján kibocsátott cert esetében. De ezt iot olvtárs nemigazánértette meg, hogy mit jelent... 

Nem tudom, hogy az EV cert esetében előírás/elvárás volt-e az ilyet igénylő entitás felé az, hogy a privát kulcsot hsm-ben tárolják, de szerintem nem. Onnantól kezdve meg egy megfelelő belső ember elég, hogy kipiszkálja a rendszerből a szükséges fájlt... Csak idő meg pénz kérdése. Ahogy a DV cert támadhatósága is.