Http 2.0 krijgt waarschijnlijk ingebouwde versleuteling

De kans is groot dat http 2.0, de opvolger van http 1.1, ondersteuning voor versleuteling via de tls-standaard ingebouwd krijgt. Dat wil niet zeggen dat http even veilig wordt als https: mogelijk worden certificaten niet gecontroleerd, waardoor man in the middle-aanvallen mogelijk blijven.

Op dit moment wordt nog steeds gewerkt aan de nieuwe versie van het http-protocol; of daadwerkelijk wordt gekozen voor encryptie, is dus nog niet op papier vastgelegd. Volgens de voorzitter van de http-werkgroep van de Internet Engineering Task Force is een groot deel van de community echter voorstander van het inbouwen van encryptie. Dat zegt hij tegenover de Financial Times. De IETF is verantwoordelijk voor een groot deel van de standaarden en specificaties op internet, waaronder de http-specificatie.

Hoe de standaard aanwezige encryptie er precies uit moet gaan zien, is op dit moment nog niet besloten. Duidelijk is wel dat de http-werkgroep voorstelt dat de client de macht krijgt om een beveiligde verbinding af te dwingen. Op dit moment kan alleen de server dat. In de nieuwe situatie zou het dan verplicht worden om encryptie aan te bieden, maar is het niet verplicht om die aangeboden encryptie daadwerkelijk te gebruiken. "Als twee partijen via een open kanaal willen communiceren, moet dat mogelijk zijn", zo zei de voorzitter van de werkgroep, Mark Nottingham, eind vorige maand op een IETF-bijeenkomst in Berlijn.

De http-versleuteling zou naast https moeten bestaan, en versleutelde pagina's zouden gewoon via de protocol-identifier 'http' moeten worden aangeroepen. Voor de encryptie kijken de opstellers van de nieuwe specificatie naar tls, dat ook in https wordt gebruikt. Verschillen met https zijn er echter ook: zo stelt Nottingham op de mailinglijst van het project voor om de certificaten van versleutelde http-verbindingen niet te verifiëren. "Dat zou de uitrol vergemakkelijken", schrijft Nottingham, die wel aantekent dat daarover nog verder gediscussieerd moet worden.

Als certificaten niet geverifieerd worden, betekent dat echter dat man in the middle-aanvallen nog steeds mogelijk zijn: het verkeer wordt dan versleuteld, maar er kan niet worden gecontroleerd naar wie het versleutelde verkeer wordt gestuurd. Wel wordt de inhoud van de communicatie beschermd tegen afluisteren, waardoor bijvoorbeeld gebruikers van openbare wifi-hotspots beter beschermd zouden zijn.

De IETF werkt sinds eind vorig jaar aan de nieuwe versie van de http-specificatie. De nieuwe specificatie neemt de Spdy-specificatie van Google als uitgangspunt, en moet onder meer de laadtijd van pagina's verkorten en het parallel versturen van content over één verbinding mogelijk maken. De standaard moet in 2014 gereed zijn. De standaard wordt uitgerold naast http 1.1; voorlopig wordt de huidige http-versie nog niet uitgefaseerd. Gezien de alomtegenwoordigheid van http 1.1 zal die standaard waarschijnlijk nog vele jaren na de uitrol van http 2.0 ondersteund blijven door webbrowsers en -servers.

Reacties (76)

Laat mij toe de 'waarschijnlijk' in de titel toch wat af te zwakken, op de httpbis mailing lijst is er namelijk wel wat kritiek op het voorstel; lees http://lists.w3.org/Archi...p-wg/2013JulSep/0948.html en verder. Laatste comment van de WG chair (de man v/h interview met FT) luidt:
Given the risk of this becoming the mother of all ratholes, I'm inclined to think that it might be best to fork this discussion off to a design team, which can talk about it separately and come back to the WG with something more fully baked. Would that work for people, and if so, who would be interested in dedicating substantial time to it?

Zelf ben ik trouwens geen voorstander van het voorstel, om de redenen die Polarbear heeft aangehaald, schijnveiligheid is in mijn ogen gevaarlijk dan plain-text. Ben dan ook benieuwd hoe mensen uit IETF's security community hier tegenover staan.

Het grappige vind ik juist dat dit uberhaubt nieuws is, want HTTP/2.0 en always encrypted is punt dat al meer dan een jaar op de tafel ligt en de reden hiervoor is vooral technisch.

Kijk eens goed hoe op die moment websocket of SPDY ge-deployed wordt op het publieke Internet. Eigenlijk altijd met HTTPS als je wilt dat het altijd werkt.

Waarom is dat ? Omdat er allerlei systemen zijn dat proberen naar HTTP-verkeer te kijken en/of aanpassen en die snappen nieuwere protocollen niet en verbreken dan de verbinding.

Dus HTTP/2.0 op basis van SPDY zal ook SSL/TLS gaan gebruiken. In de SPDY specificaties staat het niet in het document, maar er is gewoon weinig keus anders werkt het niet op het grootte boze Internet.

Toen de nieuwe HTTP/2.0 discussies op gang kwamen was direct al duidelijk dat encryptie nodig was, de vraag is alleen welke vorm het krijgt en komt het in de standaard zelf te staan.

Met alle respect voor de taskforce, maar het zal wel weer downwards compatible met het http 1.1 protocol moeten zijn.

Dus in feite gedoemd om te mislukken, en daar komt bij dat de overheden natuurlijk de encryptie sleutels willen hebben waardoor er weer een stuk weg is.

Het probleem met man-in-the-middle is eigenlijk het dns protocol en de implementatie daarvan het besturingssysteem.

Denk dat heel de architectuur eerst onder de loep moet worden genomen zodat je een hele nieuwe http en dns krijgt waardoor man-in-the-middle eigenlijk niet meer mogelijk is. En niet zoals dat nu gebeurd we gaan gewoon met pleister werk aan de gang.

Kortom een grote ommekeer.

De reden voor encryptie is een voornamelijk technische, dat is nu juist die compatibility.

Omdat er heel veel netwerken zijn waar transparante en andere proxy servers en onzin in het netwerk zit die met gewoon HTTP altijd proberen te kloten, maar niet met HTTPS moeten ze dus nieuwe protocollen wel uitrollen met HTTPS.

Ik kan me wel belangrijkere toevoegingen voorstellen. Ik heb geen idee wat er nieuw is, of wat de verhouding tot SPDY is, maar dingen als multipart requests (om meerdere files binnen één request op te halen zodat bijv sprites niet meer nodig zijn) en statefulness (waardoor er geen gezever meer is met sessies) lijken me handiger om toe te voegen dan iets dat eigenlijk al bestaat.

En wat het is nut van encryptie nog, als de veiligheid ervan niet gegarandeerd kan worden?

backwardcompatibility.

Waarom?

De twee kunnen prima naast elkaar bestaan en gebruikt worden.

[Reactie gewijzigd door _Thanatos_ op 27 augustus 2013 12:53]

Zal het veel trager worden hierdoor? Met grote hoeveelheden data.

Veel moderne CPU's hebben instructies om data te decrypten in de CPU zitten. Hiermee doe ik bijvoorbeeld op een Xeon E3-1200V2 met TrueCrypt grofweg 3GB/s aan doorvoer. Voordat dát een bottleneck is zijn we wel enige tijd verder denk ik

Dus nee, ik voorzie geen vertragingen op moderne CPU's. En zelfs op oude CPU's zal er nog wel genoeg CPU tijd over zijn om de encryptie/decryptie te doen lijkt mij.

Zelfs zonder die extenties zie je dat op het grootte geheel nauwelijks terug.

Ik verwacht het tegendeel. De encryptie is maar een extraatje, de belangrijkste nieuwe feature is imho de compressie. Nu steeds meer webverkeer over mobiele verbindingen, dus beperkte bandbreedte gaat, zal dat een flinke snelheidswinst opleveren.

De meeste versleutelingen zullen de hoeveelheden niet vergroten. Dat is wel onder de voorwaarde dat compressie wordt toegepast voor het versleutelen, erna is het niet (goed) meer mogelijk.

Mooie ontwikkeling, ik hoop dat het gehoor gaat krijgen. HTTPS versleuteling is vaak een wat hogere drempel om in te bouwen aangezien je een publiekelijke CA moet betalen voor een certificaatje, of je gebruikers en certificaat moet laten inbouwen. Hoewel Man-in-the-middle attacks nog steeds mogelijk zijn bij deze manier van encryptie zal het al een stuk helpen.

Man in the middle is triviaal als de certificaten niet gecheckt worden, het biedt een schijnveiligheid en daar heeft niemand wat aan.

Net alsof man-in-the-middle nu bij HTTP onmogelijk is. Dit voorstel voegt toe dat op een 'toevallig' juiste end-to-end verbinding dan niet op meegekeken kan worden.

Zo zie je ook zelden dan mensen de bij de eerste keer SSHen de server fingerprint controleren. Zelfde probleem. Toch heeft het de voorkeur over telnet.

Startcom is een breed geaccepteerde CA en biedt gratis certificaten aan.

Het nadeel van certificaten is dat je die per domeinnaam moet regelen en regelmatig moet bijwerken.

Om de kans op een MITM-aanval te verkleinen kun je net als SSH doen. Je slaat de serversleutel bij het eerste bezoek op, en waarschuwt de gebruiker als die wijzigt. Als je slechts zo nu en dan via iemands wifi-netwerk surft, ben je dan beschermd. Alleen een partij die vanaf dag 1 constant een mitm-aanval kan uitvoeren, kan dat dan nog ongemerkt doen.

Geheel velig is het natuurlijk niet, maar als we dit niet als alternatief op https gaan zien maar als een aanvulling daarop is het zeker een goed idee

Ik zie niet in wat de toegevoegde waarde is van TLS als de certificaten niet worden gecontroleerd. De huidige situatie is veel helderder, HTTP = unencrypted, HTTPS = encrypted (en HTTPS kan je ook met self signed certificaten doen maar dan krijg je een melding in de browser).

Het zou overigens fijn zijn als TLS 1.3 wat meer wordt ondersteund (browsers en servers).

HTTPS voorziet in 2 dingen: Authenticatie en encryptie. Voor authenticatie is een certificaat nodig, wat o.a. geld kost.

De toegevoegde waarde van dit voorstel is encryptie. Zoals je zegt komt dit op hetzelfde neer als een self-signed certificaat, maar dan zonder de melding in je browser.

De nieuwe situatie wordt dus: HTTP1.1 = open, HTTP2.0 = encrypted, HTTPS=encrypted+authenticated.

"De nieuwe situatie wordt dus: HTTP1.1 = open, HTTP2.0 = encrypted, HTTPS=encrypted+authenticated."

In HTTP2.0 moet zowel encrypted als on-encrypted ondersteunen, dus dit is niet helemaal waar. In de nieuwe situatie heb je HTTP met encryptie, HTTP zonder encryptie en HTTPS met encryptie en autorisatie

"De nieuwe situatie wordt dus: HTTP1.1 = open, HTTP2.0 = encrypted, HTTPS=encrypted+authenticated."
.....
en HTTPS met encryptie en autorisatie

Hier worden authenticatie en autorisatie door elkaar gehaald.
Beide zijn wezenlijk verschillend en om miscommunicatie te voorkomen is het belangrijk in dit soort discussies beide helder te hebben.

Authenticatie (in het geval van een http(s) verbinding) gaat over het vaststellen dat een partij ook daadwerkelijk die partij is die hij claimt te zijn.
Daarvoor worden certificaten gebruikt die zijn ondertekend door vertrouwde partijen. Zo'n partij kan een 'publieke' organisatie (CA) zijn zoals Verisign of een geheime/prive partij. (Self-signed klinkt nogal negatief, het houdt voornamelijk in dat de certificaten niet zomaar door iedereen te verifieren is).
Authenticatie van de server is verplicht bij https en authenticatie van de client wordt vaak gebruikt bij VPN's of toegang tot speciale netwerken, applicaties en dergelijke.

Authorisatie gaat over het bepalen wat iemand (of een systeem) mag.
Als een client geauthenticeerd is door middel van bijvoorbeeld een client certificaat, dan wordt vervolgens gekeken wat die client eigenlijk mag.

Vergelijk het bijvoorbeeld met het witte huis.
Iedereen die naar binnen wil, zal zich moeten auhtenticeren. Als vervolgens met zekerheid vaststaat wie je bent, wordt er gekeken of je überhaupt naar binnen mag.
En vervolgens hebben mensen verschillende rechten op toegang tot verschillende ruimtes.

HTTPS vereist helemaal geen authorisatie. Het kan...

Log dagelijks in op firewalls, routers en hordes anderen zonder officieel certificaat via HTTPS. Zou knap lastig zijn als het verplicht was.

Maar goed, wat mij betreft +1 achterlijk idee. Laten we de gebruikers nog wat meer verwarren (ze begrepen het immers al zo goed)... Certificaten hoeven met DNSSEC straks in principe ook geen geld meer te kosten, gewoon je eigen cert in je DNS publiceren en klaar.

Mja het doet misschien encryptie, misschien ook niet. Misschien controleert ie het certificaat, misschien ook niet.

Het komt op mij in het bijzonder over als een hoop paniek over prism. Nou vind ik het prima dat ze die pesten, maar gebruikers verwarren vind ik geen strak plan. Het huidige principe is vrij simpel en steeds meer sites redirecten standaard naar de https versie. Lijkt me een prima oplossing.

Er is natuurlijk wel sprake van authorisatie. Bij officiele certificaten gebeurt dat automatisch doordat browsers/operating systems deze vertrouwen, en bij self signed wordt het aan de gebruiker over gelaten om te authorizeren.

Ben het wel met je eens dat gebruikers verwarren niet handig is. Ik snap ook niet welk probleem HTTP 2.0 nu oplost? HTTP of HTTPS was volgens mij duidelijk genoeg, de snelheidsverbetering van SPDY is wel welkom.

Ben het wel met je eens dat gebruikers verwarren niet handig is. Ik snap ook niet welk probleem HTTP 2.0 nu oplost?

Het voorkomt dat iemand het verkeer (Content) kan onderscheppen en opslaan wanneer een site niet standaard https gebruikt, bijvoorbeeld wanneer iemand de fiber cables rechtstreeks aftapt. Wanneer ze je communicatie willen onderscheppen kunnen ze nog steeds een man in the middle attack uitvoeren, Maar ze kunnen tenminste niet terug in de tijd gaan of ongericht informatie van iedereen onderscheppen.

[Reactie gewijzigd door Anoniem: 109989 op 26 augustus 2013 21:32]

Ja maar wat heb je aan encryptie als deze niet te vertrouwen is, het onderscheppen van data wordt triviaal en biedt dus alleen maar schijnveiligheid. Het is niet voor niets dat een self signed certificate een melding oplevert.

Self-signed certificates zijn anders de enige betrouwbare manier om beveiligd te communiceren. Mits goed toegepast natuurlijk, je moet er wat moeite voor doen om het certificate op een veilige manier op de client computer te krijgen.

Het gebruik van certificaten die getekend worden door een "Authoriteit" is onveilig. Je bent dan afhankelijk van de betrouwbaarheid/beveiliging van die Authoriteit en de hele keten van authoriteiten die er boven hangt. Ik denk dat je er tegenwoordig gerust vanuit kunt gaan dat de NSA en andere geheime diensten her en der een vinger in de pap hebben.

Als je je beveiliging echt serieus neemt gebruik je self-signed certificaten. Is overigens nooit anders geweest.

Het gebruikt van certificaten die door een "Authoriteit" getekend zijn is een vertrouwens kwestie. Je vertrouwd erop dat de Authority zijn veiligheid op orde heeft en dat hij bijvoorbeeld ook niet dubbele certificaten verkoopt.

Het probleem is alleen dat dat inderdaad niet altijd goed gaat (Diginotar anyone?). Ook is het zo dat er niet altijd goede controle plaatsvind wanneer een instantie een certificaat aanvraagt, zo was het lange tijd mogelijk dat de rabobank een certificaat aan kon vragen voor rabobank.nl, maar dat derden (criminelen) óók een certificaat voor rabobank.nl konden aanvragen, terwijl zij helemaal niet de rabobank waren. Dat resulteerde in Phising attacks die ogenschijnlijk legitiem waren omdat ze een certificaat gebruikte wat geen waarschuwingen opleverde. Pas later zijn de browsers een groene adresbalk / groen element gaan toevoegen om te laten zien dat het certificaat ook daadwerkelijk toebehoorde aan een organisatie die geverifieerd was, en je dus écht kon vertrouwen.

Maar dat kan óók allemaal met je self-signed certificates gebeuren... Maar dan heb je het tenminste zelf nog in de hand.

Wat betreft HTTP 2.0 is het grote voordeel niet zozeer de authenticiteit van de server, maar de encryptie tussen ontvanger en server. Dat scheelt al een boel, kan de NSA (of wie er dan ook tussen jou en de server in zit) in ieder geval weer iets lastiger meekijken... Mijn verwachting is dan ook dat de grote browser het checkboxje 'gebruik beveiligde verbindingen' default aan zullen hebben staan...

[Reactie gewijzigd door 4np op 27 augustus 2013 09:23]

Krijg je in de browser ook zo'n groen blokje te zien als je je eigen certificaat maakt?

Als je het goed doet wel, dat wil zeggen, als je het self-signed certificaat toevoegt aan de vertrouwde certificaten op de client. Dat klinkt wellicht onnodig gecompliceerd en onpraktisch maar er is een reden voor dat het alleen op die manier werkt.

Als je het niet op genoemde manier doet kan de client nooit garanderen dat er een encrypted verbinding tussen de zender en de (beoogde) ontvanger bestaat en zal er dus een waarschuwing verschijnen. Dat die waarschuwing doorgaans nog al lastig weg te krijgen is komt omdat het eigenlijk een foutmelding is, het is gewoon niet gelukt een betrouwbare verbinding op te zetten. De basis van symmetrische encryptie is namelijk dat er een betrouwbare uitwisseling van een sleutel (shared secret) tussen beide partijen plaats gevonden heeft. Als dat niet het geval is heeft encryptie verder eigenlijk niet zoveel zin. De data gaat dan wel encrypted over de lijn maar je weet niet wie de partij is waar je de sleutel van hebt ontvangen, oftewel wie er aan de andere kant van de lijn hangt. Volledig veilige communicatie met een volslagen onbekende zeg maar.

Bedankt !

En toch is het onzin dat een serieuze IT-er met self signed certificaten werkt, tenminste niet zo als deze term in zijn algemeenheid gebruikt wordt. Alle certificaten leiden uiteindelijk naar een self signed certificaat ook die waar sommigen goud geld voor neerleggen.

Of zoals wikipedia het zegt:

Users, or their software on their behalf, check that the private key used to sign some certificate matches the public key in the CA's certificate. Since CA certificates are often signed by other, "higher-ranking," CAs, there must necessarily be a highest CA, which provides the ultimate in attestation authority in that particular PKI scheme.
Obviously, the highest-ranking CA's certificate can't be attested by some other higher CA (there being none), and so that certificate can only be "self-signed." Such certificates are also termed root certificates. Clearly, the lack of mistakes or corruption in the issuance of such certificates is critical to the operation of its associated PKI; they should be, and generally are, issued with great care.

Nu kan je zelf root certificaten maken maar die zet je niet op je server omdat dat onhandig is wanneer de private key op straat komt (moet je een nieuwe public key weer distribueren. Dus wat doe je: je neemt je self signed 'root' certificaat en tekend daarmee een ander certificaat en die gebruik je dan.

Maar alleen encryptie is nutteloos, alleen verificatie zonder encryptie is wel zinnig bv als de data voor de rest niet gevoelig is, zoals 'lamp aan' maar wanneer (als lamp) wel weten dat het van je eigenaar komt. Ben benieuwd waarom hun denken dat dat zinnig zou zijn.

[Reactie gewijzigd door Mr_Light op 27 augustus 2013 01:21]

Nou, triviaal...

Unencrypted http verkeer kun je bij iedere publieke hotspot sniffen. Om encrypted data te onderscheppen moet je het verkeer via een proxy zien te krijgen, dus je moet echt 'in the middle' (kunnen) gaan staan.
Gaat serieus verder dan netwerkverkeer sniffen.

Met arp spoofing is het geen kunst om er tussen te komen. Er zijn legio tooltjes voor die ervoor zorgen dat je in kunt breken op een https sessie. Het kostte me 2 uur voor ik het voor het eerst op mijn thuisnetwerk aan de praat had. Als je eenmaal weet hoe het in elkaar zit en welke tooltjes je nodig hebt, is het letterlijk een druk op de knop. Je moet het tooltje wel een certificaat aanbieden waarmee het kan werken. Vervolgens krijg je in de browser te zien dat dat certificaat niet vertrouwd wordt.
Het enige dat tegen man-in-the-middle beschermt is het vertrouwen in een certificaat. De veiligheid van https valt of staat met het vertrouwen in een certificaat. Dus nooit een untrusted certificate melding achteloos wegklikken!
Als je self signed certificates gebruikt, installeer je eigen ca certificate op de apparaten die je gebruikt. De thumbprint uit je hoofd leren en iedere keer controleren kan ook, of zou een thumbprint al te faken zijn?

HTTP2.0 sluit authenticatie ook niet uit. Als ik mijn browser zo in kan stellen zie ik HTTP2.0 als een grote aanwinst:

* een lijst met 'do-not-authenticate' domeinen
* een lijst met root certificaten die ik naar wens kan aanpassen (of van het OS zelf)
* een popup met waarschuwing als een certificaat niet in de 'do-not-authenticate' lijst staat of niet tegen de CA gecheckt kan worden.

Ik denk dat het grote verschil met HTTPS is dat HTTP2.0 geen "pre-installed certificate authorities" vereist.

Het gaat om het geval dat je bijvoorbeeld met een onbeschermde WiFi hotspot verbind. Met Http/1.1 kunnen WiFi sniffers gewoon je verkeer uitlezen.

Het gaat om het geval dat je bijvoorbeeld met een onbeschermde WiFi hotspot verbind. Met Http/1.1 kunnen WiFi sniffers gewoon je verkeer uitlezen.

Laat die encryptie dan plaatsvinden in een abstractielaag onder http.
Dan hoeft al die server-software niet te worden herschreven.

Aangezien de laag onder HTTP de transportlaag TCP/IP is zal dat helemaal niet gaan. En een abstratielaag toevoegen tussen TCP/IP en HTTP zorgt er nog steeds voor dat je alles moet herschrijven. Sterker nog: je maakt het nodeloos complex.

[Reactie gewijzigd door 4np op 27 augustus 2013 09:09]

Aangezien de laag onder HTTP de transportlaag TCP/IP is zal dat helemaal niet gaan.

Oh jawel hoor, een point-to-point IPsec verbinding is best mogelijk hoor.
Dit is zelfs voor IPv6 specifiek ontworpen (onder andere) om juist encryptie te te kunnen passen op de transportlaag zodat het verkeer een laag hoger er niets van hoeftte merken en er niets aangepast hoeft te worden.

Een bijkomend voordeel is dat IPsec de mogelijkheid biedt tot het signeren van de data zonder deze te coderen.
Dat houdt in dat je data kan versturen die voor iedereen leesbaar is als ze die onderscheppen, maar dat de uiteindelijke ontvanger zeker weet dat die data ook klopt.

Soms is het namelijk niet erg als meerdere mensen bepaalde data zien, maar wel als iemand die inhoud kan manipuleren.
Als gek voorbeeld zou je verkiezingsuitslagen kunnen nemen.
Iedereen is erbij gebaat dat die data publiekelijk toegankelijk is, maar je wil wel 100% zeker zijn dat iedereen dezelfde gegevens te zien krijgt en dat die data niet ergens onderweg is gewijzigd.

Ja, met SMTP, IMAP, POP3 etc. ook. DNS is ook niet versleuteld, dus dat je naar sexmetomas.nl ging was ook duidelijk uit het A record verzoek (en dat iemand aan het sniffen was waarschijnlijk omdat ie van z'n stoel viel ).

Onbeschermde hotspots zijn nog steeds geen goed idee dus. Ook niet met HTTP/2.0. Bovendien doet het misschien iets, ze moeten er nog over discussieren...

SMTP, IMAP en POP3 kunnen alledrie versleuteld aangeboden worden. Veel providers bieden dit aan, bv XS4All. Bij DNS kan dit niet standaard, tenzij je bv DNSCrypt van OpenDNS gebruikt.

Veel? Of sommige? De tech-geeks van xs4all aanhalen als voorbeeld is niet bepaald representatief voor de NL ISP-markt. Volgens mij zijn er onder de bulk el-cheapo providers die Jan Modaal kiest nog niet veel die secure versies van POP3 en/of IMAP bieden.

Voor SMTP en IMAP kun je STARTTLS of respectievelijk SMTPS (SMTP over SSL) en IMAP4-SSL (IMAP over SSL) gebruiken. Dit is ook redelijk standaard trouwens.

Als je encyrptie gebruikt is en goed kijkt hoe het in praktijk werkt zul je zien dat meestal direct duidelijk is met wie je 'spreekt'. Zoals welke website je bezoekt.

Kijk maar eens hoe HTTPS nu werkt, SSL/TLS verbind met een IP-adres dat uniek is voor die website. Of er wordt HTTP-virtualhosting-achtig protocol (SNI) gebruikt voor SSL/TLS en de naam van de website wordt in de clear meegestuurd.

Of te wel zien met wie je communiceerd is al redelijk duidelijk, zelfs met HTTPS. Kijken naar DNS is niet eens nodig.

[Reactie gewijzigd door Lennie op 27 augustus 2013 11:40]

De toegevoegde waarde is juist dat je encryptie kunt hebben zonder certificaat. Dat voordeel gaat veel verder dan alleen het niet nodig zijn van certificaten.

Aangezien eerst de TLS verbinding wordt opgezet, voordat de http header wordt gestuurd, is het niet mogelijk om een virtual server op een https verbinding te draaien. De server weet immers nog niet welk domein wordt aangesproken als de TLS verbinding wordt gelegd (die informatie zit in de http header), en kan dus niet het juiste certificaat sturen.

Oftewel, per IP adres kan je maar 1 https domein draaien, wat het erg duur in gebruik maakt. (totdat ipv6 grootschalig doorbreekt.)

Daar zijn ondertussen al oplossingen voor voorzien.

http://en.wikipedia.org/wiki/Server_Name_Indication#Support

Wordt dus tegenwoordig door de meeste browsers/servers mooi ondersteund.

Behalve IE op Windows XP, een combinatie die wij bij onze bezoekers helaas nog iets te vaak terug zien. Zo jammer, maar ook zo voorspelbaar.

Zo ook de Andriod 2.x browser.

Tenzij natuurlijk alle sites binnen dezelfde virtual server hetzelfde certificaat gebruiken.

Ik zie ook het nut niet boven https.

Edit: Als ze zonodig de veiligheid van communicatie willen verbeteren, laat ze dan eerst maar eens met een goede (makkelijk te gebruiken) standaard voor encrypted e-mail komen en zorgen dat deze wereldwijd correct wordt ondersteund.

[Reactie gewijzigd door Anoniem: 415197 op 26 augustus 2013 23:35]

Goede zaak, op die manier wordt internetverkeer gewoon by default versleuteld. Dit is veel makkelijker dan HTTPS voor 'normale' sites waar authenticatie niet nodig is omdat er geen certificaat hoeft worden aangevraagd.

Het is nu ook wel mogelijk om HTTPS met een self-signed certificaat te gebruiken, wat ongeveer op dezelfde beveiliging neerkomt als dit. Maar dat is geen praktische oplossing omdat elke browser hierover zal waarschuwen en vertikken te verbinden.

[Reactie gewijzigd door Compizfox op 26 augustus 2013 15:07]

verkeer naar "normale" websites die niet specifiek de 2.0 standaard ondersteunen, zal nog steeds onversleuteld zijn, alles wat legacy is zal dus nog even (on)veilig zijn

Met 'normaal' bedoelde ik niet legacy HTTP 1.1, maar sites die geen bank of webshop of iets dergelijks zijn.

Eigenlijk alle sites die op dit moment geen HTTPS maar HTTP gebruiken, zoals Tweakers dus

De HTTP 2.0-specificatie claimt vrij expliciet dat het de HTTP 1.1-standaard niet vervangt, maar dat ze naast elkaar zullen blijven bestaan.
Je kan dus ook niet van legacy HTTP 1.1 spreken en gezien de enorm complexe uitwerking - zeker in verhouding tot 1.1 - verwacht ik dat het ook jaren gaat duren voor 2.0 gemeengoed wordt.

Niemand ziet tegenwoordig meer op wat voor URL ze zijn, alleen de XXXXXXX.com is nog zichtbaar, de rest van de URL is lichtgrijs weggemoffeld, want alleen de domain name is namelijk HEEL belangrijk, de rest doet er niet meer toe...

Of er nou http of https voor staat... 99,9% van de mensen weten het niet eens en het zal ze een zorg zijn.... "ALS HET MAAR WERKT"

Voor een gemiddelde gebruiker is het domein ook het belangrijkst, denk aan phising, en HTTP of HTTPS wordt toch wel redelijk veel op gewezen.

Niemand ziet tegenwoordig meer op wat voor URL ze zijn, alleen de XXXXXXX.com is nog zichtbaar, de rest van de URL is lichtgrijs weggemoffeld, want alleen de domain name is namelijk HEEL belangrijk, de rest doet er niet meer toe...

Of er nou http of https voor staat... 99,9% van de mensen weten het niet eens en het zal ze een zorg zijn.... "ALS HET MAAR WERKT"

In Chrome wordt https groen en duidelijk getoond. In IE (10) wordt zowel http en https gewoon duidelijk getoond (niet grijs) en met https staat er een slotje bij. Ik denk dat je in de war bent met 'www'. Dat wordt ge-greyed. De rest niet.

In Internet Explorer heeft http en https toch echt een (iets) licht grijzere kleur. Als er HTTPS wordt gebruik verkleurt trouwens de hele URL balk naar groen of rood (hangt ervan af of het certificaat op orde is).

Wat heb je aan encryptie, als deze niet betrouwbaar is?
Toevoeging van Spdy is wel nuttig

Stel je voor dat jij en ik moeten ontsnappen van een tijger. Dan hoeft ik niet sneller te lopen dan de tijger, alleen maar sneller dan jij.

Het punt is, ze moeten met http 2.0 zorgen dat het snel omarmt wordt EN ze willen encryptie toevoegen. Dus is het optioneel. En het ontbreken van geverifieerde certificaten is niet ideaal, maar de tijger pakt eerder die gebruiker die geen encryptie heeft.

Maar misschien is die moeilijkere prooi wel vetter, dus zullen er ook tijgers zijn die daar achter aan gegaan.

Punt is, dat deze vorm van encryptie misleidend is.
Straks gaat iedereen met een HTTP-2.0 servertje zeggen dat die encryptie heeft.

De analogie van de tijger is toch best duidelijk. Iedere fiets is steelbaar maar degene die niet dubbel vast staat is als eerst weg. Zo dan?

De encryptie is niet misleidend, want is nog steeds geen https. Het is nog steeds http. Dus de browser kan nog steeds aan de gebruiker communiceren dat het certificaat niet wordt vertrouwd. Dus niet ieder servertje kan zeggen dat het encryptie heeft, om de simpele reden dat er geen secure protocol wordt gebruikt, maar gewoon http.

-kruimeldieven zal je altijd houden.
Maar op in de fietsen te blijven.

er staan 2 fietsen.
1 oude zonder slot
1 nieuwe van laten we zeggen 400 euro met een slot wat in 5 seonde te kraken is, omdat het slot te zwak is.

De betreffende dief, zal eerder achter die nieuwe gaan. Hij krijgt er ten slotte meer geld voor. En helemaal als hij weet dat dat keurslot, zo gemakkelijk te kraken is.

De encryptie is wel misleidend, omdat er gezegt wordt dat er encryptie gebruikt wordt, terwijl deze door $random app te ondersheppen is.

Zelfde als ik heb een veilig slot voor mijn fiets, maar iedereen heeft de master key.

Je hebt me overtuigd. Mail ze maar dat het een slecht idee is.

Weet je waarom encryptie wordt gebruikt ? Voornamelijk om een technische reden.

Omdat er allerlei "middle-boxes" zijn die aan HTTP zitten te prutsen (corporate firewalls, etc.) en de enige manier om een nieuwe versie uit te rollen is om encryptie toe te passen, want die boxes kunnen dan de nieuwere versie niet tegenhouden.

Dus encryptie altijd, is HTTP gevraagd dan zal er geen certificate verificatie plaat vinden. Is HTTPS gevraagd, dan wordt wel gecontroleerd.

Ander voordeel is dat meekijken naar het HTTP verkeer niet meer kan, alleen als iemand actief een man-in-the-middle attack uitvoert. Dus alleen sniffen is dan onvoldoende.

Al die "middle-boxes" krijgen ook een keer een update naar HTTP-2.0 en dan? Dan gaan we in eesn ROT24 gebruiken, zodat deze niet mee kunnen kijken?

Encryptie zonder een vorm van certificate verificatie is gewoon plain tekst.
HTTP 1.0 is een hele tijd veilig geweest, omdat er maar een beperkt deel van de mensen tcp packages konde lezen.

Je moet als cliënt de keus krijgen om wel of niet encrypted een connectie op te bouwen.

Dat is alsof je een telefoongesprek met iemand aangaat en je de optie krijgt om wel of niet afgeluisterd te worden als er toevallig iemand geïnteresseerd is in jouw gesprek.

Waarom de optie?

Dus is waarschijnlijk voor webservices op interne netwerken om de overhead van encryptie over te slaan en om debuggen mogelijk te maken.