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.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?