Http 2.0 krijgt standaard encryptie via https-uri's

Het http 2.0-protocol zal vrijwel zeker standaard encryptie geactiveerd hebben, maar er zijn meerdere mogelijkheden opgeworpen om uri's te beschrijven. De voorkeur lijkt uit te gaan naar het gebruik van https in de uri, omdat dit een reeds bekende verwijzing naar encryptie is.

Afgelopen zomer klonken er geluiden dat de http 2.0-specificatie versleuteling ook naast https moet kunnen aanbieden, waardoor versleutelde webpagina's ook via de protocol-identifier 'http' kunnen worden aangeroepen. Daarvoor zijn twee mogelijkheden voorgesteld: 'http'-uri's zonder serverauthenticatie, ook bekend als 'tls-relaxed', of een implementatie waar de server via een certificaat wordt gecontroleerd. Anderen stelden een implementatie voor waarbij http 2.0 alleen gebruikt kan worden bij adressen die beginnen met 'https://', waardoor uri's die beginnen met 'http://' uitsluitend voor http 1.x gebruikt worden.

Volgens een e-mail van voorzitter Mark Nottingham naar leden van de http working group blijkt echter uit een rondgang bij onder andere browserbouwers, logischerwijs nauw betrokken bij de totstandkoming van de standaard en sterke voorstanders van een breder encryptiegebruik, dat zij de voorkeur geven aan een implementatie met https. Hierdoor kunnen sites die http 2.0 met encryptie willen aanbieden dus uitsluitend uri's met https gebruiken.

Deze voorgestelde methode zou volgens Nottingham zonder wijzigingen aan de huidige protocolbeschrijving doorgevoerd kunnen worden. Browserbouwers zijn immers nog niet 'verplicht' om http 2.0 voor http-uri's te implementeren. Desondanks blijft het wel mogelijk om webservers content te laten serveren via http 2.0 en http-uri's, maar dan zal encryptie niet zijn ingeschakeld.

Nottingham noemt nog een aantal openstaande beveiligingskwesties die besproken moeten worden voordat de volledige http 2.0-specificatie als draft kan worden voorgesteld. Zo moeten er nog nieuwe p2p- cachingmogelijkheden worden besproken voor proxycaching en het al dan niet implementeren van veiliger tls-implementaties, zoals perfect forward secrecy.

Reacties (86)

Er zijn meer dan genoeg websites waar je geen encryptie nodig hebt.
Denk daarbij aan publieke website voor bedrijven of frontpage van tweakers of ....
Er zijn meer websites waar je het niet nodig hebt dan websites waar je het wel nodig hebt.
Dus standaard geactiveerd is niet echt nodig.
Het zal eerder met knullige IT-ers te maken hebben:
vb: nieuws: Huawei zet privégegevens klanten cashback-actie onbeschermd online

Er zijn meer dan genoeg websites waar je geen encryptie nodig hebt.

Ik heb overal encryptie nodig.

Omdat het anderen (mijn provider, packetsniffers, de NSA, de AIVD, de ex-collegae van Edward Snowden, enzovoort) gewoon geen reet aangaat wat ik bezoek.

Wát je bezoekt (het HTTP request) valt niet onder de encryptie, de content dan weer wel.

Toch wel, alleen het IP adres niet. Soms kan daaruit de domeinnaam worden afgeleid, maar de URI sowieso niet, die zit in de HTTP header en wordt gewoon mee geëncrypt.

Bij SNI wordt de hostname van de website ook verstuurd voor de encryptie, zodat de server alvast en context switch kan doen naar de juiste virtualhost en bijhorend certificaat.

Ja, maar als een website een dedicated IP heeft (wat niet nodig is bij SNI, maar genoeg sites c.q. dedicated servers die dat toch hebben) weten 'ze' daardoor alsnog naar welke website je connect (eventueel op subdomeinen na dan).

Jouw mening. Met het recente nieuws over de afluisterpraktijken van de NSA en andere overheden (ook Nederland), denk ik dat encryptie voor alles erg hard nodig is.

Bijvoorbeeld: GoT komt op Schiphol en gaat door de douane...
Douanier: "Zo meneertje, u leest wel erg vaak wikipedia artikelen over chemie. Daar kunt u bommen mee maken. Wij vinden dat wel verdacht. Komt u even mee?"
GoT: "Maar..."
Douanier: "Alles wat u zegt kan tegen u gebruikt worden."
GoT: "Eh..."
6 uur later..
Douanier: "We hebben het even gecheckt en we kunnen verder niks verdachts vinden. Sorry dat u uw vlucht heb gemist. Tot ziens."

Dus, daarom.

Al mijn mobiel telefoonverkeer is ook versleuteld, of het nou met m'n moeder is of met m'n bank. Waarom zouden we dan we dan voor het web wel sommige dingen minder veilig maken? Gewoon default alles over TLS, voor de zekerheid.

Een website wat totaal onbelangrijk is vb: http://www.kanariepiet.com/ kan je encryptie toepassen, maar dat is totaal overbodig.
Een website wat wel belangrijk is vb: https://www.abnamro.nl/nl/logon/identification.html is uiteraard van belang dat het wel encrypted is.
Of je webverkeer encrypted is of niet kan de IT-er (beheerder) instellen op de server.
Meestal zijn dit bekwame mensen, tenzij je prutsers aanneemt.

Dat is ook de reden waarom tegenwoordig WiFi routers al standaard WPA aan staat.
Bijna elke woning heeft er al 1 en wordt door een "12 jarige buurjochie" geconfigureerd.
Vroeger had je allemaal open WiFi netwerken, maar omdat WPA tegenwoordig aan staat heb je dat niet meer.
Er is alleen 1 verschil: Als je een server door een buurjochie laat configureren dan ben je als bedrijf wel heel verkeerd bezig.

Geloof me, een telefoongesprek met mijn moeder hoeft, net zoals www.kanariepiet.com, heus niet via encryptie. Toch is het fijn dat het standaard gebeurt. Gewoon zodat niemand er over hoeft na te denken en er dus ook geen valse verwachtingen ontstaan over wat er wel niet af te luisteren valt.

Het is even een lastige transitiefase (niet voor gebruikers overigens, alleen voor site beheerders) die wel een paar jaar gaat duren maar daarna de gewoonste zaak van de wereld is. Net als encryptie van je mobiele gesprek.

Is je argument serieus. Een website heeft geen encryptie nodig want de router doet dat wel? In dat geval, mooi. NSA, stap maar op want mijn router maakt het hele internet volledig veilig.

Omdat encryptie extra rekenkracht vergt zowel op server als client, zeg maar vooral voor de server. Waarom de it-beheerder geen keus laten. Bij veel publieke sites zoals wikipedia is dat toch helemaal niet nodig, en zeker als die volledig op donaties werken hebben zij zeker voordeel om alle rekenkracht (lees: kosten) te sparen!

Onzin. Het is verwaarloosbaar.

Zie dit bv.:
https://www.imperialviole.../25/overclocking-ssl.html

Oud artikel, er wordt vergleken met http tov tegenwoordig known broken ciphers (rc4), aes wordt als over bodig ingeschaald voor normaal gebruik. Moderne hardware mag dan wel crypto instructies hebben, maar nog lang niet alle hw is modern. Verder is SNI nog geen gemeen goed en heeft elk cert. dus z`n eiden ip nodig (ip6 nog steeds geen optie)

Soms is het gewoon tijd om te upgraden. De techniek houdt ons niet meer tegen. Iedereen is (of kan) inmiddels wel over naar een recente browser. Server software en OS'en zijn klaar voor SNI en IPv6.

Het enige wat ons tegen houdt is geld (geen business case), politiek (geen beslissing durven nemen) en psychologie ("ik wil geen verandering!").

Anyway, HTTP 2.0 is morgen nog niet ingevoerd. Dit gaat nog 3 tot 5 jaar duren voordat het een beetje gebruikt gaat worden. Ik mag hopen dat die andere zaken dan inmiddels wel op orde zijn.

Soms is het gewoon tijd om te upgraden.

Dát was het met IPVv6 tien jaar geleden ook al. En nog steeds is maar mondjesmaat toegepast. Ik draait het al tien jaar, en native heb ik het een jaar of twee geleden gekregen. Maar de techniek wordt tegengewerkt door een gebrek aan ondersteuning vanuit hardware partijen voor bijvoorbeeld firewalls, en software leveranciers. (Ook al is die software gebouwd op iets wat het perfect ondersteunt)

Als je als netwerkhardwareleverancier na 10 jaar nog geen IPv6-ondersteuning hebt in je apparaten, dan ben je een prutser. Dat spul moet je dan niet kopen.

Probleem is dat er vanuit klanten blijkbaar ook geen vraag naar is. Ik zie het met mijn ogen op m'n werk. We zijn een IT-achtig bedrijf en zowel onze systeembeheerder als onze developers hebben totaal geen benul van IPv6. Misschien als we zeggen dat het van Apple is en het spellen als iPv6 dat het dan wel aanslaat.

Je kunt trouwens altijd wel iets van hardware of software vinden dat niet met IPv6 werkt. Maar dat wil niet zeggen dat je het al niet kan gaan gebruiken. En als je het niet gebruikt, dan ga je er ook niet achter komen wat er niet werkt.

Als je als netwerkhardwareleverancier na 10 jaar nog geen IPv6-ondersteuning hebt in je apparaten, dan ben je een prutser. Dat spul moet je dan niet kopen.

Oh, die ondersteunt 't wel, omdat de leverancier gekozen is juist op die ondersteuning.

Maar als ik dan kijk dat de firewall ondersteuning in m'n VDSL router thuis beneden niveau is (het mag wel of niet, maar je kan geen ACL's bouwen). En de firewall van m'n synology NAS ook niet fatsoenlijk ondersteuning biedt voor subnet toegang * ( het kleinste blok in ipv6 is een /64, dus ruim 4 miljard adressen ), dan wordt het al snel duidelijk waarom er nog niet veel animo is. Er is wel ondersteuning, maar die is beneden het niveau wat we voor IPv4 hebben.


*) wel op ipv4 trouwens, daar kun je gewoon CIDR notatie gebruiken, maar als je dat met ipv6 adressen probeert weigert de interface dat.
Wat nogal een issue is, aangezien het hele thuisnetwerk toegang moet krijgen tot dat ding, maar de machine's random IP adressen pakken iedere <x> tijd. (een standaard feature van IPv6)

Leuk.
Maar vaak werkt de cache niet bij https (of enkel totdat het scherm wordt gesloten).

En waar ik nu werk, zit een proxy die het https verkeer via een eigen certificaat doorstuurt (die ik niet in mijn browser installeer ). Dat lijkt me ook niet lekker te gaan. Ik loop nu al te balen als sites als github en Google je standaard naar https doorsturen.
(Overigens; bij banken krijg je wel het juiste certificaat )

Alles standaard geëncrypteerd heeft toch geen enkel nadeel (tenzij je nsa heet misschien)?
Als het kan en het kost niks zie ik er absoluut geen enkel probleem in.

Het kost natuurlijk wel wat, die extra reken kracht kost energie en geld. Encryptie zal wel meer standaard gaan worden, perse nodig voor alles is het niet vind ik.

Maar als website maker zou ik het idioot vinden wanneer ik bepaalde paginas via http ga serveren en andere via https. Een website zou zich niets moeten aantrekken van dat protocol, en ik zie niet in waarom een serverbeheerder pagina x via http zou willen serveren en een andere via https. Het maakt het allemaal zoveel gecompliceerder. Dat data van een CDN niet versleuteld is tot daar aan toe ...

Jij vindt het niet nodig. Anderen misschien wel. Het kan ook zeker geen kwaad om wel encryptie te gebruiken. Waarom dan zo anti-ecnryptie?

Er zijn meer dan genoeg websites waar je geen encryptie nodig hebt.
Denk daarbij aan publieke website voor bedrijven of frontpage van tweakers of ....
Er zijn meer websites waar je het niet nodig hebt dan websites waar je het wel nodig hebt.
Dus standaard geactiveerd is niet echt nodig.
Het zal eerder met knullige IT-ers te maken hebben:
vb: nieuws: Huawei zet privégegevens klanten cashback-actie onbeschermd online

Dat heeft natuurlijk weinig te maken met zo'n actie als bij Huawei. Of daar versleuteld verkeer werd gebruikt of niet doet er totaal niet toe. Het gaat hier namelijk om end-to-end encryption, niet om dat die gegevens wel of niet versleuteld waren opgeslagen of wat dan ook.

Verder vind ik https nooit kwaad kunnen. Data mining is big business en hoe minder partijen erbij kunnen, hoe beter.

Een SSL certificaat kost tegenwoordig ook niks meer, de Class 1 dan.
Ik zou niet weten waarom websites geen SSL zouden aanbieden.

@-ETz-candyman: ik betaal 0 euro voor mijn certificaat bij StartSSL, en mijn domein kost ook niks: .cf. Het is dan ook een privé-site-je.

[Reactie gewijzigd door Soldaatje op 13 november 2013 18:24]

Een dedicated IP is ook een kost om rekening mee te houden...

Een dedicated IP is niet noodzakelijk dankzij SNI.

Maar dan moeten we wel even Windows XP 32-bit uitroeien, want die ondersteunt dat niet. (Daardoor Firefox ed ook niet)

Da's natuurlijk onzin. Het staat FireFox vrij om TCP pakketjes te interpreteren zoals ze dat zelf willen. Er is geen enkele goede reden om een webprotocol als SNI niet in de webbrowser te implementeren. Daarvoor is het tenslotte een webbrowser.

Da's natuurlijk onzin. Het staat FireFox vrij om TCP pakketjes te interpreteren zoals ze dat zelf willen. Er is geen enkele goede reden om een webprotocol als SNI niet in de webbrowser te implementeren. Daarvoor is het tenslotte een webbrowser.

Vrijwel alle browsers, inclusief Chrome, safari en Firefox gebruiken de crypto libraries van Windows zelf. De 32 bit SSL libraries van Windows XP ondersteunen SNI niet. En ze lijken geen van allen interesse te hebben een eigen implantatie te gaan bouwen. De enige uitzondering was dacht ik opera.

Ik heb nog een paar miljard IPv6-adresjes liggen. Je mag er wel een paar hebben. Gratis :-)

Maar even serieus. Als we nu allemaal IPv6 zouden gebruiken, was dit helemaal geen issue.

'Niks' zou ik het niet noemen, zolang er een (jaarlijkse) financiële impact is. Het blijft in mijn ogen fout dat je 'trust' moet kopen. De laatste jaren zijn er genoeg voorbeelden van CAs geweest die blijkbaar hun zaken (o.a. private keys) dan toch niet zo privaat hebben kunnen houden. Self-signed is tegenwoordig ook niet echt een optie voor publieke zaken aangezien de gemiddelde gebruiker bang is van dat rode streepje/waarschuwing.

Mee eens. Een certificaat is verder niks als een stapel random bits. Dat kost niks en is alles wat je nodig hebt voor encryptie. Het systeem van een handvol bedrijven dat voor CA speelt is kapot en vrijwel waardeloos. Hier moet iets beters voor komen en hopelijk wordt hier in het kader van HTTP 2.0 ook over nagedacht.

Volgens mij gaat het niet om de kosten van het certificaat maar om de extra server belasting voor de encryptie. Voor kleine sites maakt dat niet zoveel uit maar voor de Googles en Facebooks van deze wereld kan dat in de papieren lopen.

Het zullen ook die kosten zijn waarom grote clubs als Yahoo (ondanks alle kritiek) anno 2013 nog steeds niet standaard hun webmail versleutelen.

zolang er mensen zo goedkoop mogelijk hun site gehost willen hebben (a 99 cent per jaar zeg maar) zullen ze die 15 euro per jaar voor ssl wel al snel te duur gaan vinden.

je weet toch dat er lang niet genoeg ip4 adressen zjin om dat te doen he... en ip6 ik gok dat 75% van het internet nog niet klaar is om binnen nu en 3jaar ip6 uit te rollen...

Hierdoor kunnen sites die http 2.0 met encryptie willen aanbieden dus uitsluitend uri's met https gebruiken.

Lijkt mij ook beter. Het is misschien minder makkelijk omdat je rekening moet houden met het protocol en niet klakkeloos kan uitgaan van http. Aan de andere kant is er wel een duidelijke scheiding en zijn fouten minder snel gemaakt.

Ben benieuwd hoe http 2.0 er definitief uit gaat zien, maar het lijkt allemaal helemaal in orde. Hoe staat het met Googles spdy in combatie met de nieuwe http standaard?

Hoe staat het met Googles spdy in combatie met de nieuwe http standaard?

HTTP 2.0 is voor een groot deel gebaseerd op SPDY. Ik neem aan dat SPDY dus wel zal verdwijnen zodra HTTP 2.0 geïmplementeerd is.

Hoe zit het dan met server push in SPDY? Ik mag toch hopen dat ze dat eruit slopen, ik mag toch graag zelf bepalen wat mijn browser binnenhaalt, en dus, bijvoorbeeld, geen bandbreedte verkwisten aan ads en dergelijke.

Er verandert wat dat betreft weinig ten opzichte van de huidige situatie. Het is nog steeds de browser van de gebruiker die bepaalt of er een push-channel wordt geopend met een server, niet de server. Net als dat nu jouw browser (en niet de server) bepaalt dat hij een ad binnenhaalt (of een plugin in jouw browser dat voorkomt).

Push channel is een stuk efficiënter dan al dat polling verkeer of onnodig lang connecties open laten staan alleen om te weten of er misschien een nieuw berichtje binnen is.

Is dat zo? Ik heb mij verder niet in het protocol verdiept, maar wat ik begrepen heb is het aan de server om te bepalen wat hij de client toestuurt, als je het over server push hebt. Mbv server hints zou je dan een betere situatie krijgen, ten koste van een extra round-trip.

En het blijft selectief natuurlijk; als ik tether wil ik bijvoorbeeld wel stylesheets binnenkrijgen, die zouden natuurlijk ook via een Server Push verstuurd kunnen worden. Maar is het aan de browser om te zeggen: stuur mij CSS en verder niets? En luistert de server daar dan ook daadwerkelijk naar?

Momenteel kunnen ze al functionele push-like features implementeren via WebSocket, long-polling (comet) en Flash. Het enige verschil is dat het SPDY het als officieel protocol ondersteund. Wat het dus ook centraler zou maken om onder controle te houden.

En toch is er wat met die technieken gebeurt om bepaalde updates te pollen, zoals bijvoorbeeld notificaties op websites. Als het in het protocol geintegreed wordt zie ik het snel gebeuren dat afbeeldingen, CSS scripts en ook ads worden geintegreerd in de datastream.

Daarom vraag ik mij dus af wat de browser daadwerkelijk kan doen om ongewenste content, zoals in mijn voorbeeld dus bijvoorbeeld álle afbeeldingen, te weigeren en dus ook niet over de dataverbinding binnen te krijgen.

Als daar een solide oplossing voor is, prima, goede verbetering. Maar volgens mij is dataverkeer-besparing nooit Google's first interest geweest, zeker niet dataverkeer van consumenten.

WebSocket, long-polling en Flash-sockets zijn geen polling. Het is de browser die pushed. Natuurlijk moet de client de verbinding eerst opzetten, maar dat lijkt me niet anders. Dat is sowieso nodig simpelweg vanwege je NAT, welke techniek dan ook.

Hoe bepaal je dat nu dan? Zit je met een debugger een breakpoint op ieder request te zetten?

Nee, ik blokkeer standaard afbeeldingen op webpages indien ik tether via mijn mobiele telefoon. Cross-domain requests blokkeer ik sowieso altijd al. Dit scheelt enorm in het dataverbruik, maar kan dus mbv SPDY buitenspel gezet worden.

Komop push is een interessante feature!
Server-push heeft juist het voordeel dat de server iets kan laten weten,
anders moet de client steeds "pollen".

Een voorbeeld: een email client: momenteel checkt de browser om de zoveel tijd
of er nieuwe berichten zijn, constante poll dus en onnodig indien de server
simpelweg kan laten weten of de email binnenkomt, is dus zonder vertraging!

-edit-
Dit voorbeeld gaat wel degelijk over een webmail client, heeft niks te maken met imap ofzo!

[Reactie gewijzigd door Anoniem: 435796 op 14 november 2013 20:58]

We hebben het hier over HTTP, niet over IMAP of zo. Een beter voorbeeld zou zijn van die notificaties op site zoals facebook en zo.

mrnikosia doelt op http-push. Dat wordt steeds meer gebruikt tegenwoordig. Vooral bij ajax-based sites waar de gebruiker lange tijd op dezelfde pagina blijft.

Deze techniek zorgt ervoor dat de webserver updates kan pushen naar de klant ipv dat deze om de zoveel tijd moet pollen.

Dat bedoel ik ook.

Mail is geen goed voorbeeld want dat gebruikt protocollen zoals IMAP.

Een voorbeeld wat wel via HTTP push kan zijn notificaties op facebook en vergelijkbare sites.

Volgens mij kan mail een prima voorbeeld zijn, mits je het over webmail hebt. Daar kan het juist ergens handig zijn om niet te hoeven pollen totdat er een nieuw mailtje binnenkomt maar pas de inbox te refreshen nadat de server heeft gepusht dat er iets veranderd is.

Als je het zo stelt kan alles wel een voorbeeld zijn. Je kan overal wel een http wrapper overheen leggen. Web irc, Web telnet, and so on.

[...]


Lijkt mij ook beter. Het is misschien minder makkelijk omdat je rekening moet houden met het protocol en niet klakkeloos kan uitgaan van http. Aan de andere kant is er wel een duidelijke scheiding en zijn fouten minder snel gemaakt.

Ben benieuwd hoe http 2.0 er definitief uit gaat zien, maar het lijkt allemaal helemaal in orde. Hoe staat het met Googles spdy in combatie met de nieuwe http standaard?

Lijkt mij ook de beste oplossing. Zo is het ook meteen duidelijk of er wel of niet versleuteling wordt gebruikt. Wel zo handig voor de gemiddelde gebruiker.

[Reactie gewijzigd door Argantonis op 13 november 2013 18:10]

Mij lijkt de andere implemetatie juiste beter. HTTP(S) verkeer is altijd encrypted, en iedereen gaat dat aanbieden, ongeacht het protocol. HTTPS voegt dan certificaten toe zodat je als gebruiker weer dat je een verbinding hebt met de juiste server.
Als gebruiker ga je er dan op vooruit. Voor HTTPS veranderd er niks, maar HTTP is nu ook encrypted.

(En een bank of webshop met creditkaart die denk dat ze wel op HTTP kunnen omdat het toch encrypted is, moet je als klant gewoon boycotten, zoals nu ook. Hiervoor moet je gewoon een certificaat eisen)

maar wie typt die http vandaag nog wanneer hij/zij een url ingeeft in de adresbalk? Meeste browsers tonen het prorocol zelfs niet meer eenmaal de pagina in beeld staat. Browsers in de toekomst kunnen perfect proberen of https bestaat, geeft dit een foutmelding dan kunnen ze alsnog eerst proberen met http voor ze een foutmelding geven.

Browsermakers zouden er zelfs voor kunnen kiezen om altijd eerst https te proberen, zelfs als de gebruiker specifiek http aanklikt, dit vanwege de vele legacy urls die vandaag te vindne zijn op miljarden webpages.

Dan doe je terloops een enorme aanname, nl dat de https versie dezelfde pagina zal tonen als de http versie en dat hoeft helemaal niet zo te zijn. Je maakt dan in een klap een deel van het web ontoegangkelijk.

Klopt, een kleine rondgang die ik onlangs heb gedaan liet zien dat maar liefs 20% van onze klanten op https een andere site heeft draaien, vaak een controle paneel.

Het kan ook dat op een shared server alle https verzoeken doorgezet worden naar 1 domein, namelijk het domein waar de beveiligde site op draait. Apache ken ik niet zo goed maar nginx heeft daar standaard wel 'last' van.

Het is niet de server die er 'last' van heeft, maar de client. Bij het opzetten van de TLS-verbinding, weet de webserver niet voor welk domein dat is en moet dus maar een aanname doen welk ssl-certificaat opgestuurd moet worden. Dat is soort van opgelost met de extensie SNI, wat tegenwoordig door servers altijd wel ondersteund wordt. Er zijn echter nog veel clients die SNI niet ondersteuen, en dus nog steeds last hebben van het feit dat de server aannames moet gaan maken.

Je hebt helemaal gelijk in wat je zegt maar dat is niet het issue bij nginx. Deze heeft een rare gewoonte van 'als er niets matched dan maar de eerste site die ik tegenkom'. Zelfs onder port 80 en ook op 443. Vandaar dat je dat altijd even af moet vangen met een default catch all.

nginx heeft helemaal geen moeite met verschillende domeinen op https. Maak er al lang gebruik van zonder enig probleem, gewoon de documentatie even goed doorlezen.

En imho dient een webserver ongeacht of het http of https is dezelfde site te serveren. Wil je iets anders zien, zet het dan op een ander (sub)domein.

Mij lijkt de andere implemetatie juiste beter. HTTP(S) verkeer is altijd encrypted, en iedereen gaat dat aanbieden, ongeacht het protocol. HTTPS voegt dan certificaten toe zodat je als gebruiker weer dat je een verbinding hebt met de juiste server.
Als gebruiker ga je er dan op vooruit. Voor HTTPS veranderd er niks, maar HTTP is nu ook encrypted.

Maar als dit wordt ingevoerd is het voorlopig nog niet zo dat iedere website versleuteld is als je er via http naar toe gaat. Dus dan wordt het ambigu.

Als gebruiker ga je er dan op vooruit. Voor HTTPS veranderd er niks, maar HTTP is nu ook encrypted.

Het huidige HTTP zal niet zo snel encrypted worden, anders gaan hele hostingproviders omvallen omdat ze de load niet meer aankunnen (encryptie vraagt relatief veel load).

Dus als ze http ook mogelijk encrypted zouden maken dan krijg je enkel maar een onduidelijk mengelmoesje van encrypted / unencrypted sites. En dat zou spammer-heaven worden.

liever gewoon tls relaxed zeker met het gebruik van DNSsec heb je server authenticatie niet nodig voor zomaar elke site natuurlijk zijn er zaken als banken etc waar je nog steeds certificaten wilt, maar voor de comunicatie met webfora etc is dns-genoeg bewijs dat ik met tweakers.net servers praat ... toch zou het voor de beveiliging veel beter zijn als standaard data versleuteld is in plaats van dat je met gratis cheapo (of erger nog self signed) certs gaat werken. ook dat hele wot gedoe is een ramp... mensen gaan veel te snel accord met foutive certs dat aangeleerde gedrag kon wel eens zorgen dat je in de toekomst ook een keer in de fout gaat bij je bank over verzekeringsmaatschappij... met alle gevolgen van dien..

Iets is mij toch niet helemaal duidelijk. Wordt het straks wel mogelijk om HTTP 2.0 te gebruiken zonder encryptie?

Ik mag toch hopen dat onversleuteld versturen technisch onmogelijk wordt gemaakt. Dat doet even pijn maar een paar jaar later verbaas je je er over dat het vroeger überhaupt zonder encryptie gebeurde...

Ja dat gaat 'm echt worden (!) Dan moeten dus ook alle plaatjes op de FP van Tweakers (o.a) met encyrptie verstuurd worden? Dat lijkt me een bak laadtijd (en dus serverpower) toe te voegen die eigelijk helemaal nergens voor nodig is.

Encryptie kost tegenwoordig toch geen drol meer aan rekenkracht.

Omdat niet alles encrypted is. Als straks álles door (zwaardere) encryptie moet weet ik dat zo net nog niet.

Processorkracht ontwikkelt zich sneller dan dat encryptie zwaarder wordt. Daarnaast zit veel van de encryptie al hard gecodeerd en zwaar geoptimaliseerd in je CPU.

Zie bv.: https://en.wikipedia.org/wiki/AES_instruction_set

Of het zich nou sneller ontwikkelt of niet maakt niet uit... het gaat nog altijd ten koste van de (energie- en tijds-) besparing die je anders had gehad door de grotere rekenkracht, dus het kost wel degelijk iets.

Het blijft inderdaad een kosten/baten-afweging. Mijn punt is dat de kosten peanuts zijn. Hoeveel waarde je hecht aan de baten, veiligheid en privacy, is een afweging die iedereen zelf moet maken. Persoonlijk vind ik dat veel waard. En ik denk dat andere mensen er ook meer waarde aan zouden moeten hechten.

Het is anders niet voor niets dat Google pas nadat een breach door NSA-afluisteren van de interne google-connecties ook intern binnen Google's private cloud encryptie op de lijn gaat toepassen. Als de kosten op dergelijke schaal daadwerkelijk peanuts waren had Google nooit de keuze voor mix van extern encrypted intern unencrypted gemaakt.

Ik denk dat de kosten niet zitten in de extra CPU-cycles, maar in de complexiteit van het beheer. Verder vind ik het niet raar dat je er van uit gaat dat je eigen prive netwerk secure is. Maar ja, dat was vroeger...

Bij de client merk je dat niet zo, maar ik kan je verzekeren dat het op serverniveau wél degelijk uitmaakt. Waarom denk je dat google zolang gewacht heeft met https!?!

Ja dat gaat 'm echt worden (!) Dan moeten dus ook alle plaatjes op de FP van Tweakers (o.a) met encyrptie verstuurd worden? Dat lijkt me een bak laadtijd (en dus serverpower) toe te voegen die eigelijk helemaal nergens voor nodig is.

Zoals Jace ook al zegt, zo moeilijk is dat niet meer voor processoren van tegenwoordig. Computers worden ook nog steeds elk jaar weer een stuk sneller dus zoveel impact heeft dat ook weer niet. En het is een kleine prijs om te betalen.

Als je tweakers.net via https bezoekt komen alle plaatjes al met https van tweakimg.net
Edit, lamaar, als ik een plaatje in een nieuwe tab open redirect https-everywhere automagisch naar de https versie.

[Reactie gewijzigd door Dannisi op 14 november 2013 06:49]

Versleuteling word een verplichting in de standaard dacht ik, net zoals dat vandaag bij spdy al het geval is.

Het verhaal is niet zo duidelijk geschreven. Zover ik begrijp is http:// dus http 1 en dus zonder versleuteling. Dat is wel een hele grote teleurstelling. Ik verwacht dan ook niet dat http 1 ooit uitgefaseerd gaat worden, omdat dan gebruikers steeds https moeten typen.

Daarbij zie ik TLS-relaxed als semi-veilig. Ik had liever dat standaard alles semi-veilig was, en dat met https:// dit dus wel veilig is. Nu is het dan bij https minder duidelijk (vergeleken met nu) of het veilig of semi-veilig is, en dat wordt lastig uitleggen aan een gebruiker.

Het argument dat iemand niet encrypted nodig heeft, vind ik nogal zwak. Sommige personen, zoals ik, willen wel altijd encrypted. Nu kan ik vaak niet kiezen, want de server bied alleen http aan. Daarbij verliezen mensen niets als je niet geven om encryptie (te veel), en het toch standaard krijgen - maar andersom dus wel.

Helaas vergeten veel mensen ook hoe eenvoudig het is om unencrypted wifi af te luisteren..

@Maurtis:
Ik betwijfel of https standaard wordt aangevuld in de je browser, als er nog altijd http is.Hoe moet een browser dan weten of het http of https is? Als deze het graag proberen, dan kan dat nu ook al (en dat wordt nu ook niet gedaan - helaas, wel via een plugin ja, maar niet op mijn mobiel bijvoorbeeld.) Het verschil is dus een verschil tussen 0 en 8 tekens. .

[Reactie gewijzigd door apokalypse op 13 november 2013 20:32]

omdat dan gebruikers steeds https moeten typen.

Het is het verschil tussen 7 of 8 karakters, verwaarloosbaar dus.

Bovendien typt vrijwel niemand meer de naam van het protocol in omdat browsers er al jaren vanuit gaan dat er HTTP (en niet FTP of Gopher) bedoelt wordt en dat prima zelf kunnen detecteren. Ik gebruik zelf een plugin die per default eerst alles met https probeert te doen. Het is niet ondenkbaar dat binnen afzienbare tijd browsers standaard al de voorkeur zullen geven aan https boven http, zeker als HTTP 2.0 af is.

[Reactie gewijzigd door Maurits van Baerle op 13 november 2013 19:39]

Nee, de default voor browsers wordt https (de meeste mensen tikken het protocol niet meer). Als die er niet is komt er een fallback naar http, MAAR die kan certificaat-loos TLS doen (TLS is een moderne variant van SSL, en wordt in het merendeel van de SSL verbindingen al gebruikt).

Je kan het vergelijken met on the fly encryptie onderhandeling tussen beide kanten. (Zoals OTR in sommige chatclients)

Om backwards compatibel te blijven zal http 1.1 en 1.0 net zoal nu ook nog mogelijk zijn. In elk geval tot http 3.0 gok ik :-)

[Reactie gewijzigd door arjankoole op 14 november 2013 11:50]

Encryptie is zo sterk als de zwakste schakel. Vertrouwen ook. En dat is haar https om gaat: kunnen vertrouwen dat je contact hebt met de juiste partij en dat je gegevens niet afgeluisterd en niet gemanipuleerd kunnen worden. Wat is nu de hele zwakke schakel? Zoals gewoonlijk dat het een businessmodel is waarbij de CAs flink geld verdienen door zo min mogelijk aan veiligheid te doen. Je kan er tegenwoordig niet meer op vertrouwen dat de certificaten terecht zijn uitgegeven, je kan er niet meer op vertrouwen dat de certificaten bij de juiste partij horen. Al jaren geleden is het CAmodel rijp geworden voor de sloop, maar ja dat kost de grote CAs en hun onderaannemers inkomsten. Stel je toch eens voor dat ze verantwoordelijkheid zouden nemen. De standaard encryptie in http 2.0 is achterhaald. Er is echter geen oplossing afgezien het businessmodel de prullenbak in donderen en de accountants die er aan meewerken incluis.

Je haalt twee dingen door elkaar. SSL/TLS zorgt voor twee dingen:

• Encryptie (beschermt tegen afluisteren)
• Authenticatie (met wie praat je?)

Met die encryptie is niks mis (met de juiste cipher suite). Maar het systeem van certificate authorities is inderdaad rijp voor de sloop.

Hmm ik heb op sites waar ik ssl "verplicht" vind voor gebruikers, gewoon een 302 redirect van alles met http naar https ... kloar is klara

Wordt er dan ook iets aan de Man-in-the-Middle attacks gedaan die diverse mobiele browsers toepassen? Op mijn Nokia Asha heb ik geen eens de keuze, de ingebouwde browser en alles via de Ovi Store past het toe.

Als ik een HTTPS request doe, dan wordt dat eigenlijk naar een Nokia server gedaan. De Nokia server maakt verbinding met het URL wat ik gespecificeerd heb, decrypt de gegevens op de Nokia server en encrypt ze weer met hun eigen certificaat, wat vervolgens door de browser op mijn mobiel klakkeloos geaccepteerd wordt.

Opera Mini doet dit ook, en vele andere mobiele browsers ook. Dit geeft een vals gevoel van veiligheid dat er niemand mee kan kijken, want op zijn minst Nokia (of Opera) kan meekijken, en dan is het gelijk alweer zeer waarschijnlijk dat de NSA ook meekijkt, bijvoorbeeld.

Ook bedrijven, scholen en dergelijke pasen dit soort praktijken toe. Een hulpmiddel om dit te detecteren is https://www.grc.com/fingerprints.htm

Ik weet niet zo goed hoe dit op te lossen zou zijn in het protocol, maar een soort van twee-weg validatie van de verbinding (dus niet alleen server door client, maar ook client door server) lijkt mij een aardige start.

Da's geen Man-In-The-Middle attack. Dat is een endpoint attack, en dat kan je niet oplossen met HTTP2. De aanval gebeurt namelijk vorobij het einde van het HTTP channel, namelijk in je browser.

Je denkt ten onrechte dat het een MITM is omdat het tussen je browser en je scherm gebeurt, maar dat is cryptografisch gezien niet het midden.

Het gebeurt tussen browser en server, door een 'all-traffic-mobile-optimizing'-proxy. Dus wel degelijk een MITM....

perfect foward security, lol