ugrás a tartalomhoz

Deprecating Non-Secure HTTP

Hidvégi Gábor · 2015. Május. 6. (Sze), 14.05
A Mozilla fokozatosan kivezetné a nem biztonságos HTTP támogatást
 ■
1

Cache

vbence · 2015. Május. 6. (Sze), 16.02
Gyorsan nyomtam egy CTRL+F -et, hogy szerepel-e a "cache" szó a szövegben. Nem szerepel.
2

Cache?

Poetro · 2015. Május. 6. (Sze), 16.05
És a cache miért is szerepelne benne?
3

Érvelés

vbence · 2015. Május. 6. (Sze), 16.11
Gondoltam van benne valamilyen szintű érvelés; potenciális ellenérvek cáfolása. Érdekelt hogyan védik meg a döntést, ami lehetlenné teszi assetek cache-elését.
4

Irónia

Hidvégi Gábor · 2015. Május. 6. (Sze), 16.20
Ha ilyen mértékben fejlődnek a hardverek és az internetelérés sebessége, felesleges bármit is kasba rakni.
5

Cloudflare és társai tudnak

MadBence · 2015. Május. 7. (Cs), 13.48
Cloudflare és társai tudnak HTTPS-t, és az, hogy tetszőleges szerver belenyúlhat a HTTP kérésbe, kifejezetten rossz: gyorsítótárazás helyett tipikusan inkább módosítják a HTML-t, és jobb esetben reklámokat injektálnak, rosszabb esetben DDOS támadást indítanak a GitHub ellen.
6

Neeem

vbence · 2015. Május. 7. (Cs), 16.27
Aki ilyen kaliberrel rosszalkodni akar azt ezután sem állítja meg senki. A Comcast uganolyan gonosz marad, és Kína is bármit küldhet bármilyen IP címről (ha eddig nem tiltották le, nyilván ezután sem fogják).

A http könnyen kibővíthető lenne digitális aláírással, hogy a belenyúlás elkerülhető legyen, ha erre valós igény van.

Nem azt mondom, hogy nincs szükség az SSL fölötti HTTP-re, de ha építek egy szolgáltatást miért ne dönthetném el, hogy mi a védeni való tartalom, és mi az általánosan publikus.

A CloudFlare és társai csak a tartalomszolgáltató erőforrásait védik, nem a fogyasztókét.
7

Ha a szolgáltató nem lát bele

MadBence · 2015. Május. 7. (Cs), 19.59
Ha a szolgáltató nem lát bele a tartalomba, nem tud belepiszkálni sem. Egyébként a HTTPS biztosítja az adatok integritását is, szóval nem értem miért kéne feltalálni a melegvizet.
A CloudFlare pedig igenis megoldás a problémára: az oldalad erőforrásait a userhez közeli szerverről fogja kiszolgálni, ezáltal gyorsabb lesz.
8

Sir Tificate

Gixx · 2015. Május. 15. (P), 21.18
Meglovagolva a hisztériát, gondoltam egyet, és megnéztem, hogy nekem, mint a rendszergazdai dolgokban abszolút amatőrnek mennyi pénzbe, időbe, és erőfeszítésbe kerül a weboldalamat HTTPS mögé dugni.

Tulajdonképpen nem is olyan sokba.

Pénzbe: semmibe
Időbe: 1-2 óra
Erőfeszítésbe: kicsit kellett gondolkodni

De kezdjük az elején. Google-ban rákerestem arra, hogy "Free SSL Certificate", és az első találatra ráböktem. Bár az oldal eléggé múlt századi, de azért frissülget. Jó lesz.

Aztán mivel nem akartam tudatlanul is elrontani valamit, a Google-ban új keresést indítottam: "StartSSL Tutorial". Az első találat megint csak jónak bizonyult.

A cikk nem túl friss, de nagyrészt még aktuális, ami le van benne írva. Szépen lassan, lépésről lépésre követve a leírást - az eltéréseknél kicsit gondolkodva és kitalálva a megoldást - végigvittem a folyamatot, és lett is egy szép, hiteles SSL tanusítványom. A leghosszabb időt az vette igénybe, amíg megtaláltam, hogyan tudok a domainemhez a hitelesítéshez szükséges, a megadott email címek közül egyet fabrikálni. Így tettem szert egy postmaster##kukac##gixx-web.com-ra...

Aztán beállítottam az Apache-ot is és már csak tesztelni kellett. Elsőre nem ment, mert bár a port nyitva volt, de a tűzfalon le volt tiltva a 443-as kapcsolódás.

Miután az is engedélyezve lett, Voilá: https://www.gixx-web.com

Előnyök:
- gyorsan megvan
- rengeteg tutorial van a neten
- ingyenes

Hátrányok:
- az ingyenes verzió nem támogatja az aldomaineket
9

Mindent egybe?

Hidvégi Gábor · 2015. Május. 16. (Szo), 10.02
Ez az egész megint csak arra mutat rá, hogy a HTML alapú, mindent egybe, statikus oldalakra épülő web csak problémát okoz. Miért kell az egész oldalt letitkosítani, ha felhasználói adatok, sütemények is szükségesek hozzá? Miért nem lehet különválasztani a titkosítandó adatokat a titkosítatlanoktól?

Nyilvánvalóan vannak olyan oldalak, amelyeknél a megtekintett tartalom is érzékeny adatnak számít, ilyenkor mehet egyben az egész, de ha például egy átlag webshopot böngészek, elég lenne a bejelentkezési adataimat és a süteményemet rejtjelezni.
10

A HTTPS feladata nem csak a

MadBence · 2015. Május. 16. (Szo), 13.35
A HTTPS feladata nem csak a titkosítás, hanem a hitelesítés is, annak biztosítása, hogy ami a hálózaton érkezik az az, amit a másik fél elküldött.
12

Ehhez elég lenne a fejléceket

Hidvégi Gábor · 2015. Május. 16. (Szo), 20.19
Ehhez elég lenne a fejléceket titkosítani, valamint elküldeni egy ellenőrző összeget, ami alapján a kliens eldönthetné, hogy az adott adatrész hiteles-e.
14

Adat

Poetro · 2015. Május. 16. (Szo), 20.38
Az adatok nem csak a fejlécben, hanem a body-ban is közlekednek POST kérés és GET válasz esetén. Gondolom nem feltétlen szeretnéd tudatni a jelszavadat illetve a bankszámlád adatait az egész világgal.
15

Félreérted

Hidvégi Gábor · 2015. Május. 16. (Szo), 21.05
Lásd 9-es hozzászólás.
16

ha például egy átlag

Poetro · 2015. Május. 16. (Szo), 21.38
ha például egy átlag webshopot böngészek, elég lenne a bejelentkezési adataimat és a süteményemet rejtjelezni

Számomra a kosár tartalma, és hogy miket nézek is érzékeny információ.
17

Gondolom, akkor tiltod a

Hidvégi Gábor · 2015. Május. 17. (V), 01.42
Gondolom, akkor tiltod a Facebook és a Google Analytics scriptjeit is, ugye? A kosár jogos, azt kifelejtettem.
11

Miért?

Poetro · 2015. Május. 16. (Szo), 17.09
Miért kellene szétválasztani? Ha nem tudod, hol kell keresni az érzékeny információt az sokkal jobb az elrejtése szempontjából. Ha minden titkosítunk és hitelesítünk, akkor a támadó nem tudja, melyik részben van elrejtve.
13

Ez nekem eléggé a security by

Hidvégi Gábor · 2015. Május. 16. (Szo), 20.26
Ez nekem eléggé a security by obscurity esetének tűnik. Elvileg egy erős titkosítás alkalmazása elég kéne hogy legyen, függetlenül az adatmennyiségtől. Egyébként meg nem tök mindegy, hogy 100 bájtnyi vagy 20 kilobájtnyi adatot fejtesz vissza? Ha a kulcs megvan, lényegtelen az adatok mennyisége, mert ott van benne az a száz bájt értékes információ.

Ha belegondolsz, amikor puttyal be SSH-zol egy szerverre, és egyesével ütögeted a billentyűket, azok is valahogy titkosítva vannak, kis adatmennyiség, és mégis elég megbízható a protokoll, mert sokan ezt használják, legfeljebb nem az alapértelmezett porton.

Egy X termék leírását teljesen felesleges titkosítani, nem hordoz plusz információt, emiatt érdemes szétválasztani, hisz a titkosítás erőforrást igényel mindkét fél részéről.
18

Más

Hidvégi Gábor · 2015. Május. 18. (H), 08.21
Elképzelhető, hogy más van a háttérben, lásd a hwsw cikkét, Van védelem bekezdés.