Wat een flauwekul. Alsof je voor een eenvoudige website waar niks kwetsbaars aan hangt per se https zou moeten gebruiken.

Ik vind dit ook een goed idee. Het opzetten van https is nu gewoon nog veel te moeilijk, als je een tijdelijke webserver wilt draaien op je pc is het lastig om https daar goed werkend te krijgen. Ook kunnen er misschien wat meer hulpmiddelen voor ontwikkelaars worden gebouwd, het opzetten van ssl in code is gewoon nog te lastig.

M.a.w.: alle privé site en privé initiatieven moeten verdwijnen, alleen zakelijke initiatieven die smeergeld kunnen betalen
om een "vertrouwd" certificaat te kopen (welk vertrouwen totaal gebakken lucht is) die mogen nog van EFF.

Ik dacht ooit dat een van die F's in EFF voor freedom zou staan maar dat is niet zo.
En freedom willen ze kennelijk ook niet. EFF Must Die.

Persoonlijk heb ik geen zin om 130 euro per jaar te betalen voor een certificaat.
Er op mijn website om geen enkele persoonlijke gegevens gevraagd.

HTTPS verkeer verbruikt ook meer CPU power, wat vooral belangrijk is op mobiele devices. En aan de server kant zal het betekenen dat die minder gelijktijdige verbindingen kan onderhouden.

Het protocol zelf is brak genoeg dat het wat mij betreft vervangen mag worden. Al zijn de recent voorgestelde vervangingen inclusief "HTTP 2.0" gewoon niet beter, hooguit nog complexer. Het grotere probleem is dat HTTPS geen volwaardige vervanger is, zelfs niet met de laatste uitbreidingen. Uiteindelijk stuit je altijd weer op het vrij fundamentele probleem dat het model onder wat SSL doet --naast onverwacht brak, zie heartbleed-- het model van het web heel erg slecht past.

Begin dus maar eerst met iets anders te verzinnen dan die georganiseerde uitbuiterij van de verzameling "certificate authorities". Je zal heel PKI moeten afschieten en met een ander model komen.

Ik vond op http://stackoverflow.com/questions/149274/http-vs-https-performance nog een heleboel redenen waarom je liever http verkeer gebruikt. Dus eigenlijk wil je alleen https gebruiken voor gevoelige data.

Tja, SSL willen doen zonder crypto accelerator is als willen gamen zonder grafische kaart.
Dus omdat encryptie nu op je CPU terecht komt, gaan we nu dan ook weer telnetten omdat SSH iets meer performance vraagt?

Duidelijk nog nooit gehoord van DANE.
Maar ja, ik las al dat "HTTPS opzetten veeeeels te moeilijk is" ...voor simpele zielen.

Wat een BS.

Het protocol is prima, het gebruik ervan af en toe wat minder. Bijvoorbeeld; moeten we FTP dan ook maar verbieden omdat wat mensen zijn die wel een NAS willen hebben omdat ze dan op het werk naar die leuke vakantiefoto's kunnen kijken maar geen flauw idee hebben van wie er eigenlijk nog meer bij die foto's kan?
Plus, alsof HTTPS wel onfeilbaar is!

Dit soort uitspraken van het EFF zijn M.I, véél gevaarlijker dan HTTP; als je het volk dom probeert te houden... Vul de rest zelf maar in...


??? Huh? Wat heeft de >inhoud< van een website nu weer met SSL te maken? Of probeer je 3rd-party-people door te sluizen?


Voor servers maakt het niet heel veel meer uit, tenzij je oude hardware hebt natuurlijk. Voor mobiele devices scheelt het wel iets waarschijnlijk, in de praktijk betwijfel ik of het een merkbaar verschil wordt. Of je nu na 4 uur of 3 uur en 3 kwartier surfen je accuutje aan een draadje moet hangen...

Voor degenen die klagen over de kosten: SSL certificaten zijn gratis aan te vragen bij StartSSL, en worden in de huidige browsers vertrouwd.

Maar configuratie is wel wat lastiger dan simpele HTTP, vooral omdat het met HTTPS nog altijd heel eenvoudig is om het zo te configureren dat het bij jouzelf werkt, maar dat anderen wel een waarschuwing op het certificaat krijgen, namelijk wanneer de intermediate CA certificaten niet op de server staan, maar wel lokaal.

Tsja, er zijn belangrijker zaken; https://www.virusbtn.com/virusbulletin/archive/2014/07/vb201407-Mayhem

Wat op dit moment geen standaard is maar een *voorstel* voor een standaard. Maar wel interessant.

Wat ik ook interessant zou vinden is als certificaten door meerdere partijen ondertekend zouden kunnen zijn. Het omvallen van Diginotar bijvoorbeeld had lang niet zulke ingrijpende gevolgen gehad als belangrijke domeinen handtekeningen van meerdere CA's tegelijkertijd actief hadden kunnen hebben in hun certificaten. Als je één CA dan niet meer vertrouwt kan je op basis van de andere CA's het certificaat blijven gebruiken.

Ook zou ik het heel goed vinden als elke bank een 'fingerprint' van hun TLS-certificaat zou meedelen aan hun klanten en je op basis daarvan hun (root-)certificaat zou kunnen vertrouwen. Het kan op de achterkant van je pinpas worden afgedrukt. Dan is er geen CA meer nodig om te weten dat je werkelijk met je bank praat, je hebt een directere en ik denk betrouwbaardere manier om dat te controleren.

Wat mij in de manier van presenteren door EFF stoort is dat voorbij wordt gegaan aan het feit dat HTTPS technisch gezien helemaal geen zelfstandig protocol is maar een combinatie van twee protocollen: HTTP en TLS/SSL. De laatste wordt gebruikt om de eerste te versleutelen. Voordat de versleuteling door de verzender en nadat de ontsleuteling door de ontvanger plaatsvindt werken beide kanten met doodgewone HTTP-berichten.

Als je "HTTP must die" als kreet letterlijk neemt heb je ook geen HTTPS meer, omdat HTTP daar een onlosmakelijk onderdeel van vormt.

startssl gratis en voorniets

https://auth.startssl.com/


Beveiligde verbinding mislukt

Fout tijdens het verbinden met auth.startssl.com. SSL-peer kon niet onderhandelen over een acceptabele set beveiligingsparameters. (Foutcode: ssl_error_handshake_failure_alert)

Potverdikke :(

Ik zou liever zien dat versleuteld verkeer automatisch uitsluit dat er onversleutelde delen kunnen worden meegestuurd. Dus of wel, of niet, maar nooit gedeeltelijk, zoals nu vaak het geval blijkt te zijn op sommige sites of verbindingen.

Ook zie je vaak een verkeerd gebruik van sleutels of te zwakke sleutels (geen PFS bijvoorbeeld).

Versleuteling heeft mijn voorkeur in alle gevallen. Het heeft echter ook nadelen met betrekking tot caching en performance en streaming protocollen (deze laatste is een prima target). Versleuteling alleen, lost niet alles op. Dan nog blijft er een kwetsbaarheid over op het eindpunt na ontsleuteling, of op het beginpunt.

SSL known vulnerabilities: 4, 3 down 1 to go
TLS: 4 known, 2 down, 2 to go

Dat is geen SSL (L4) issue maar een HTTP (L7) issue.

Want gratis, dat is goed.

(en als dan straks startssl gehacked is, dan gaan we hier roepen: ja, maar wat verwacht je ook van een gratis dienst?)

Agree 100 % !!! Onzinnige uitspraken vandaag de dag,. om moe van te worden :)

"Dus jij doet liever zaken met een nep-site van je bank, dan met je echte bank?"

Jij wilt graag dat je verbinding encrypted is, indien je op www.tvgids.nl wilt zien wat voor film er vanavond op TV is ? Dat is een goed voorbeeld van een website waar je geen privacy gevoelige info prijs geeft.

Een internet banking website is nou juist *niet* "een eenvoudige website waar niks kwetsbaars aan hangt". Wat dat betreft vind ik je reactie nogal merkwaardig.

Denk je overigens dat het gebruik van HTTPS bij een website per definitie aantoont dat de website niet ''nep'' is ? Ook criminelen kunnen HTTPS gebruiken namelijk. Het aantal gebruikers dat het certificaat nakijkt is verwaarloosbaar.

"Ik vond op http://stackoverflow.com/questions/149274/http-vs-https-performance nog een heleboel redenen waarom je liever http verkeer gebruikt."

Geheel mee eens, HTTPS moet je gebruiken waar dat nodig is, en niet overal.

Die kan je nog wel heel makkelijk MitMen en er dan een leuk stukje malware aan toevoegen.

Het probleem met HTTP is dat ontwerpers ten onrechte denken dat je hierop met een gebruiker en wachtwoord veilig bent. Maar dat is niet zo, de browser stuurt de user ID en wachtwoord onversleuteld over de lijn. Ook als de server wel encryptie ondersteunt. Pas als de authenticatie mislukt gaat het via encryptie, maar dan is het al te laat.

Het is vreemd dat dat zo weinig aandacht krijgt.

Huh? Ik denk dat als je het inrichten van een website/webserver met https lastig vindt je eerst even in wat techniek moet storten. Juist het opzetten van websites/servers door niet technisch onderlegde personen brengen veel risico's met zich mee. Met SNI is het opzetten van meerdere vhost's op 1 ip ook niet lastig meer.

Van de meeste servers en mobiele devices zijn de CPU's zo krachtig dat die over het algemeen maar weinig te doen hebben. Dat beetje extra overhead voor een SSL verbinding is in de praktijk dus geen issue.

Gaaap, dan neem je bij Xolphin ofzo een betaald certificaat van 15-20 euri ofzo

Als ik de reacties hier lees ga ik inzien dat het opzetten van een webserver en inrichten van een website kennelijk iets is wat door Jip en Janneke gedaan moet kunnen worden. Als het 'iets' lastiger wordt omdat je bijv. een contactformulier wilt gebruiken of een inlog op je site wil voor bijv. het beheren van de pagina's dan is het ineens onzin om https te gebruiken?

De gemiddelde webserver e.d. beschikken over CPU's met meerdere core's die het beetje overhead wat een SSL verbinding vraagt makkelijk aan kan. Met de huidige SNI techniek is ook het opzetten van meerdere virtual hosts op 1 ipadres gemakkelijk geworden. Gebruik evt. het SPY protocol als je https verbindingen wilt versnellen.

Ik word droevig van de onkennis en onkunde als ik lees dat SSL certificaten kennelijk nog duur zijn. Voor een paar tientjes (of nog minder) kan je goede certficaten die door alle gangbare browsers ondersteund worden in Nederland aanschaffen. Bijv. bij Xolpin en dergelijke bedrijven.

Kortom: Als je niet kennis en kunde hebt, richt dat gewoon geen webserver of website op of regel iemand die dat wel heeft en zo je site veilig in de lucht kan brengen.

Ik lees hier veel over dat dit niet nodig is, omdat de website geen persoonlijke gegevens op staan. Dit vind ik echter geen argument: door geen HTTPS (of iets dergelijks) op je website te draaien is het niet alleen een risico voor jou als webmaster, maar ook voor de eindgebruikers. Zoals staat vermeld, is informatie wat niet versleuteld is eenvoudig aan te passen.

Je moet als webmaster niet alleen aan jezelf denken, maar ook aan de eindgebruikers!