Meglepődve olvasom itt a többedik fórumban, hogy melyik proxy hogyan tud https forgalmat kibontani.
A magam részéről még ott tartok, hogy a https-t azért hozták létre, és azért kényszerítik most már rá mindenkire, mert hogy mennyire nagyon biztonságos is, és senki nem juthat illetéktelenül a forgalmamhoz.
Akkor hogyan is van ez? Én jelenleg ezt csak úgy tudom elképzelni, hogy ha valaki kibont egy https forgalmat, akkor miután újra összecsomagolja, akkor nekem kliens oldalon látnom kell, hogy ez nem az eredetileg elküldött csomag. És persze visszafelé is.
Eddig számomra a zöld lakat azt mutatta, hogy a szerver és köztem a forgalom titkos. De ezek szerint mégsem.
Lehet, csak azért nem értem, mert még nem proxy-zták meg a https forgalmat, de nagyon megköszönném, ha valaki erről valami megnyugtatóbbat írna.
Hozzászólások
Welcome to the Security Theater!
Ebben a témában megnyugtatót csak az tud mondani, aki hazudik ;)
szerintem.
zrubi.hu
anno mikor ezzel foglalkoztam egy CA-t kellett hiteleskent elhitetni a bongeszovel hogy ez zold lakatoskent mukodjon
https://wiki.squid-cache.org/Features/SslBump
neked aztan fura humorod van...
A HTTPS alapvetően már mindenre is használt port és forgalmi típus már, a VPN-től a kártevők célba juttatására. Egy cég szempontjából jelenleg az egyik legnagyobb veszélyforrás a felhasználók után.
A fenti állapotban a proxy lesz az aki az SSL kapcsolatot bontja és nem a böngésző, ekkor végre lehet hajtani az ellenőrzést AV, sendbox, DLT stb, majd ez után egy adhoc generált key-el újratitkosítja aminek a kicsátója maga a proxy lesz. Ahhoz, hogy böngészőnek is tetsszen ez a CA-t amit a proxy használ minden böngészőbe, alkalmazásba és a rendszerbe fel kell venni mint trusted CA és kész.
Olyan alkalmazás ami megköveteli az SSL spinning-et, pl banki alkalmazások, ott ez nem fog működni így.
s/spinning/pinning/
Egyébként érdekes, nálunk a cégnél is bontják az SSL-t, próbáltam olyan site-ot, ahol volt ssl pinning beállítva (nem banki alkalmazás, többek közt a bank illetve merchant kategóriára nálunk nincs bontás), és nem szólt a böngésző.
Szintén láma, viszont ebben a doksiban szép rajzok vannak a témában:
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/
A téma megértéséhez szükség lesz erős TCP/IP alapismeretekre, különös tekintettel a NAT-olás, és TCP header-ek alapos ismeretére.
Ezek segítenek megérteni, hogy miért lehet könnyedén és "büntetlenül" (értsd: észrevétlenül) MITM jellegű támadásokat végrehajtani.
Könnyedén, ha te vagy a proxy/router/ISP.
Igen - többek között - ez ellen találták ki a TLS-t, amit a HTTPS protokol is használ.
De ennek gyakorlati kivitelezése sajnálatos módon több sebből vérzik - és most nem csak a heartbleed-re gondolok :D
Nagyon röviden és pongyolán - az érthetőség kedvéért:
A zöld lakat attól lesz, hogy a BÖNGÉSZŐD által végzett ellenőrzések alapján minden rendben van.
Tehát innentől a kérdés, hogy mi alapján lesz zöld az a lakat... De mivel ez sem egy rövid téma, íg maradjuk az SSL inspection releváns részeknél.
a böngésződ megbízik MINDEN aláíró tanúsítványban (CA) amit az operációs rendszer vagy maga a böngésző annak ítél.
Igen, sajnos neked mint user gyakorlatilag nincs beleszólásod ebbe.
Ha megnézed szép nagy a lista, és ezek a CA-k vagy profit orientált szervezetek, vagy politikai befolyás alatt álló "non-profit" intézmények, vagy épp a saját országod/céged által irányított szervezeti egységek. De vannak köztük éppen egymással háborúban álló entitások is...
A röviden összefoglalt végeredmény, hogy te azok MINDEGYIKÉBEN 101%-ig megbízol. Mert a Microsoft, a Google, a Mozilla, USA, vagy épp Kína, stb ezt "mondta".
a CA-k pedig egymástol függetlenül kiállíthatnak ugyan arra a URL-re szóló tanúsítványt :)
(Természetesen a CA-k "komoly" auditokon kell hogy átmenjenek, de a mai kapitalista világban a gyakorlatban csak pénz kell hozzá)
Innentől lehet máris érthető miért marad zöld a lakat akkor is, ha közben valaki - jogosan, vagy jogellenesen - azt feltörte, elemezte/módosította, majd újra csomagolva továbbította feléd...
(És persze vannak ezt a problémát kiszűrő "workaround" megoldások is, de egyik sem kötelező, és egyik sem elegendő önmagában)
zrubi.hu
Semmi köze a NAT-olásnak a témához.
Lecserélheted a certificate-et, ha a forgalom rajtad keresztül zajlik, de ettől még a felhasználó számitógépén is modosításokat kell végezned.
Tehát, önmagában az, hogy ISP vagy, még nem elégséges.
Ez abban az esetben igaz, ha nincs rendszergazdai jogosultságot az érintett eszközökön.
Maradjunk a gyakorlati részénél. Ha nyugodt szeretnék lenni, hogy a számomra fontos oldalakkal való forgalmamat nem olvassa senki, akkor már nem elég a zöld lakat, hanem:
1 - Egy biztonságos csatornán megnézem, ki hitelesítette az oldalt.
2 - Ezentúl minden kapcsolódáskor megnézem, hogy ki hitelesítette az oldalt, és ha nem ugyanaz, akkor aggódok? (Ha meg ugyanaz, akkor nyugodt maradok.)
Nincs erre valami tool, valami böngésző plugin, ami ezt helyettem elvégzi?
DNS CAA rekord (DNSSec-el ha rooting vissza is ellenőrzöd, tudod ellenőrizni).
HTTP Public Key Pinning, csak egy HTTP fejlécet kell hozzá küldeni, a böngésző tudja, mit csináljon vele, nem kell plugin. (cserébe kulcscsere nagyobb odafigyeléses)
Szerk.: egy fentebbi kommentre utánanéztem, nem, _már_ nem tudja egyik nagyobb böngésző sem, hogy mit kezdjen a HPKP-val, kivezették (Firefoxban még elvileg visszakapcsolható az about:configban) :(
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Alapvetően ez lenne a módszer, de
nagyjából már az 1. pontnál elbuksz, mert a legtöbb esetben ilyen csatorna és/vagy ez az információ nem egyértelmű és/vagy jelzés nélkül változik.
És az egyre rövidebb életűek a tanúsítványok ezt csak tovább nehezítik.
A gyakorlatban egy viszonylag jól működő 'teszt', ha több szesközről és/vagy több internet elérésről is megnézed ugyan azt az oldalt - illetve annak tanusitványát, és annak kibocsátóját. (pl céges laptop + céges net vs privát mobilnet - és ennek permutációi)
De ehhez elég elszántnak kell lenned, hogy ezt minden fontos oldallal megcsináld ;)
zrubi.hu
a NAT-nak ahhoz van köze, hogy miért triviális eg MITM támadás megvalósítása TCP szinten. - a legtöbben már ezt sem értik...
zrubi.hu
Én továbbra sem értem, mi a kapcsolat a NAT-al?
Hát az, hogy NAT nélkül nem lehetne észrevétlenül csak úgy beállni két fél TCP/IP kommunikációjába (transparent proxy)
https://en.wikipedia.org/wiki/Network_address_translation#/media/File:N…
Egy router ugye 'csak' lecseréli a kliens által küldött TCP csomag fejléceiben a valódi forráscímet a sajátjára, majd így küldi azt tovább a szerver felé... A szerver a válaszcsomagot erre a hamis IP címre küldi, majd a router a NAT táblából visszakeresi, hogy ezt kinek kell továbbítania, amikor ismét lecseréli, de most a DST IP-t, az eredeti kliensére.
Így sem a kliens, sem pedig a szerver nem tudja, hogy ez valójában megtörtént, mindenki örül :)
De itt kizárólag a router 'jóindulatán' múlik, hogy 'csak' a fejlécet cserélgeti (általában azért, mert a kliens IP-je nem route-olható az interneten) De valójában akár az adattartalmat is kicserélhetné, ha akarná. És technikailag ezt megteheti bármelyik router amelyik a kommunukációs útvonalon van a kliens és a szerver között, akkor is ha valójában rendes IP-je van mindkét félnek.
Ezek alapján pl IPv6 esetén elméletileg nincs is szükség NAT-ra, mert jut mindenkinek 'publikus IP'. - A gondolták ezt az internet újratervezői az IPv6 kitalálásakor....
Egy transzparens proxy pontosan ugyan ezt csinálja annak érdekében, hogy az adattartalmat ellenőrizhesse "menet közben". Az ellenőrzés akár arra is kiterjedhet, hogy változtat benne pl a vírusos file-okat nem engedi a klienshez, vagy az egész hozzáférést eleve megtagadja (URL filtering)
A TLS az csak a sikeres NAT után jön képbe, tehát a kommunikációba ékelődött transparens proxy a NAT segítségével 'átveri' a klienst és a szervert is, hogy a L7-es protokolokat is átnézhesse, vagy adott esetben módosítsa is. NAT nélkül már itt elbukna a dolog - ezért egy transzparens proxy funkcióhoz a NAT kötelező feature. - itt jön be az IPv6-ból eredetileg hiányzó feature a NAT, amit pont emiatt mégis utólag implementáltak:
https://hup.hu/cikkek/20111127/ipv6_nat_implementacion_dolgoznak_a_netf…
Igen ám, de pont az ilyen támadási forma kiszűrésére a TLS tanúsítványokat alkalmaz, ezért a transzparens proxynak ezt is hamisítani kell - és itt elértünk a "hogyan maradjon zöld a lakat" és a "miért csinálják ezt egyáltalán" kérdésekhez, amiről ez a topic is szól.
zrubi.hu
Egy router köszöni szépen NAT nélkül is meg tudja ezt oldani. Triviálisan: egy interface-re felhúzod a 92.119.122.43 címet, arra bindolod a proxyd, amikor beesik a kliens forgalma a routerre, azt saját magára fogja routeolni és a proxyd kiszolgálja, nem kellett hozzá a címet módosítani.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Felhúzod a címet egy interface-re és elkapod a beérkező csomagokat, addig oké. De hogy fog a proxyd kifelé kommunikálni ugyanazzal az IP címmel ha a routing önmagára mutat? Persze állíthatsz be rá policy routingot meg minden, de azért az általában nem a triviálisan szinten van.
Amilyen megoldásokat én láttam ott általában mindig volt egy DNAT a proxy IP címére. Főleg hogy általában nem egy adott célra kimenő HTTPS forgalmat akarnak általában proxyzni hanem az összeset. Az összes IP címet meg csak nem húzhatod fel arra a szegény interface-re.
Ez oké, ha lényeges, hogy kifelé ugyanannak a címnek kell látszódnia. De nem kell a klasszikus értelemben vett NAT ahhoz, hogy közbeékeld magad két gépre, csak mindkét irányból rajtad keresztül kell mennie a csomagoknak.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Nem a kifelé látszódásra gondoltam. Hanem arra hogy ha felhúzod a 42.42.42.42-es IP címet a routerre hogy elkapd a 42.42.42.42:443-ra menő forgalmat egy valamid nevű proxyval, akkor amikor a valamid akar kifelé kommunikálni az igazi 42.42.42.42-vel akkor a route tábla szerint csak magával fog beszélni. Erre megoldás a policy routing ami általában nem a triviális/junior szinten van, mondjuk annyira nem is nagy varázslat.
A másik hogy ha a 42.42.42.42 mellett a teljes 42.42.42.0/24-et akarod proxyzni akkor veheted fel az összes IP címet az interface-re hogy a valamid tudjon rá bindolni. Vannak olyan valamid-k amik képesek interface-re bindolni - nem tudom hogy ez-e a helyes kifejezés - de ez inkább kivétel.
Kérdéses hogy mi van azokkal a forgalmakkal amik szintén a 42.42.42.42 felé mennek, de nem HTTPS. Mondjuk ICMP vagy akár csak SMTP - gyakran előfordul főleg kisebb cégeknél hogy van 1db mindenes szerverük amin van egy weboldal és egy MTA. A route miatt az is a valamid felé fog menni, ezeket is proxyzni kell. Én ICMP proxyt nem ismerek Linux alatt, ott marad a NAT.
Legvégül ha minden HTTPS forgalmat akarsz monitorozni akkor arra a 0.0.0.0/0 fog illeszkedni, de akkor minden kimenő forgalmat a valamid-n keresztül kell intézned.
A Linux kernelben vannak rá megoldások - pl TPROXY, az még benne van? - hogy ne NAT-olj, de ebben az esetben is már a Netfilter-rel játszol, nem a routinggal.
Nagyon gyakori scenario az is hogy más doboz végzi a route-olást és a HTTPS proxyzást. Ekkor a routeren nincs nagyon más lehetőséged mint a DNAT.
Szóval, igen technikailag megoldható, hogy ne írd le a NAT karaktersorozatot, de a gyakorlatban ilyet én nem nagyon láttam.
Valóban, de egy céges gép esetében nem is biztos hogy rendszergazda vagy, és szinte biztos hogy ott figyel a céges CA.
országos szintű tanúsítvány is egyre gyakrabban kell lásd "nemzeti aláíró tanúsítványok"
mellesleg aki már megpróbálta "karbantartani" a trusted CA-kat az tudja hogy a gyakorlatban lehetetlen feladat. Minden update felülcsapja, és a böngészők sem a usereket segítik e téren.
a már beépült nagy CA-k meg persze nem a kispályások játéka, de ettől még a lehetőség adott.
Csak a töredéküknél létezik Certificate Transparency.
És elég sok nagy nevű lebukott már mindenféle bénázással, a bizalom mégsem szűnt meg... mert a többség fel sem fogja, hogy ennek mi a jelentősége. Beléjük nevelték hogy ha zöld a lakat akkor örülünk, ha meg a böngésző rinyál, akkor "accept the risk".
zrubi.hu
> mellesleg aki már megpróbálta "karbantartani" a trusted CA-kat az tudja hogy a gyakorlatban lehetetlen feladat. Minden update felülcsapja, és a böngészők sem a usereket segítik e téren.
En probaltam, es eleg az adott disztribucio / operacios rendszer dokumentaciojat elolvasni ezen a teren, hogy megnyugtato megoldasra lelj. Egyszeruen csak olyan helyre kell bemasolni az additional trusted CA certeket, ahonnan az oprendszer felveszi. Debian es RedHat alapu disztroknal van ilyen, Macen es Windowson pedig a tanusitvanykezeloikbe importalt CA certeket ritkan vagjak felul az updatek.
Blog | @hron84
via @snq-
A kulcsszó az additional, amit hozzáképzeltél.
Így van, én valójában nem hozzáadni, hanem elvenni szeretnék - ez az ami a gyakorlatban "szélmalomharc"
zrubi.hu
Azon túl, amit fent Tassadar írt (hogy a NAT-hoz és igazából a TCP-hez semmi köze, simán a titkosítatlan és nem ellenőrzött payload a gond), a nagy CA-k elleni kirohanásod is félrevezető lehet.
Egyrészt néhány spyware-t leszámítva (emlékezetes balfaszságok random laptop gyártóktól, akik az előretelepített 3rd party szutykukkal behúztak egy-két új CA-t.... kiderült, botrány lett, javították és még emlékezetesebb "security" termék gyártók, akik saját a SSL MITM implementációjukhoz minden gépre ugyanazt a kulcspárt használták... kiderült, botrány lett, javították) a rendszer/böngésző CA listája naprakészen van tartva és ellenőrizve van, másrészt a CA-k felé is egyre komolyabb elvárások vannak (Certificate Transparency [nem tudnak úgy kiállítani tanúsítványt, hogy azt utólag le tudják tagadni], CAA rekordok [nyilvánosan publikálhatod, hogy melyik tanúsítvány-kibocsátónak kell a láncban lennie] stb.). És mivel egy rosszul kiállított tanúsítvány elég lehet ahhoz, hogy egy tanúsítvány-kibocsátóban a bizalom megrendeljün (egyrészt vásárlói oldalról, másrészt a tanúsítványtárakat naprakészen tartók oldaláról, harmadrészt a CA fórum böngészőgyártói oldaláról... - gyakorlatilag roló lehúz), _és_ egyre jobban tudják egymást is ellenőrizni (CT-ben keresik a tanúsítványokat, amiért be lehet panaszolni a konkurrenciát), mindenki próbál rendesen eljárni.
Egyre kevésbé....
Nem, nem érthető, mert vagy 1) a "valaki" a saját CA-ját telepítette a gépedre (tudod ellenőrizni és össze tudod vetni mondjuk az oldal CAA rekordjával) vagy 2) kapott az eredeti CA-tól egy tanúsítványt a megfelelő névre. Na az, hogy valaki 1) el tudja irányítani a forgalmad, 2) legyen jogköre kikényszeríteni egy CA-ból egy "fake" tanúsítványt és 3) ezt meg is tegye.... ott már nem a CA infrastruktúra rossz felépítése a legnagyobb gond...
--
Félre ne érts, nem azt mondom, hogy ez egy jó rendszer. Nekem is jobban tetszene egy DANE alapú megoldás (DNS + DNSec + a DNS-ben tárolt publikus kulcsok), ahol csak egy root kellene (bár a kormányzatok úgy talán még egyszerűbben tudnának MITM-elni az országuk TLD-jén belül, mert csak az annak üzemeltetésért felelőstől kell "elkérniük" a kulcsot...), de messze nem annyira gyászos, mint ahogy lefested.
BlackY
"Gyakran hasznos ugyanis, ha számlálni tudjuk, hányszor futott le már egy végtelenciklus." (haroldking)
Jól értem, hogy ahhoz, hogy valaki SSL proxy-t állítson a forgalomba, a kliensek gépén is kell konfigurálnia? Azaz, amíg az én gépemhez nem nyúlnak, addig nyugodt lehetek, hogy a forgalmamat sem bontják?
A forgalmat bonthatják, de SSL warning-ot fogsz kapni, ha nem tudnak a gépedhez nyúlni.
Jep. Illetve megjegyzendő, hogy jól szituált SSL bontó proxyk egyébként ellenőrzik a valódi cél tanúsítványát, és ha az rossz volt, akkor a kliens fele is rosszat generálnak, hogy a kliens is tisztában legyen vele, hogy baj van.
Basszus, évek óta ssl interception-el élek és fel sem tűnt, hogy soha nincs warning (:
Nem olyan rég egy szomszéd topicban valaki elmondta, hogy az EV certet nem tudják így bontani, mert akkor nincs ott a lakat mellett a szervezet neve. Neki se tűnt fel, hogy már rég nincs ott egyébként se :)
Alapvetően igen*, a kliensnek meg kell bíznia a CAban, amivel a "kamu" certeket generálják. Persze egy cégnél group policyból is simán lenyomnak egy ilyet, ha arról van szó.
*legalábbis nem a szerver oldal tudta nélkül. Viszonylag jellemző pattern, hogy az igazi cert sem a valódi webszerveren lakik, hanem előtte valami load balanceren pl, és a cső végén már sima HTTP (esetleg egy másik HTTPS) van, és azért ma a mindenféle cloudos infrák világában nem triviális, hogy ez közvetlen ott lesz már a load balancer mellett.
ez az optimista hozzáállás :)
De kik nem nyúlnak a gépedhez?
- Az OS frissítés bármikor odatehet egy + CA tanúsítványt.
- a böngésződ bármelyik frissítéskor odatehet egy újabb CA-t,
- a "next gen" víruskergetők fícsörként bontják az SSL-t ;)
- a kormány által hazsnált CA-t te magad fogot feltenni. (Kínában mondjuk ezt megteszik helyetted ;)
- a kompromittált CA-k pedig évek múlva buknak csak le.
zrubi.hu
Ez nézőpont kérdése.
- amíg egy átlag user a zöld lakat "ellenére" abban a naiv hitben él, hogy a kapcsolata "biztonságos"?
- amíg egy böngésző a self signed tanúsítványt tűzzel vassal üldözi, mert az meg nem biztonságos? :)
- amíg mások döntik el helyettem hogy kiben bízok meg?
- az hogy ezekre a problémákra 20+ éve nincs értelmes megoldás?
ez szerintem elég gázos.
aztán, persze lehet egyedül vagyok ezzel... mert a többség egészen biztosan a boldog tudatlanságban él :D
zrubi.hu
Nem vagy. Egy rakás újvonalas izé, élen pl a cert transparencyvel azt kerülegeti, hogy a CAk körülötti trust modell kb úgy szar, ahogy van a gyakorlatban, egy másik fele (rövid lejáratú certek pl, bár ennek a trust modellhez is van köze) azt, hogy revocation technikailag szar. A TLS1.3ban az ocsp staplinggal már majdnem jó :D És mindenközben semmi értelmes feature nincs a normális önrendelkezés elősegítésére.
a Cert. Transparency szerintem az egyik leg értelmesebb ötlet, a CA-k kal szembeni bizalom növelésére és/vagy elnyerésére.
kár, hogy kitalálása óta (ami már majd 10 éve volt!) csupán egy "maroknyi" CA volt hajlandó ezt megvalósítani...
zrubi.hu
>a Cert. Transparency szerintem az egyik leg értelmesebb ötlet, a CA-k kal szembeni bizalom növelésére és/vagy elnyerésére.
Ezt ugyan nem vitatom, legalább valamiféle technikai dolog, egészen átgondolva, és egész értelmesen megcsinálva. De ettől még mindig csak kerülgeti a kupacot alapvetően, a hozzá adott érték azért még mindig leginkább csak valamiféle reaktív üzemmód, messze nem silver bullet. Cserébe azért hoz egyrészt üzemeltetési kockázatokat (amiket viszonylag arrogáns módon letolnak azzal, hogy hát nagyobb a gain), másrészt, ami nagyobb baj, hogy pont a saját magad által meghatározott "kiben bízok" dolgot még nehézkesebbé teszi. Meg hát a cinikus sapit felvéve azért nehezen megy el az ember amellett, hogy micsoda véletlen egybeesés, hogy pont az lett a technikai megoldás a googletől, hogy kötelező legyen minden potenciális új internet siteot lejelenteni, mert különben majd nyiffogni a chrome.
> - amíg egy böngésző a self signed tanúsítványt tűzzel vassal üldözi, mert az meg nem biztonságos? :)
Pedig a self-signed cert tenyleg nem biztonsagos. Ez olyan, mintha en azt mondanam, hogy kivalo agysebesz vagyok, es errol barmikor kiallitok neked egy igazolast. Aztan, hogy tenyleg az vagyok-e vagy se, az majd a reklam utan kiderul.
Blog | @hron84
via @snq-
Már hogy a fenébe ne lenne biztonságos egy cert, amit én generáltam a kicsi kezemmel, és tudom, hogy megbízom benne? Sokkal biztonságosabb, mintha belekeverek egy tök fölösleges "megbízható harmadik felet".
A CA ráadásul a megbízhatóságról szól, a technikai biztonsághoz, mint olyanhoz nem sok köze van.
Adott CN-re bármikor bárki csinál selfsigned certet, a te általad generált certtel betűre azonos mezőkkel. Keresztkérdés: hogyan bízhatok meg valamiben, amiből tetszőleges számú lehet tetszőleges számú helyen, és bármelyik helyettesítheti a másikat?
A fingerprint-je biztosan nem lesz azonos, tehát továbbra is a bögésző ellenőrzési módszerén múlik, hogy meg tudja őket különböztetni.
zrubi.hu
Adott CN-re bármikor
bárkibármelyik CA csinálselfsigned certet, a te általad generáltatott certtel betűre azonos mezőkkel. Keresztkérdés: hogyan bízhatok meg valamiben, amiből tetszőleges számú lehet tetszőleges számú helyen, és bármelyik helyettesítheti a másikat?Szóval ahogy zrubi is írta, ugyanolyan mezőket természetesen igen, pont ugyanazt viszont természetesen nem. Innentől meg csak a kliens dolga, hogy mennyire segít nekem. Sajnos nem nagyon, pedig megtehetné.
Érdekes egyébként, hogy egyik oldalról azért van örömködés, ha egy app pl cert pinninggel működik (ami ugye pontosan ez), mert akkor nem lehet bontani, a másik oldalról én ne akarjam ezt csinálni saját hatáskörben, mert az nem biztonságos.
Bárki csinál, csak aláírni nem tudja ugyanazzal a certtel. Ha a 'bárki' certje megbízhatónak van beállítva, akkor működik. Ha nem, akkor nem.
Beneztem bocs
s/biztonságos/biztonságosabb/. A https biztonságosabb, mint a plaintext http, de csak a protokoll/módszer korlátain belül.
Érdekes egyébként, hogy egyik oldalról azért van sírás-rívás, mert a https-t át lehet csomagolni, és megfelelő körülményekközött ezt a végfelhasználó nem veszi észre, másik oldalról meg azért, mert egy kormányzati hitelesítésszolgáltató certje nincs ott...
Egy átlag user nem ezt hiszi.