CloudFlare schakelt ssl voor gratis accounts in

CloudFlare heeft voor al zijn gratis accounts - ongeveer 2 miljoen websites - ondersteuning voor ssl ingeschakeld. Betaalde accounts hadden al langer ssl. Er is wel een nadeel: oudere browsers accepteren de CloudFlare-certificaten niet.

De beslissing om ssl in te schakelen voor gratis accounts, zorgt ervoor dat het aantal websites met ssl verdubbelt, beweert CloudFlare: dat waren er 2 miljoen, en daar komen circa 2 miljoen gratis CloudFlare-accounts bij. CloudFlare is een dienst die websites zich laat beschermen tegen onder meer ddos-aanvallen en als cache fungeert, zodat websites bij grote drukte overeind blijven.

De certificaten voor gratis klanten hebben wel een nadeel: ze zijn alleen geschikt voor modernere browsers. Alleen die hebben namelijk ondersteuning voor meerdere websites op één ip-adres; oudere websites ondersteunen maximaal één certificaat per ip-adres. Wie een recente browser gebruikt, zou geen problemen moeten ondervinden. Internet Explorer-gebruikers op Windows XP en gebruikers van Android-versies ouder dan Ice Cream Sandwich worden echter niet ondersteund.

De certificaten van CloudFlare gebruiken geen RSA, maar Elliptic Curve-cryptografie. Die zorgt ervoor dat de serverload vermindert en alle gratis accounts voorzien kunnen worden van ssl, aldus CloudFlare. Oudere browsers hebben eveneens geen ondersteuning voor Elliptic Curve-certificaten. Elliptic curve-cryptografie is moeilijker te kraken dan klassieke algoritmen zoals rsa.

Uit statistieken van CloudFlare blijkt dat 85 procent van de Nederlandse bezoekers een browser gebruikt die recent genoeg is. Naar eigen zeggen had CloudFlare geen andere mogelijkheid om ssl in te schakelen: het bedrijf zou dan 2 miljoen ip-adressen moeten aanvragen, maar daarvoor zijn te weinig ipv4-adressen voorhanden. Betaalde accounts kunnen wel een eigen ip-adres krijgen en daardoor ook verbindingen met oude browsers versleutelen.

Overigens moeten websitebeheerders zelf nog de verbinding tussen CloudFlare en de webserver versleutelen om echt veilig te zijn; CloudFlare levert een certificaat om dat mogelijk te maken. Ook worden websitebezoekers niet automatisch verwezen naar de https-versie, al kunnen beheerders dat wel aanzetten.

Reacties (18)

Ofwel ze gebruiken SNI, is een beetje lastig op te maken uit deze nieuws post:

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

Server Name Indication (SNI) is an extension to the TLS computer networking protocol[1] that indicates to what hostname the client is attempting to connect at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 virtual hosting for HTTPS.

To make use of SNI practical, it is necessary that the vast majority of users use web browsers that support it. Users whose browsers do not support SNI will be presented with a default certificate and hence are likely to receive certificate warnings, unless the server is equipped with a wildcard certificate that matches the name of the website.

tweakers begint steeds meer jip en janneke berichtjes te plaatsen. Van mij had dit soort technische details best in het bericht mogen staan.

Een ander niet-Jip-en-Janneke aanvulling is dat met eliptical curve certifciaten gaat gebruiken ipv de nu gebruikelijke RSA.

Microsoft ondersteunt dat sinds Vista, hetgeen verklaart waarom XP buiten de boot valt. Tot nu toe echter wilde deze certifciaten niet van de grond komen. Waarschijnlijk omdat er in het begin wat onduidelijkheid was over patenten.

CloudFlare zelf begin 2014 verkondigde nog trots dat hun eigen HTTPS mini-blog één van de eerste 50 websites ter wereld was die dit nieuwe certificaat gebruikte. En vervolgens binnen een maand vervingen ze het door een gewoon RSA certifciaat vanwege het gebrek aan ondersteuning

Maar sindsdien is XP uitgefaseerd (offiieel dan ) en kan men dus waarschijnlijk beter deze diensten gaan uitrollen.

De implementatie van ECDSA binnen BouncyCastle is overigens niet bepaald snel te noemen. Op (oudere hardware met) Android zou je het performanceverlies van ECDSA ten opzichte van RSA dus wel kunnen merken.

@Armin: Als je gewoon OpenSSL (of een fork;)) gebruikt zou het inderdaad sneller moeten zijn. De stelling van CloudFlare dat het sneller is klopt dan dus ook voor wat betreft hun servers (native C). De Java-implementatie (BouncyCastle) daarentegen schijnt niet al te best te presteren, zie Google.

[Reactie gewijzigd door jvd-nl op 30 september 2014 00:26]

Op Android zou je het performanceverlies van ECDSA ten opzichte van RSA dus wel kunnen merken.

Voor de duidelijkheid, dus jij zegt dat op Android ECDSA ipv sneller (wat je normaal zou verwachten), langzamer is ivm de brakke implementatie?

Let wel, ik zeg niet dat dat niet waar is, ik vraag alleen of ik je goed begrijp

Ik ben nog steeds aan het wachtern op de uitrol. Ik heb nog geen enkele CloudFlare website gevonden waar dit nu daadwerkelijk uitgerold is. (Het schijnt zo'n 12 a 24 uur te duren na aanzetten.) En die paar websites waarvan de eigenaren zeggen dat het aangezet is, gebruiken nog steeds RSA.

Ik heb namelijk nog nooit een werkelijke HTTPS website gezien met ECDSA certificaten. Zoals gezegd CloudFare zelf rapporteerde eerder dit jaar dat het totale aantal op aarde minder dan 50 was, dus zo gek was dat gelukkig niet.

Maar ik wil het nu wel eens 'in het echt zien', zodat ik ook eens kan testen hoe snel/langzaam dit ECDSA nu is. Men praat er immers al 10 jaar over, maar het bestaat dus nog steeds nergens.

'We' zijn live:

https://www.ssllabs.com/s...ompany.com&s=104.28.25.86

De meeste browsers ondersteunen het wel (IE6 is geloof ik de laatste die het niet ondersteunt). Als web developer is het vervelender dat bijvoorbeeld de SLL module in Python 2.7 en Pinterest het niet ondersteunen.

SNI wordt niet ondersteund t/m IE8 op Windows XP. Er zijn nog best veel computers met Windows XP, dus er blijft een doelgroep waarop SNI niet wordt ondersteund (tenzij zij op Windows XP een andere moderne browser gebruiken).

Ik hoop toch dat de meeste mensen die nog Windows XP gebruiken, een andere browser dan Internet Explorer gebruiken....

[Reactie gewijzigd door Soultaker op 29 september 2014 23:23]

Ook worden websitebezoekers niet automatisch verwezen naar de https-versie, al kunnen beheerders dat wel aanzetten.

Kunnen beheerders zelf bepalen welke HTTP headers zij meesturen? Zo ja, dan is het relatief simpel om HTTP Strict Transport Security in te schakelen. Na het eerste keer bezoeken van de site (of de site plaatsen op een lijst die met de browser wordt meegeleverd) wordt dezelfde site in de toekomst alleen nog maar via SSL bezocht, zelfs als de gebruiker per ongeluk 'sitenaam.ext' intypt of zelfs 'http://sitenaam.ext'. Als de site niet beschikbaar is via SSL, wordt er geen onveilige verbinding gemaakt.

Toegegeven, de eerste keer bezoeken van een site kan dan onveilig zijn (door http te gebruiken in plaats van https), maar als op dat eerste bezoek geen aanval is, dan zijn alle opvolgende bezoeken veilig.

Een reden waarom CloudFlare dit waarschijnlijk doet is omdat zoekmachines zoals Google SSL sites een hogere score (gaan) geven, waardoor ze hoger in de index komen te staan.

[Reactie gewijzigd door The Zep Man op 29 september 2014 18:24]

Ben ik de enige die tijdens een (betaalde) cloudflare periode meer downtime had dan zonder cloudflare?
Ik had vrijwel nooit last van downtime totdat ik van de dienst gebruik ging maken.
Zodra AMS op hun twitterfeed tevoorschijn kwam lag mijn site er in Nederland uit. En dat gebeurde wel een keer per week.

Enigszins offtopic, maar dat is wel een 'probleem', ja. Als je normaal nooit ergens last van hebt dan heb je bij Cloudflare ineens wel last van 'downtime' (of eigenlijk, dat je onbereikbaar bent voor een deel van het publiek). Dat is omdat een aanval op hun AMS colocatie, bijvoorbeeld, dan ineens ook voor jou problemen oplevert.

Als je echter zelf wel, bijvoorbeeld, regelmatig een DDoS te verstouwen krijgt, of anderszins downtime ondervindt dan scheelt het weer wel veel. (En de DDoS-last komt niet zo snel op jouw server te liggen.)

SSL/ PRO / BUSINESS / ENTERPRISE
[That feature requires a higher subscription level than is currently active for domain.com]

Waarschijnlijk is het nog niet volledig uitgerold.

https://blog.cloudflare.com/introducing-universal-ssl/:

"For new customers who sign up for CloudFlare's free plan, after we get through provisioning existing customers, it will take up to 24 hours to activate Universal SSL."

Het kan dus nog 24 uur duren voordat alles geactiveerd is.

Hier hetzelfde. Bij login kreeg ik de mededeling dat er een nieuwe SSL feature beschikbaar is, maar bij het selecteren van SSL krijg ik inderdaad ook:

[That feature requires a higher subscription level than is currently active for domain.com]

We gaan het morgen maar eens uittesten.

Cool... Dan ga ik mijn sites achter cloudflare ook op ssl zetten....

Volgens mij snap je het principe niet echt. Het gaat hier vooral om websites die nu GEEN SSL gebruiken. Daar is dus geen MITM voor nodig want iedereen kan alles lezen. Nu wordt dus een deel van het traject versleuteld.

Ik ben het er volstrekt mee eens dat dit slechts beperkt zin heeft indien de klant zelf niet zijn verkeer naar cloudflare ook versleuteld, maar met MITM heeft dit weinig te maken.

(Waarschijnlijk ben je in de war met de keyless SSL feature die CloudFlare vorige week introduceerde. Dat is een MITM'achtige structuur. Doch echter nog steeds niet onveilig door de wijze van opzetten.)