Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 40 reacties
Bron: CNET News.com

Diverse autoriteiten op het gebied van de uitgifte van Secure Socket Layer (SSL)-certificaten zullen in 2006 bij elkaar komen om een nieuwe methode te bespreken om te kunnen garanderen dat communicatie met een website veilig is. De huidige methode van SSL-certificering voor websites werd oorspronkelijk door Netscape ontwikkeld. Sindsdien wordt het bekende gele slot-icoon gebruikt om aan te geven dat de communicatie met de website beveiligd is tegen meekijkers van buitenaf. Ook heeft een SSL-certificaat lange tijd garant gestaan voor de validiteit van de website in kwestie. Vanwege het groeiende aantal phishing-aanvallen en de devaluatie van SSL-certificaten is er de laatste jaren een roep gekomen om een nieuwe methode om de integriteit en veiligheid van een website mee aan te geven. Dit is temeer belangrijk omdat het aantal ‘gevoelige’ handelingen op internet de komende jaren hard zal groeien. De online verkoop, dit jaar in de VS nog goed voor een omzet van 172 miljard dollar, zal volgens een schatting van Forrester Research in 2010 goed zijn voor 329 miljard dollar aan geldtransacties via internet. Daarnaast hebben phishing-aanvallen in 2004 wereldwijd de financiële dienstsector een bedrag van 400 miljoen dollar lichter gemaakt. Diverse certificeringsbedrijven zijn daarom met elkaar en met de makers van de grootste internetbrowsers in gesprek over een nieuw certificaat dat garant moet staan voor een grotere zekerheid van veilige communicatie.

SSL slotHet grootste probleem met de huidige uitgifte van SSL-certificaten is dat er niet meer in alle gevallen een grondig onderzoek wordt uitgevoerd naar de integriteit van de aanvrager. In sommige gevallen is het opgeven van een valide e-mailadres al voldoende om een certificaat toegewezen te krijgen. Dat, in combinatie met de gedaalde kosten voor certificering, heeft ervoor gezorgd een SSL-certificaat zeker niet meer gelijk staat aan een veilige internetomgeving waarin zonder gevaar vertrouwelijke informatie heen en weer kan worden gestuurd. Bedrijven die de certificaten verkopen zoals VeriSign, Comodo, GeoTrust en Cybertrust zullen daarom in het zogenaamde CA Forum proberen een nieuw model van certificering te ontwikkelen. De beoogde datum van presentatie hiervan is daarbij halverwege 2006.

SSL-icoon in IE6 (boven) en Firefox 1.5 (onder)
SSL-icoon in IE6 (boven) en Firefox 1.5 (onder)

De manier waarop browsers certificering weergeven, vormt ook een onderdeel van het probleem. Elk SSL-veiligheidscertificaat, ongeacht de autoriteit van de leverancier ervan, wordt op identieke wijze aan de gebruiker gepresenteerd. Onderscheid tussen verschillende certificaten is daarom moeilijk in één oogopslag te zien. Naast een nieuw ontwerp van beveiligingscertificaten dienen dus ook browsers hun methode van beveiligingsweergave opnieuw uit te vinden. Internet Explorer zal hier vanaf versie 7 mee beginnen. In tegenstelling tot het rechts-onderaan zichtbare slot voor SSL-certificering, zal een indicatie van de nieuwe certificering zich in de adresbalk bevinden. Websites die gebruikmaken van deze certificering, zullen daarnaast de adresbalk een groene kleur meegeven. Ook Opera en Firefox hebben de implementatie voor de nieuwe beveiligingsindicator hoog op de agenda staan. Voordat het zover is, zal wel eerst deze nieuwe certificering ontwikkeld moeten worden. Het grootste probleem daarbij zullen de te overbruggen verschillen zijn tussen de verschillende certificeringsauthoriteiten. Als die drempels geslecht zijn, dan zou volgens een woordvoerder van VeriSign de beveiliging van websites - en daarmee het vertrouwen van de gebruikers - een grote stap voorwaarts kunnen maken.

SSL-beveiligingscertificaat SNSbank.nl

Lees meer over

Moderatie-faq Wijzig weergave

Reacties (40)

Als ik het goed begrijp worden deze beveilingscertificaten te gemakkelijk uitgegeven door dezelfde mensen die nu een standaard in het leven willen gaan roepen. Hadden ze dan niet beter wat voorzichtiger ermee omgesprongen zodat deze stap gewoon overbodig zou zijn??

Dit lijkt wel heel erg op jezelf van werk voorzien op de kosten van een ander.

Als ze bij de ICANN nu nog niet geloven dat Verisign niet het meest betrouwbare bedrijf is om dit soort dingen in handen te geven zal dit besef er waarschijnlijk nooit komen!

Edit: Ik zie het niet als ik op T.net ben, is dit nu een onbetrouwbare website???
Helaas leggen veel bedrijven hun vertouwen in verisign, omdat ze die blindelings kunnen betalen. Maar naar mijn idee is dat achter de feiten aanlopen en kan ik misschien beter hoogst persoonslijk digitale certificaten uitgeven, net als Verisign. Misschien ben ik meer te vertrouwen ... ik weet het niet.
Ik zou iig de 'minimal requirements' uit proberen te voeren van de EUGridPMA. Dat betekent op zijn minst dat je fysiek langs moet komen bij een contact punt van de CA om je fysiek te legitimeren (ja ... ook in de wetenschappelijke hoek waar dit dus voor is). Dat is al meer dan bij Verisign.
Want voor de eenvoudigere certificaten hoef je alleen maar online te betalen, zonder al te veel fysiek contact, dus met handigheid te faken.
Daarbij ... als jij alle subCA's van Verisign geinstalleerd hebt in je browser, hoe kan jij dan zien als leek welke nou betere certificaten uitgeeft dan anderen? Dat weet echt niemand. Je browser doet alleen zijn checks en waarschuwt je bij verdachte zaken. Als die niet voorkomen, kan jan-met-de-korte-achternaam de geldigheidstest door staan in je browser en spontaan ben je niet meer gealarmeerd. Helaas geen paranoia dit keer, maar werkelijkheid...
Tsja, Opera geeft netjes aan met 1 tot 3 hoe zwaar de beveiliging is.
Het gaat echter niet zozeer om de beveiliging, maar om de 'echtheid' van de website.

Als je naar www . p0stbank . nl gestuurd wordt, kan die best een valide SSL certificaat hebben, en dan betekent dat slot-icoontje meteen niets meer.
normaal zou er dan bij moeten staan: this certificate is issued by a compagny that is NOT trusted

*sorry voor slecht Engels.

Een deel ligt dus ook bij het bedrijf wat de certificaten uitrijkt.

Je moet ook maar eens leren lezen voor je klikt (nu gooi ik wel mijn eigen ruiten in :P )
Verisign zal je bedrijf controleren en bekijken of je echt wel bij de postbank werkt.
Maar ... je kan bij Verisign voor genoeg geld gewoon ook een eenvoudig certificaat kopen met de naam die jij er in wilt hebben. Dit zal nog wel gaan veranderen op den duur... maar dat zal nog wel eens duren.

Het probleem bij dit concept is dat ik VeriSign, Thawte en anderen niet goed genoeg ken... ik heb geen idee wie en wat ze nu wel en niet tekenen.

Ik had liever gewild dat de banken zelf een CA opzetten en beheren waar ik vertrouwen in zou kunnen hebben en waar niets en niemand anders wat mee zou kunnen tekenen.
Dan kan je de hele keten tenminste controleren, zonder dat ik de subCA van thawte toevallig nog niet in mijn vertrouwde lijst had geinstalleerd.

Ik de-installeer graag al die vage standaard CAs eerst liever, dan kan ik weinig verrassingen krijgen.

Quote of the Day:
Security is for the Paranoid, Trust is for the Naive
Opera geeft die info in een pop-up als het niet vertroud is of als de uitgever niet op de lijst voorkomt.
Maar ik dacht dat Opera daar ook aardig mee vooruit loopt.
En daar ligt het probleem ook weer - de meldingen voor een vertrouwde en niet vertrouwde berichten lijken teveel op elkaar.
Welnee bij in vertrouwd bedrijf of uitgever krijg je niet zo'n scherm, alleen als er iets mis is. zoals dus een niet vertroude uitgever of een verlopen datum.
Of een certificaat met een andere URL dan de URL waarop hij gebruikt wordt. Zowel Opera als Firefox waarschuwen me daar nog elke keer voor:
- The server's name "www.domain.com" does not match the certificate's name "www.otherdomain.com". Somebody may be trying to eavesdrop on you.
- You are connected to a site pretending to be www.otherdomain.com, possibly to obtain your confidential information.
Zo'n soortgelijke melding krijg ik zelfs als ik naar de webmail van mijn werk ga, omdat webmail en www niet overeenkomen.

Edit: was een reactie op ytsmabeer.
"This certificate is issued by somebody we don't know. In order to proceed we need you to click OK to accept the certificate. Else you can't do your work"

*click*...
Misschien gaat je reactie niet over Opera, maar toch: Opera meldt het expliciet wanneer beveiliging zwak is (Hotmail bijvoorbeeld, en mijn bank :(). En bovenaan in de adresbalk wordt altijd het beveiligingsniveau weergegeven als ik het goed heb.
Visionmaster >

Je hebt grotendeels gelijk. Maar dat je geen controle hebt over de keysigning praktijken van Thawte en Verisign is juist het probleem. Waarom zou een bank daar beter in zijn? En welke lijst van "trusted" CA's zou jij wel willen laden? Dit is het probleem van "key management".

Het zal, imho, een onafhankelijke stichting moeten worden die het vertrouwen geniet van de meeste gebruikers. De bestaande certificaten moeten openbaar gemaakt worden (zodat er controle kan plaatsvinden) en tegen kostprijs aangeboden worden (zoals domeinnamen nu).
Alternatieve certs zoals http://www.cacert.org vertouw ik meer dan VeriSign vanwegen het concept wat achter CACert zit. VeriSign is een bedrijf dat zo veel mogelijk winst probeert te maken, CACert niet.
@Thuissendy:
het is inderdaad key management. De bank hoeft niet beter te zijn, als deze maar via een gecontroleerde en zoveilig mogelijke manier maar het publieke certificate van hun CA stuurt. Vervolgens kan de bank certificaten uitgeven aan hun servers (alle servers die publiekelijk te bereiken zijn), zodat je vanaf huis met de geinstalleerde CA van de bank alle door deze bank getekende server certificaten kan controleren als klant. (Even rekening houden met problemen die kunnen ontstaan met aliasing in DNS en zo... en nog een paar dingen). Verder zal de bank ook aan CRL updates moeten doen, die de klanten via de browser ook standaard moeten laten activeren of gelijk OCSP gebruiken mis de bank een Internet verbinding heeft die een beetje stabiel is.
Dan hebben ze mijn vertrouwen al meer gewonnen dan nu. Tegelijkertijd zou je als klant een certificate moeten krijgen en die in je browser stoppen. Dat kan je nu al eenvoudig, maar al is het soms aan de server kant (bijv. met Tomcat) lastig om mutual authentication aan te wakkeren, omdat je de SSL afhandeling van Apache de deur uit kan sturen voor iets dat dat wel volledig afhandeld op een handigere manier.
Maar misschien is het voor de thuisgebruiker handiger om met hardware tokens te werken. Mooie USB rekenmachinetjes die bijv. er voor zou kunnen zorgen dat je private key nooit die USB stick verlaat, maar dat je wel alles kan doen wat je wilt cryptografisch gezien. voor meer vragen zie mijn mail als je meer wilt weten ... (8>

ik doe zelf 'iets' met Grid Computing en Security met de hoofdletter 'S' van Sinterklaas. }:O

Wat betreft je tweede punt, zo'n organisatie bestaat nu net een paar maanden. Dat is de International Grid Trust Federation (IGTF. Mijn collega is de stoel :+ (the chair) en is gericht op de wetenschappelijke omgeving over de wereld en bestaat uit 3 PMA, de EUGridPMA (European Policy Management Authority), de TAGPMA (The Americas Grid PMA) en de APG PMA (Asian Pacific Grid PMA).
De organisatie zijn een groepen van CAs. Iedere CA representeerd de wetenschappelijk omgeving in 1 lang. Zoiets heb je ook in de commerciele hoek nodig (al hoewel de Zwitserse CA (SWITCH CA) een commerciele is).
Meer info via mail (on request). :z

<pas op! wijsneusmode>
ps: zelf praat ik liever of X.509 certificaten, want SSL vervoert de certificaten en zullen aan de andere kant van de lijn in een SSL_context als chain te voorschijn komen in het X.509 format per certificaat, of als het een chain betreft, in een STACK_OF(X509 *). En daarbij is het volgens de RFC is het toch echt een X.509 certificaat.
</pas op! wijsneusmode>

Quote of the day (tis al weer dinsdag nu...)::
Hoe meer je weet, hoe meer je er achter komt dat je nog niets weet.

Ergo. ik ben nog de n00b in de groep.
Misschien gaat je reactie niet over Opera, maar toch: Opera meldt het expliciet wanneer beveiliging zwak is (Hotmail bijvoorbeeld, en mijn bank ). En bovenaan in de adresbalk wordt altijd het beveiligingsniveau weergegeven als ik het goed heb.
En toch is echt je grootste zorg niet of die beveiliging nu sterk (128+ bits) of zwak (64 of minder bits) is. Die 64bits encryptie ga jij met je thuis computertje of kleine serverfarm net zo min kraken dan die 128+ bits encryptie.

Het belangrijkste is dat de website wordt gecontroleerd op echtheid. Als jij bijvoorbeeld naar www.postbank.rekening.nl gaat dan kan die site best een 256bits encryptie hebben en een geldig, niet verlopen, certificaat. Maar ik zit dan wel gezellig op het domein rekening.nl en niet op iets wat met de postbank te maken heeft. Dat is vele malen belangrijker dan de sterkte van de encryptie, zwakste schakel enzo :)

Ik zie dit probleem nog niet zo snel opgelost worden trouwens. Je kunt de uitgifte van certificaten nou eenmaal niet zó moeilijk maken. Immers, als ik als klein internet bedrijf geen certificaat kan krijgen omdat met niet kan vaststellen of ik wel/niet betrouwbaar ben schiet de certificering zijn doel voorbij.

Daarbij komt ook nog eens dat de huidige bedrijven die SSL certificaten uitgeven allemaal commercieel zijn. Dit soort zaken zie ik liever in handen van een instantie zonder winst oogmerk. Op de een of andere manier gaan geld en betrouwaarheid in mijn ogen niet zo goed samen...
wat heeft dat er nou weer mee te maken ?
omdat hun meer winst maken en daarop meer focussen ( wat eigenlijk elk bedrijf wel wil en de meeste ook doen anders begin je geen bedrijf lijkt me. ) dan is hun website maar minder vertrouwelijk ?
Dit heb ik helaas aan den lijve mogen ondervinden.

Om een certificaat bij VeriSign aan te vragen dien je je te legitimeren, en daarbij een bewijs dat jij werkzaam bent voor het bedrijf waarvoor je een certificaat wilt aanvragen.

Ik heb daarop een kopie van het legitimatiebewijs van mijn baas samen met een uittrreksel van de KvK van het bedrijf gefaxt, waarop mijn baas staat vermeld als eigenaar.
Het verzoek werd echter afgewezen omdat de bedrijfsnaam bij wijze van spreke "Bedrijf Internet B.V." terwijl het domeinnaam waarvoor ik het certificaat aanvroeg was geregistreerd door "Bedrijf Internet".

Heeft een maand geduurd tot we de domeinnaam op de correcte naam hadden overgeschreven en het certificaat in huis hadden. Dat "onderzoek" zit bij Verisign dus wel goed, als je het mij vraagt.

We hebben toen een tijdelijk certificaat gekocht via ik mene instant-ssl.com waarbij het sturen van een e-mailtje vanaf postmaster@hetdomein.tld voldoende was |:(
wat heeft dat er nou weer mee te maken ?
omdat hun meer winst maken en daarop meer focussen ( wat eigenlijk elk bedrijf wel wil en de meeste ook doen anders begin je geen bedrijf lijkt me. ) dan is hun website maar minder vertrouwelijk ?
Inderdaad ja. Lijkt me een logische conclusie eigenlijk?
Een bedrijf dat certificaten uitgeeft om hier winst mee te maken zal minder naar de betrouwbaarheid van een bepaald bedrijf kijken en meer naar de $/¤ die het bedrijf bereid is te betalen.

Voor de duidelijkheid: ik heb het hier dus niet over de bedrijven die de certificaten gebruiken maar juist over de bedrijven/instanties die deze certificaten uitgeven!

De hele wereld kan wel vrolijk proberen om de "vrije economie" te bevorderen, voor sommige dingen heb je gewoon een onafhankelijke instelling nodig. Een instelling/organisatie met een winstoogmerk is per definitie niet onafhankelijk. Vandaar dus mijn conclusie dat een non-profit organisatie de beste keus is voor het uitgeven van certificaten. (En dan ga ik er even vanuit dat hierin verschillende landen evenredig zijn vertegenwoordigd...)
Je moet je wel bedenken dat als VeriSign er ECHT met de pet naar gooit, dat gelijk kunnen stoppen met de CA spelen.

Wat niet weg neemt dat ik ze niet direct vertrouw. :+
Dat werkt nou juist andersom: juist een bedrijf dat geld kan verliezen als ze onbetrouwbare certificaten uitgeven zal donders goed opletten anders lopen al je klanten weg. Een overheidsinstantie die een monopolie op de uitgifte heeft kan blunderen wat ze wil, het kan toch geen klanten verliezen.
Zo slecht is je engels niet: alleen company, dus zonder g!
Ik zie eerlijk gezegd niet wat er nu zo 'mis' is met de huidige SSL certificaten. De CA's zijn toch bedoeld om te verifiëren dat berichten tussen A en B uitgewisseld worden ook daadwerkelijk van A en B af komen en niet van een partij C die zich als B wil voordoen? En dat doet SSL tot dusver uitstekend.

Het probleem is echter dat host A erg op host C kan lijken, maar niet de zelfde partij zijn. Dit valt buiten de grenzen van SSL die enkel een veilige verbinding waarborgt.

In princiepe gaat het dus niet zozeer om een alternatief, maar om een toevoeging. Een aanvullend nieuw certificeringssysteem dus, om daadwerkelijk te waarborgen dat je (vóór het communiceren) de partij voor je hebt die je voor je denkt te hebben. Dit in combinatie met SSL zorgt voor een veilige verbinding én met werkelijk diegene waarmee je die verbinding wilt hebben.
yo dude, SSL-certificaten is een verwarrende term misschien. Je haalt een paar dingen door elkaar :+

De CAs zijn er voor bedoeld om bij partij B te garanderen dat de identiteit die partij A verkondigd, gegarandeerd is door de CA, die jij vertrouwde (het heet ook een "Trusted 3rd Party").

Dus het is voornamelijk identieitsvast stelling. Dat gebeurt boven op een SSL lijn. Deze lijn is beveiligd met een session key. Deze sleutel wordt gegenereert op het moment dat je een SSL verbinding opzet, dus vlak voor de handshake, want in de handshake gebruik je dat.
Over deze beveiligde verbinding smijt je nu een certificaat of een hele keten, min het CA certificaat, wat in de normale wereld alsnog maar 1 certificaat betekent...) en dan doe je de identiteitscontrole. Tevens wordt ook vaak gekeken (als het een host certificaat betreft) of de DNS naam die in het certificaat geschreven staat overeen komt met de SSL link informatie (met een reverse lookup, wat nog wel eens een probleem _kan_ geven). Ook natuurlijk de CRL en/of OCSP checks niet vergeten! En je heb een gegarandeerde ID in je handen. Nu moet je eigenlijk nog je software zo programmeren dat je op basis van je ID je nu kan weigeren of toelaten.

Met OpenSSL kan je zelf ook een keypair maken. Deze kan je eenvoudig genereren en zelf gebruiken en verspreiden. Wellicht wil je een SMIME mailtje bakken, dan moet je toch echt de public key aan de andere kant hebben gekregen.
Ik vind het alleen bullshit dat je bij de ene toko voor een paar tientjes een SSL certificaat hebt en dat je bij Verisign 800 pond voor een (2 jaar) SSL certificaat betaald.
Dat is helemaal geen bullshit.

Organisaties als Verisign en Comodo controleren een identiteit en verstrekken garanties over deze identiteit aan bezoekers alvorens ze een certificaat verstrekken.

Met name voor klanten van webstores met grotere transacties betekent deze verzekering een garantie dat de transactie(s) met de betreffende webstore te vertrouwen zijn.
Ja, maar ik vertrouwde Verisign en Comodo niet, wat nu? (8>
Daarbij is mijn Nederlandse paspoort geen 800 euro waard! Mijn identiteit is digitaal blijkbaar meer waard, dan fysiek aan het loket van mijn vliegtuigmaatschappij.
Ik had liever gewild dat SurfNet of de Nederlandse staat de CA kan spelen. Dan weet ik redelijk zeker dat mijn identiteit redelijk vast gesteld kan worden door die mensen, dus kan ik er op vertrouwen dat mijn buurman echt misschien wel mijn buurman zou kunnen zijn als ik zijn auto online overkoop.
phishing is een groot probleem, en natuurlijk zullen duidelijke rode (kruis) en groene (goed tekens) goed zijn, maar pak het probleem ook bij de bron aan. 90% van de gevallen gebeurd via HTML e-mails...

Per direct HTML mail uitschakelen, eruit slopen, etc.

Maar het wordt idd ook tijd voor een nieuw type certificaat, wat en hoe daar moeten ze nog maar even over babbelen.
je argumentatie van de HTML mail is gelijk bij auto ongelukken.

10% van de auto ongelukken gebeurd door mensen die gedronken hebben, dan zeg ik laten we snel die nuchterre personen van de weg halen, scheelt al mooi 90% van de ongelukken.....
easydisk heeft natuurlijk een valide argument dat het versturen van klikbare links door een dienstenleverancier niet bevordelijk is bij het bestrijden van "phishing". Als links meesturen nou eens nooit gedaan zou worden door bijvoorbeeld banken, kan elke email met een klikbare link direct als phishing worden aangemerkt.
De dienstenleveranciers zijn mede schuldig als ze hun klanten niet helpen om effectief dit soort misbruik te bestrijden. Het zou helpen als de wetgever het risico van dit type aanvallen bij de dienstenleverancier legt.
Ja handig.. En dan stuur ik een link naar m'n collega, ben ik meteen spam,...
Er was zoiets als DNS-spoofing en man-in-the-middle attacks. PuTTY e.d. geven netjes aan dat de server key is gewijzigd, is dat ook zo bij webbrowsers?
Misschien is bij dat nieuwe protocol de server key gekoppeld aan de sitenaam zodat een applicatie dat niet zelf bij hoeft te houden.
Dat een nieuw protocol beter zou zijn teger phishing is volgens mij een beetje onzin. (Het probleem ligt bij de gebruikers die niet goed opletten).
't Is vast ook een beetje geldklopperij :)
De server key is nu al gekoppeld aan de sitenaam, sitenamen zijn onveilig om de reden die je zelf al aangeeft(DNS spoofing), in een key staat geen HW adres of IP nr vermeld, en de tijd dat "geldklopperij" en browsers samengaan duurt nog even.

Ik hoop trouwens wel dat dit nieuwe alternatief ook een s redelijk betaalbaar word. Wel een uitdaging natuurlijk, betrouwbaar en goedkoop, maar als je een webmail,www certificaat wilt, en het "zoals wij" wel leuk had gevonden(maar voor de doelgroep niet noodzakelijk) om certificaten uit te delen aan klanten, dan ben je een kapitaal kwijt.
Je hebt gelijk. Zo'n middleman attack werkt alleen bij non-secure protocollen zoals SSH v1 waarbij je de keys kunt achterhalen tijdens het handjes schudden.
Hmm.. als er maximaal maar 1 certificaat per (domein)naampje zou worden uitgegeven dan zou het veel makkelijker zijn.
Hmm.. als er maximaal maar 1 certificaat per (domein)naampje zou worden uitgegeven dan zou het veel makkelijker zijn.
Dat gebeurt ook wel in de regel, maar kan niet echt op gerekend worden helaas. Tussen de CAs is er weinig communicatie over zulke zaken. Dus je kan makkelijk 2 verschillende certificaten hebben gekocht of gemaakt voor 1 domeinnaam.
Het lastige is als je 1 server hebt en meerdere domeinen ondersteunt :)
Uhm ... HW adres is niet zo interessant, als mijn NIC er uit vliegt heb ik een nieuw certificaat nodig ... das onzin dus.
Het IP nr is niet vermeld ... ah ... maar toch wel!
Je hebt doorgaans een SSL verbinding en in de SSL context is het IP adres van de host opgenomen aan beide kanten. Als je een host certificaat hebt (tikkie anders dan voor humans) dan wordt er een reverse lookup gedaan van het IP adres en daar moet de DNS entry in voorkomen die op het certificaat staat.
Je moet je vertrouwen ECHT richten op de CA, niet voor niets zijn zij de 'Trusted 3rd Party'. Deze heb je vertrouwd toen je IE, Firefox, Konquerer, Opera, whatever hebt gebruikt met CA certificaten pre-installed van partijen ik soms echt niet ken. Deze dudes (deze CAs) tekenen dat certificaat. Als je een gold of platinum certifcaat tegenkomt van Verisign, dan is er genoeg geld neergelegd om een mannetje langs te laten komen om de identieit van de klant vast te stellen. De rest vind ik persoonlijk crap.
Even om mijn persoonlijk stokpaardje maar toch weer te berijden..

Certificaten tonen aan dat de partij waarmee je een verbinding op wilt zetten ook daadwerkelijk de partij is die in het certificaat vermeld staat.

De grootste truc echter (een waarvan heel veel phishing sites dankbaar gebruik van maken) is dat bijna niemand aandacht besteed aan de INHOUD van het certificaat.. ja, ik lees mijn certificaten door voor ik ze accepteer.
Maar het 'doorklikken bij rare meldingen'-syndroom is helaas nog niet uitgestorven..

Wat ik verwacht is dat deze onderneming een resultaat oplevert dat het makkelijk maakt voor een gebruiker om de echtheid van de andere partij te verifieren. Of, ik moet het anders zeggen, dat hoop ik althans..
Ik lees ook altijd de inhoud en ik lees iedere regel van het certificaat. Liefst haal ik zelf nog even door OpenSSL heen om te kijken dat het niet perongeluk al is ingetrokken door de CA.
Na het typen van velen replies in deze thread is mijn conclusie dat de browsers ook een beetje een rol spelen in het onderwerp van dit nieuwsbericht door de eenvoudige gebruiker een tricky keuze te geven om het onbetrouwbare certificaat toch te accepteren.

Dit had een "default deny" moeten zijn. Als iedereen zeurt bij zijn bank dat de website niet te vertrouwen is, dan zullen ze dit wel moeten corrigeren, anders verkopen ze niet via de site.
Dat is het veiligste. Dan maar die gare Verisign en andere CAs in mijn browser (liever door zelf te installeren volgens de instructies van de bank!) maar goed... maar dat jan-en-alle-man tenminste een rood knipperend scherm te geven als ze naar een niet-te-vertrouwen website surfen.
Is het niet gewoon beter om vanaf nu enkel nog maar certificaten te gaan verstrekken aan gecontroleerde instanties, zoals ooit bedoeld. Dan duurt het ook een jaar, maar hoeft het systeem niet opnieuw uitgevonden te worden. Scheeld met een hele hoop gedoe lijkt me zo, aangezien die andere vorm van certificering ook wel meer dan een jaar in beslag zal gaan nemen.
SSL Certificaten zijn ook wel rete goedkoop geworden, je kan nu bij godaddy.com ( niet een kleine register ) voor 29.99$ per jaar al een SSL Certificate krijgen en ik gebruik deze ook voor mijn OWA en ik moet zeggen dat dit perfect werkt!

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True