Google: 97 procent YouTube-verkeer over https

YouTube heeft in een blogpost gemeld dat 97 procent van zijn verkeer via versleutelde verbindingen loopt. Dat het bedrijfsonderdeel van Google de 100 procent niet haalt, komt volgens het bedrijf doordat sommige apparaten moderne vormen van https niet ondersteunen.

Het hoopt binnen niet al te lange tijd niet-versleutelde verbindingen volledig uit te faseren, maar hoe lang dat zal duren, is onbekend. Het grootste deel van de onversleutelde data gaat naar mobiele apparaten, namelijk 96,2 procent. Vermoedelijk gaat het om apparaten die nooit meer een upgrade krijgen naar een versie waarin modern https of http/2 ondersteund wordt, schrijft Google in een rapport over de overgang naar https.

Andere redenen dat https niet ondersteund wordt is omdat sommige landen en organisaties https-verkeer blokkeren of op andere manieren slechter doorgeven. Ook het managen van certificaten via verschillende domeinen voor sites die via Blogger gehost worden, leveren soms problemen op omdat er ook niet-Google-domeinen gebruikt kunnen worden.

Implementatie van https voor YouTube startte in 2014. In maart 2014 kondigde Google aan dat Gmail alleen nog via https bereikbaar is. Andere diensten volgden snel, maar zijn geen van allen volledig over. Ook stapte google.com en YouTube over op hsts waardoor per ongeluk naar http-url's navigeren, wordt vermeden. Tweakers stapte onlangs volledig over op https wat ook niet over één nacht ijs ging.

Reacties (19)

[Docschnitzel]

Wat is er eigenlijk zo lastig aan een mogratie naar https en hsts?

[FrankHe]

Dat zijn eigenlijk een twee tal zaken. (edit: deze gelden zowel voor de implementatie bij Google, Tweakers en eigenlijk iedere site / online platform)

In de eerste plaats de eigen infrastructuur en applicaties bij Google zelf. Gelukkig is Google nog een relatief jong bedrijf maar ze zijn al lang genoeg present om toch al de nodige legacy in de systemen te hebben. Dat is een ding wat opgepakt is / moet worden. Afhankelijk van de kwaliteit en discipline van de ontwikkelaars in het verleden kan dit een betrekkelijk eenvoudige klus zijn maar doorgaans heeft dit best wel de nodige voeten in de aarde om alles helemaal naar https om te bouwen.

De andere is externe afhankelijkheden, te weten, het ontvangende apparaat. Hierbij ga je gegarandeerd de nodige legacy devices tegenkomen. Een oude smartphone of misschien nog een verdwaalde PC met Windows XP installatie, ze zijn er allemaal nog steeds. Of dat verstandig is? Nee, als je tante of oma nog XP gebruikt, als de sodemieter die bak uitzetten en even met familie en vrienden 300 euro bij elkaar leggen voor een machine die meer bij de tijd is. Maar ook met meer recente apparaten zul je problemen tegenkomen het de ondersteuning van https. Dit komt omdat https ook al behoorlijk oud is waardoor oudere vormen van https middels SSL bijvoorbeeld niet meer als veilig worden beschouwd. Daarom is https TLS nu de standaard. Het liefst met een zo lang mogelijke sleutel. Dus geen 128 bit meer maar voortaan ten minste 265 bits en het liefste 1024 of zelfs hoger. Niet alle devices ondersteunen deze hedendaagse standaard van https. Dan kun je ervoor kiezen om deze wel te blijven ondersteunen maar dit houdt in dat je aan de serverkant je de standaarden ook moet verlagen tot bijvoorbeeld SSL 128 bit. Maar dat wil je niet. De server stel je in op het accepteren van minimaal TLS 265 bit. Hierdoor zullen oudere devices die dit niet ondersteunen geen verbinding kunnen maken met je platform. De enige manier die dan nog wel werkt is het ouderwetse onversleutelde http. Google maakt hierin naar mijn mening de juiste keuzes. Als iets niet meer veilig genoeg is (SSL 128 bit) dan trek je de ondersteuning ervan in. Het is dan jammer dat nog een paar procent uitsluitend via http met de kan communiceren maar dat is dan maar zo. De verwachting is gelukkig dat dit percentage per maand zachtjes aan iedere keer een beetje kleiner wordt.

[Reactie gewijzigd door FrankHe op 30 juli 2024 23:12]

[PolarBear]

Daarom is https TLS nu de standaard. Het liefst met een zo lang mogelijke sleutel. Dus geen 128 bit meer maar voortaan ten minste 265 bits en het liefste 1024 of zelfs hoger. Niet alle devices ondersteunen deze hedendaagse standaard van https. Dan kun je ervoor kiezen om deze wel te blijven ondersteunen maar dit houdt in dat je aan de serverkant je de standaarden ook moet verlagen tot bijvoorbeeld SSL 128 bit. Maar dat wil je niet. De server stel je in op het accepteren van minimaal TLS 265 bit.

128 bits symmetrische encryptie (want daar heb je het over) is voorlopig meer dan voldoende. De meerwaarde van 256 bits is vrij laag, sterker AES256 is relatief zwakker dan 128 bits.

Volgens mij haal je een aantal dingen door elkaar, je hebt het protocol SSL/TLS waarbij SSL eigenlijk volslagen achterhaald is (maar nog beter dan niets) en TLS wil je eigenlijk in ieder geval boven v 1.0 zitten. Daarboven op heb je het key exchange/agreement wat met asymmetrische encryptie gaat (Youtube gebruikt bij mij ECDHE_ECDSA). Omdat Google elliptic curve encryptie gebruik kan je het aantal bit niet zomaar gelijken met voorheen gebruikte Diffie-Hellman. Dan de daadwerkelijke encryptie van de de verbinding wat met AES_128_GCM gaat (bij Youtube).

Google gebruikt dus gewoon een AES 128 bits encryptie.

[linuxguru1]

128 bits symmetrische encryptie (want daar heb je het over) is voorlopig meer dan voldoende. De meerwaarde van 256 bits is vrij laag, sterker AES256 is relatief zwakker dan 128 bits.

Misschien is het de moeite waard daarbij te vertellen dat het gaat over aanvallen op AES256 van 10 rounds en minder.

Voor zover ik weet is de beste aanval op full AES de volgende: https://lirias.kuleuven.b...456789/314284/1/aesbc.pdf

[eurob]

Heeft het encrypten en decrypten invloed op de snelheid van serveren van video naar de client?

[jeroen7s]

ja, de encryptie heeft natuurlijk een invloed, maar deze is zeer verwaarloosbaar

[Vaan Banaan]

Inderdaad.
De asymmetrische sleutel is meestal ECC 256 wat te vergelijken is met een RSA 3072 bit sleutel, dus een stuk korter en vreet minder CPU cycles
IE8 ondersteunt geen ECDSA, ik vemoed dat daar die paar procenten vandaan komen wat onversleuteld van de desktop komt.
Rapport uit 2015: http://csrc.nist.gov/grou...session2-andrews-rick.pdf

[Pimorez]

Ik denk dat je daarvoor best het gelinkte artikel over de overstap van Tweakers naar https kunt lezen (staat in de onderste alinea).

[Raindeer]

Hoeveel procent van het Tweakers verkeer is over HTTPS?

Goed van Google dat ze dit doen. De echt repressieve regimes stop je er niet mee, want die gebruiken proxies etc. Maar het is een extra laag waar bedrijven, de gewone hacker en ISPs niet door komen

[jer123c]

Gezien tweakers naar mijn weten niet op dergelijke legacy devices gebruikt wordt lijkt mij dit 100% (ervanuitgaand dat elke pagina van tweakers https is.).

[FrankHe]

Goed om te horen dat de migratie naar https zo goed als voltooid is. Een nieuwe stap opweg naar een veiligere wereld met meer rechtszekerheid en gegarandeerde vrijheid. Ieder individu is vrij om de informatie te verkrijgen die zij of hij naar eigen inzicht relevant en nuttig denk te vinden. Of het nu gaat over kwasie onbenullige kattenvideo's of andere zaken met een eventueel meer diepere betekenis.

De volgende stap is nu om ervoor te zorgen dat alle onderwerpen evenredig goed vindbaar zijn en blijven. Vormen van AI (kunstmatige intelligentie) kunnen helpen om in onnoemelijk grote sets van bewegende data relevante correlaties te ontdekken en deze inzichtelijk te maken. Dat is natuurlijk bij uitstek waar Google mee bezich is. Dankzij https is de datacommunicatie tussen jou en Google in ieder geval verzekerd van authenticiteit, er zit geen andere partij tussen die iets met de data kan doen. Wat nog rest is het zelfregulerende vermogen van Google zelf om ervoor te zorgen dat de geserveerde data waarheidsgetrouw is en een correcte afspiegeling vormt van wat er zich in de wereld, op internet afspeelt.

Hopen op een zonnige toekomst van de mensheid

[keitje]

Zo heeft de Blackberry Playbook een YouTube player die geen HTTPS ondersteund.

[Navi]

Ze kunnen beter http gewoon niet meer serveren, moet je eens kijken hoe snel de apparaten zich dan aanpassen als Youtube niet meer ondersteunt wordt..

[CH4OS]

Google pocht hier wel zo leuk mee, maar als je je site forceert naar HTTPS en HTTP verzoeken redirect naar HTTPS, is het ook niet meer zo "raar" dat het verkeer dan voornamelijk HTTPS-verkeer is, niet?

Mede hierdoor hou je ook wel wat HTTP verkeer uiteraard, dus ik denk ook niet, dat 100% HTTPS-only verkeer haalbaar zal zijn.

[CAPSLOCK2000]

Ik ben blij dat de wereld eindelijk heeft geaccepteerd dat HTTPS de standaard hoort te zijn. Ik in het commentaar boven mij is er nog niemand die nog in twijfel trekt of HTTPS wel nodig is en of het niet veel te duur of langzaam is. Een jaar geleden was dat wel anders, toen vonden velen HTTPS nog niet nodig voor "gewone" websites en werd het zelfs als overdreven en overbodig gezien.

[sdk1985]

Er kleven helaas nog wel een aantal nadelen aan HTTPS. Waarschijnlijk heb je zelf ook gemerkt dat tweakers regelmatig een stuk trager is sinds de overstap naar SSL. Het kost gewoon vele malen meer rekenkracht aan de serverkant. Het internet in de huidige vorm is nog lang niet klaar voor een volledige overstap.

[CAPSLOCK2000]

Er kleven helaas nog wel een aantal nadelen aan HTTPS. Waarschijnlijk heb je zelf ook gemerkt dat tweakers regelmatig een stuk trager is sinds de overstap naar SSL. Het kost gewoon vele malen meer rekenkracht aan de serverkant. Het internet in de huidige vorm is nog lang niet klaar voor een volledige overstap.

In mijn ervaring valt het allemaal reuze mee, voor de meeste websites maakt het helemaal niks uit.


De server is maar zelden het probleem. Moderne processoren hebben hardwareondersteuning waardoor SSL erg snel is geworden. Het is eerder de CPU in je telefoon die het niet aan kan, al is hardwareondersteunde crypto daar inmiddels ook de norm.

Voor de meeste sites is de CPU toch al niet de bottleneck, de meeste CPU's zijn voornamelijk idle want die sites krijgen niet genoeg bezoekers. Als er al een bottleneck is dan is het eerder de disk, RAM of het netwerk dan de CPU. Als CPU wel de bottleneck is dan is het typisch omdat de applicatie veel CPU nodig heeft, dat beetje extra voor SSL zal het verschil dan niet maken.

Uiteindelijk kost SSL maar een klein beetje extra en we krijgen er veel voor terug.

[sdk1985]

[...]


In mijn ervaring valt het allemaal reuze mee, voor de meeste websites maakt het helemaal niks uit.


De server is maar zelden het probleem. Moderne processoren hebben hardwareondersteuning waardoor SSL erg snel is geworden. Het is eerder de CPU in je telefoon die het niet aan kan, al is hardwareondersteunde crypto daar inmiddels ook de norm.

Voor de meeste sites is de CPU toch al niet de bottleneck, de meeste CPU's zijn voornamelijk idle want die sites krijgen niet genoeg bezoekers. Als er al een bottleneck is dan is het eerder de disk, RAM of het netwerk dan de CPU. Als CPU wel de bottleneck is dan is het typisch omdat de applicatie veel CPU nodig heeft, dat beetje extra voor SSL zal het verschil dan niet maken.

Uiteindelijk kost SSL maar een klein beetje extra en we krijgen er veel voor terug.

Dat is niet hoe het werkt. Een goede website draait niet live op de MySQL database maar gebruikt zo veel mogelijk caching. Hierbij wordt de output van php/MySQL in de simpelste vorm (plugin caching) als statische html pagina opgeslagen. Op deze manier kan een server letterlijk duizenden verzoeken per seconde afhandelen. (Natuurlijk zijn er vele andere/betere vormen van caching en kun je ook aan de SSL kant dingen cachen, maar laten we het even begrijpelijk houden...).

Ga je SSL introduceren dan gaat die waarde flink omlaag. Zie dit voorbeeld:

quote: https://github.com/vulcand/vulcand/issues/196

SSL
Concurrency Level: 40
Time taken for tests: 24.536 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 755000 bytes
HTML transferred: 10000 bytes
Requests per second: 203.79 [#/sec] (mean)
Time per request: 196.285 [ms] (mean)
Time per request: 4.907 [ms] (mean, across all concurrent requests)
Transfer rate: 30.05 [Kbytes/sec] received

Geen ssl
Concurrency Level: 40
Time taken for tests: 1.995 seconds
Complete requests: 5000
Failed requests: 0
Total transferred: 755000 bytes
HTML transferred: 10000 bytes
Requests per second: 2506.69 [#/sec] (mean)
Time per request: 15.957 [ms] (mean)
Time per request: 0.399 [ms] (mean, across all concurrent requests)
Transfer rate: 369.64 [Kbytes/sec] received

Dat scheelt dus meer dan factor 12. Als het hele internet morgen met SSL stopt dan kunnen we de helft van de datacenters sluiten .

Ben overigens wel benieuwd naar de vele voordelen die jij in SSL ziet. Zakelijk is het niet meer dan logisch, dat staat niet ter discussie. Maar welk voordeel zie jij voor het bezoeken van tweakers.net vanaf een prive verbinding (ongedeeld, eigen ip) met een prive computer (opnieuw ongedeeld)? Is geen retorische vraag, ben oprecht benieuwd.

[Reactie gewijzigd door sdk1985 op 30 juli 2024 23:12]

[CAPSLOCK2000]

Ben overigens wel benieuwd naar de vele voordelen die jij in SSL ziet. Zakelijk is het niet meer dan logisch, dat staat niet ter discussie. Maar welk voordeel zie jij voor het bezoeken van tweakers.net vanaf een prive verbinding (ongedeeld, eigen ip) met een prive computer (opnieuw ongedeeld)? Is geen retorische vraag, ben oprecht benieuwd.

Het grote voordeel is dat je er niet meer over hoeft na te denken.
Nu wordt SSL nog als iets bijzonders behandelt. Iemand moet beslissen of SSL nodig is of niet. De meeste mensen zijn niet in staat om die afweging te maken, ze missen de achtergrond. Vervolgens moet er een SSL-cert gekocht worden en moet iemand aan het werk om de webserver te configureren. Dat is extra werk tegen een meerprijs. Vervolgens moet bij iedere aanpassing aan de website opnieuw worden beoordeelt of SSL nodig is of niet en voor welke URLs. Ook dat zal vaker fout dan goed gaan, als ik de gemiddelde websitebeheerder ken.
Ik zie liever dat SSL de standaard wordt, dan hoeft er nooit meer iemand na te denken of het nodig is en kan het ook niet fout gaan. Omdat het standaard is op iedere website hoeft de beheerder niks extra's te doen, dat drukt de kosten van de implementatie.

Ik vergelijk het wel eens met papieren brieven. Die worden standaard in een envelop verstuurd en zijn dan wettelijk beschermd via het briefgeheim. Een ansichtkaart heeft die bescherming niet. Iedereen die hem ziet kan hem lezen. Daarom gebruiken de meeste bedrijven maar altijd een envelop. Het is beter om de kosten van wat extra envelopjes te betalen dan dat bij iedere brief iemand moet nadenken over het gebruik van een envelop of niet. Dat kost een hoop tijd en vroeg of laat gaat het fout.