[Szerk]: Elnézést, ha félreérthető volt: nem működött hibásan a wget, csak a hibás fejrészt nyugtázta egy warning-gal.
- NevemTeve blogja
- A hozzászóláshoz be kell jelentkezni
- 677 megtekintés
Hozzászólások
Szerk: na most lehet, hogy ismét én vagyok a hülye. Úgy tűnik, hogy valaki olvasott valami brossúrát, miszerint ilyen Strict-Transport-Security nélkül nem működik a http, és beleerőltetett egy ilyen a fejrészbe. Ilyesmit vélek látni:
Strict-Transport-Security: 33444555; includeSubDomainsVagyis kimaradt a max-age= rész.
- A hozzászóláshoz be kell jelentkezni
És ilyenkor a kliesnek ezt ki is kell hagynia:
The UA MUST ignore any STS header fields not conforming to the
grammar specified in Section 6.1 ("Strict-Transport-Security HTTP
Response Header Field").- A hozzászóláshoz be kell jelentkezni
A parse_strict_transport_security else ágába futsz bele, de ez csak HSTS esetben hívódik meg, lásd még az opt.hsts feltételvizsgálatát.
Az opt.hsts default true, tehát a megoldás: --no-hsts
Éljen a web túltitkosítása és az instabil implementációk erőltetése! :)
- A hozzászóláshoz be kell jelentkezni
Vagy inkább az RFC-t nem olvasó fejlesztő tákolmánya... Ez egy _hibás_ STS header, amit a wget-nek kutya kötelessége lenne ignorálni, mivel nem felel meg az RFC-ben leírt formátumnak.
- A hozzászóláshoz be kell jelentkezni
Igen, való igaz, hogy az implementációt megvalósító szélsőségesen idealista, fősodratú mérnök úr sem állt a helyzet magaslatán. De biztos volt ott is valaki, aki szakmailag™ megindokolta, hogy mennyivel szuperbiztonságosabb™ így a rendszer, hogy hibás header esetén nem csinál semmit (elszáll hibával). :)
A helyes működés egy --no-hsts default vagy egy optional hsts lenne, ahol elejt egy warningot hibás hsts esetén. Ehelyett az alapműködés a túltitkosítás erőltetése és az RFC szembeköpése lett.
- A hozzászóláshoz be kell jelentkezni
Az RFC az, ami alapján kódnak illetve a weboldalnak működnie kellene, ergo itt "két hülye egy pár" esete forog fenn: egy hülye, aki hibás header-t állított be, egy másik, ami meg ezzel nem tud mit kezdeni. Mindkét fél hibázott, az elvárt működést leíró szabályokat nem követi. Ez utóbbi (az RFC) összeállítója pont az ilyen hibás szerver oldali implementációkat kezelendő írta elő azt, hogy a hibás header-t el kell dobni. Ez egy döntés volt a részéről, mert lehetne az a mondás is, hogy hibás header esetén tcp resetet kéretik küldeni, és nem letölteni a tartalmat. Se. Mivel ez egy nem kötelező header, így annak hiánya, hibás tartalma nem szabad hogy befolyásolja az oldal működését (szabványos kliens esetén), így egyértelmű, hogy a hibás header eldobása és a művelet folytatása a helyes döntés - ez az, amit az rfc is előír.
- A hozzászóláshoz be kell jelentkezni