Protokollag 8-10 duer ikke
Det tog ikke lang tid efter ISO modellens syv protokollag før der med galgenhumor var tilføjet et par lag mere: 8=financial, 9=political.
Senere har Bruce Schneier og andre argumenteret for at der faktisk er 3 legitime lag mere: 8=user, 9=org, 10=legal
I den abstrakte analyser af protokoller er det måske ikke nogen dårlig forbedring af modellen, men i praksis duer lag 8-10 ikke.
Jeg er pt. med på sidelinien i HTTP/2.0 standardiseringen, jeg har ikke tid & penge og formodentlig slet ikke temperament til at deltage i IETF clusterfucks, men jeg er med på mailing listen og gør hvad jeg kan i rollen som havkatten i hyttefadet når jeg har tid.
Man skulle tro at vi efterhånden var blevet ret gode til protokol design, men det lader ikke til at være tilfældet: Der er stadig folk der tror at de bestemmer over lag 8-10.
I HTTP/2.0 sammenhæng er der seriøst folk der insisterer på at alt skal være krypteret, ellers vil de ikke være med.
Det er selvfølgelig nobelt og ædelt at kære sig om de stakkels brugeres privatliv osv. men spørgsmålt om "du og hvilken hær ?" er altid relevant.
Der findes steder hvor kryptering simpelthen er uønsket og det er slet ikke de steder de fleste tror.
Det er f.eks meget normalt at fængselsindsatte ikke har ret til nogen form for privatliv, med mindre det er deres advokat eller præst de taler om. (Jeg skal ærligt indrømme at jeg ikke kender de præcise forhold i danske fængsler, men jeg formoder at indsatte bandeledere ikke uden videre kan bruge kryptering til at køre netværket videre udenfor.)
Børsmæglere er "on the record" deres telefoner bliver optaget, deres emails bliver arkiveret og ofte er der "Network Flight Recorders" til at optage al trafikken, pakke for pakke, til evt. senere bevisførelse, en metoder der også bruges i mange safety-of-life systemer til opklaring og udredning.
Listen er lang og indeholder en masse situationer hvor legal magtanvendelse finder sted: Børn i skoler, umyndiggjorte mentale patienter, ansættelsesforhold.
Hvis man gør kryptering til et krav i HTTP/2.0 kan HTTP/2.0 ikke bruges alle disse steder.
QED: Forsøg på at standardisere lag8-10 skader protokollens ubredelse.
Næste spørgsmål er så om det i det hele taget virker efter hensigten hvis man dette til trods prøver ?
Svaret er nej, meget klart nej.
Vi har HTTPS idag og vi har talrige eksempler på at lande, firmaer, spioner og kriminelle fifler rundt med rod-certifikater for at mislede, forvanske og aflytte beskyttede forbindelser.
Når det er vores eget lands efterretningstjeneste eller politi der gør det, er det en fuld legitim anvendelse af statens magt under demokratisk kontrol og alt det der bavl (se også : Wambergudvalget), men hvis det er et land vi ikke er venner med er det pludselig et brud på fundamentale menneskerettigheder osv.
Hvis man tror at en RFC's tekst har nogen indflydelse på det niveau af lag 10, så er man ikke tør bag ørene.
Men sikkerheden bliver da bedre, ikke ?
Det er faktisk ikke givet.
Når man ikke efterlader plads i protokollen til legitim magtanvendelse, bliver protokollen voldtaget indtil den legitime magtanvendelse kan finde sted, ofte med meget mere drastiske reduktioner i sikkerhed end der er nødvendige for magtanvendelsen.
Det er f.eks meget almindeligt simpelhen at blokere totalt for HTTPS, for at sikre at man kan analysere/filtrere/aflytte trafikken, hvilket betyder a trafikken er ubeskyttet hele vejen fra ende til ende.
Hvis protokollen indeholdt en mulighed for at have HTTPS frem til proxy'en og en anden HTTPS session fra proxyen til serveren, ville brugeren have bedre beskyttelse og proxyens legitime behov for at se indholdet ville være opfyldt.
Det man kan gøre og bør gøre, er at designe maksimal gennemsigtighed ind i protokollen: Hvis nogen kan se min HTTPS traffik skal jeg som bruger kunne vide det, protokollen bør sige til mig: "Du har sikkerhed, men $CORPPROXY kan se og modificere dine data."
Så kan brugeren, informeret om de faktiske forhold, overveje om det er et sted hun ønsker at arbejde, om det er en regering han ønsker at stemme på eller osv.
"Deliver tools, not policies"
phk
Om Poul-Henning KampPoul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.
Follow @bsdphkKommentarer (10)
Jeg må da sige at jeg synes muligheden for certifikatløs kryptering er en ganske grel mangel i HTTP 1.1. Der er mange sider som godt lige kunne bruge krypteret login, men som ikke har det fordi det kræver en del ekstra besvær. Muligheden for at kryptere uden at browseren går i paranoid sikkerhedsmode ville være rigtig kærkommen. Men jeg vil give dig ret i at det er dumt at gøre kryptering obligatorisk.
Er der ellers i øvrigt noget interessant på tegnebrættet, hvad bliver killer featuren i HTTP 2.0?
-
1 -
0
Det er jo muligt at inspicere i HTTPs i dag, og brugerne ved godt at de opgiver en del af deres privacy ved anvendelse af virksomheders internetforbindelser. Som jeg ser det, er det ikke et spørgsmål om protokoldesign men tillid til den organisationelle struktur i samfundet og den rimelige forventning til, at statsapparatet faktisk opererer med en passende grad af integritet.
Selvfølgelig skal man have muligheden for at køre klartekst i sin protokol. Det er heller ikke et sikkerhedsspørgsmål, men et spørgsmål om sund fornuft; hvis jeg ikke ønsker overhead, hvorfor skal jeg så være bundet til at have det?
SSL og TLS er blevet ændret talrige gange siden 1996 og derfor kan man da også have en forventning om, at adskillelsen af krypto og transport/kommunikationsprotokoller tjener alles formål; der er intet der tyder på at kryptoanalytikerne stopper deres arbejde i fremtiden :)
-
1
-
0
Hvorfor er der overhovedet brug for en ny protokol? Hvad er der i vejen med HTTP/1.1?
-
2
-
1
https://www.varnish-cache.org/docs/trunk/phk/http20.html giver vel en god forklaring
-
2
-
0
Det er nogle gode pointer Poul-Henning bringer, men det første problem jeg kan se, er at udvikling af applikationer som bruger en protokol, man ikke kan inspicere, bliver meget tungt. Det er ikke ofte at jeg har startet wireshark for at inspicere en http-forespørgsel, men de få gange jeg har gjort det, har jeg sparet flere dages frustrerende fejlsøgning.
-
3
-
0
Da ca. 11 ud af 10 applikationer ikke tjekker ret meget omkring SSL certifikater, så kan en udvikler ofte bruge en proxy som Fiddler, der med sit eget root cert (som man skal stole på) kan udstede fake certs som klienten stoler på. Så kan man i Fiddler inspicere trafikken.
Wireshark kan også (hvis man har private key) dekryptere bl.a. SSL forbindelser. Så det er ikke det største problem.
Jeg forstår godt at nogle vil have krav om kryptering, for at udbrede det.
SSL har vist sig broken i et eller omfang det sidste år (indbrud i nøglecentre, dårlig certifikathåndtering hos MS ...), så hvilken kryptering der skal anvendes ved jeg ikke. Det var også MS som ikke tillod at man slettede den tunesiske efterrretningstjenestes root cert, eller rettere, de installerede den automatisk igen når man besøgte en side med et certifikat udsted af dem. SSL er ikke særligt sikkert, uden bedre klientvalidering af cert.
Kryptering af hvadsomhelst giver ingen mening hvis du spørger mig. Hvorfor skal der være krav om kryptering når jeg læser JP.DK ?
-
0
-
0
Det eneste jeg for alvor savner i HTTP 1.1 er automatisk load balancing og failover support. Klienterne bør have support for at prøve en anden IP-adresse hvis den primære ikke svarer.
Har de husket den slags funktioner i HTTP 2.0 ?
-
0
-
0
Der er ikke meget protokollen kan gøre ved det hvis serveren ikke svarer. Til gengæld tillader DNS systemet flere A records per subdomæne, hvilket giver en load balancing og failover effekt. Men man kunne da godt forestille sig en protokol som lægger nogle bedre styringsmuligheder oven på dette system.
-
0
-
0
Med lidt rimelighed kan man godt sige at det er en del af protokollen, hvad man skal gøre hvis en server ikke svarer. Det er beskrevet i SMTP RFC 821 hvad der skal ske, når en mailserver ikke svarer. Jeg ønsker mig bare noget tilsvarende for HTTP.
RFC 6555 "Happy Eyeballs" beskriver en metode, som vil virke hvis man kan leve med at der kun kan være to noder, og at den ene node skal være IPv4 og den anden IPv6. Og vi antager at alle klienterne er dual-stack og har adgang til både IPv4 og IPv6.
Tag det med v4 og v6 ud af den RFC og du har et godt bud på hvordan HTTP-failover kunne virke.
-
0
-
0
Jeg vil være ked af hvis HTTP begynder at fungere som en slags substitut for routnings protokoller - de funktioner i mangler i denne forbindelse kan findes i LISP routnings protokollen som forhåbentligt begynder at vinde indpas, så slipper vi også for BGP ;P
-
0
-
0
Tilføj kommentar
