A Chrome következő verziója a HTTP-n kiszolgált jelszó- és bankkártya adatbekérő oldalakat nem biztonságosnak jelöli már

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

Google Chrome HTTPS figyelmeztetés

A Google elkezdte kiértesíteni a webmestereket arról, hogy 2017. januárjától, az 56-os verziótól kezdve, a Chrome böngésző nem biztonságosnak jelöli azokat az oldalakat, amelyek jelszavakat és/vagy bankkártya adatokat kérnek be HTTP-n keresztül. A Google az általa kiküldött levélben példákat is mutat azokra az oldalakra, amelyek januártól figyelmeztetést fognak a böngészőben kiváltani.

A Google nem fog itt megállni, mert hosszútávú terve az, hogy az összes, nem HTTPS-en keresztül kiszolgált oldalt idővel nem biztonságosnak jelöli majd.

Részletek itt.

( uid_15480 v | 2016. 12. 29., cs – 14:58 )

Akkor epp itt az ideje a HTTPS redirectet bekapcsolni ;D

Udv.

( bodobacs | 2016. 12. 29., cs – 15:11 )

Egy sima tájékoztató jellegű oldalra miért kell ezt ráerőltetni?

( Chain-Q v | 2016. 12. 29., cs – 15:26 )

A Google nem fog itt megállni, mert hosszútávú terve az, hogy az összes, nem HTTPS-en keresztül kiszolgált oldalt idővel nem biztonságosnak jelöli majd.

És ennek az az értelme hogy? Azon kívül, hogy pl. az összes caching proxit értelmetlenné teszi, vagy legalabbis jelentősen megbonyolítja (pl. rendezvényszervezéskor, fos uplinkkel ez még mindig fontos, nekem ez usecase), meg felkúrja egy mezei kőstatikus, csak publikus infókat tartalmazó HTTP oldal kiszolgálásának a hardverigényét is az egekbe.

De a Google cloudba nagyon secure módon tudod majd feltölteni az adataid, mielőtt az összes titkosszolgálat lebackupolja direktben onnan. Hát nem kényelmes? Nem kell vesződni lehallgatással meg MITM-mel meg ilyenekkel. Remek lesz.

(Ps: maximálisan a privacy meg a titkosítás mellett vagyok. De úgy érzem túltolják a biciklit már megint, és ráadásul nem is a jó irányba.)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Cache-elni tud am a bongeszo is, dinamikus tartalmon meg a proxy sem segit. A titkositas pedig nagyjabol 2% plusz load-ot jelent a CPU-nak, szoval ezeket a 90-es evekbol szarmazo tevhiteket ideje volna mar levetkozni. Pontosan az ilyen hisztik miatt tolja ezt a Google, mert elege van belole, hogy folyamat csak a hummoges megy, hogy jaaaj jo lenne, de... nincs egy vagyonom cert-re (Let's Encrypt = free, de egy Comodo cert is kemeny 9 dollar evente), nincs ra 256 magos Xeon-om (+2%, mint lattuk), tiltva van a HTTPS a cegnel (miert?!) esatobbi. 20 eves technologiarol beszelunk. Oldjatok meg, parszazmillio site-nak mar sikerult.

Amugy pont az ilyen elhanyagolhato pluszterheles/koltseg miatt nincs az egvilagon semmi ertelme betitkositani 100 oldalt, masik 17-et meg nem. Minek? Konkretan tobb melo (es hibalehetoseg), mint 100%-ban TLS-en tolni.

Blue Mobile egyebkent 2500-ert ad neked 3GB mobilnetet, csereld le a kabelest, ha ennyire szornyu az eleresed. Vagy ne csereld, csak akkor ne bubozzal.

Nem igazan lattom fos uplink mogott ulo 100-1000 emberen hogy segit a bongeszo cacheles.
Az sem hogy a keycdn hardwares titkositasa milyen szuper cool, ha az en klienseimnek nincs olyanja. Amugy a titkositas csak egy resze a dolognak, mennyire gyors a decrypt ?
Vagy hogy elfelejtik hogy nagy latency-s kapcsolatokon nagyon lassu tud lenni a https.
En rengetegszer hasznalok tcpdump-ot mindenfele debug-ra, annak nagyjabol annyi a https kikenyszeritesevel .

A legnagyobb gond hogy nem old meg semmit.
Pl rengetegszer talalkozzok olyan esetel hogy email cim jelszavat felhasznalva spamet kuldennek at a szervereken. Ezekben az esetekben kb semmit nem segit ha a POP3-at/IMAP-ot POP3S/IMAPS-ra kenyszeritted mivel a jelszavakat nem middle man modszerrel szerzik meg. Hanem a user+jelszot egy kliens oldalu virus gyujti be registry-bol, lementett jelszofile-bol/akarhonnan, egy kisebb szazalekban pedig a user '123456'-ot hasznal(t) jelszonak .
Https-el is igy vagyok, mindenki azt hiszi eljon a Kanaan ha csak https lesz, ja hogyne . Egyeduli dolog ami valtozik hogy nehezebb lesz debugolni, es a nem gyakori esetek/konfiguriciok megszivjak.

"Tiltva van a https a cégnél - miért?" Hint: Például DLP. Meg elég kevés olyan tűzfal (meg kapcsolódó hálózati határvédelmi politika/szabályzat) van, ami képes átcsomagolni az áthaladó https kapcsolatokat. Enélkül meg gyakorlatilag esélytelen szűrni a forgalmat, legfeljebb ip alapján, de az meg (lásd az Office 365-höz engedélyezendő forgalmak listáját és a kitételt, miszerint proxy nélkül, direktben kell) inkább gáz, mint nem...

ezt mar egyszer ateltuk a sajat tanusitvanyokkal. Volt olyan bongeszo kiadas ami nem engedett tovabb a warning oldalan.

Szoval nyugodj meg, fog ez meg durvulni... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( cadmagician | 2016. 12. 29., cs – 18:03 )

Ugy kell az mint tanyara a villany

------------------------
Jézus reset téged

( dcsaba v | 2016. 12. 29., cs – 23:44 )

LOL cimke...
HATALMAS betűkkel: Az oldal nem biztonságos, stb...
Az átlag user nem fog eljutni addig félelmében, hogy az apró betűs résznél a lap alján értelmezze az undorító google beszólást: tudomásul veszem, hogy az oldal nem biztonságos, megerősítem a kivételt stb...
Az SSL certek jól fognak fogyni és a php deveknek is lesz most melójuk.

LOAD "http://digx.hu",8,1

( persicsb | 2016. 12. 30., p – 12:14 )

"összes, nem HTTPS-en keresztül kiszolgált oldalt idővel nem biztonságosnak jelöli majd. +

A HTTPS megléte önmagában még semmilyen biztonságot, legfeljebb valamilyen szintű titkosságot jelent csak. False sense of security az egész.

A nem self-signed certet használó SSL-es biztonságosabb, mint a plain text (a self signed ennél csak egy paraszthajszállal jobb...). A valid és megbízható azonosítást követően kiadott SSL-es cert biztonságosabb, mint a "ha a postmaster postafiókjához vagy a dns-hez hozzáférsz, akkor elhisszük, hogy jogod van adott domainre certet igényelni" alapon kiadott cert.

( Zs | 2016. 12. 30., p – 15:00 )

A cél nemes - a módszer vitatható.
Mottó: a pokolba vezető út is jó szándékkal van kikövezve.
Egyébként meg nem kötelező Chrome-ot használni...

( leho | 2016. 12. 31., szo – 09:14 )

Nagyon rendes a Google hogy már megint atyáskodni próbál a világ felett, de akkor legyen kedves adni hozzá ingyen cert-et, különben elég büdös a dolog. Kíváncsi vagyok, pl hány étteremtulajdonos fog fizetni cert-ért, vagy akárcsak megérteni a probléma lényegét, amikor majd elkezd apadni a webes forgalom, mert a látogatókat riogatja a böngésző, hogy nem biztonságos az oldal. Értem én, persze, hogy az itt elkapott jelszót máshol felhasználhatják, mert az emberek nagy része mindenhová ugyanazt a jelszót használja, de az meg egyrészt PEBKAC, másrészt meg beleillik abba a vitába, ami a jelszavas azonosítás elmaradottságáról szól mostanában.

Évek óta hozzá lehet jutni ingyen tanúsítványhoz. Illetve az évi 3500 forint / év sem hiszem, hogy túl sok lenne azért, hogy biztonságosabban kezelje az adatokat, plusz egy kis SEO-ért (értsd: amelyiknek lesz, annak a szarát a Google előbbre fogja sorolni).

Lekommunikálás kérdése. Nem azt kell mondani az étterem tulajdonosnak, hogy ha nem vesz tanúsítványt, akkor hátrébb lesz, hanem azt, hogy ha vesz (vagy csináltat valakivel ingyenest - ami neki feltehetően azért pénzbe kerül, mert a fasz se dolgozik neki ingyen), akkor _előrébb_ lesz, mint a hülye konkurencia.

Ennyi.

--
trey @ gépház

( T_chris | 2016. 12. 31., szo – 13:11 )

Ez jó lesz...
A Google nem fog itt megállni, mert hosszútávú terve az, hogy az összes, nem HTTPS-en keresztül kiszolgált oldalt idővel nem biztonságosnak jelöli majd.
Vannak ezek a hordozható sim kártyás wifi megosztó lomok.
Ezeknél van olyan, hogy ha egy eszközzel rácsatlakoztál akkor meg kell nyitnod egy weboldalt. Tökmindegy milyet, csak http legyen. :)
- - - - - - - - - - -
"A fejlesztők és a Jóisten versenyben vannak. Az előbbiek egyre hülyebiztosabb szerkezeteket csinálnak, a Jóisten meg egyre hülyébb embereket. És hát a Jóisten áll nyerésre." By:nalaca001 valahol máshol

Hollandiában/Belgiumban is megy ez a móka, pl az itteni "BKV" utánzatokon is. Az arriva minden buszán van free wifi, jól is működik, de ott is http kell a bejelentkezéshez, mert https-en is hajlandó lenne dolgozni, de ott jön a figyelmeztetés, hogy nem biztosnágos az oldal. (pl ráfrissítek egy https://google.com címre bejelentkezéshez, és figyelmeztet, hogy nem biztonságos a cert, utána meg bejön az arrivás bejelentkező lap, persze http-n :) )