Mozilla-ontwikkelaar wil ondersteuning voor http-verkeer uitfaseren

Richard Barnes, security engineer bij Mozilla, heeft voorgesteld om de ondersteuning voor onversleuteld http-verkeer stapsgewijs af te bouwen. Volgens de softwareontwikkelaar is http te gemakkelijk af te tappen en te misbruiken voor bijvoorbeeld het uitvoeren van phishingaanvallen.

Barnes stelt in een posting op Google Groups dat steeds meer internetorganisaties voorstellen om onversleuteld http-verkeer links te laten liggen en om standaard te kiezen voor versleuteld https-verkeer. Om deze omschakeling te bespoedigen, stelt de security engineer voor om stapsgewijs http-verkeer te gaan weren in browsers als Mozilla's Firefox. Dit moet de privacy van internetgebruikers verbeteren en aanvalsmethoden van cybercriminelen via http verminderen.

De softwareontwikkelaar stelt een aantal fases voor om een internetbrede omschakeling naar https te bespoedigen en om webontwikkelaars aan te moedigen om https als standaard te kiezen. In de eerste fase moeten zogeheten privileged contexts gedefinieerd worden, waarin het minimale veiligheidsniveau wordt beschreven. De W3C is daar al mee bezig. In fase twee moet bepaald worden wanneer deze privileged contexts de minimale basis gaan vormen om nieuwe features in een browser als Firefox te kunnen gebruiken.

In de derde fase wordt bepaald dat alleen verkeer dat afkomstig is van https-sites toegang biedt tot nieuwe features in de browser. Daarvoor moet een datum bepaald worden op basis van statistieken die aangeven in welke mate https op internet wordt gebruikt. Barnes denkt dat in de vierde fase http vrijwel in zijn geheel is afgezworen.

Barnes wil met zijn voorstel bekijken of er draagvlak is onder ontwikkelaars. Er klinken op de discussielijst van Mozilla-ontwikkelaars vooral instemmende geluiden, maar er worden ook potentiële problemen beschreven. Zo zijn vrijwel alle intranetsites op http gebaseerd en oudere apparaten ondersteunen niet altijd veilige https-implementaties. Daarnaast maken sommige websites melding van een daling van de inkomsten uit het tonen van reclamebanners als er wordt overgeschakeld op https.

Firefox ondersteunt sinds versie 36 standaard http/2. In dit nieuwe protocol vormen versleutelde verbindingen de basis. Ook browsers als Chrome gaan deze kant op. Daarnaast dalen de kosten voor het aanvragen van een ssl-certificaat, terwijl er inmiddels ook steeds meer gratis opties verschijnen.

Reacties (123)

[Sevenanths]

Sorry, maar voor kleine hobbyist websites kost een certificaat gewoon te veel geld. Ik hoorde onlangs ook iemand zeggen dat voor zijn fotowebsite http gewoon volstond, en dat kan ik goed begrijpen. Het enige wat de vooruitgang in mijn ogen tegenhoudt is diens prijs.

EDIT: kanjer van een dt-fout

[Reactie gewijzigd door Sevenanths op 23 juli 2024 18:26]

[azerty]

Op dit moment wel, alhoewel je perfect een certificaat van bijvoorbeeld StartCom zou kunnen gebruiken, maar daar is de procedure nog steeds vrij omslachtig.

Ik kijk meer uit naar het initiatief van (onder meer) Mozilla: Let's Encrypt. Als dit officieel uitgebracht word zou het mogelijk moeten zijn om automatisch certificaten aan te vragen en te installeren voor je sites, zonder kosten.

Met dit initiatief is het dan wel perfect mogelijk (tenzij je op shared hosting zou zitten, maar daar valt denk ik ook wel een mouw aan te passen) om voor ELKE site SSL te voorzien.

[grizzler]

Werkt dat ook op shared hosting? Normaal gesproken moet je toch een eigen IP-adres hebben als je HTTPS wilt doen. Daar moet je tegenwoordig ook flink voor betalen en alleen op IPv6 gaan zitten is nog niet interessant.

[dbram]

waarom shared hosting... 5-10 EUR / maand voor een VPS of dedicated en dan 2 eur extra installatie per ip en dan gratis per maand tot 8 of 16ips dacht ik...

[lordfragger]

Die servers kosten tegenwoordig inderdaad echt niks meer, maar de uren die je er moet insteken om alles op te krijgen en elke maand te onderhouden (anders krijgen we weer servers die 5 jaar achter lopen met hun patches) moet je ook rekenen.

Tel daarbij dat veel van die websites gemaakt zijn door iemand die net wat dingen op hun plek kan slepen in iets dreamweaver-achtig en ik heb liever dat die sites op een (goedkope) shared hosting zitten.

[dbram]

Inderdaad eeuwige shared vs dedicated toestanden.

Ik zal het zo uitdrukken, ik verkies dedicated. Eenmaal je boven de paar ip's zit is het goedkoper om dedicated te gaan ipv shared.

Maar volgens de hier aangehaalde argumenten kan je beter shared hosting gaan als de kennis ontoereikend is. Eigenlijk gebruik dan je dan beter een voorgesleuteld pakket en vergeet je ook beter om aan (shared)hosting te doen.

Alles hangt af van wat je kan (tijd en kennis) t.o.v. of voorgekauwde zaken goed genoeg zijn.

[svennd]

5 euro/maand voor een dedicated ? Shared host : 10 euro/jaar! Daarnaast is nog maar de vraag of jelokalevoetbalclub ook de benodigde kennis heeft om een VPS/dedicated te beschermen.

[Rob Wu]

Ja het werkt ook met shared hosting. Met Server Name Indication (SNI) kan een server met één IP adres verschillende websites tonen over https. Alle moderne web browsers ondersteunen SNI.

[Spinal]

Nee, eigen IP-adres is al jaren niet meer nodig. Alleen oude IE-versies op Windows XP (en lager) ondersteunen het niet, maar Windows XP en die oude IE's worden toch al niet meer ondersteund (en, zeker in Nederland, nog nauwelijks gebruikt)

[tom.cx]

Het ziet er inderdaad goed uit. Alleen vraag ik mijzelf dan wel uit hoe Let's Encrypt er voor gaat zorgen dat er geen 'foute' sites gebruik kunnen maken van de dienst. Het is zoals ik het zie zo eenvoudig dat je eenvoudig een phishing site kan opzetten. Natuurlijk zal er wel een detectie systeem zijn. Maar als het 24 tot 48 uur duurt dan kan je al genoeg slachtoffers maken.

[CAPSLOCK2000]

So what dat "foute" sites ook een "goed" SSL-certificaat hebben? Fishers doen het nu helemaal zonder SSL-certificaat en daar trappen mensen ook in. De meeste mensen hebben geen flauw benul van HTTPS en accepteren gewoon alles.

[Blaise]

Met als verschil dat een foute site met een goed SSL certificaat een slotje laat zien in de browser, wat een vals gevoel van veiligheid zou kunnen opwekken.

[CAPSLOCK2000]

Weer dat "valse gevoel van veiligheid'. Als je alleen maar naar het slotje kijkt heb je nu ook al een vals gevoel van veiligheid. Maar de meeste mensen kijken zelfs niet naar slotje, die hebben permanent een vals gevoel veiligheid. Die grote massa is beter af als alles HTTPS gebruikt.

[Ge Someone]

Het gaat er vooral om dat een "foute" site niet een certificaat van een ander kan gebruiken (verkrijgen). Het hele https verhaal is gebaseerd op de betrouwbaarheid van SSL certificaten.
Ik zie hier niet veel in, zou het niet beter zijn de IPsec mogelijkheden van IPv6 standaard te maken (bij de overgang naar dit protocol)? Ik zeg niet dat dat sneller zal gaan .

[CAPSLOCK2000]

Dat zal liggen aan hoe ze controleren de controle doen. De controles zijn echter nu al zo boterzacht dat je er geen waarde aan kan hechten. Een EV-certificaat zegt nog wel wat maar een normaal certificaat controleert niet meer dan dat je toegang hebt tot DNS en/of mail van dat domein. Ze controleren niet of je ook recht hebt op dat domein.

IPsec zie ik ook graag gebruikt worden maar daarvoor hoeven we niet op IPv6 te wachten, dat kan net zo goed op IPv4. Nu nog een eis toevoegen dat je IPsec moet gebruiken als je IPv6 wil doen gaat niet meer lukken, daarvoor is het al te ver uitgerold.

IPsec zit overigens met hetzelfde probleem als HTTPS: hoe controleer je of je het juiste certificaat gebruikt?

Een oplossing is om dit via DNS te communiceren. Dat heet DANE.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 18:26]

[Reason]

In principe is het vrij simpel, ze laten de agent op de server die een host is van een specifiek domein een aantal dingen "exposen" zodat Let's Encrypt dit kan verifiëren.

Bijvoorbeeld (zoals google dat doet) een bestandje in de webroot van je nieuwe domein met een code erin, of een reverse DNS lookup om te kijken of het IP adres van je aanvraag wel bij dat domein hoort.

Zie: https://letsencrypt.org/howitworks/technology/

Op shared hosting kan je ook prima meerdere sites draaien met 1 ip-adres en meerdere certificaten. Zie: SNI

[Reactie gewijzigd door Reason op 23 juli 2024 18:26]

[Trommelrem]

Precies. Voor veel zaken voldoet HTTP ook gewoon. Zolang er geen wachtwoorden en persoonlijke gegevens overheen gaan, vind ik HTTPS onzin. Ik implementeer het wel zo veel mogelijk, omdat heel veel websites wel een login hebben, maar het geeft ook een gevoel van schijnveiligheid. Het heeft geen zin om HTTPS verkeer te gebruiken als de backend, bijvoorbeeld een database, niet eens encrypted is.

Zie bijvoorbeeld CU2. Die antieke website waar niet eens encryptie op de database zit, terwijl CU2 dat wel garandeert volgens hun eigen voorwaarden. Dan heeft HTTPS compleet geen zin meer. Dat is alsof je wel het waardetransport beveiligt, maar het pand waar de waarde heen gaat, heeft niet eens een slot op de deur.

[Reactie gewijzigd door Trommelrem op 23 juli 2024 18:26]

[sumac]

Hoezo moet een database encrypted zijn? Je bedoelt dat de wachtwoorden versleuteld worden opgeslagen? Dat zijn twee verschillende dingen. Een database versleutelen gebeurt zelden. Soms wordt verkeer tussen database en webserver versleuteld, maar ook dat gebeurt zelden. HTTPS voegt altijd iets toe, en zeker in het geval van onversleutelde wachtwoorden. Het is tegenwoordig achterhaald en not done om wachtwoorden niet te versleutelen, maar als het niet gebeurt, juist dan voegt HTTPS wel degelijk iets toe.

[Trommelrem]

Alleen de wachtwoorden versleutelen? Daar schiet je niets mee op. Er staat meer in zo'n database dan wachtwoorden. Denk aan N.A.W. gegevens van gebruikers. Ook die moeten voldoende beveiligd zijn.

[sumac]

Ik betwist jouw "helemaal niets". Maar het wordt een welles-nietes spelletje. Los daarvan, wachtwoorden kun je hashen, maar NAW gegevens moet je ook weer kunnen ontsleutelen. Dus ergens in je code moet de sleutel staan om dit te doen. Die veiligheid is dus ook betrekkelijk. Want ook nu sla je een (soort van) wachtwoord onversleuteld op. En als je nu gaat zeggen dat dit altijd veiliger is dan niet versleutelen, dan zeg je precies hetzelfde als wat ik zeg over https.

[kalekip1]

Hoe zou jij statements uitvoeren dan? Eerst alle miljoenen records laten decrypten om vervolgens een simpele LIKE search te kunnen doen?

SELECT * FROM `users` WHERE `surname` LIKE decrypt_functie('%van der B%')

[Reactie gewijzigd door kalekip1 op 23 juli 2024 18:26]

[YaPP]

En daarom heeft PostgreSQL standaard SSL encrypte op de verbindingen. Beetje zonde als alles beveiligd is, maar je database verkeer af te luisteren is. MySQL heeft dat idd standaard niet.

[EraYaN]

Zou je daarom je database server en webserver niet op een intern netwerk met elkaar laten communiceren of in ieder geval achter een firewall? Het is echt niet nodig om non-ssl verkeer tussen die twee over het inetrnet te laten gaan. Als ze op een andere locatie staan kun je er gewoon een tunnel tussen leggen...

[YaPP]

Zou je daarom je database server en webserver niet op een intern netwerk met elkaar laten communiceren of in ieder geval achter een firewall?

Op een intern netwerk is idd altijd beter. Dat kan niet altijd bij VPS providers, hoewel sommige ook VLAN support hebben. Daarnaast is het alsgoed een goede pratice. Zelfs google encrypt tegenwoordig verkeer tussen servers en datacenters, aangezien ook dat afgetapt kan worden, en ook afgetapt werd.

De overhead van SSL verbindingen opbouwen kun je eventueel weghalen door PgBouncer op de webserver te draaien. Die houdt dan via connection pooling een permanente verbinding naar de database server open.

[Reactie gewijzigd door YaPP op 23 juli 2024 18:26]

[EraYaN]

Kun je dan niet beter een ge-encrypte tunnel opzetten? (Die er altijd is dus?)

[CAPSLOCK2000]

Ik heb een beetje een hekel gekregen aan de opmerking "dat is schijnveiligheid". Geen enkele maatregel is compleet veilig. Veiligheid schep je door een hoop kleine maatregelen op te stapelen.

HTTPS is een relatief makkelijke en goedkope maatregel die in de meeste gevallen een hoop veiligheid toevoegt. Overal en altijd HTTPS gebruiken is de makkelijke oplossing. Dan hoef je niet na te denken of het nodig is en in de toekomst hoef je niet bij iedere herziening die overweging opnieuw te maken. De meeste mensen kunnen die overweging niet eens goed maken.

[mikenuun]

Kost je €10 per jaar hé voor een simpel certificaatje.
Als je toch al op Hobby Niveau een domeintje hebt (Wat waarschijnlijk duurder is)
Lijkt het me een klein bedrag,

Maar iedere euro is er een te veel als het voor de hobby is, mee eens.

[Kurai Hoshi]

Hobby domeintje is ook maar een euro of tien per jaar, plus nog wat voor de hosting, meer dan dertig euro zal het niet zijn, als daar nog een tientje bij komt is dat dus een flinke verhoging. Nog steeds geen drama natuurlijk, nog geen euro per maand. En een hobby kost geld. Kan me voorstellen dat providers hier ook makkelijker op in gaan spelen en je een compleet pakket gaan aanbieden, zodat het minder dan een tientje wordt.

Maar ik voorzie zo dan ook een wildgroei aan certificaten als ieder hobby domeintje een certificaat kan krijgen, wat heeft het certificaat dan nog voor zin? Creer je zo niet een schijnveiligheid? Alles is https dus het zal wel goed zijn. *click* en je bent de sjaak...

[EraYaN]

En tuurlijk heeft het nog zin. Certificaten moeten nog steeds kloppen hoor. Jij kan echt geen certificaat krijgen voor rabobank.nl (als de CA zich niet op laten kopen, maar dat is nu ook al zo).

Een https met een "slecht" certificaat wordt nog steeds geweigert.

[Kurai Hoshi]

Maar een certificaat voor rabobnak.nl natuurlijk wel,

de gebruiker is geconditioneerd te denken dat als het balkje boven maar groen is en er https staat, dan zal het wel goed zijn.

Nu zal er wel wat controle zijn, maar hoeveel tijd heb je nodig om mensen om de tuin te leiden?

[EraYaN]

Je krijgt als het goed is ook geen groen balkje daarvoor... Die worden nog steeds vrij goed gecontroleerd (in nederland dan hea) Je moet dan al bij de kvk een bedrijf hebben dan rabobnak heet.

EDIT: dan komt de rabo je halen denk ik zomaar ik zie de stapel blaf brieven al voor me.

[Reactie gewijzigd door EraYaN op 23 juli 2024 18:26]

[CAPSLOCK2000]

Het vervelende is dat we weten dat het vroeg of laat fout gaat. Er zijn wereldwijd duizenden bedrijven die certificaten kunnen uitgeven en er is felle onderlinge concurrentie. Al die bedrijven staan dus onder druk om het zo goedkoop mogelijk te doen. Je kan er dus van uit gaan dat er ook een paar tussen zitten die de kantjes er van af lopen om de prijs te drukken. Hierdoor wordt de prijs naar beneden gehaald en wordt de rest gedwongen om hun prijzen ook aan te passen. Dat betekent dat die anderen hun controles ook goedkoper moeten maken. Met gewone certificaten hebben we al het punt bereikt dat de controle bestaat uit niet meer dan een e-mailtje beantwoorden of een stringetje in je DNS publiceren, al het andere is te duur. EV-certificaten zitten ook al in de neerwaartse spiraal. Vroeg of laat zullen deze ook niet meer genoeg zijn en zal wel iemand zo iets als extra-extra-veilige-certificaten bedenken.

[EraYaN]

Maar het word nooit slechter dan HTTP.

[Eloy]

Mozilla is juist degene die is gestart met Lets's Encrypt, een gratis CA.

https://letsencrypt.org/

[goarilla]

En is die CA getekend door een trusted CA ? Want anders moet je toch certificaten gaan importeren.

[Yggdrasil]

Ja, dat is ie. Maar check vooral even die site.

[com2,1ghz]

Danku, Toevallig zelf nog bezig met het uitzoeken van gratis certificaten.

[Rafe]

Als nieuws: EFF wil gratis certificaten uitdelen via onafhankelijke certificaatautoriteit live is (halverwege dit jaar) is dat ook geen bezwaar meer.

[svennd]

https://letsencrypt.org/

Ik geef je overschot van gelijk, ssl certificaten zijn duur en brengen weinig extra beveiliging bovenop eigen gegeneerd keys. Maar dat schuwen alle browsers wel, ondanks https duidelijk veiliger is dan http.

Een alternatief zoals letsencrypt bezig aan is kan ik aanvaarden. Ik hoop dat het er dan ook snel komt.

[bassekeNL]

GoDaddy geeft gratis certificaten aan open source projecten. Zet je site op github en hang er een GPL aan.

[fonsoy]

Dat lijkt me niet echt een goed argument.
Ik betaal voor een instap SSL certificaat bij Versio slechts een paar euro per jaar. Soms zijn ze nog in de aanbieding ook. Dat is meestal een fractie van wat je voor de hosting moet betalen.
Dat snelheid een argument is, ja dat kan ik me voorstellen. Dat is ook de reden waarom tweakers.net niet overstapt op https
De informatie op de site is immers publiekelijk beschikbaar.

[niqck]

Ik gebruik al een aantal jaren een SSL certificaat van Gandi. Kost me nog geen 15 euro per jaar. Zo duur is dat nu ook niet... En binnenkort is er letsencrypt.org, gratis... dus de prijs is niet meer van toepassing.

[Heli0s]

Een Comodo PositiveSSL kost 9 euro per jaar:

https://www.sslcertificaten.nl/SSLCertificaten

[YaPP]

Sorry, maar voor kleine hobbyist websites kost een certificaat gewoon te veel geld.

Hosting: €15,- tot €29,- per jaar voor een simpele HTML/PHP site.
SSL certificaat: €9,- per jaar. (zie: https://www.sslcertificaten.nl/SSLCertificaten)

Ik snap je argumentatie echt niet.
Vroeger betaalde we gerust €100,- per jaar voor hosting, en nu veel minder maar dan is SSL te duur?

[flossed]

Volgens mij valt dat wel mee,
maar het is wat je veel vindt, je betaald immers ook om de zaak te hosten, of voor je eigen internet verbinding. Ik heb van Gandi.net een bruikbare SSL certifcaat voor 12.50. per jaar. vind ik niet een onoverkomelijk bedrag

[dwarfangel]

De hoge kosten komen voornamelijk voort uit hoge marges. Wanneer er meer SSL's afgenomen zouden worden, doordat deze bijvoorbeeld verplicht gesteld zouden worden door de overheid, of in dit geval een browser, zal de vraag en concurrentie vanzelf toenemen, wat resulteert in betere prijzen.

De kostprijs van een SSL ligt onder de 2 euro per maand. Reken maar uit, daar kun je best en beetje over onderhandelen met je hostingpartner. Het hoeft echt niet niet veel meer te kosten..

[siteoptimo]

Een basiscertificaat kost 4,5 euro. Dat is ongeveer wat een domeinnaam kost. Via Cloudflare kan je vrij eenvoudig gratis SSL aanvinken en configureren zonder echt zelf een certificaat te hebben.

Verder bestaan er ook nog tal van gratis certificaten zoals die van StartCom, StartSSL of FreeSSL.

[Firefly III]

Wat, een tientje per jaar bij Comodo? Poeh he, dat is duur.

[GuntherDW]

In principe is het wel duur ja, je betaalt voor iets wat je zelf ook kan doen.
Klopt, het wordt dan niet zomaar accepted in browsers, maar waarom iemand betalen om op cru gezegd 1 knopje maar te drukken.

Daarom ben ik inderdaad ook voor dingen als "StartSSL", gratis SSL certs die 1 jaar geldig zijn. Wil je langer durdende certs/wildcards moet je je ID scannen en eenmalig betalen.

Het enige waar je eigenlijk bij de "grote" cert boeren voor betaalt is de naam, niet voor de veiligheid, want dat is even sterk als je zelf een certificate signeert.

[Firefly III]

Je betaalt voor een bedrijf dat haar eigen private keys goed beschermt en een redelijke controle doet op het uitgifteproces, en dat constant laat auditen door een derde partij.

De prijs zit hem niet in het certificaat, want inderdaad, voor de security hoef je het niet te doen.

Gezien de huidige PKI, met root ca's en wat al niet, vind ik dat tientje niet zo'n punt.

[mvd64]

Probeer eens StartSSL voor een gratis cert.

[hendrickbert]

Moet je hoster het ook ondersteunen zonder direct een duur pakkket te nemen.

[Blaatpraat]

Slechte hoster, heb je in dat geval.
Ik bied standaard SSL, IPv6, DNSSEC enzovoorts aan, zonder meerkost.
Als klanten bij mij een ander certificaat willen, dan de basis van StartSSL, zijn ze hier vrij in.
Mijn mening is dat iedere webhosting zonder problemen dit zou moeten kunnen voorzien, het is nu niet dat de servers van tegenwoordig het niet aankunnen, noch dat het veel werk is om te implementeren...

[Invoke]

Een basis SSL certificaat heb je al voor € 9 per jaar, dat lijkt me prima betaalbaar.

[Gurd]

Ligt er naar mijn mening toch aan wat voor eisen je stelt. Een simpel SSL certificaat (domain validated) kost minder dan 20 euro per jaar.

[Sorcerer8472]

Op zich een goed plan. Hierdoor wordt het steeds minder belangrijk hoe je nou met het internet verbonden bent; nu verbind ik bewust niet met wifi-hotspots in restaurants e.d.

Echter, ik zie wel mogelijke problemen met volumeverkeer zoals grote downloads en video. Dit kost meer verwerkingskracht als het via https moet lopen. De vraag is in hoeverre dit een probleem zou kunnen zijn. Ook zal latency naar verwachting iets toenemen en zal energieverbuik licht toenemen.

De vraag is in hoeverre deze zaken nou wel of niet een probleem zijn. Ik gok dat het meevalt, maar ik denk dat het op zich een goed idee is als niet alle videoverkeer op internet versleuteld hoeft te zijn (met daarna nog een DRM-stap als je een beetje pech hebt).

[FragFrog]

Als je gevoelige zaken wilt doen over een onbeveiligde WiFi hotspot is het natuurlijk een fluitje van een cent om ofwel TOR te gebruiken, ofwel een VPN tunnel op te zetten naar een betrouwbaar netwerk (wat min of meer op hetzelfde neerkomt). Maar dat doet bijna niemand, want het kost extra bandbreedte en maakt je verbinding trager. Exact wat HTTPS forceren ook gaat doen.

I've said it before and I'll say it again: de kans dat iemand je wachtwoord steelt met een MitM aanval is dusdanig veel kleiner dan de kans dat iemand hetzelfde voor elkaar krijgt middels phising / malware / beveiligingsgaten op de server zelf (denk: SQL injecties) dat de kosten-baten volslagen buitenproportioneel zijn. Tweakers.net heeft daar zelf nog eens een mooi .plan over geschreven, waaruit bleek dat de HTTPS pagina twee keer zo lang nodig had om te laden - en voor wat? Die minieme kans dat iemand een targetted MitM aanval uitvoert om je t.net verkeer te zien? Mijn login-gegevens krijgen ze sowieso niet (want dat gaat netjes versleuteld), dus worst case scenario zouden ze dit bericht kunnen aanpaIGNORE PREVIOUS SENTENCE. GLORIOUS WEB MASTERS SHOULD ALL IMPLEMENT SSL! BUY CERTIFICATE NOW FROM NORTH KOREAN SECURITY, ALL HAIL GLORIOUS LEADER!

[Yggdrasil]

Volgens Google is de extra verwerkingskracht tegenwoordig te verwaarlozen. Zij hebben geen extra capaciteit hoeven in te schakelen toen ze alle verkeer naar google en gmail via TLS gingen laten lopen.

De latency is wel een reëel probleem. Deze neemt substantieel toe (zo'n 3,5x). Hier kan echter nog wel aardig wat aan geoptimaliseerd worden door het verbeteren van de software-stack en bijv. het cachen van sessie-tickets e.d.

Bron: http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

Ik neem aan dat dit soort nadelen door toegenomen gebruik de nodige aandacht zullen krijgen en zullen verdwijnen. Ook zal dan hopelijk de tooling verbeteren waardoor activeren en beheren van TLS straks nauwelijks extra werk en kennis vereist van hosters en bouwers. Dat is vereist voor een bredere adoptie. Projecten zoals https://letsencrypt.org/ werken hier al aan.

[Reactie gewijzigd door Yggdrasil op 23 juli 2024 18:26]

[mvd64]

Maar je hebt wel een apart IP voor elke site met certificaat nodig...

[Bigs]

Tegenwoordig kun je prima SNI inzetten en is het dus niet meer nodig om een apart IP per certificaat te gebruiken.

[mvd64]

To make use of SNI practical, the vast majority of users must use web browsers that implement it. Users whose browsers do not implement SNI are 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.

[Maurits van Baerle]

En aan die voorwaarde wordt al jaren voldaan aangezien IE, Chrome, Firefox, Safari en Opera al jaren SNI ondersteunen.

[Blokker_1999]

SNI bestaat al meer dan 10 jaar en werd reeds in 2006 opgenomen in OpenSSL en in 2007 gebackport naar OpenSSL 0.9.8. Alle moderne browsers ondersteunen dit principe. Maak zelf al jaren gebruik van SSL certificaten die niet IP/host gebonden zijn maar puur op hostname gaan.

[niqck]

Iemand die een browser gebruikt die geen SNI ondersteund is zo een beetje in het stenen tijdperk van het internet blijven hangen. De meest gangbare browsers (IE, FF, Chrome, Safari, Opera) ondersteunen SNI. De enige browsers die voor zover ik weet problemen vertonen zijn IE6/XP, Android < 3.0, (oude) Blackberries. Voor grote websites kan ik begrijpen dat dit een probleem is, die willen een zo groot mogelijk publiek kunnen bereiken waarbij niemand voor een "gesloten deur" staat, maar voor een hobby-ist lijkt me dat een minder groot probleem.

[HansvDr]

Klanten van ons, en wij hebben nog aardig wat Windows 2008 R2 servers draaien met IIS.

Dat ondersteunt geen SNI helaas.

En de servers alleen voor SNI overzetten op 2012 zit er niet in.

[Verwijderd]

Ik zo'n gevallen kan je altijd een reverse proxy ervoor zetten, die het HTTPS-gedeelte afhandelt.

[runelaenen]

Neen, tegenwoordig kan je meerdere certificaten op 1 ip installeren aan de hand van SNI.

[mvd64]

Thanks, wist ik niet. Ik ga me er eens in verdiepen.

[Blokker_1999]

Toch vreemd dat een techniek die al zowat 10 jaar bestaat nog altijd bij velen niet gekend is.

[runelaenen]

Het wordt dan ook nog niet lang door alle gebruikte browsers ondersteund. Gelukkig moeten we nietmeer kijken naar IE6

[Sfynx]

Dat is omdat het al die tijd niet veel gebruikt werd met dank aan Windows XP.

[bartmau93]

Je kan gewoon meerdere sites met een certificaat op een VPS hosten hoor.

[MikeN]

Dat is niet meer het geval sinds SNI is uitgevonden: http://en.wikipedia.org/wiki/Server_Name_Indication

De enige enigsinds problematische browsers die geen SNI doen zijn Internet Explorer op Windows XP en Android 2.x, die beide steeds meer verdwijnen van de markt gelukkig.

[azerty]

niet waar. Er bestaat zoiets als SNI, waardoor je meerdere sites met verschillende certificaten op dezelfde server kunt draaien. Natuurlijk, oudere browsers ondersteunen dit niet (IE6-8 op XP bijvoorbeeld), maar hoe belangrijk zijn deze nog?

[sven wiltink]

Een apart ip is niet nodig. Een certificaat kan voor meerdere subdomeinen worden gebruikt. Er kunnen ook meerdere ip adressen achter 1 domein hangen dmv srv records en dns resolvers als round Robin.

[Jimbolino]

"steeds meer gratis opties" voor ssl certificaten?
ik ken er maar één: startcom.org

[Ibex]

Bij Cacert.org kan je afaik ook gratis certificaten verkrijgen.

[Jaap-Jan]

Maar het rootcertificaat van cacert.org zit standaard in geen enkele browser.

[Eloy]

Dat is alleen handig voor jouw eigen services die je alleen zelf gebruikt. Bijna niemand heeft het CACert Root Certificaat geinstalleerd.

[wimme.net]

Dit jaar zou er wel nog een gratis optie bijkomen, namelijk letsencrypt.org

[Fruit]

WoSign (chinese certificatenboer) is gratis en gebruikt het StartCom rootcertificaat: https://buy.wosign.com/free/. Heeft meer opties dan StartCom zelf en is ook commercieel te gebruiken geloof ik.

Beter wel OCSP stapling gebruiken, want anders zal de eerste pagina een beetje langzaam verschijnen.

[mashell]

Ergens rammelt dit. Bij http is de identiteit van de verzender niet vast te stellen. Dat kan wel bij https, dus daarom gaan we maar al het verkeer versleutelen. Een beetje extreme maatregel. Correct zou zijn een verbeterede versie van http waarin het probleem niet zit maar de data niet versleuteld wordt verstuurd zodat keuze voor versleuteling een bewuste blijft. Maar zoals je bij IPv6 ziet gaat de adoptatie van nieuwe protocollen zo langzaam dat zoiets een kansloos verhaal gaat worden.

[Verwijderd]

Versleuteld verkeer is ook extra overhead.
Dit is gewoon standaard alle verbindingen trager maken en effectief ook een extra bos aan rekenvermogen oproken.
En totaal zinloos voor het grootste gedeelte van het internet verkeer wat bestaat uit het enkel en alleen consumeren van data.

[tom.cx]

Dat ligt er ook weer aan hoe sterk de SSL encryptie is en hoe deze ondertekend is volgens mij. Ik merk zelf bij sites (misschien dat het on milliseconden gaat) geen verschil met https en http verbindingen.

[T0mBa]

Als je alleen al naar Google kijkt:
6 miljard zoekopdrachten per dag.
Neem dan 1 milliseconde vertraging door encryptie.
Dat zijn in totaal 70 dagen vertraging per dag!

Dus als héél het internet via encryptie zou lopen kan je je wel voorstellen dat het aantal "verspilde" cpu cycles gigantisch wordt. In ene tijdperk dat de mensheid zijn energieverbruik moet inperken is dat toch absurd?

[kalekip1]

Daarom ook HTTP/2.0.

[i-chat]

ik weet niet of je nu een alu hoedjes theorie probeert te spammen of wat het dan wel prcies is, maar bij https is alleen de server kant maar te identificeren, en verder gaat het vooral om versleutelen...

het hele punt is hier nu juist dat encryptie nu juist het beoogde doel was en niet die validatie ... al wordt er iid ook over phishing gesproken, vind ik privacy een veel belangrijker issue... het feit dat je bij een http verbinding letterlijk iemands username + pass mee krijgt is best eng vooral als je weet dat een substantieel deel van de bevolking niet snapt waarom hergebruik van wachtwoorden gevaarlijk is.

[mashell]

het feit dat je bij een http verbinding letterlijk iemands username + pass mee krijgt is best eng vooral als je weet dat een substantieel deel van de bevolking niet snapt waarom hergebruik van wachtwoorden gevaarlijk is.

En dat is nou net de reden dat je niet al het verkeer moet gaan versleutelen. Als mensen denken dat al het verkeer versleuteld is, dan denken ze ook dat het veilig is. Terwijl we weten dat websites hier vaak erg slordig zijn. Aan beide kanten, zowel gebruiker als site beheerder moet er een bewustzijn komen over hoe om te gaan met zulke data. Je maakt dat bewustzijn een stuk gemakkelijker door de data die beveiligd is getransporteert een speciale behandeling te geven en het niet onder te laten gaan tussen al dat versleutelde verkeer.

[Martijndoes]

Op zich juich ik dit toe. Het zou veel makkelijker zijn als gewoon alle sites https gebruiken. Maakt het ook veiliger en makkelijker voor de consument. Die waarschuwingen die gebruikers nu krijgen als er mixed content is of als een SSL certificaat niet klopt zegt ze niks en dus klikken ze die door. Als alles https is kan er gewoon keihard gezegd worden dat sites die geen https zijn geblokkeer worden door de browseers.

Je moet alleen de verantwoordelijkheid niet meer bij de ontwikkelaar leggen dan maar bij de hosting partijen. Het web moet iets blijven waar ook de hobbyist makkelijk een site neer kan zetten en gedoe met SSL certificaten kan veel makkelijker door de hosting partij afgehandeld worden.

[i-chat]

aan de andere kant, waarom zou het logo van tnet, of het plaatje bij het knopje verzenden (togegeven dat kant tegenworldig ook met css en zo. maar toch... via https worden verstuurt, dat zorgt alleen maar voor extr kosten want die versleuteling kost gewoon cpu kracht... bovendien is het vertrouwen op certs van rare partijen uit landen als china of bedrijfjes die hun zaken niet op orde hebben, niet nuttig maar kost de huidige gang van zaken gewoon keiharde pegels, zowel omdat je een zwaardere webserver moet huren, als omdat sommige van die gratis certs niet eens vertrouwd worden in je browser.

het grote probleem hier is dat ssl 2 problemen probeerd op te lossen waavan er eentje al een tijdje achterhaald is..
> het verzorgen van encripty, waar het feitelijk ga gaat,
> het authenticeren van servers, uit naam van een bepaald bedrijf, of bepaalde website (dit is lang niet altijd nodig en/of van belang... het is een leuke feature, maar in heel veel gevallen kun je er vanuit gaan dat het de server wel is, een meer nog nu dns sec er is

[Mijzelf]

Het gebruik van gratis certificaten degradeert het systeem. Certificaten zijn duur omdat de de certificaat verlener moet controleren of de aanvrager wel degene is die recht heeft op het domein. En nu rammelt het systeem al.

Als http wordt gedropt en er een wildgroei aan 'gratis' certificaten en self-signed certitificaten komt, krijg je veel meer websites die alarmbellen laten rinkelen door self-signed of verlopen certificaten, of door ingetrokken root certificaten, of ...

Dus mensen raken gewend die meldingen weg te klikken, en het kind ligt bij het badwater in het riool.

[Blaatpraat]

Ooit al eens een gratis certificaat aangevraagd?
De procedure om te verifiëren of je wel de eigenaar bent, is bij mijn weet de correcte methode.
Mailtje sturen, of een TXT-record aanmaken.

Het is niet omdat het gratis is, dat het niet goed is.
Geld vragen voor een simpel certificaat is juist iets dat foutief is imo.
Geld vragen voor een beter certificaat, is iets anders, maar de basis mag gratis zijn...

[Faeron]

HTTPS is geen garantie voor privacy (of veiligheid). De kans dat iemand mijn verbinding afluistert is vele male kleiner dan de kans dat een website eigenaar Facebook meuk of andere trackers in z'n website verwerkt of er een kwetsbaarheid in heeft zitten waardoor aanvallers bij de gegevens kunnen. HTTPS wordt als je het mij vraagt behoorlijk overgewaardeert. Zeker ten opzichte van de andere zaken die betrekking hebben op privacy en beveiliging.

[teek2]

Alleen bij Facebook weet je het. Maar als je 1 keer iets belangrijks doet zonder HTTPS op een publiek netwerk ben je snel de sjaak.

[cyberstalker]

Ik kan niet anders dan dit een goede zaak vinden. Het probleem met versleuteling is dat deze te kraken is, wat gelukkig nog wel een redelijk kostbaar proces is (kost veel CPU-kracht). Als je alleen de vertrouwelijke informatie onversleuteld wordt daar natuurlijk alles op ingezet, terwijl men bij het versleutelen van alles geen idee heeft wat vertrouwelijk is totdat men het ontsleutelt.

Hiermee maak je het dus lastiger om ongericht te tappen.

[Wailing_Banshee]

Dat zou voor mij het einde van Firefox zijn. Ik ga geen certificaten installeren op mijn thuis pc voor intern gebruik.