EFF wil gratis certificaten uitdelen via onafhankelijke certificaatautoriteit

De Electronic Frontier Foundation heeft Let’s Encrypt aangekondigd. De onafhankelijke Internet Security Research Group zal vanaf aankomende zomer gratis certificaten verstrekken. De EFF werkt samen met Mozilla, Cisco, Akamai, IdenTrust en onderzoekers van de universiteit van Michigan.

Volgens de EFF moet de Let's Encrypt-dienst er voor gaan zorgen dat websitebeheerders in minder dan een minuut een certificaat voor een website kunnen installeren, waardoor de sites voortaan via versleutelde https-verbindingen benaderbaar zijn. Momenteel zou een gemiddelde webmaster nog 1 tot 3 uur nodig hebben om een certificaat aan te vragen en op de juiste wijze te installeren, doordat het proces complex en bureaucratisch is. Ook komen er de nodige kosten bij kijken.

Voor het Let’s Encrypt-initiatief ontwikkelt EFF een Linux-tool waarmee het aanvragen en de installatie van een certificaat op een Apache-webserver vrijwel geheel wordt geautomatiseerd. De tool maakt het ook mogelijk om certificaten in te trekken en om te bepalen of een website uitsluitend via https of tevens via het onversleutelde http-protocol benaderbaar is.

De Let's Encrypt-tool werkt bij het aanvragen van een gratis certificaat op basis van het ACME-protocol terwijl via diverse online databases wordt gecontroleerd of een certificaataanvraag al dan niet gehonoreerd moet worden. Tevens is de onafhankelijke en non-profit Internet Security Research Group opgericht samen met Mozilla en de universiteit van Michigan. Cisco, Akamai en IndenTrust ondersteunen het project op technisch vlak. De eerste certificaten kunnen vanaf aankomende zomer worden aangevraagd.

De EFF stelt dat het inmiddels hoogst noodzakelijk is om alle websites die nog op http draaien te laten overstappen naar https. Als redenen noemt de privacybeweging verbeterde beveiliging en het moeilijker maken van internetcensuur en het bespieden van internetgebruikers door bedrijven of overheden.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (131)

[unglaublich]

Toevallig net nog mijn certificaten vervangen voor SHA-2 certificaten. Ik moet eerlijk zeggen dat het vervangen van 3 certificaten mij 1 uur duurde inclusief genereren, approval en installatie. Dat vind ik wel meevallen. Het zou wel beter geautomatiseerd kunnen worden.

Als mensen toevallig hun eigen SSL certificaten hebben is het misschien goed om te checken:
https://shaaaaaaaaaaaaa.com/

[Jo0p]

Hoe betrouwbaar is dit? Google.com .nl en zelfs abnamro.nl faalt!

[unglaublich]

Omdat ze zo veel mogelijk gebruikers willen blijven ondersteunen blijkbaar? Als ik het zo bekijk klopt het inderdaad dat ze SHA-1 certificaten gebruiken:

SHA-1 with RSA Encryption ( 1.2.840.113549.1.1.5 )

Maar goed, ook zij zullen spoedig over gaan lijkt me.

[teek2]

Super.
Je wilt niet weten hoe lastig het is om een certificaat te krijgen. Zeker als je aardig wat speelt met webservers en email. Voor elke domein weer door dezelfde rompslomp is te irritant en complex. En als je zelf een certificaat maakt krijgen mensen waarschuwingen te zien waardoor ze meteen weggaan van je site.

[freaky]

Je wilt niet weten hoe lastig het is om een certificaat te krijgen

Verklaar je nader... Vraag zo'n 10-40 DV certificaten per maand aan en heb ze allemaal binnen 10-15 minuten inc installatie tenzij ik heel moeilijk moet doen om bij het e-mail adres voor de verificatie te komen. Beheer niet bij alle klanten ook de e-mail.

Dat enkele hier het proces niet snappen of het te moeilijk vinden zegt meer over de kwaliteiten van die personen als systeembeheerder dan het proces zelf.

[teek2]

Juist! Als systeembeheerder! En de EFF wil juist dat normale mensen zoals ik ook met certificaten aan de gang gang.

Als ik er 10-40 per maand aanvraag kan ik het ook vast op een gegeven moment binnen 15 minuten (wat nog steeds belachelijk lang is natuurlijk vergeleken met het opzetten van een hele server (bij digital ocean) binnen een minuut.)

Hoe lang duurde het bij jou, vanaf het moment dat je voor het eerst een webserver aan de praat had tot aan het moment dat je het hele certificaat-aanvraagproces goed genoeg snapte om er 1 in het echt te gebruiken? Dat is de vraag.

[Reactie gewijzigd door teek2 op 22 juli 2024 13:24]

[freaky]

Nee dat is niet de vraag.

Ik laat m'n buurvrouw namelijk m'n auto ook niet keuren voor de APK. Sterker nog, dat mag ze niet eens van de overheid.

Als je een webserver beheert en veiligheid wil pretenderen dan mag je als bezoeker aannemen dat iemand met verstand van zaken dat gedaan heeft. Of die nu ingehuurd is of in dienst is zal mij een biet wezen.

Vreemd genoeg is er in IT land een of ander globaal heersend concept dat iedereen het zelf maar moet kunnen terwijl we het wel normaal vinden dat de ketel wordt nagekeken door een erkend vakman, het gas wordt aangelegd door een erkend vakman, de auto wordt gecontroleerd door een gecertificeerd monteur, etc.

Waarom zou dat hier anders zijn?

[Reactie gewijzigd door freaky op 22 juli 2024 13:24]

[teek2]

Ik wil dat ik veilig op mijn Drupal installatie kan inloggen en ik wil dat mijn vrouw niet allerlei alarmmeldingen krijgt als ze mijn mailserver op haar telefoon instelt.
Daarvoor moet ik een certificaat krijgen. En ja, dat krijg ik wel voor elkaar hoor. Het kost veel tijd om me in te lezen over hoe dat moet.

Dat jij vind dat niet Jan en alleman een certificaat mogen krijgen maar dat dat aan een soort elite voorbehouden moet blijven, die wel de tijd en het geld hebben om die hele zooi uit te zoeken is een vreemd soort protectionisme. Er zijn namelijk geen nadelen aan het makkelijker beschikbaar maken van certificaten. Elke crimineel die er iets mee wil kan dat nu ook al.

Wat jij vind is dat een apparaat wat makkelijker stucken mogelijk maakt niet op de markt moet komen want dat is zielig voor de stuckers? Kom op zeg. Of om in jouw voorbeeld te blijven: Je vind dat het mij moeilijk moet worden gemaakt om mijn eigen auto te onderhouden? Dan ben je geen tweaker in ieder geval.

[Reactie gewijzigd door teek2 op 22 juli 2024 13:24]

[freaky]

Dat kan toch ook? Je moet dan alleen tijd investeren om iets te leren. Dat moest je ook om te leren spreken, fietsen, autorijden, etc. En dat ligt niet aan de mensen om jouw heen, de fabrikant van je fiets of de fabrikant van je auto. Het ligt zuiver en alleen aan het feit dat je die kennis nog niet hebt.

Het hoeft wat mij betreft helemaal niet voorbehouden te blijven aan elite (wel met de kanttekening dat het bij dingen van groter belang, zoals een webshop, toch wel prettig is dat het gedaan wordt door iemand die het niveau hobbyist overstijgd). Wellicht dat het APK voorbeeld niet de beste was.

Dat je er iets voor moet leren is echter niet de fout van de certificaten noch hun leveranciers. Je wilt blijkbaar hobbyen en begint dan te klagen over het feit dat het je aan de kennis ontbreekt. Beetje vreemd.

Je neemt namelijk wel een kant en klare dienst af voor je server. Daarom had je hem zo snel staan - je hebt dat deel dus wel uitbesteed... En dat is vergaand te automatiseren, met certificaten ligt dat aanzienlijk lastiger. Een image van een kant en klare webserver uitrollen is nou eenmaal makkelijker (het goed inrichten van die webserver daarentegen wellicht weer niet).

[Verwijderd]

"Normale mensen" zullen niet met de hand een web server beheren. Die zullen dat over het algemeen doen met een controle paneel van een hosting provider.

Je mag er denk ik vanuit gaan dat de bekendere controle panelen binnen afzienbare tijd het aanvragen en installeren van deze gratis SSL-certificaten met 1 druk op de knop zullen ondersteunen. Wellicht zelfs automatisch en volledig transparent bij elk domein wat je via datzelfde controle paneel beheert.

Doen ze dat niet dan hierbij de gratis tip voor hosting providers die zich willen onderscheiden

[vDorst]

Ik heb het van het weekend nog een keer gedaan. Binnen 1 uur had ik het goed werkend.
Ik moes wel uitzoeken elke type certificaat ik wilde en hoe deze te generen/installeren in linux.

[teek2]

Maar dan heb je niet de tijd meegerekend die het kost om te snappen hoe het werkt, welke je nodig hebt (ja er zijn meerdere soorten, die de bank heeft kan jij niet betalen), waar je die het beste gratis kunt krijgen en hoe je het in nginx/apache krijgt. Jij bent al een aardige expert.

Nginx aan de praat krijgen onder ubuntu is zo simpel als apt-get install nginx ... maar dan moet je een certificaat gaan installeren.

[Kees]

En toch bieden de certificten van een bank geen greintje meer zekerheid of betere encryptie dan een 9 euro rapidssl certificaat.

Hoog tijd dat deze markt gratis gaat worden voor de basis certificaten. Hopelijk komt er voor een Extended Validation certificaat ook een goedkope oplossing.

[TDeK]

Technisch stelt het idd geen klap voor, maar het zit hem in de 'chain of trust'. Een secure verbinding is één, maar ben ik ook wel echt verbonden met Google of mijn bank? Dat stukje verificatie is waar EV SSL certificaten om draaien. Want wat houdt mij tegen om bij een gratis certificate authority een certificaat voor google.com aan te vragen (of *.com) en die te gebruiken bij een MitM aanval? Jij ziet dan nog steeds netjes een groen slotje. En technisch is het perfect SSL, maar in de praktijk wordt al je verkeer onderschept.
De CA is dus zowel noodzakelijk als de grootste zwakte van deze hele chain of trust. Idealiter bellen ze elke aanvrager na, maar dat gebeurt vaak niet. En wat moet je doen als een CA corrupt blijkt te zijn (vb Diginotar)? Alle root certificates zitten in de browsers gebakken en deze handmatig uitzetten zorgt voor niet opbouwende SSL verbindingen. Zie ook http://convergence.io

[Kees]

Klopt, maar het is niet zo dat hoe meer je betaald voor een certificaat hoe beter de chain of trust is. Ook bij een gratis certificaat krijg jij geen google.com certificaat te pakken, domweg omdat de verificatiemail naar het mailadres in de whoisgegevens gaat bijvoorbeeld.

En corrupte CA's, de chinese overheid kan ook certificaten uitleveren die door elke browser geaccepteerd worden. Die hebben ook geen hele frisse reputatie qua internet veiligheid.

[TDeK]

Zo gauw een CA is opgenomen in de browser root certificate lijst kunnen ze doen wat ze willen. Google eens op Comodo en zie hoeveel incidenten ze wel niet hebben gehad. Of wat denk je van een gestolen private root key? Dan kan ik signeren zonder dat de CA er ook maar iets van weet.
Kortom, allemaal erg leuk van de EFF doet, maar het onderliggende systeem van de chain of trust is dermate rot dat het me verbaasd dat het niet nog veel vaker fout gaat. En ondertussen vangen de CA's veel te veel geld voor schijnveiligheid idd. Het enige goede wat hieruit kan voortkomen is dat meer kleine sites dadelijk over SSL gaan, maar meer dan het crypten van de lijn kun je er niet van verwachten.

[Armin]

maar het onderliggende systeem van de chain of trust is dermate rot dat het me verbaasd dat het niet nog veel vaker fout gaat.

Op zich ergens eens, maar de reden waarom het niet vaker fout gaat is omdat er ook weer vangnetten voor dit systeem zijn. Private root-keys worden zelden gestolen. Ik dacht dat 'onze' NLse DigiNotar de enige was.

Intermediate worden wel een paar keer per jaar gejat, plus dat er een aantal keren per jaar 'per ongeluk' wat foute certifciaten uitgegeven worden. Op het totaal zjin dat echter fracties van een % en worden ze doorgaans binnen een paar dagen ontdekt en uitgeschakeld.

Immers daarvoor heb je weer revocatie (CLR, OCSP, OCSP Staple) en certifciaat pinning. Niet elke browser doet dat even goed (Firefox, Opera en IE uitstekend - Chrome matig - Safari en Android stock ronduit brak), maar dit systeem is de reden waarom het goed werkt.

Op dit moment werkt het certifciaat systeem als basis voor TLS/SSL best goed. Zo goed, dat het wanneer goed toegepast zelfs voor een organsiatie als de NSA of AIVD onmogelijk is om in te breken op een secure verbinding.

[i-chat]

de beste oplossing is natuurlijk dnssec, en dan ook in dns je pubkey publiceren, maar als je ziet dat het merendeel van de nederlandse webhosts nog niet eens SNI aan willen bieden, dan maakt dit initiatief echt geen schijn van kans...

misschien als je dan ook validatie / chain of trust wilt, dat je ook daar in dns iets voor kunt regelen, browser checkt cert, cert is van comodo volgende maand is ie van de chines overheid bam! warner warning error error.

[Reactie gewijzigd door i-chat op 22 juli 2024 13:24]

[Pinkys Brain]

Om de een of andere reden weigeren de browser makers ook de rfc te ondersteunen om een certificaat in dns te stoppen... Maar hier wil Google dan weer wel geld en moeite in stoppen?

Word ik toch een beetje wantrouwig van...

[Rafe]

kunnen ze doen wat ze willen

Totdat ze bij de eerstvolgende audit door de mand vallen. Regelmatige audits horen er bij. Op https://cabforum.org/ is er veel info te vinden.

een gestolen private root key

Dat is bij een serieuze CA met HSM (minder zal tegenwoordig niet geaccepteerd worden lijkt me) praktisch onmogelijk: http://security.stackexchange.com/a/24906/24849

[Reactie gewijzigd door Rafe op 22 juli 2024 13:24]

[Eagle Creek]

HSM's bieden bescherming voor de sleutel maar nog niet voor toegang tot de CA en sub (intermediate) CA's.

Hoewel gebruik van een HSM voor een serieuze CA in mijn ogen een must is, is het een deel van de keten. Bij DigiNotar bijvoorbeeld had men toegang tot het signingsysteem. Wanneer die toegang niet voldoende wordt afgeschermd dan wel gemonitord, zal een HSM maar een beperkte toegevoegde waarde hebben.

Een van de grootste voordelen van gebruik van een HSM is dat de sleutel "gegarandeerd" binnen de eigen infrastructuur blijft, daar waar die anders "buiten de deur" tot in treuren toe misbruikt kan worden.

De betrouwbaarheid van certificaat valt of staat met die van een CA (en de gehele trust chain).

[Conzales]

SSL wordt dan ook voor 2 verschillende doeleinden gebruikt, al is dit dan samen; beveiliging en verificatie. Het verificatiegedeelte, weten met wie je te doen hebt, is misschien rot, maar wanneer ik wachtwoorden ergens over http moet invoeren doe ik dat toch echt niet zonder ssl. Voor het verificatiegedeelte kan ik nog altijd zelf de vingerafdruk van het certificaat controleren als de boel niet te vertrouwen is; internetcafe in het buitenland bijvoorbeeld.

[robvanwijk]

En corrupte CA's, de chinese overheid kan ook certificaten uitleveren die door elke browser geaccepteerd worden. Die hebben ook geen hele frisse reputatie qua internet veiligheid.

Dat er al een probleem is wil toch niet zeggen dat je het probleem dan meteen maar nog wat groter moet maken door elke idioot de mogelijkheid te geven om hetzelfde kunstje uit te halen?

Klopt, maar het is niet zo dat hoe meer je betaald voor een certificaat hoe beter de chain of trust is. Ook bij een gratis certificaat krijg jij geen google.com certificaat te pakken, domweg omdat de verificatiemail naar het mailadres in de whoisgegevens gaat bijvoorbeeld.

Dat houdt me nog steeds niet tegen om www.tweaker.net (dus zonder de laatste "s") aan te vragen en alsnog te MitM'en... Weliswaar alleen bij mensen die een typo maken of die ik bijvoorbeeld via email een geprepareerd linkje geef, maar dan nog, daar is meer dan genoeg rottigheid mee uit te halen. Of ik kan zelf die whois-gegevens opvragen en een gerichte aanval op die mailbox proberen (dan om drie uur 's nachts aanvragen, mailtje lezen, mailtje verwijderen, geen haan die er naar kraait).

Begrijp me niet verkeerd, ik juich het toe dat de EFF probeert beveiligde verbindingen te promoten, maar ik ben bang dat het grote publiek niet snapt tussen een veilige verbinding (niemand kan meelezen) en een veilige verbinding (ik weet zeker dat de server waar ik mee praat ook echt de server is waarmee ik denk te praten).

Wat er nu gaat gebeuren is in feite (om het maar even in populaire termen te formuleren): "Mijn verbinding is zo veilig dat zelfs de NSA die niet kan kraken... alleen jammer dat ze me makkelijk kunnen MitM'en zodat we samen die onkraakbare sleutel kunnen afspreken".

Misschien is de meest pragmatische oplossing dat browsers twee sets root certificates gaan bijhouden: eentje waar ze écht vertrouwen in hebben (en die een mooi groen slotje laat zien), een andere die ze net genoeg vertrouwen om de verbinding te accepteren, maar die in de interface geen feedback geeft die wijst op een "echt" veilige verbinding (dus net zoals nu http-verbindingen worden behandeld).

[musiman]

Je hebt niet alles bij het rechte eind.
Ten eerste is er wel degelijk verschil in certificaten en veiligheid. Op de site van https://www.ssllabs.com/ssltest/ kun je testen of jouw certificaat gevoelig is voor diverse zwakheden.
Ten tweede kun je niet zomaar een *.google.com of *.com krijgen. Geen enkele CA, ook niet de gratis CA's, zal zo'n certificaat verstrekken.
En ten derde, Diginotar was NIET corrupt. Oke, ze waren "niet helemaal up-to-date" qua security én hun complete netwerk design etc. etc. was crap, maar ze waren niet corrupt (voor zover wij weten natuurlijk).

[Reactie gewijzigd door musiman op 22 juli 2024 13:24]

[TDeK]

Ok, en wij weten zeker dat TürkTrust, China Internet Network Information Center, Dhimiyotis en GoDaddy niet corrupt zijn (geweest)? Blijkbaar wel, want hun root CA's zitten in onze browsers.
Wat betreft SSLLabs heb je gelijk, maar dat zijn veelal issues met de serverconfiguratie, niet met het certificaat an sich. Een certificaat bepaalt bijvoorbeeld niet de ciphers (en de combinatie en de volgorde), dat doet de server. Idem de verschillende handshakes en protocol bepalingen, of SSL3, TLS1.0 ed wordt aangeboden, allemaal serverwerk. SHA-256 is een van de zaken die wél certificaat afhankelijk zijn.

[Jester-NL]

Ok, en wij weten zeker dat TürkTrust, China Internet Network Information Center, Dhimiyotis en GoDaddy niet corrupt zijn (geweest)? Blijkbaar wel, want hun root CA's zitten in onze browsers.

En dus mogen we aannemen dat ze niet corrupt zijn Bovendien, als de door jou genoemde CA's niet volgens de afspraken van het cab-forum te werk gaan, zijn die certificaten net zo snel verwijderd als indertijd met Diginotar...

Wat betreft SSLLabs heb je gelijk, maar dat zijn veelal issues met de serverconfiguratie, niet met het certificaat an sich. Een certificaat bepaalt bijvoorbeeld niet de ciphers (en de combinatie en de volgorde), dat doet de server. Idem de verschillende handshakes en protocol bepalingen, of SSL3, TLS1.0 ed wordt aangeboden, allemaal serverwerk. SHA-256 is een van de zaken die wél certificaat afhankelijk zijn.

En laat nou het grote probleem met SSL-implementatie juist in die server-configuratie zitten... en juist dan is SSLlabs een grote hulp.
Sowieso krijg je bij een verlopen of ingetrokken certificaat een hele duidelijke melding in je browser... daar heb je SSLlabs echt niet voor nodig
Laten we het (zeker client-sided) niet moeilijker maken dan het is: een certificaat is geldig of niet. Indien niet, krijg je dat heel duidelijk te zien. En jij, de klant, kunt daar niets aan doen (of je moet heel bewust een foutmelding negeren... en wat ben je dan??)

[Verwijderd]

Tja, en daar zit de crux. Het certificaat doet twee dingen (en ongetwijfeld schop ik nu wel een paar securityguru's tegen de schenen):
1) Versleutelen van verkeer
2) 'bewijzen' dat je bent wie je bent etc.

Voor de gemiddelde site van Jan Modaal is nummer 1 veruit het belangrijkste. Maar alle problemen ontstaan door 2. Netto resultaat: voor de site van Jan Modaal blijft het internet onveilig. Ik heb dit altijd een typisch geval van ivoren toren gedrag gevonden. Hier zijn twee functies verenigd in één.

Als iemand in staat is verkeer om te leiden, zonder dat de gebruiker het merkt, kan hij al zoveel, dat deze gebruiker toch al het haasje is of wordt.

[Olaf van der Spek]

maar ben ik ook wel echt verbonden met Google of mijn bank?

Alsof consumenten dat begrijpen...

[TDeK]

Dat speelt overal. Controleer jij elk eurobiljet op de echtheidskenmerken? Weet jij of elke auto in jouw straat wel echte kentekenplaten heeft? Oftewel: hoeveel kennis kunnen (en mogen!) we verwachten van een normale gebruiker? Wat SSL betreft is het simpel: het is het probleem van de CA en de website die het cert aanbiedt, niet van de eindgebruiker.

[svennd]

Ik denk dat consumenten er wel duidelijk op gewezen worden als het certificaat niet geldig is, ondanks dat een ongeldig certificaat nog steeds veiliger is dan een gewone http verbinding...

[Q-collective]

Qua encryptie biedt het inderdaad nul meer dan een goedkoper certificaat. Maar dat is natuurlijk maar het halve verhaal bij SSL. De hele industrie rondom de SSL instanties is gebaseerd op het gegeven dat het uitgegeven wordt door een instantie die vertrouwd wordt (bijvoorbeeld door browsers, zodat je geen enge meldingen krijgt), dáár betaal je voor. Anders had iedereen natuurlijk een self-signed SSL certificaat. En je betaald meer naarmate de controle door de instantie intensiever is. EV certificaten hebben een lange verificatieprocedure en dat is dus duur.

De oplossing hiervoor is ook al bedacht en heet DNSSEC, maar wordt niet door iedere registrar ondersteund.

[Kees]

Ik kan een certificaat kopen voor 9 euro nu. Krijgt niemand waarschuwingen van in de browser (heb voor *.tweakers.net ook de goedkoopste wildcardcertificaat gekocht, dat werkt niet meer in android < 2.0 maar verder geen klachten over gehad).

Ik kan ook een certificaat kopen van 1600 euro (en dat is nog niet eens een EV) waarbij ook niemand meldingen krijgt en de encryptie even sterk is als bij het certificaat van 9 euro. (uiteraard afhankelijk van hoe ik het aanvraag).

Dus ja, die trust speelt zeker een rol, maar niemand* zal zelf die trust nalopen en denken 'owh, geotrust certificaat van 9 euro, dat vertrouw ik niet, het is geen symantec certificaat van 1600 euro' (en ja, ik weet dat geotrust van symantec is, dat maakt het nu juist zo vreemd)

* uitgezonderd bezoekers van deze website

[Thystan]

Wordt er vanwege android <2.0 niet standaard https enforced?

[Kees]

Nee, zie ook plan: Dilemma: moet Tweakers https inzetten?

[i-chat]

dnssec alleen is niet genoeg, die moet je nog steeds uitbreiden met pubkey informatie anders zit je nog steeds met untrusted certificaten en die methode wordt nog door geen enkele browser ondersteund...

[Jester-NL]

Een RapidSSL van 9 euro... daar hoef je niet veel meer dan een CSR voor aan te leveren.Je krijgt een mail op een mail-adres op het domein waar je het certificaat voor aanschaft, en da's zo ongeveer alle controle...
Een EV-certificaat (dat door een bank wordt gebruikt) vereist, naast die CSR toch wat extra controles.... KvK-gegevens, telefonisch controle of de aanvrager wel bij het bedrijf werkt én gerechtigd is om een certificaat te bestellen... whois-controle...
De encryptie is over het algemeen identiek, maar zeggen dat er 'geen greintje meer zekerheid' is, is toch niet helemaal waar.

[Kees]

Klopt, maar ook in de markt voor EV certificaten zitten grote verschillen. Ik zie al EV certificaten voor 189 euro, maar ook voor 949 euro (of met SAN van 329 tot 1849 euro).

En daar zit uiteindelijk gewoon geen verschil meer in behalve de prijs. Het certificaat van 1849 euro bied niet meer zekerheid dan die van 189 of 329 euro. Verder moet je er maar vanuit gaan dat die validatie ook daadwerklijk is gedaan en dat men er niet met de pet naar heeft gegooit. En dat is iets wat je niet echt zelf kan controleren, dus moet je de CA maar vertrouwen. En als zelfs de chinese overheid een CA is dan weet je in hoeverre je de CA's kan vertrouwen.

Zelf zie ik een EV certificaat niet als iets nuttigs, van een domain validated certificaat weet je ook dat die gewoon door de eigenaar van het domein gekocht is (als de normale procedure gevolgt is natuurtlijk).

[bbob]

Als iemand fout wil kan deze ook een ev certificaat kopen.
kvk nummer leuk, tel contact voip nummers zijn zo gekocht.
Ik vraag me af of ze in ned eerst het kvk uittreksel opvragen, daarop staan dan de mensen die een volmacht hebben.
Dan nog als je echt fout wil lukt ook ev certificaat.
Uiteindelijk is het doel encryptie van de verbinding waardoor anderen gegevens niet kunnen onderscheppen.
ssl zegt verder niets over de betrouwbaarheid van het bedrijf zelf, alleen dat je communicatie veilig is.

[Jester-NL]

SSL zegt inderdaad niets over de betrouwbaarheid van het bedrijf...
However, ik heb het idee dat je bij je opmerkingen over EV aanvragen, je voornamelijk baseerd op de informatie hier, en niet op wat er exact gevraagd wordt
Laat ik dat dan maar even verduidelijken:
Je doet een aanvraag voor een certificaat op een site. Laten we het voor het gemak even houden op voorbeeld.com
Je maakt een CSR aan, met daarin (onder andere) de bedrijfsgegevens, overeenkomend met de gegevens zoals die verifieerbaar zijn bij een KvK.
De partij waar jij je aanvraag doet (verkoper, danwel CA) gaat vervolgens controleren of voorbeeld.com volgens de whois-gegevens wel gekoppeld is aan het bedrijf in de KvK-gegevens.
Ze nemen contact op met je bedrijf, via een telefoonnummer dat uit een openbare bron kan worden gevonden. (Dat houdt dus in dat de contact-gegevens op je website NIET worden gebruikt ) Bij dat contact willen ze van HR weten of jij, de aanvrager, werkt voor het bedrijf en gemachtigd bent om die bestelling te doen.
Is bovenstaande op orde, dan gaat er een approvermail naar een vooraf opgegeven mailadres. Dat adres moet óf op voorbeeld.com bestaan, óf terug te vinden zijn in de whois-informatie..
Na het klikken op een link in genoemde mail wordt het certificaat pas toegestuurd.
Bovenstaande maakt het overigens ook knap lastig voor kleine, en pas-gestarte bedrijven om een EV-certificaat te bestellen. Daar is momenteel een best prijzig stukje inbreng van een notaris voor nodig.

All in all, met de nodige moeite en tijd gaat het je vast lukken om een EV-certificaat uit te laten geven dat niet klopt. Tuurlijk, want het is allemaal vertrouwen, mensenwerk en gebakken lucht... die hele SSL-wereld. Maar toch doet die hele industrie wel zijn best om dat vertrouwen in stand te houden...

[bbob]

Waar het artikel het niet over heeft is het ip probleem.

Er zijn miljoenen site gehost op shared ip adressen. Helaas kun je daar niet zo maar een ssl certificaat voor uploaden.

Het begin als dit is leuk maar een multidomein certificaat zou dan ook de volgende stap moeten zijn.
Je zou natuurlijk ook kunnen denken aan ip v6 certificaten alleen wordt dat helaas nog niet breed genoeg ondersteund.

[Kees]

SNI word door vrijwel alle browsers ondersteunt, en wie wil IE6 nu nog ondersteunen?

[Armin]

Inderdaad, het krijgen en installeren van een certifciaat is vaak niet het probleem.

Het probleem begint daarna, en wel bij het volgende:
1) Vele advertentienetwerken kunnen niet met SSL/TLS omgaan. Tenzij je dan dus de SSL/TLS via een dienst als CloudFlare laat doen, heb je dan dus een vet probleem, want geen inkomsten.
2) Het toepassen van SSL kan indien verkeerd gedaan ervoor zorgen dat Google (hetgeen een grote bron van bezoekers is) jouw nieuwe site als een andere ziet. Dan zak je opeens in de zoekresultaten en krijg je opeens veel minder bezoekers.
3) Externe content netwerken kennen vaak geen SSL/TLS. Dus als jij een filmpje linkt van een andere website speelt die opeens niet meer. YouTube kent HTML5 en is dus SSL/TLS compatible, maar de meeste Flash gebaseerde spelers/bronnen falen.

[Verwijderd]

Geen idee waar jij je certificaten haalt, maar bij mij heb ik op een kwartiertje of zo mijn certificaat. En de meeste CA resellers hebben ook de nodige documentatie voor de meest-gebruikte webservers.

Tuurlijk moet je wel wat tweaken om het echt veilig te krijgen (enkel nog TLS gebruiken en dergelijke), maar dat mag voor de gemiddelde IT'er toch geen probleem zijn, aangezien verondersteld wordt dat zij toch de basis van encryptie kennen en begrijpen.

Meer zelfs, ik zou zelfs geen website meer opzetten zonder SSL/TLS. Je hebt dit ook al nodig om SPDY te kunnen gebruiken (wat sneller is dan gewoon HTTP/HTTPS vanwege multiplexing), en Google gaat HTTPS sites in de toekomst toch een hogere ranking geven.

En voor de prijs moet je het zeker niet laten (7EUR/jaar voor een hostname-based certificaat).

[i-chat]

ja en 10 euro per maand per cert omdat je een vast ip adress moet hebben tenzei je een vps afneemt (waar je zelf sni regelt)... das toch mooi 127 euro per jaar...

[Reactie gewijzigd door i-chat op 22 juli 2024 13:24]

[Verwijderd]

SSL certificaten zijn gebonde aan hostname of domeinnaam, niet aan IP adres. Er is geen enkele reden waarom dit niet via dynDNS zou werken.

Als je echter gebruikt maakt van een hosting-bedrijf, neem ik aan dat die allemaal al SNI ondersteunen tegenwoordig, of ben ik daar mis in?

En in noodgevallen kan je nog altijd CloudFlare er voor zetten en die SSL laten afhandelen. Is zelfs gratis voor één site, dacht ik.

[freaky]

Je kunt wel degelijk certificaten krijgen die gebonden zijn aan IP adressen. Veel CA's ondersteunen dat echter niet, maar dat heeft weinig met de certificaten zelf te maken.

En nee SNI is nog steeds niet erg populair. Heel Windows XP kun je al vergeten dan namelijk (tenzij de browser een eigen SSL stack gebruikt) en je kan wel roepen dat mensen dan maar moeten updaten, maar dat bepalen ze zelf wel. Dus kun je kiezen tussen zoveel % aan klanten verliezen of een eigen IP adres.

[RaZer0r]

Waarom een vast ip?

Kan je niet gewoon een CNAME verwijzing naar een no-ip.com adres ofzo gebruiken?

Dat het handiger is staat buiten kijf, maar het is echt geen requirement voor een ssl certificaat

[Yggdrasil]

Een vast IP is niet per se nodig zolang het bij één TLS site blijft, maar als je er meerdere wilt draaien moet je SNI gebruiken (en daardoor een boel bezoekers uitsluiten) óf voor elke site een apart IP adres.

Wij willen nog niet aan SNI, dus moeten we nog aparte IP adressen gebruiken. Dat kost de meeste tijd voor ons.

[Verwijderd]

Afgelopen maand meerdere certificaten aangevraagd, binnen ca. 10 minuten had ik ze en dat nog gratis ook. Gewoon via StartSSL gedaan. Ik moet zeggen, werkt lekker en servers met deze SSL certificaten doorstaan vrijwel iedere test van SSL Labs.

[Verwijderd]

Helaas is de gratis StartSSL variant niet bruikbaar voor commerciële doeleinden en passen ze die definitie nogal willekeurig toe. Als je iets verkoopt of affiliate links of banners ofzo op je website hebt staan is het dus even oppassen.

[Verwijderd]

Ik heb eigenlijk nog nooit problemen met ze gehad, zelfs niet toen ik zakelijk begon met een gratis certificaat bij hen en een webwinkel had. Maar kan zijn dat dit in de loop der jaren veranderd is.

[Gitano]

Te krijgen valt wel mee, maar de installatie is wat lastiger. Dus zeker ook dat ze daar een tool voor gaan uitbrengen die het allemaal voor je doet zal helemaal helpen over te stappen.
En alles gratis.
ik zeg laat maar komen dit ;-)

[hackerhater]

mwah zo lastig is het niet op Linux met root-toegang en kennis van webserver-configuraties.
Maar het vereist wel kennis inderdaad.

[Verwijderd]

Valt best mee. Het proces is volledig te automatiseren met wat API calls en een e-mail scriptje. (Afhankelijk van de verkoper en root CA die je gebruikt.)

Wat mij vooral dwarszit zijn de kosten, vooral voor de meest eenvoudige certificaten die alleen een e-mail verificatie doen. Een dergelijk certificaat zou niet meer dan $5 mogen kosten. Enfin, gratis is natuurlijk nog mooier ;-)

[Blaise]

Als je je door de gruwelijke interface heen weet te werken is het volledig gratis bij StartCom. Werkt in alle browsers. Revoken kost wel geld.

[Reactie gewijzigd door Blaise op 22 juli 2024 13:24]

[arjankoole]

Je wilt niet weten hoe lastig het is om een certificaat te krijgen.

Pardon? Ik doe er ongeveer 15 minuten over. En dan heb ik 'm ook al in m'n server geprakt. En nee, dat is geen self-signed. Gewoon een wildcard cert van een cert boer.

[teek2]

Nogmaals, het gaat om een normale gebruiker die zelf een wordpress blogje op zijn eigen servertje gaat draaien, niet om iemand die het al jaren doet.

[Jester-NL]

En voor die Wordpress-gebruiker zijn er allerhande handleidingen op het internet... of de helpdesk van de verkopende partij.

* Jester-NL vraagt zich af of StartSSL ook gratis (Nederlandse) telefonisch ondersteuning heeft, en medewerkers die eventueel even met je mee willen kijken als het niet lukt

[witchdoc]

uh? Ooit https://www.startssl.com/ geprobeert?
Hun class 1 ssl cert is gratis en erg eenvoudig moet ik zeggen.

[halofreak1990]

Staat er ook ergens Windows Support (IIS) tussen?

[Jester-NL]

Het uitgifte-traject is wat anders... maar het blijven certificaten. Waarom zou er gèèn IIS-support zijn? Het blijven namelijk gewoon SSL-certificaten

Dus, haal in een (virtuele) linux even je certificaat op, bak een .pfx en klaar.

[Reactie gewijzigd door Jester-NL op 22 juli 2024 13:24]

[gertvdijk]

Wat is precies het verschil met de insteek die CACert heeft? Ook gratis, wilde graag in alle trust stores komen en is dat maar deels gelukt. Debian/Ubuntu hadden een tijd CACert opgenomen in de ca-certificates packages, maar is daar inmiddels weer uitgehaald.

CAcert.org is a community-driven Certificate Authority that issues certificates to the public at large for free.

Waarom gaat het "Let's Encrypt" wel lukken om gratis certificaten aan te bieden die worden vertrouwd in browsers en waarom CACert niet?

[Timoo.vanEsch]

Omwille van het brede draagvlak?

[Eloy]

Omdat Mozilla meedoet misschien?

[roviaro]

Zoals al gezegd gaat het om draagvlak (voor gebruikers). Ik zit zelf ook bij CACert en helaas moet je daarbij handmatig nog gaan rommelen met root certificates afhankelijk van je browser en platform.

Ik weet niet hoe het er nu voor staat maar als het niet lukt om standaard meegeleverd te zijn in de trust stores van courante OSes zal het niet gaan lukken (ook al is het gratis).

Ik neem aan dat Let's Encrypt dit goed regelt. Een goede uitroltool is ook nooit weg trouwens.

[Verwijderd]

EFF heeft denk ik betere contacten. Mozilla is sowieso zelf onderdeel van het project en zal het dus ongetwijfeld ondersteunen. Als Cisco en Akamai inderdaad de boel technisch regelen (en vooral dichttimmeren) maken ze denk ik ook een goede kans bij Internet Explorer en Chrome.

[Bozevkwa]

Wat ik mij afvraag is of dit initiatief geen schijn veiligheid creëerd: als iedereen een makkelijk en eenvoudig een certificaat kan aanvragen kunnen personen met minder frisse bedoelingen dat ook.

Tuurlijk, ik vind het een goede stap om sites veiliger te maken, maar ik ben bang dat het ''we kunnen https sites blindelings vertrouwen als er maar een groen slotje staat' gevoel na een paar negatieve ervaringen helemaal weg is.

[Myrdhin]

Het gaat hier om domain validation. In het certificaat staat alleen de domeinnaam en verder geen gegevens van de aanvrager. Personen met minder frisse bedoelingen kunnen toch al zo'n cert aanvragen voor nog geen 10 euro...

[SuperDre]

maarja, als het helemaal gratis is, dan wordt de drempel dus nog veel lager...

[i-chat]

die drempel is al (te) laag, 5 tot 10 euro om honderden mensen in de val te laten lopen met cryptolockers a 300 tot 30000 euro pp...

en bovendien denk ik dat ze echt zo stom niet zijn om *.googIe.com uit te geven.

[Verwijderd]

Denk je echt dat dit uitmaakt? Een hacker die 300 euro pp vangt zal echt niet vallen over de kosten van een certificaat. 5 euro, 50 euro of zelfs 150 euro zal hem/haar weinig uitmaken denk ik.

[Fido]

Een ssl certificaat is gratis. Heel simpel, maar werkt gewoon zonder waarschuwing in de browser. http://www.startssl.com

[Rolandp]

Een certificaat heeft een dubbele functie. Aan de ene kant biedt het de bezoeker de garantie dat er een verbinding is gemaakt met de daadwerkelijke website; degene die het certificaat heeft aangevraagd. Dit deel kan schijnveiligheid bieden in verband met lieden met minder frisse bedoelingen. Uit de tekst haal ik dat er wel een check wordt gedaan op wie het certificaat aanvraagd op basis van het ACME protocol.

Aan de andere kant zorgt het certificaat en de daarbij behorende SSL verbinding ervoor dat data onderschept tussen bezoeker en website niet (zo goed als niet) te lezen/manipuleren is. Dit met betrekking tot censuur en sleepnetsurveillance.

[SuperDre]

Maarja, als elke jan en alleman zomaar een certificaat kan aanvragen dan heeft het weinig zin om te weten wie de certificaat heeft aangevraagd.
En helaas is al gebleken dat certificaten langer niet de veiligheid garanderen dat men niets meer kan lezen met een man-in-the-middle attack..

[i-chat]

man in the middle is lang zo makkelijk niet als mijn vaak wel suggereerd, er zijn echter een paar zaken van belang, gebruik alleen vertrouwde netwerken, en als je die niet kunt gebruiken, maak dan als eerste een versleutelde verbinding naar een vertrouwd netwerk voordat je verder gaat...

een vpn opzetten naar huis voor dat je over de mcdonalds wifi naar je bank surft is heus de moeite niet... en kan een hoop leed besparen.

de belangrijkste oorzaken van mitm aanvallen (dsn poisoning) is bijv al afgevangen door dnssec. en EV certs zijn inherrent niet veiliger dan 2euro certs het enige verschil is de uitkering van schade wanneer het kalf al verdronken is...

[Verwijderd]

een vpn opzetten naar huis voor dat je over de mcdonalds wifi naar je bank surft is heus de moeite niet... en kan een hoop leed besparen.

Voor jou en mij en een hoop tweakers idd... Voor de overige 99% van de bevolking wel...

[Verwijderd]

Het gebruik van certificaten heeft twee doelen: authenticatie en encryptie. Deze gratis dienst zal vooral encryptie een vlucht doen nemen. Authenticatie is voor dit soort eenvoudige certificaten nooit echt van groot belang geweest. Meestal gaat het puur om simpele e-mail verificatie en dat zal bij deze gratis dienst niet anders zijn.

Voor authenticatie van enige betekenis zul je EV-certificaten moeten gebruiken (de bekende groene balk) en ik vermoed dat die niet gratis zullen worden. Vandaar dat er waarschijnlijk ook weinig/geen weerstand is voor dit initiatief van bestaande aanbieders van certificaten. Die zien hier denk ik een stukje bewustwording en indirect marketing voor hun dure EV producten.

[Warbringer]

Ik draai intern een eigen Certificate Authority en al mijn computers, laptops, tablets en smartphones vertrouwen mijn eigen CA waardoor ik op mijn interne sites "groene slotjes" te zien krijg. Netter zou natuurlijk zijn om m'n certificaten te laten signeren door een Verisign of iets dergelijks, maar heb je die prijzen wel eens gezien?

Als de EFF een standaard trusted CA zal worden in Firefox, Chrome, Safari etc. etc. dan zal ik mijn CSR's (Certificate signing requests) graag bij hun neerleggen zodat ik voortaan standaard groene slotjes krijg :-)

[Reactie gewijzigd door Warbringer op 22 juli 2024 13:24]

[kwikstaart]

@Fido hierboven doet nog een suggestie: https://www.startssl.com/ - gratis certificaten!

[mgizmo]

precies en dan kun je ook nog SAN met meerdere wildcards opvoeren in 1 certficaat

[Verwijderd]

Geen idee waar jij de prijzen gezien hebt, maar ik betaal +- 70EUR/jaar voor een domain-wide certificate (*.domain.com). En deze zijn niet minder veilig dan gewone host-based certificates.

Op de Qualys SSL test haalpt mijn setup een score van A+, wat zelfs beter is dan de score van de meeste banken.

Dus nee, zo moeilijk en duur is het allemaal niet...

[Yggdrasil]

Het is niet héél veel geld, maar toch duur zat voor de hobbyist.

[Warbringer]

Heb nooit gezegd dat het moeilijk is maar met name duur. Ik heb 8 certificaten nodig à 70 euro per jaar, dan is dat een stevige prijs voor wat automatische "groene slotjes". Dan blijf ik nog wel even zitten met m'n eigen Certificate Authority en de noodzaak om daar eenmalig m'n eigen certificaat te importeren als trusted authority.

@kwikstaat : Goeie tip! Die ga ik even bekijken

[nassau]

Gratis certificaten (domain validated, 1 jaar geldig) haal ik al sinds jaar en dag bij http://www.startssl.com/

Werkt prima. Maar dit initiatief maakt ook het proces minder ingewikkeld en dat is zeker een plus. Goed bezig dus EFF.

[Phyxion]

Het enige jammere aan StartSSL is dat subdomains niet ondersteund worden (of maar één, maar dan zou je geen www er meer voor kunnen gebruiken). Nou is dat niet voor elke site nodig maar het blijft wel wat een gemis.

[RaZer0r]

? hoezo? ik heb ondertussen al tig subdomein certs

mail.
mailfilter.
www.
firewall.

en allemaal via startssl ... 2 weken voor het vervallen van het cert krijg je mooi een mailtje, en kan je je cert vernieuwen... werkt perfect ;-)...
En volledig gratis, het enige nadeel is dat revocation idd geld kost :-).

[mgizmo]

wildcard werkt ook bij ze.

[Phyxion]

Ik heb toevallig een paar week terug hier naar gekeken, voor de gratis certificaten kan je maar één subdomein toevoegen per hoofddomein. Je kan dus niet deze allemaal tegelijk toevoegen:
mail.
mailfilter.
www.
firewall.

Tevens was het maar één certificaat per domein, dus ik vraag mij dan af hoe je dit voor elkaar hebt gekregen (gratis)?

[nassau]

Dat is merkwaardig. Ik heb meerdere certificaten op één hoofddomein kunnen aanvragen.

Een echt wildcard certificaat kost wel geld idd.

[Phyxion]

Weet je nog hoe je dat precies gedaan hebt dan?

[nassau]

Ik heb nu certificaten op (voorbeeld)

www.bla.nl
svn.bla.nl
git.bla.nl

Dat mag gewoon bij StartSSL

[Phyxion]

Ik zal het nog eens bekijken dan, misschien heb ik dit gemist. Bedankt voor de info

[gertvdijk]

Ik gebruik ook StartCom StartSSL certificaten maar er zijn wel wat addertjes. Revoken kost geld en ook kan je pas een paar dagen voor het verstrijken van het huidige certificaat een nieuwe aanvragen.

[ultimasnake]

Top! Moet dan wel op aangemerkt worden dat de 'huis, tuin en keuken internetter' opnieuw uitgelegd moet krijgen wat het groene slotje betekend, want als iedereen met 1 commando een https licentie kan aanvragen op een website dan zal ook de phishing site ineens veilig lijken voor de leek (want dat is ze immer geleerd, sites met een slotje zijn veilig).

Natuurlijk kan dat nu ook al, maar het gebeurt doorgaans blijkbaar niet (misschien omdat je toch aardig wat moet afdragen). Dit kan ik echter alleen maar toe juichen weg met http!

[Carharttguy]

10 euro per jaar, noem jij dat aardig afdragen? Als phisher moet je eigenlijk een debiel zijn om geen SSL certificaat te kopen.

[ultimasnake]

Kosten heb ik het niet over, zelfs de 'duurdere' wildcard licenties zijn vaak nog peanuts. Maar voor een geldig SSL certificaat moet je wel de nodige persoonsgegevens afdragen bij je hostingbedrijf of de instanties zelfs met valse identificatie zal iemand daardoor makkelijker te traceren zijn (gebruik van de valse identiteit valt ook te backtracen naar een persoon)

[Carharttguy]

Je hoeft voor een domain only SSL toch alleen een geldig email adres te geven? De rest van informatie valt gewoon te faken. En hoe zou een valse identiteit te backtracen zijn? Als het goed is, is dat nu net niet de bedoeling.

[Verwijderd]

want als iedereen met 1 commando een https licentie kan aanvragen op een website dan zal ook de phishing site ineens veilig lijken voor de leek (want dat is ze immer geleerd, sites met een slotje zijn veilig

Inderdaad, dus dit soort initiatieven betekenen het einde van DV certificaten aangezien het valideren geen enkele waarde meer heeft en dus de betrouwbaarheid van het certificaat hiermee volkomen is verdwenen.

Ben er sowieso voor om alle commerciele websites verplicht een EV ertificaat te laten gebruiken.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:24]

[theduke1989]

Dit zou iets goed zijn voor versio.nl die bakken er niks van als het gaat om ssl certificaten.
Daar duurt het inderdaad lang en is het moeilijk om zo'n certificaat aan te schaffen.
Hopelijk kan ik dus via EFF een certificaat bemachtigen en me shop beter beveiligen en de klanten een beter gevoel geven.


ps: maar nu dit allemaal makkelijker wordt, betekend dit dat ook dat er ''neppe'' shops makkelijk toegang er tot krijgen waardoor er weer fraude etc gepleegd kan worden...

[Verwijderd]

Nee, "neppe" shops kunnen dit nu al net zo makkelijk aanvragen als jij nu doet. Het enige wat veranderd zijn de kosten.

[i-chat]

dnssec lost het meeste daarvan op... dit soort certs zijn ook niet echt voor webwinkels bedoeld, en heel misschien met het validatie systeemv an certs wel anders...

misschien moeten dan wel over naar meerlaags certs,
simpel slotje = host / email based validation geschikt om te weten dat je data niet onderschept kan worden en alelen verstuurt wordt naar die website in je adres balk...
iets ander tekentje = iets betere validatie, men weet tenminste wie de eigenaar van de site is,
groene balk = ev certificaat met alle bijhorende shizzle...

dan kun je mensen leren om voor onbelangrijke sites zoals een forum of een nujij alleen te kijken of het slotje er is...

voor webwinkels te kijken of er een cert is en of dat cert ook de naam van de winkel voert..

voor banken of er een grote groene balk is...

[Jester-NL]

Versio heeft op dit vlak gewoon een ongelovelijke brakke bedrijfsvoering. Ik denk niet dat een proces waar ze niets aan verdienen beter gaat werken dan een deal waar ze wel geld uit halen... want nu moet jij aan Verzio betalen, en zij aan de CA (of hun leverancier... ). En dat traject verkloten ze

[Tijger]

Alles goed en wel maar is het nu echt verstandig of nodig om iedere website op HTTPS te draaien?

[Carharttguy]

Waarom zou dat niet verstandig zijn?

En waarom het niet doen? Het heeft praktisch gezien alleen maar voordelen.

[Mijzelf]

Het heeft wel degelijk nadelen. Er is meer handshake, en dus kost het meer tijd om te verbinden, en encryptie kost rekenkracht, en dus stroom.

Een licht, cpu-limited servertje kan meer http dan https verbindingen tegelijk aan.

[i-chat]

misschien moet iemand dan maar een co-processor-card bouwen met hardwermatige versnelling van sh256 / bcript etc liefst in de de smaken isa (voor jouw limited cpu servertje) misschien nog in pci voor mensen die pci-e voor nuttiger zaken reserveren... en eventueel in pci-e voor servers met echt hoge loads...

[Mijzelf]

Juist. Nu heb ik een weerstation gebaseerd op een microcontroller, die een webinterfeesje aanbied via wifi. De enige I/O die nog vrij is zijn 3 GPIO pinnen.

Waar ga ik die coprocessor van jou installeren?

[Carharttguy]

Tuurlijk zijn er nadelen, maar zoals ik zei: praktisch gezien niet.

Je merkt niets van die langere verbindingstijd als gebruiker. En als webdevver met een shared hosting account hoef je ook totaal geen rekening te houden met rekenkracht of stroom.

Gewoon certificaatje installeren en gaan.

[Mijzelf]

Enig idee hoeveel nasjes een webserver draaien?

[Carharttguy]

Helemaal geen idee.

Maar als je een website op je nasje draait die jouw nasje zo zwaar belast dat hij het moeilijk krijgt, moet je misschien toch voor een hostingoplossing opteren. Kost waarschijnlijk minder dan de elektriciteit dat die nas verbruikt.