HTTPS használata böngészőben...

Titkosítás, biztonság, privát szféra

HTTPS Everywhere Add-on
18% (50 szavazat)
HTTP Nowhere Add-on
0% (1 szavazat)
HTTPS Everywhere + HTTP Nowhere ÉS a csak http-s oldalak külön engedélyezése
3% (7 szavazat)
Kit érdekel...
41% (112 szavazat)
Egyik se!
38% (102 szavazat)
Összes szavazat: 272

( m.informatikus | 2017. 02. 28., k – 07:34 )

https://addons.mozilla.org/hu/firefox/addon/https-everywhere/ -> 1x felrakod 5mp alatt és elfelejted!

https://addons.mozilla.org/hu/firefox/addon/http-nowhere/

HTTPS Everywhere + HTTP Nowhere ÉS a csak http-s oldalak külön engedélyezése = utóbbiban be lehet állítani whitelisttel, h. mégis engedjen pár non-https oldalt, mert 2017-ben ugyan már elenyészően, de vannak még http-only siteok (az eredeti "http-s" szöveg megtévesztő, "pár non-https"-t jobb lett volna írnom :) )

( sarkanyolo v | 2017. 02. 27., h – 19:56 )

Az általam használt szenzitív oldalak (bank, mail, stb) már nagyon régóta https-el működnek.
Híroldalaknál, fórumoknál, stb nem nagyon érdekel.

( scineram | 2017. 02. 27., h – 23:25 )

Én is az oldalra bízom a dolgot, és TLS 1.0 is elfogadható. De azért a verzió (1.3) intoleranciát nem engedem.

Öt is van is van :-) Mindegyik szép kerek.

1. HTTPS használata böngészőben HTTPS Everywhere Add-on.
2. HTTPS használata böngészőben HTTP Nowhere Add-on.
3. HTTPS használata böngészőben HTTPS Everywhere + HTTP Nowhere ÉS a csak http-s oldalak külön engedélyezése.
4. HTTPS használata böngészőben kit érdekel.
5. HTTPS használata böngészőben egyik se!

--
Fuszenecker Róbert

( zrubi v | 2017. 02. 28., k – 09:05 )

Már már vallási szinter emelkedett a "HTTPS everywhere", miközben a többségnek fogalma sincs, hogy mégis mi ellen "védene"... Oh wait.

Csak a jéghegy csúcsa:
Ugye mindenki 101%-ban megbízik a böngészője által szállított ÖSSZES Root CA-ban, és az öket kezelő profit orientált cégekben?

(Preferencies -> Advanced -> Certificates -> Authorities)

--
zrubi.hu

Ez a "nyafogás" NEM arról szól hogy a HTTP biztonságosabb. Főleg mert nehéz is lenne a "biztonságosabb"-at definiálni.

Viszont a HTTPS pont a MITM típusú támadásoktól és a kommunikáció lehalgatása ellen védene - ha működne. Manapság viszont simán lehet "zöld lakatos" MITM támadást kivitelezni. És ezt csinálják is a gyakorlatban különböző indokokkal. Innentől viszont értelmét veszti azt mantrázni hogy https kell mindenhová, mert nem kell. Legtöbb esetben nem is lesz neked semmivel sem jobb, ha az adott oldalt https-en nézegeted http helyett. Sőt, van ahol kifejezetten káros ennek a kieröltetése.

Persze, aki nem is érti, hogy miért, annak csak az jön le, hogy "zöld lakat" = biztonságos. És boldogan él tovább a tudatlanság mámorában, hiszen ez alapján a facebook is biztonságos, meg a CloudFlare is, meg a Cloudpets is.

szerintem.

--
zrubi.hu

Szoval akkor asszem egyetertunk abban, hogy a https nem gyogyir mindenre, de altalaban kicsit jobb mint a http. A userek 95+ szazaleka ugyis pont ugyanannyira bizik meg egy zold lakatos oldalban mint egy sima http-ben. Mert mondjuk eszre se veszi a kulonbseget. Ezeknek a tomegeknek pont segitene ha megtanulnak, hogy az a zold lakat ott kell hogy legyen.

Es lehet, hogy lehet csinalni MITM-et https-en, de biztos, hogy nehezebb mint http-n. Es ezert mar nem is mondanam, hogy "siman" lehet.

Arra viszont tenyleg mondhatnal egy peldat, hogy valahol "kifejezetten káros" a https eroltetese. Tehat nem felesleges, nem feleslegesen macaras, hanem _karos_.

Kifejezetten káros, olyan esetben:

ahol neked kell(ene) megvédeni a balga (céges) userereket az interneten fellelhető szeméthalomtól.
* Ilyenkor vagy kiengeded mindenhová a HTTPS forgalmat - így gyakorlatilag azt csinál mindenki amit nem szégyell. A mindenki alaltt pedig az összes useredet, és az összes weboldal "üzemeltetőt" is értem.

* vagy MITM támadást hajtasz végre rajtuk a céges tanúsítvány segítségével - ami jogilag igencsak aggályos.

* vagy megpróbálod URL alapján kiszűrni a nem kívánt tartalmakat - ami pedig a gyakorlatban nem működik.

vagy olyankor is káros a https eröltetése, amikor egy forgalom már beslső, erősen kontrollált hálózaton megy. Pl: reverse proxy és webszerver között, ahol szépen lehetne IDS/IPS/L7 rendszerekkel elemezni a foglamat, és ezzel megvédeni a webszervereket - de a bugyuta szabványok miatt - amik csak azt szajkózzák, hogy HTTPS = jó, HTTP = rossz. - https-t kell hogy használj, így cserébe megfelelesz a PCI DSS-nek, de nem tudod megvédeni a webszerveredet és az azon futó ratyi alkalmazást az alapvetően primitív támadásoktól sem.

Ezen felül az egész HTTPS everywhere 'vallás' velejárója, hogy a kevésbé hozzáértőkbe már beleégett hogy HTTPS=biztonságos

A te példád is jól mutatja:
"Ezeknek a tomegeknek pont segitene ha megtanulnak, hogy az a zold lakat ott kell hogy legyen."

Mert ez így önmagában durva tévútra visz. Pont arra akartam felhívni a figyelmet hogy a zöld lakat nyugodtan ott lehet bármelyik adathalász, vírus és trójai terjesztő oldalon is. Csak annyit jelent, hogy a böngésződ és a szerver között titkosítva töltöd le a vírusokak, és/vagy adod oda az adataidat VALAKINEK, akiről sajnálatos módon nem tudod hitelt érdemlően megmondani hogy kicsoda. El kell hinned az ÖSSZES zöld lakatos tanúsítvány kiadónak, hogy ö istibizti igazat mond - ami kb annyit jelent, mindha megbíznál bárkiben aki becsönget hozzád és egy névjegykártyával "igazolja", hogy Ő bizony a megbízott pénzbeszedő, és neki kell odaadni a havi lakbért.

Szintén ennek áldozata az FTP forgalom, olyan esetekben is, ahol az ég világon semmi értelme titkosítani, hiszem mondjuk mindenki számára publikus (opensource) cuccokat töltesz le: ftp.kernel.org.

Ezek áteröltetése titkosított formára, teljesen felesleges, és az "álbiztonság" mellett új implementációs hibákat is bevonzanak. Feleslegesen.

szerintem.

--
zrubi.hu

Azert a HTTPS-t albiztonsagnak nevezni az kicsit eros. Nyilvan nem ad 100%-os biztonsagot (mint ahogy semmi), de igenis noveli a biztonsagot. Minden amit irsz arrol szol, hogy a HTTPS macerassa teheti az eletedet mint uzemeltetonek (amit elismerek), de ezt nem hivnam "kar"-nak.

Az FTP peldaja pont azt mutatja, hogy kihal az a szolgaltatas ami nem nyujt semmilyen vedelmet. Nem azert hal ki mert teljesen hasznalhatatlan lenne, hanem azert mert az esetek jelentos reszeben nem hasznalhato, azok viszont amelyek tudnak titkositani (is) mukodni azok minden esetet kepesek kiszolgalni. Es igy rogton kevesebb implementaciora van szukseg vagyis az implementacios hibakbol _kevesebb_ lesz. (Es ugye itt most nem a HTTPS vs HTTP-rol beszelunk, ahol az implementacio kb ugyanaz +egy SSL reteg, hanem az FTP vs mas titkositott file szolgaltatas (pl HTTPS), amikor ket tok kulon implementacio van ugyanarra a problemara csak az egyik tud tikositani a masik meg nem.)

Egyebkent ha tok publikus dolgot toltesz le akkor sem haszontalan titkositas, mert biztosabb lehetsz benne, hogy tenyleg azt toltod le amit akarsz (es ugye itt valojaban hitelessegrol es nem titkossagrol beszelek, de valahogy altalaban ahol az egyik van ott elerheto a masik is). Es most lecci ne huzd elo megint a kartyat, hogy de hat "meg ugy sem lehetsz benne biztos!", mert persze biztos nem lehetsz, csak biztosabb.

"Egyebkent ha tok publikus dolgot toltesz le akkor sem haszontalan titkositas, mert biztosabb lehetsz benne, hogy tenyleg azt toltod le amit akarsz (es ugye itt valojaban hitelessegrol es nem titkossagrol beszelek, de valahogy altalaban ahol az egyik van ott elerheto a masik is). "

A HTTPS ponthogy csak a titkosságot tudja biztosítani. De a 100%-os hitelességet nem tudja biztosítani. Hiszen meg kell bíznod egy olyan harmadik félben a hitelességhez, akire semmi ráhatásod nincs. Ezt kéne felfogni.

A HTTPS a titkosságot sem garantálja 100%-osan, sőt, kevésbé mint a hitelességet, mert a hitelesség hiányából MITM támadással egy lépésben következik a titkosság hiánya.

Az, hogy a hitelesség nem 100%, csak mondjuk 80% még mindig nem teszi elfogadhatóbbá a 0%-ot, amit a http/ftp nyújt.

"Az, hogy a hitelesség nem 100%, csak mondjuk 80% még mindig nem teszi elfogadhatóbbá a 0%-ot, amit a http/ftp nyújt."
Ez az egész szál nem arról szól, hogy az FTP/HTTP elfogadható.
Hanem arról, hogy a HTTPS önmagában, 3rd partyra bízott identitáskezeléssel ugyanúgy egy false sense of security.

Hogyan csinálnád jól az identitáskezelést kizárólag in-band kommunikációval? Azt állítottad, hogy meg lehet csinálni teljesen biztonságosan in-band kommunikációval a biztonságos kulcscserét (ami valójában kulcsidentitás-probléma), mert az aszimmetrikus kulcsú titkosítás erre lehetőséget ad.
Mi lenne erre a protokollod?

Felhúzok egy titkosított csatornát találomra, majd tesztelem valamelyik ismert tulajdonságát olyan módon, hogy a kulcsok eltérése esetén a teszt eltörjön.

Szerinted, ez nem in-band azonosítás, mert hogy a tesztelendő tulajdonságot előre ismernem kellett. De: Ezt a gondolatmenetet folytatva, ha valakit azonosítani akarok, akkor egy külső csatornához kell folyamodnom. Ennek a külső csatornának viszont nem tudom garantálni a biztonságát, hiszen akkor azt ennek a csatornának a szempontjából nézve in-band garantálnám. Vagyis ha in-band nem tudom garantálni valaminek a biztonságát, akkor out-of-band sem, következésképp biztonságos kulcscsere nem létezik. Sem in-band, sem out-of-band.

Erre a következtetésre csak akkor nem jutunk el, ha bizonyos csatornákat (pl. személyes találkozás) eleve, alapvetésként biztonságosnak fogadunk el, vagy bizonyos adatokat eleve, alapvetésként ismertnek tekintünk (pl. a személy neve). Ezeknek a csatornáknak vagy adatoknak a megválasztása viszont merőben önkényes. Ha ugyanis semmit nem tudok a partneremről, akkor nem látom be miért lenne biztonságosabb egy személyes találkozó egy élő videóhívásnál. Ha pedig valamit ismertnek tekintek, ami lehet a személy neve, nem látom be miért ne lehetne ez az ismert adat a neve helyett a személy GPG-kulcsa.

Konklúzióként két eredményre juthatunk:
a) Ha semmilyen adatot és csatornát nem tekintünk eleve adottnak, akkor arra, hogy biztonság nem létezik sem in-band sem out-of-band.
b) Ha valamilyen adatot (vagy csatornát) eleve biztosítottnak tekintünk akkor pedig ennek az adatnak a mibenlététől függően valamilyen csatornán, (vagy a biztonságosnak tekintett csatornán) pedig lehetséges in-band azonosítani.

De még mindig nem az azonosítás a téma, hanem a kulcscsere. A biztonságos kulcscserével azt mondod, hogy megoldható TELJESEN in-ban biztonságosan. Pedig előtte megmondtad, hogy ilyen definíció szerint sem lehetséges. És én is csak ennyit mondtam: Kizárólag in-band biztonságos kulcscsere nincs. Te pedig erősködsz, hogy van.

A te általad "előre adott" információ pont a kommunikációs csatorna szempontjából out-of-band adat.

Ami in-band megoldható, az egy olyan kulcscsere, amihez egy másik titkosítás másik kulcsait biztonságosan out-of-band szerezted meg.

Ha in-band nem oldható meg a biztonságos kulcscsere, akkor egy másik csatornán sem, vagyis nem létezik out-of-band de biztonságosan megszerzett információ sem. És ezen a ponton a "biztonságról" való beszélgetés értelmét veszti.

Ettől függetlenül elismerem, technikailag mindenben egyetértünk, de a "biztonság" fogalmáról más az elképzelésünk.

A titkos kulcscsere megoldhato. A biztonsagos nem. Nagyon nagy kulonbseg.
A PKI sem oldja meg a biztonsagos kulcscseret, csak a titkosat.

Hogy egy peldat mondjak:
van neked egy publikus kulcsod, letoltod az internetrol.
Honnan tudod, hogy valoban ahhoz tartozik, akinek mondja magat?

Vagy hogy maskent mondjam: felepitesz egy titkositott csatornat, ahol egymasnak a kulcsokat in-band kulditek el. Mi garantalja, hogy valoban azzal a fellel kommunikalsz, akivel szeretnel?

Szerinted az extended validation certificate-nel miert kell szemelyesen (azaz out of band) igazolni a vasarlonak magat a PKI CA elott? Mert in-band nem tudja.

Vagy egy masik pelda: szerinted miert letezik a certificate pinning?
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#What…
Ezt olvasd el es rajossz, hogy a PKI ugyanugy nem old meg egy csomo problemat.

Tökéletesen a jelenlegi PKI infrastruktúrának sok gyengéje van. Ettől még nem igaz, hogy az in-band kulccsere ne lenne megoldható, sőt!

Ha van olyan adatod, ami alapján azonosítani tudod a másik felét, akkor felhúzol egy titkosított csatornát, azon belül ellenőrzöd, és készen vagy. Ha nincs ilyen adatod, akkor out-of-band sem tudsz biztonságosan kulcsot cserélni.

Annak, hogy klasszikusan olyan adatokat ismertünk el hitelesnek, amiket digitálisan nem lehet jól ellenőrizni (pl. személyi igazolvány, vagy arckép) semmi köze hozzá hogy in-band vagy out-of-band cserélünk kulcsot. A jog és a technika fejlődésével ez változik. Az e-szemelyi egy e-cégkivonattal pl tökéletes lehet majd digitálisan EV-cert igénylésre, mint ahogyan a DNSSEC+DNS-be írt kulcs is tökéletes lenne domain certek validálásához.

A biztonságosság nem az in-band/out-of-band technológián múlik, hanem azon, hogy mit ismersz el biztonságosnak.

Ha abban akarsz biztos lenni, hogy ugyanazzal az emberrel beszélsz akit "tegnap láttál a sarkon" akkor "in-band" nagyon nehéz lesz azonosítanod. Ha meg azt, hogy ugyanazzal az emberrel beszélsz, "akivel toron kulcsot cseréltél" azt meg "out-of-band", nem fogod azonosítani, bármennyire szeretnéd.

"Ha van olyan adatod, ami alapján azonosítani tudod a másik felét"
Ezt in-band nem tudod megoldani, pont ez a lényeg. Ezért nem lesz sosem biztonságos az in-band kulcscsere, csak titkos. Secrecy vs security.
"Az e-szemelyi egy e-cégkivonattal pl tökéletes lehet majd digitálisan EV-cert igénylésre"
Az e-személyi megléte egy out-of-band információ: megbízol a kiadó államban, hogy csak magyar állampolgároknak, csak valódi létező magánszemélyeknek ad ki e-személyit. Az már in-band információ, hogy a NISZ CA állítása szerint a magát hzsolt94-nek mondó felhasználó kulcsa valóban H. Zsolt magánszemélyhez tartozik. De ezt nem garantálja semmi in-band, csak out-of band információ és bizalom.

"A biztonságosság nem az in-band/out-of-band technológián múlik, hanem azon, hogy mit ismersz el biztonságosnak."
Pont ez a lényeg: hiába van titkosítot csatornád, in-band sosem tudod biztonságossá tenni. Ez a lényeg.

"Ha abban akarsz biztos lenni, hogy ugyanazzal az emberrel beszélsz akit "tegnap láttál a sarkon" akkor "in-band" nagyon nehéz lesz azonosítanod. "
Nem nehéz, hanem lehetetlen. Pont ez a kulcsdisztribúciós probléma lényege.
És épp ezért nem lehet in-band teljesen biztonságosan kommunikálni, csak legfeljebb titkosan.

Vagy szerinted hogyan lehet in-band biztonságosan kulcsot cserélni?

Önkényesen úgy definiálod a biztonságot, hogy a kulcs birtoklását egy földi biológiai személyhez akarod kötni. Ebben az esetben persze, előbb utóbb valahol át kell hidalni hogy a biológiai személy nem rendelkezik digitális azonosítóval.

De ez a megkötésed abszolút önkényes, és - ha a berögződött szokásoktól eltekintünk - sok esetben teljesen szükségtelen. A legtöbb esetben például teljesen érdektelen hogy egy identitás mögött ki áll, csak az érdekel hogy ugyanerről az identitásról másoknak milyen visszajelzései vannak. És az identitás alatt itt tényleg bármit érthetsz, fizikai eszközt, szervert, céget, vagy anonym dealert.

A kommunikáció biztonságának egyik feltétele, hogy tényleg azzal beszélgetek-e, akivel szeretnék.
A másik feltétele, hogy más ne tudja lehallgatni a beszélgetést.

És egy titkosított csatornán a kommunikáció biztonsága épp ezért a kulcs identitása biztosításának felel meg.
Ez egyáltalán nem önkényes definíció, nem csak én definiálom így.

Az aszimmetrikus kulcsú titkosítások csak abban segítenek, hogy a két beszélgetőpartner más-más kulccsal éri el a kommunikáció biztonságát, így ha az egyik fél kompromittálódik, az a másik félre nincs kihatással. Ez, és csak ez az aszimmetrikus kulcsú titkosítás lényege.

"A legtöbb esetben például teljesen érdektelen hogy egy identitás mögött ki áll, csak az érdekel hogy ugyanerről az identitásról másoknak milyen visszajelzései vannak. "
Az teljesen érdektelen, hogy mások mit mondanak az identitásról, ha igazi biztonságról van szó. A lényeg, hogy ÉN tudjam az identitást ellenőrizni.
Persze kényelmi szempontból az terjedt el, hogy ezt az ellenőrzést átadjuk valamely harmadik félnek (pl. Web-of-trust, vagy PKI), de így máris nem teljes a biztonság: harmadik féltől függ az identitás ellenőrzése, így mindenképpen meg kell bízni harmadik félben.
Nos ez a fajta bizalom az, ameddig a feltételezett biztonságod terjed, magyarázd el mondjuk a volt DigiNotar ügyfeleinek, hogy mennyire jó a PKI-ba vetett feltétlen bizalom.

És ÉN hogyan ellenőrzöm hogy pl. az igazi Google-el beszélek? Egyáltalán hogyan definiálod hogy mi felel meg neked Googlenek? Valójában sehogy, ha te ugyanazzal a rendszerrel állsz kapcsolatban, akit a környezeted Google-ként (el)ismer, az számodra biztonságos.

A legtöbb identitás amivel kommunikálsz valójában kitalált fogalom, kreált dolgokat, szolgáltatásokat takarnak.

Az asszimetrikus kulcsú titkosítások ennél sokkal több mindenben segítenek - szimmetrikus esetben minden egyes partnerpárhoz tartoznia kell egy kulcsnak (gráf élei), míg aszimmetrikus esetben csak minden egyes parnerhez (gráf pontjai) - de ezt hagyjuk.

Egyébként persze, lehet úgy kialakítani a biztonság fogalmát, hogy csak a hajnalban, bekötött szemmel, föld alatt rendezett személyes találkozó teljesítse. Csak ez tényleg egyfajta értelmetlen fanatizmus, annyira nem fedi a valós igényeket.

"És ÉN hogyan ellenőrzöm hogy pl. az igazi Google-el beszélek? " Ha valóban ellenőrizni akarod, mert nem elég neked a PKI-ba vetett bizalom, akkor ahhoz (ugyanúgy, mint az Extended Validation-ös certificate-k keletkezésekor) személyes kapcsolatfelvétel kell. Ez bizony ilyen.

"ha te ugyanazzal a rendszerrel állsz kapcsolatban, akit a környezeted Google-ként (el)ismer, az számodra biztonságos."
Te összekevered a bizalmat meg a biztonságot. Nem, nem lesz számomra valóban biztonságos az, hogy sokan ugyanabban a 3rd party által megbízhatónak jelölt dologban bízunk meg. ont a DigiNotar példája mutatja meg a rendszerben lévő hatalmas lyukat.
Az EU is elismeri, hogy a HTTPS by design hibás.
https://www.enisa.europa.eu/media/news-items/operation-black-tulip
" In the current setup, browsers and operating systems (e.g. Microsoft’s certificate store) place trust by default in a large number of CAs (hundreds) by default, so a failure with one of them creates a risk for all users and all websites. The security of HTTPS equates to the security of the weakest CA. HTTPS should be modernized, to be more resilient against attacks and more user-friendly. "

"A legtöbb identitás amivel kommunikálsz valójában kitalált fogalom, kreált dolgokat, szolgáltatásokat takarnak."
A szolgáltatások mögött jogi vagy természetes személyek vannak.

"szimmetrikus esetben minden egyes partnerpárhoz tartoznia kell egy kulcsnak (gráf élei), míg aszimmetrikus esetben csak minden egyes parnerhez (gráf pontjai) "
Pont ezt mondtam, de sebaj: minden fél rendelkezik 1-1 kulccsal, így 1 gráf pont bedőlése nem vonja maga után az élek mögött lévő gráfpontok bedőlését. Mesélj, mi másban segít még az aszimmetrikus crypto, ami élesen elkülöníti a szimmetrikus kriptotól. Nincs más valódi különbség.

"Csak ez tényleg egyfajta értelmetlen fanatizmus, annyira nem fedi a valós igényeket."
Nem, a valós biztonsági igény valóban az ilyen biztonság lenne. Azonban a kényelemért hajlandóak vagyunk feladni sok mindent. És minél több kényelmet adunk magunknak, annál kevésbé biztonságos az egész. A PKI a jelenlegi módon (OS és browser vendorok mondják meg, kiben kell megbíznod és kiben nem) egy rendkívül kényelmes dolog - de cserébe rendkívül sérülékeny is.

> Az EU is elismeri hogy a HTTPS by design hibás.
Ez az állásfoglalás csak arról szól, hogy a jelenlegi PKI bizalmi forrása silány minőségű, és ebben azt hiszem mind egyet is értünk.

> A valós biztonsági igény valóban ilyen biztonság lenne.
Ez csak a te vaskalapos véleményed.

A valóság ezzel szemben az, hogy engem pl. teljesen hidegen hagy hogy a valódi Google, GitHub, Facebook Inc-el beszélek-e, mert ez semmilyen garanciát nem jelent számomra. Ha valami gondom van velük, esélyem sincs az én erőforrásaimmal jogilag érvényesíteni. A biztonságot nekem az adja, hogy ha sokezer emberrel szemben korrektül járnak el, akkor valószínűleg velem is úgy fognak. És ezt történetesen remekül lehetne in-band ellenőrizni. Az más kérdés, hogy a jelenlegi PKI rendszer valóban nem ezt teszi.

"Ez az állásfoglalás csak arról szól, hogy a jelenlegi PKI bizalmi forrása silány minőségű, és ebben azt hiszem mind egyet is értünk. "
Hát de....hát de, hát de minek bizalmi forrás, amikor tökéletesen lehet in-band biztonságosan kulcsot (és így certeket cserélni)? Hát nem old meg mindent a nyílt kulcsú titkosítás?
Minek kéne a PKI-ban megbízni, amikor megy minden in-band és a nyílt kulcs mindenre megoldás?

Az attól függ, hogy mit tekintesz biztonságnak.

Ha abban akarsz biztos lenni, hogy valóban ahhoz csatlakozol, aki a domain nevet megvette, akkor például DNSSEC + DNS-ben tárolt publikus kulcs lehetne a megoldás.

Ha abban akarsz biztos lenni, hogy valóban ahhoz csatlakozol, akit egy meghatározott hatóság (pl. cégbíróság) XY néven ismer el, akkor annak a hatóságnak kell(ene) valamilyen digitális hitelesítőadatot biztosítani. (pl. listázni valahol a publikus kulcsát)

A probléma nem a PKI-ban mint szerkezetben van, hanem hogy a PKI "forrása" máshova vezet, mint amit a hétköznapokban hitelesnek tekintünk. A jelenlegi PKI kis túlzással olyasmi, hogy "Abban akarok biztos lenni, hogy valahol a világon van legalább egy akármilyen ügyintéző aki azt állította, hogy az ő neve XY."

"Ha abban akarsz biztos lenni, hogy valóban ahhoz csatlakozol, aki a domain nevet megvette, akkor például DNSSEC + DNS-ben tárolt publikus kulcs lehetne a megoldás."
A DNSSEC HTTP esetében megintcsak out-of-band információ: nem a HTTP csatorna felett, és nem is azzal a féllel kommunikálsz, akivel titkosítottan adatot cserélnél.
Valamint feltételezed, hogy a DNS regisztrátor megbízható. Ez mind out-of-band információ mondjuk egy HTTPS kapcsolat felépítésekor.

"Ha abban akarsz biztos lenni, hogy valóban ahhoz csatlakozol, akit egy meghatározott hatóság (pl. cégbíróság) XY néven ismer el, akkor annak a hatóságnak kell(ene) valamilyen digitális hitelesítőadatot biztosítani. (pl. listázni valahol a publikus kulcsát)"
Szintén out-of-band információ.

"A probléma nem a PKI-ban mint szerkezetben van"
Nem hát. A probléma sokkal mélyebb, mint a PKI és valójában megoldhatatlan. Épp ezért a PKI-ban megbízni feltétel nélkül és teljesen biztonságosnak állítani ki, hülyeség. És ugyanígy, abban hinni, hogy a HTTPS az alapvető titkosságon kívül bármiféle biztonságot ad, butaság és vakhit.

Persze, szőrözhetünk az in-band/out-of-band definícióján, de:

Ezzel az erővel az éppen lefikkantott klasszikus PKI is out-of-band, merthogy a bedrótozott root CA-k out-of-band információk. Kriptográfiai szempontból meg teljesen érdektelen hogy HTTP-n vagy DNS-en keresztül szerzem be az információt. Ha nagyon akarom akkor az X509-es certeknél előírom, hogy csak DNS hierarchia szerint felépülő bizalmi lánc minősül érvényesnek, és máris minden "in-band" egészen az egyetlen gyökér kulcsig.

Igazából a PKI lényege pontosan az, hogy nagyon kevés, előre ismert információra vezesse vissza az összes bizalmi problémát, így az egyes alkalmakkor ne legyen szükség külön-külön out-of-band azonosításra. A jelenlegi elterjedt PKI rendszernek egyetlen tervezési problémája van: A gyökér információ rendkívül silány minőségű.

De itt érkezünk el ahhoz a ponthoz, hogy megtérülés/költség. A HTTPS igenis viszonylag nagy biztonságot nyújt, mert arányaiban sokba kerül közbeékelődni.

"Ezzel az erővel az éppen lefikkantott klasszikus PKI is out-of-band, merthogy a bedrótozott root CA-k out-of-band információk"
Ez így van, a PKI is out-of-band. Nem véletlenül: mivel nem lehet in-band megoldani a biztonságos kulcselosztást. Ha meg lehetne oldani, nem lenne szükség sem web-of-trustra, sem PKI-ra.
"Kriptográfiai szempontból meg teljesen érdektelen hogy HTTP-n vagy DNS-en keresztül szerzem be az információt."
A kriptográfia csak a titkosságért (harmadik fél által történő lehallgatás megelőzése) felel. A biztonság kicsit több ennél.

"A HTTPS igenis viszonylag nagy biztonságot nyújt, mert arányaiban sokba kerül közbeékelődni."
Még mindig: a HTTPS csak titkosságot nyújt, biztonságot nem.
Példa: beregisztrálok Unicode-trükkös domain neveket, például egy otpbank.hu-hoz hasonló nevű domain, majd Let's Encrypttel teljesen érvényes SSL tanúsítványt szerzek rá és beüzemelem a HTTPS-t.
Nyújt ez titkosságot? Igen. Harmadik fél csak nehezen tudja lehallgatni a kommunikációt.
Nyújt biztonságot? Nem. Akármi lehet azon a hoston, semmi nem garantálja az identitását.

Keyloggert telepítek a számítógépedre. Véd ez ellen a HTTPS? Nem.

Hogyha hálózati protokollokról van szó, akkor hálózati biztonságról beszélgethetünk. Ebben az esetben a biztonság 3 dolgot jelent: titkosítás, hitelesítés, azonosítás. Mindhárom elméletben tökéletesen megvalósítható, csatornán belül, bármiféle külső kulcselosztási kényszer nélkül.

Az, hogy nehezen tudod a kulcsot a testvéred személyéhez kötni külső segítség nélkül, éppen annyira releváns, mint hogy nem véd a hiper-szuper out-of-band kulcscsere az ellen, ha bepoloskázták a szobádat.

Végtelen emberi hülyeség ellen nincs védelem. Ettől még nem lesz kevésbé biztonságos a PKI vagy a https, és igenis kell hinni bennük.

". Ebben az esetben a biztonság 3 dolgot jelent: titkosítás, hitelesítés, azonosítás. Mindhárom elméletben tökéletesen megvalósítható, csatornán belül, bármiféle külső kulcselosztási kényszer nélkül."
Nem, tökéletesen nem valósítható meg. Csak akkor, ha elfogadod, hogy harmadik félre bízod a valódi azonosítást. Ugyanis certificate kiadásnál valójában ők végzik el azt az azonosítást, ami azt mondja, hogy az XYZ certificate az OTP Bank tulajdona, és te ebben csak megbízol.
Ugyanígy a DNS regisztrációnál is (ami a Let's Encryptben való bizalom végső feltétele) a DNS regisztrátor végzi out-of-band az azonosítást.
És ezek az azonosítások bizony nem csatornán belül történnek.

"Ettől még nem lesz kevésbé biztonságos a PKI vagy a https, és igenis kell hinni bennük."
Hinni a PKI-ban az egy dolog. És tudni azt, hogy alapvetően egy külső bizalomra épülő, rendkívül sérülékeny rendszerről van szó, az meg egy másik dolog. Csakhogy a biztonság nem a hitről szól.

- Igen, a biztonsághoz szükséges bizalomnak van egy forrása.
- Igen, ez a klasszikus PKI esetében, különösen mondjuk egy banki EV cert esetében out-of-band.
- Igen, ha természetes identitásban akarsz bízni, akkor mindenképpen out-of-band lesz a forrás, mert nincs az identitásnak olyan digitális tulajdonsága, amit ellenőrizni lehetne.

Ettől még a "A biztonsagos kulcscsere elvben sem oldható meg in-band kommunikacióval." állítás nem lesz igaz.

Ha egy identitás rendelkezik digitálisan ellenőrizhető tulajdonsággal, és ezen tulajdonsága alapján én megbízom benne, akkor azt in-band ellenőrizni tudhatom. Erre az esetre viszonylag kevés példa van, de a világ fejlődésével egyre több lesz.

Ellenorizni ellenorizheted, de a kulcsDISZTRIBUCIO nem az ellenorzesrol szol. Arrol beszelunk meg mindig, hogy inband nem oldhato meg a biztonsagos kulcsdisztribucio, pont mert az identitast csak ellenorizni tudod in-band, de az elleorzes alapjat out-of-band KELL megkapnod. Erted mar? Senkit nem erdekel az identitas ellenorzese in-band, mert nem ez a problema.

Nem kell out-of-band megkapnom, csak általános célra ez az elterjedt.

Fordítsunk ki egy megszokott eseménysort: Valakit az interneten ismertem meg, akivel szemben bizalmam alakult ki. Őt pl. a GPG kulcsa alapján folyamatosan, biztonságosan, mindenféle out-of-band információ nélkül azonosítani tudom, végig. Sőt, ha személyesen találkozom vele, akkor kell "out-of-band" digitálisan azonosítanom.

> hogy mit ismersz el biztonságosnak
> teljesen érdektelen hogy egy identitás mögött ki áll
> lehet úgy kialakítani a biztonság fogalmát
> úgy definiálod a biztonságot
> attól függ, hogy mit tekintesz biztonságnak
> szőrözhetünk az in-band/out-of-band definícióján

Fejezd már be.

1. Beregisztrálom a googlewallet.us domaint - éppen szabad, 0.71 GBP az első évre a namecheapen
2. Ráfizetek plusz kb másfél fontot egy évre a privát regisztrációért - vagy hazudok, és az ingyen van
3. Csináltatok egy domain-validated SSL tanúsítványt, ez újabb 5 GBP. Vagy ha nem akarom túlcifrázni, akkor certbot, és ingyen volt.
4. Elkezdem spammelni a gmailes tartományt (ti. gyakorlatilag mindenki gmailt használ aki ilyeneknek amúgy is bedőlne, plusz jó eséllyel ott lesz a legsűrűbb a google wallet penetráció
4a. Az emailben felszólítom őket, hogy a fraud detection miatt letiltottuk az accountot, újra hozzá kell adni a kártyát
4b. Az emailbe azt is beleírom, hogy mivel gyakori az adathalászat, ezért _mindenképpen_ bizonyosodjanak meg arról, hogy a domain névben benne van hogy google wallet, meg hogy zöld a lakat meg ha valaki extra paranoid, akkor még a fingerprintet is összenézzük
5. Ha egy nyomi bedől, akkor már vissza is termeltük a költségeket
6. ...
7. PROFIT

Jó, de ennek mi köze a https biztonságosságához? A PKI rendszer ugye közbeékelődés ellen véd, ami itt nem történt.

Hogy egy kötelező hupos autós hasonlatot hozzak: Az autók sem biztonságosak, mert a légzsák nem véd meg az ellen, hogy a benzinkútnál átverjenek az üzemanyag árával. :-)

A támadások fő iránya nem a https - pont azért, mert az relatív biztonságos - hanem például adathalászat. Ez ellen más védelem van, ami sokkal gyengébb.

A Trustware eset egy visszaélés. A jelenlegi PKI, https esetében csakis MITM ellen véd, lásd domain-validáció. Nem véletlenül rejtik el a böngészők a CA tulajdonos adatait. Az OV/EV cert más kérdés az az identitásért is felelne, ez EV esetén még valamelyest működik is.

A PKI egy technológia, a bizalom átadására, semmi több.

A MITM ellen maga az aszimmetrikus titkositas ved: van egy kulcsparod, meg a masik felnek is, es akarki, aki utkozben elkapja a kulcspar nyilvanos felet, nem tud vele mit kezdeni. Ez ved a MITM ellen. Barki lehallgathatja a csatornat, nem tud bele uzenetet kuldeni, ha csak a publikus kulcsokat ismeri, nem tud megszemelyesiteni senkit, mert a publikus kulcsbol a privat kulcsot eloallitani jelenleg lehetetlen. Ez a MITM elleni vedelem: aki lehallgatja a csatornat, nem tudja megszemelyesiteni egyik felet sem a lehallgatas eredmenye altal.
Szerintem te nem vagy tisztaban azzal, mi a MITM.

Az mar mas kerdes, hogy valoban azzal kommunikalsz-e, akivel akarsz, azaz hogy a publikus kulcs, amit megkaptal, az valoban ahhoz az felhez tartozik-e. Ez a kulcsidentitas problema (ami valojaban a kulcsdisztribucios problema), amit a PKI oldana meg

A PKI azt a problemat probalja megoldani, hogy az XYZ kulcs, az valoban ahhoz a felhez tartozik, aki allitja magarol.
Peldaul, ha felepited a kapcsolatot az XYZ fellel, majd o elkuldi neked a publikus kulcsat in-band, akkor ellenorizni tudod, hogy te az out-of-band megkapott informacio (az OS-be, bongeszobe, Java keystoreba, whatever telepitett CA certek azok out-of-band info, haho!) alapjan elhiszed, hogy valoban XYZ publikus kulcsa az, amit megkaptal. Erre valo a PKI.

Kicserélni nem tudja a kulcsot, anélkül, hogy te azt észre ne vennéd.

Hiszen alapvető az aszimmetrikus kulcsú kommunikációnál, hogy a kommunikáció megléte ELŐTT cseréljük ki a kulcsokat, és nem közben, in-band. Pont azért, mert az in-band kulcscserét nem lehet teljesen biztonságosan megtenni az identitás hiánya miatt.
Egy kicsit lehet fokozni a biztonságon, pont a PKI használatával, amikor is egy külső fél garantálja a kulcs identitását.

( traktor | 2017. 02. 28., k – 09:44 )

Direkt a hup miatt raktam fel a HTTPS Everywhere-t :) Na, jo, mondjuk inkabb, hogy itt tetszett meg. Szerintem mar nincs messze amikor a bongeszokben is a https lesz a default (martmint ha beirod, hogy example.com, akkor a https://example.com-on fog eloszor alapbol probalkozni).

( hzsolt94 v | 2017. 02. 28., k – 12:57 )

Azért azt érdemes tudni, hogy a HTTPS Everywhere legfontosabb funkciója nem az, hogy átirányít a https verzióra, hanem hogy megvéd a downgrade-attack jellegű támadásoktól.

Ez szerver oldalon is kérhető lenne - kiegészítő nélkül -, de ehhez nem elég simán az átirányítást beállítani, hanem HSTS fejlécet is kellene küldeni, vagy a HSTS preload listába feliratkozni. Ezt nagyon kevesen teszik meg, azok közül is, akik egyébként SSL-re irányítanak.