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.
- 750 megtekintés
Hozzászólások
Welcome to the Security Theater!
Ebben a témában megnyugtatót csak az tud mondani, aki hazudik ;)
szerintem.
- A hozzászóláshoz be kell jelentkezni
anno mikor ezzel foglalkoztam egy CA-t kellett hiteleskent elhitetni a bongeszovel hogy ez zold lakatoskent mukodjon
neked aztan fura humorod van...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
Szintén láma, viszont ebben a doksiban szép rajzok vannak a témában:
https://docs.mitmproxy.org/stable/concepts-howmitmproxyworks/
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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,
Semmi köze a NAT-olásnak a témához.
Könnyedén, ha te vagy a proxy/router/ISP.
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.
Igen, sajnos neked mint user gyakorlatilag nincs beleszólásod ebbe.
Ez abban az esetben igaz, ha nincs rendszergazdai jogosultságot az érintett eszközökön.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
1 - Egy biztonságos csatornán megnézem, ki hitelesítette az oldalt.
DNS CAA rekord (DNSSec-el ha rooting vissza is ellenőrzöd, tudod ellenőrizni).
2 - Ezentúl minden kapcsolódáskor megnézem, hogy ki hitelesítette az oldalt, és ha nem ugyanaz, akkor aggódok?
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)
- A hozzászóláshoz be kell jelentkezni
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 ;)
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
Én továbbra sem értem, mi a kapcsolat a NAT-al?
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
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".
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
A kulcsszó az additional, amit hozzáképzeltél.
- A hozzászóláshoz be kell jelentkezni
Így van, én valójában nem hozzáadni, hanem elvenni szeretnék - ez az ami a gyakorlatban "szélmalomharc"
- A hozzászóláshoz be kell jelentkezni
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.
a CA-k pedig egymástol függetlenül kiállíthatnak ugyan arra a URL-re szóló tanúsítványt :)
Egyre kevésbé....
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...
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)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
A forgalmat bonthatják, de SSL warning-ot fogsz kapni, ha nem tudnak a gépedhez nyúlni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Basszus, évek óta ssl interception-el élek és fel sem tűnt, hogy soha nincs warning (:
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azaz, amíg az én gépemhez nem nyúlnak, addig nyugodt lehetek, hogy a forgalmamat sem bontják?
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.
- A hozzászóláshoz be kell jelentkezni
de messze nem annyira gyászos, mint ahogy lefested.
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
>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.
- A hozzászóláshoz be kell jelentkezni
> - 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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Adott CN-re bármikor bárki bármelyik CA csinál selfsigned 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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Beneztem bocs
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
s/biztonságos/biztonságosabb/. A https biztonságosabb, mint a plaintext http, de csak a protokoll/módszer korlátain belül.
Egy átlag user nem ezt hiszi.
- A hozzászóláshoz be kell jelentkezni