Waarom het web nog niet achter HTTPS zit
Het aanbieden van alle websites over HTTPS in plaats van HTTP is een stuk eenvoudiger gezegd dan gedaan. Door de Firefox plugin Firesheep is 'session-sidejacking' een probleem dat massaal in de aandacht staat. Hierbij kunnen aanvallers de accounts van Twitter en Facebook-gebruikers kapen, ook al loggen die via HTTPS in. Het gebruik van SSL voor de complete sessie is de enige manier om luistervinken op onbeschermde draadloze netwerken op afstand te houden. Het gebruik van HTTPS kan echter voor 10% tot 20% meer processorbelasting zorgen, zegt Julien Sobrier van Zscaler Research. Een opmerkelijk getal, aangezien onderzoek van Google uitwijst dat de belasting minder dan één procent is.
Toch is dit niet het enige obstakel. Ook de toegenomen vertraging speelt een rol. Het opzetten van een SSL-verbinding vereist meer pakketjes. Eén HTTPS transactie bestaat al uit vier SSL handshake packets en zes data packets. Door alle extra bewerkingen zou dit het laden van websites vertragen.
Waarschuwing
Ook is het volgens Sobrier een uitdaging voor Content Delivery Networks (CDN), die snel content aan gebruikers willen leveren. Doordat veel partijen een alias gebruiken omdat ze niet willen dat de download van akamai.com zichtbaar is, kan dit voor een SSL-waarschuwing zorgen, aangezien het SSL-certificaat voor Akamai en niet voor de alias is uitgegeven.
Een ander probleem is dat HTTPS pagina's alleen externe content van andere HTTPS pagina's mogen bevatten, anders verschijnt er een waarschuwing dat er ook content van HTTP pagina's wordt aangeboden. Elke website moet ervoor zorgen dat zijn partners ook op HTTPS zitten. De waarschuwingen die browsers tonen zijn namelijk "eng", merkt Sobrier op. Zo waarschuwt Internet Explorer 8 gebruikers dat ze websites met SSL-fouten niet moeten bezoeken.
Zie http://en.wikipedia.org/wiki/Server_Name_Indication
Het zal gewoon een overgangsfase zijn, net als IPv6. Maar laten we maar hopen dat dit wat sneller gaat.
Ik ben wel nieuwsgierig naar hoe langzamer websites laden, 5% procent trager ofzo misschien?
Zolang we nog niet masaal over zijn op IPv6 is het dus godsonmogelijk om alles SSL te draaien.
Het vraagt eigenlijk om een geheel andere aanpak van het fenomeen internet. Een reorganisatie... Awel, prima dat het nog niet overal toepasbaar is, het lijkt me wel zaak om privacy gevoelige sites ASAP volledig te reorganiseren. De hobby site van tante Bep geloof ik wel.
Sobrier snapt dus echt niet waar het om gaat, waarom we volledige https willen.
Voorbeeldje: de Twitter button bijvoorbeeld kan je nog steeds niet via HTTPS laden (http://dev.twitter.com/pages/tweet_button_faq#https). Dit komt omdat Twitter gebruik maakt van CDN's.
Alle browsers van tegenwoordig (en sinds minstens 10 jaar) ondersteunen persistent connections (HTTP keep alive) en openen dus slechts enkele (meestal twee) verbindingen met de server. Je hebt die HTTPS handshake dus normaal gesproken maar twee keer per sessie. De extra CPU belasting als gevolg van de encryptie is nihil aangezien alleen de HTTPS handshake met public/private key encryptie (= relatief langzaam) werkt. Daarna spreken server en client een symmetrische sleutel af en wordt alles middels 128 of 256 bits symmetric encryptie versleuteld. Dit is aanzienlijk sneller en veel minder belastend voor de CPU.
Grote websites met webfarms kiezen meestal voor HTTP offloading naar een speciale HTTPS proxy of geïntegreerd met de load balancer(s). De servers zelf draaien dus gewoon HTTP maar al het verkeer wordt door de proxy/loadbalancer vertaald van/naar HTTPS. Anders zou je namelijk op iedere server een SSL certificaat moeten installeren. Nu hoeft dat maar op één of enkele plekken.
van http://en.wikipedia.org/wiki/Server_Name_Indication#Support
Browsers
Browsers with support for TLS server name indication:[6]
* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
* Internet Explorer 7 (Vista or higher, not XP) or later
* Google Chrome (Vista or higher. XP on Chrome 6 or newer[7]. OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
* Safari Safari 3.2.1 and newer on Mac OS X 10.5.6 and Windows Vista or higher, not XP
* Any Apple iDevice running iOS4 has support for TLS server name indication.
* Android
* Apache 2.2.12 or later using mod_ssl[8][9][10] (or alternatively with experimental mod_gnutls[11])
o See doc at [1]
* Cherokee if compiled with TLS support
* Versions of lighttpd 1.4.x and 1.5.x with patch [12], or 1.4.24+ without patch[13]
* Nginx with an accompanying OpenSSL built with SNI support
* acWEB[14] with OpenSSL 0.9.8j and later (on Windows)
[/quote]
Deze posting is gelocked. Reageren is niet meer mogelijk.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.