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 , , 76 reacties

Er blijken ruim 37.000 ssl-certificaten in omloop te zijn, die een gevaar kunnen vormen voor internetgebruikers. Het gaat om certificaten die gelden voor een locatie die niet uniek is, waardoor ze kunnen worden misbruikt voor hackaanvallen.

De Amerikaanse digitale-burgerrechtenbeweging Electronic Frontier Foundation onderzocht hoeveel ssl-certificaten zijn verstrekt voor niet-unieke domeinen. Een uniek domein mag op het internet maar één keer voorkomen, terwijl een niet-uniek domein vaak wordt gebruikt voor intern netwerkverkeer. Zo kunnen verschillende netwerken een lokale host met de naam 'mail' hebben, terwijl het domein 'tweakers.net' op het internet maar één keer mag worden gebruikt.

Volgens de EFF hebben certificaatautoriteiten vele duizenden keren certificaten verstrekt voor niet-unieke domeinen. Een certificaat voor het domein 'exchange' is 806 keer verstrekt, terwijl voor gerelateerde domeinen als 'exchange01' of 'exch' nog duizenden andere certificaten zijn uitgegeven. Exchange is een veelgebruikte zakelijke mailserver van Microsoft. Als verschillende partijen een ssl-certificaat voor hetzelfde domein hebben bemachtigd, is het certificaat nutteloos geworden.

Bovendien veroorzaakt dit een groter risico op man in the middle-aanvallen, waarbij een aanvaller inbreekt in de communicatie tussen een gebruiker en een server. Een aanvaller kan bijvoorbeeld een interne dns-server hacken en het verkeer dat voor de host 'exchange' is bestemd naar een externe host laten doorsturen. Met een ssl-certificaat kan hij gebruikers een beveiligde verbinding met de server laten opbouwen, zodat zij niet doorhebben dat ze met een andere server te maken hebben.

Opvallend is dat sommige certificaatautoriteiten, die zijn belast met het uitgeven van de ssl-certificaten, verschillende klanten een ssl-certificaat voor hetzelfde domein gaven. Volgens de EFF duidt dat erop dat de ca's niet controleren of certificaten wel geldig zijn. Al even opmerkelijk is dat er circa vijfduizend certificaten zijn uitgegeven voor het domein 'localhost', dat altijd verwijst naar het eigen systeem, waardoor de certificaten van weinig nut zijn.

Ook ontdekte de EFF dat er certificaten in omloop zijn voor domeinen met niet-bestaande extensies, zoals '.farm', '.tech' en '.virtual'. Op dit moment zijn die certificaten weliswaar weinig bruikbaar, omdat de bijbehorende domeinnamen niet werken, maar de Icann werkt aan de mogelijkheid voor organisaties om zelf top-level-domeinen te registreren. Een bedrijf zou daardoor het '.tech'-domein kunnen claimen, terwijl daarvoor al ssl-certificaten zijn uitgegeven.

Moderatie-faq Wijzig weergave

Reacties (76)

De titel is wat aan de zware kant..
Al deze certificaten zijn voor intern gebruik dus.

Het is gewoon makkelijk dat je geen "servernaam.domein.local" hoeft in te typen in de browser, maar gewoon "exchange" of "mail". Maar aangezien 100 anderen dus ook een certificaat voor "mail" aan kunnen vragen maakt het dus gevaarlijk. Daar leunen deze bedrijven dus heel zwaar om de beveiliging van de rest van het netwerk.

Hoe dan ook: Dit heeft geen dreiging voor verkeer dat van buitenaf komt, want via het Internet resolved "mail" niet. Daar heb je toch echt een FQDN voor nodig. (Even de hosts file truc buiten beschouwing gelaten) En dan falen die certificaten wel, want je hebt dan een certificaat nodig die geregistreerd is op een valide domein.
ik begrijp niet goed waarom deze bedrijven geld betalen voor certificaten voor intern gebruik? Je kan hiervoor evengoed zelf je certicaten gaan signen.
Er zitten zeker voordelen aan het gebruik van commerciele certificaten voor intern gebruik. Als ik een commercieel certificaat heb, dan komt mijn browser niet met een melding "There is a problem with this website's security certificate". Bij self-signed certificaten krijg je deze melding wel. Om deze melding te voorkomen, moet je specifiek je self-signed CA toevoegen aan de lijst voor trusted certificaten. En dat voor iedere browser. Veel mensen, inclusief mijzelf, willen dit gedoe allemaal niet en kiezen voor een commercieel certificaat wat automatisch al getrust wordt door je browser.
Dat is dus schijnveiligheid. Je denkt dat het veilig is omdat het balkje groen wordt.
Ik neem het je niet kwalijk, vrijwel de hele wereld doet het zo, maar het slaat eigenlijk nergens op.
Voor een systeembeheerder zou het geen enkel probleem moeten zijn om het juiste certificaat op alle pc's in te stellen, dat is een kwestie van een file op de juiste plek zetten.

Als je veiligheid belangrijk vindt dan moet je juist niet vertrouwen op de certificaten die bij je OS/browser zitten. Kijk maar eens in die lijst, daar zitten een stel behoorlijk onbetrouwbare partners. Zo'n beetje iedere regering wordt blind vertrouwt, ook die van 'schurken'staten. Ook zijn er verschillende geheime diensten die hun certificaten laten meeleveren.

Het klinkt misschien paranoide, maar de juiste aanpak is _alle_ certificaten uitschakelen en alleen die weer inschakelen die je ook echt nodig hebt. En als je toch bezig met kun je ook je eigen CA opnemen, probleem opgelost.
Jouw zogenaamde juist aanpak is totaal zinloos. Je hebt juist certificaten voor zaken die je niet zelf kunt checken. En dus moet je logischerwijze op een andere instantie vertrouwen. Als je het zelf kon checken, dan is het nutteloos er nog een certificaat voor te nemen.
Je haalt twee dingen door elkaar.
Je kan inderdaad niet iedereen controleren. Daarom kies je een klein aantal betrouwbare partners die dat voor jouw doen, zogenaamde Trusted Third Parties.

Dan moet je wel op die partners kunnen vertrouwen. Standaard vertrouwt jouw PC een paar honderd van die partners. Geen idee waarom ik de regering van Saudie Arabie zou moeten vetrouwen, maar iemand heeft besloten om ook dat certificaat standaard mee te leveren.
Als particulier houdt het op. Normale mensen kunnen niks met deze informatie.

Als bedrijf zou je wel moeten nadenken over welke Trusted Third Parties je nu echt vertrouwt. Op mijn werk zijn dat er minder dan 10.
Een normale server heeft er ook echt niet meer nodig.
Op de desktop heb je er meer nodig, maar de meer dan 100 die nu standaard zijn is sowieso te veel.

[Reactie gewijzigd door CAPSLOCK2000 op 7 april 2011 17:29]

Natuurlijk kan je dat..

Dat houdt echter wel in dat je kennis en verstand moet hebben van het opzetten en onderhouden van een CA Infrastructuur. En veel bedrijven hebben dat niet.
Ik zelf zou ook nooit betalen voor interne certificaten :)

[Reactie gewijzigd door Equator op 7 april 2011 15:46]

Omdat ze niet beter weten. De meeste mensen snappen helemaal niks van SSL.
Ze weten net genoeg om te beseffen dat als je een certificaat van een commerciele toko neemt het "gewoon" out-of-the-box werkt.
Als je smartphones of andere devices die geen automatische uitrol van root certificaten ondersteunen gebruikt moet je daar dan ook je eigen root cert op installeren, en zelfs als het er maar 2 zijn is het meestal al plezieriger en minder werk om die paar euro aan een "echt" certificaat uit te geven.

[Reactie gewijzigd door Gert op 7 april 2011 15:58]

Voor "mail" maak je gewoon een CNAME record aan zoals het hoord :z
Deze verwijst dan netjes door naar "servernaam.domein.local". Als je een Exchange systeem configureerd volgens het boekje dan maak je altijd FQDN certificaten aan. Alles daarbuiten is naar mijn mening "hobbywerk".... CNAME's is niets mis mee maar een DNS server vol A record waar niemand meer iets van snapt is een indicatie van wanbeheer....
Een CNAME record mail vereist nog een domein en een tld.

Pingen naar MAIL doet niets als je PC niet weet welk domein je bedoeld. Dat kan via de default search providers list of een hostfile entry.
Een CNAME record mail vereist nog een domein en een tld.

Pingen naar MAIL doet niets als je PC niet weet welk domein je bedoeld.
Het gaat hier om interne certificaten, binnen een netwerk dus.
De clients zullen echt wel weten welke domain suffix ze er achter moet plakken, gewoon hun eigen suffix.
Per toeval zojuist ook een informatieve post tegen gekomen over het zelfde onderwerp, wel interessant, zie: https://blog.startcom.org/?p=221
Dit zal wel leiden tot een mate van aansprakelijkheid voor deze certificaat-autoriteiten bij schade door een dergelijk onjuist verleend certificaat. De kosten hiervan kunnen zo hoog oplopen dat dergelijke autoriteiten failliet gaan, waarna de overige certificaten door die autoriteit verschaft ook waardeloos worden.
Dat kan alleen als er certificaten worden uitgedeeld aan personen die geen eigenaar zijn van het gebruikte domein.
Ik kan (als het goed is tenminste) geen certificaat aanvragen voor tweakers.net, simpelweg omdat ik geen toegang heb tot de mailbox postmaster/admin @tweakers.net. Of omdat ik niet genoemd sta als technical contact voor het domein tweakers.net.

Dit is onlangs dus nog wel gebeurd, maar dat komt omdat er bij Comodo het e.e.a. gehackt was. Jaren geleden zijn er ook niet valide certificaten uitgegeven voor de naam "Microsoft Corporation". Die zijn vrij snel weer ingetrokken, en de persoon die de goedkeuring had verleend op staande voet ontslagen. Deze certificaten staan tot op de dag van vandaag nog altijd in de Not trusted Certificate store van je Windows PC.
Ik snap het niet: Het enige waartegen een ssl certificaat beschermd is een Man in the middle attack. Dus blijkbaar worden er ook certificaten uitgegeven waar geen bescherming is tegen man in the middle. Waarvoor zijn deze certificaten dan? zodat er een slotje zichtbaar is?

merk op dat een certificaaat alleen bevestigd dat hij aan een domein is uitgegeven. Niets meer. (b.v. Als myrabobank-online.nl vrij is kan ik daar waarschijnlijk gewoon een certificaat voor krijgen.)
Het certificaat moet je zien als je paspoort. Hét gegeven waarmee jij kan aantonen dat jij Dhr. Leuk_he bent.
Het slotje betekend dat je via een 'veilige' verbinding met een server bent verbonden die door middel van het certificaat aantoont dat hij inderdaad die server is.
Verder beschermt deze veilige verbinding je ook tegen een Man In the middle attack. Omdat jij zeker weet dat je met de juiste server verbonden bent, zal er dus geen 3e partij tussen zitten.

Dit is natuurlijk gebaseerd op het vertrouwen in de uitgevende CA.

Voor wat betreft: myrabobank-online.nl: Het domein zal niet zo'n probleem zijn, maar aan goede CA (lees: een Uitgever van Certificaten die goede controle doet) zal daar geen certificaat voor toekennen.
Er is ook een gratis slotje van comodo.
http://www.comodo.com/e-c...ree-ssl-cert.php?entryURL=

Het laat een slotje zien, en het is echt geen paspoort. het enige wat het bewijst is dat degene die de signature heeft, ook controle heeft over het domein en de server op het domain.

Een paspoort geeft aan dat ik te vinden ben, maar als de whois informatie op het domein niet klopt ben je met een certificate nog steeds niet te vinden. De CA zegt ook niet meer dan dat he? het zet dat het certificaat is uitgegeven aan de site. Bij duurdere certificaten geeft het ook aan aan welk bedrijf het is uitgegeven, maar geeft daarover niet eens garanties met geld.

(Ik vermoed dat een of ander MS product heel graag een geldig certificaat heeft voordat het met een interne server connect. vandaar deze optie to niet unike certificaten)

Besef verder dat de server waarmee jij connect gehackt kan zijn. niemand heeft ooit beweerd dat daar een slotje voor uitgegeven is.
Het laat een slotje zien, en het is echt geen paspoort. het enige wat het bewijst is dat degene die de signature heeft, ook controle heeft over het domein en de server op het domain.
Een van de kerntaken van een SSL certificaat (naast key encypherment) is Server-Authentication. Met andere woorden, een stukje zekerheid dat de server waarmee je verbonden bent kan aantonen dat hij de server is waarmee jou browser is verbonden.
Als je deze 'paspoorten' zomaar kan krijgen, dan is de veiligheid daarmee verloren gegaan.
Een paspoort geeft aan dat ik te vinden ben, maar als de whois informatie op het domein niet klopt ben je met een certificate nog steeds niet te vinden. De CA zegt ook niet meer dan dat he? het zet dat het certificaat is uitgegeven aan de site. Bij duurdere certificaten geeft het ook aan aan welk bedrijf het is uitgegeven, maar geeft daarover niet eens garanties met geld.
Ik durf niet te gokken wat je nu precies bedoeld.. 'Te vinden zijn' heeft afaik niets met de certificaten van doen. Als je het hebt over de administrative/technical contact info van een domein (whois info) als controle over de aanvrager van het certificaat, dan kan ik je deels volgen. Het bied nog steeds een stukje schijnveiligheid.

De duurdere Extended Validation certificaten krijgen een veel dieper onderzoek naar de authenticiteit van de aanvrager.
(Ik vermoed dat een of ander MS product heel graag een geldig certificaat heeft voordat het met een interne server connect. vandaar deze optie to niet unike certificaten)
Ja, MS Exchange, MS OCS, etc..
Besef verder dat de server waarmee jij connect gehackt kan zijn. niemand heeft ooit beweerd dat daar een slotje voor uitgegeven is.
Dat klopt, daar is het inderdaad niet voor bedoeld :)

Er van uit gaande dat je reactie op mij was bedoeld:
Ik ben het ermee eens dat er betere regulering zou moeten zijn voor het uitgeven van dergelijke certificaten, maar we kunnen ons beter focussen op een nieuwe verbeterde beveiligingstechniek, want SSL is nu eenmaal vatbaar voor hacks. Of dat nu procedurele of technische zaken zijn, het is en blijft niet geheel veilig.
Maar waarom je dan zoveel moet betalen voor je passpoort is mij dan ook onduidelijk.
Als je wéét dat er meerdere mansen rondlopen met een paspoort voor de naam "John Doe" is de fun er ook vanaf.

Zijn die ssl-certificaten zijn niet gewoon een geldkoe?
Opnieuw een geval waarbij de eindgebruiker een vals gevoel van veiligheid krijgt.
Nou lijkt me het risico van een certificaat met SN='Exchange' te overzien, omdat je dat normaliter niet kan resolven tot iets buiten het intranet. Je moet dan al via een vreemde DNS server resolven of via een malicous proxy verbinden wil je op zo'n server kunnen uitkomen.
Zoals het bericht aangeeft resolved "exchange" alleen intern en moet de interne DNS server gehacked worden. Ik zie niet hoe een certificaat dan een probleem is gezien je veel grotere problemen hebt op dat moment. Daarna kan doorverwezen worden naar een andere server met een vals certificaat? En dan? Alle clients zullen foutmeldingen gaan geven en alle mail zal weg zijn. Niet echt low profile hacking.

Je kunt beter met je gehackte DNS gaan rommelen en bekende websites doorverwijzen naar sites met mallware.

Inderdaad is het risico zeer klein lijkt me. Ze moeten echter admins die hun server systeem Exchange/01/Exch noemen ontslaan :+

@capslock2000
Dit artikel duidt juist aan dat het mogelijk is om de DNS server te hacken en een valse emailserver op te zetten die geen melding geeft dat het certificaat niet klopt.

Het is tevens ook van deze tijd om te kijken naar DNSSEC:
http://en.wikipedia.org/w...ystem_Security_Extensions
Je DNS resolves worden dan digitaal onder tekent door een (jaja) certificaat.
Nu maar hopen dat die lullo's van de certificaatautoriteiten geen certificaten uit gaan geven voor "NS01", "NS" of "resolve01", haha

[Reactie gewijzigd door dycell op 7 april 2011 16:18]

Je hebt zo'n certificaat juist omdat DNS onveilig is. Als iemand DNS hackt krijg je een waarschuwing dat het certificaat niet klopt.

@dycell, ik snap je opmerking aan mijn adres niet, volgens mij bevestig je mijn stelling.

DNSSEC gaat in de toekomst wel een oplossing zijn, maar momenteel heb je er nog helemaal niks aan, zeker als eindgebruiker. Je moet toch op z'n minst je eigen DNS-server draaien (op je eigen pc) om er een beetje op te kunnen vertrouwen.

[Reactie gewijzigd door CAPSLOCK2000 op 7 april 2011 16:51]

Ok, prima. Maar als je intern een DNS server hebt draaien is de kans dat die gehacked wordt natuurlijk best klein.
Of groot "want het is toch intern"
Als je intern al gehacked bent is je exchange certificate je grootste zorg niet meer.
De DNS server hoeft niet gehackt te worden. Je kan er ook mee volstaan door op de specifieke host een andere (jouw) dns server in te stellen.
Het is tevens ook van deze tijd om te kijken naar DNSSEC:
http://en.wikipedia.org/w...ystem_Security_Extensions
Je DNS resolves worden dan digitaal onder tekent door een (jaja) certificaat.
Nu maar hopen dat die lullo's van de certificaatautoriteiten geen certificaten uit gaan geven voor "NS01", "NS" of "resolve01", haha
Dan moet je toch echt nog eens die wiki link goed lezen. Er worden namelijk geen certificaten gebruikt bij DNSSEC. Er worden sleutels gebruikt. Met die sleutels worden signatures gemaakt van de inhoud. Met die signatures bevestig je dat de inhoud authentiek is. Er komt dus (gelukkig) geen CA bij kijken, maar alleen de beheerders van het betreffende domein/TLD. Zij creëren dan een chain of trust van root naar domein.

DNSSEC en Certificaten/HTTPS/SSL zouden naast elkaar gebruikt moeten worden. Dat zou het internet een stuk veiliger maken.

[Reactie gewijzigd door Shaflic op 7 april 2011 22:52]

Het SSL certificaat was juist het enige dat dit oninteressant maakte, je kon dan geen trusted certificaat serveren. Athans, dat is het idee.
Daarna kan doorverwezen worden naar een andere server met een vals certificaat?
Dat kan dus juist niet. Normaliter kun je geen trusted certificaat bemachtigen op een servername dat niet van jou is.


Het is mijn inziens bijzonder kwalijk dat dergelijke certificaten zijn uitgegeven, en de signers zouden daarvoor bestraft moeten worden.

[Reactie gewijzigd door frickY op 7 april 2011 15:27]

"Dat kan dus juist niet. Normaliter kun je geen trusted certificaat bemachtigen op een servername dat niet van jou is. "

Helaas zijn er genoeg CA's die deze certificaten wel verstrekken.

Tijd voor DNSSEC! Dan weet je zeker dat je op de juiste server zit en kun je daarna SSL gebruiken om de verbinding te encrypten.
Niet echt....

Je weet alleen dat je het juiste IP adres hebt gebruikt. Afgezien daarvan weet je niets.

Er kan nog steeds iemand tussen jou en de server zitten die met een (ander) certificaat voor dezelfde servernaam jou doet geloven dat hijzelf de server is.

De manier om zeker te weten dat je met de echte server communiceert, is omdat die in het bezit is van een geldig certificaat. Als ook andere (ongerelateerde) servers een geldig certificaat kunnen hebben voor dezelfde hostnaam, dan heb je dus echt een probleem...
Wel echt...

Als je op het juiste IP adres zit, dan zit je dus niet op andermans server. Dan kan er wel iemand tussen zitten met een vals certificaat, maar daar heb je niets mee van doen, want daar heb je geen contact mee.

Je hebt simpelweg beide nodig. DNSSEC is stap 1 om op de juiste server te komen en SSL/HTTPS/Certificaat is stap 2 ter bevestiging en om een beveiligde verbinding op te zetten.
Het juiste IP adres van DNS(SEC) krijgen, en daadwerkelijk op dat juiste IP adres arriveren zijn twee compleet verschillende zaken.

Jij gaat er in jouw stelling vanuit dat iedere netwerkstap die je van je client tot het gewenste IP adres volledig te vertrouwen is. Dat de meeste man-in-the-middle attacks vanaf tussenliggende (compromised) routers worden uitgevoerd negeer je in dit verhaal. (Hence the name man-in-the-middle; Iemand op de route tussen jou en het gewenste IP waar je verkeer dus toch al langs kwam pakt jouw tcp-frames uit, doet er iets mee en emuleert (al dan niet aan de hand van een response die hij zelf van het trusted IP ophaalt) een forged answer die jij weer ontvangt.

Alleen werkt dit klassieke mim schema niet op het HTTPS protocol, omdat de tussenliggende router zijn forged frames niet kan signen.. zo dus wel.

[Reactie gewijzigd door Remz-Jay op 8 april 2011 00:21]

Dat is nou juist wat DNSSEC voorkomt!

De gegevens van het "trusted IP" worden ondertekent met een handtekening. Die handtekening klopt niet meer op het moment dat die man-in-the-middle iets met die respons doet. Dat is juist het hele punt van DNSSEC.

En die handtekening wordt gevalideerd met de publieke helft van de sleutel behorende bij de betreffende trusted IP. Het bericht veranderen en de handtekening vervalsen is nagenoeg onmogelijk voor die man-in-the-middle.

Ik negeer absoluut niet die man-in-the-middle met zijn compromised router. Sterker nog, dat is exact wat DNSSEC tegen gaat.

Zodra je dus zeker weet dat het IP adres wat je ontvangen hebt authentiek is (dankzij DNSSEC) kun je met https een encrypted verbinding opzetten. Daar zorgt DNSSEC namelijk niet voor.
Er is dus niet echt lekker opgelet bij de certificaatauthoriteiten. Ik neem aan dat deze verantwoordelijk gesteld worden en beboet worden. Alleen zo zullen ze van hun fouten leren.

Eigenlijk wordt het dus tijd voor een beter, simpeler protocol. Eentje waar balie-medewerkers ook mee overweg kunnen zelfs als ze geen idee hebben wat ze doen, want dat blijkt de praktijk.

Waarschijnlijk zal het hier niet om enorm populaire domeinen gaan omdat ik in ieder geval hoop aan te kunnen nemen dat medewerkers wel snappen dat ze van gmail niet zomaar certificaten kunnen rondstrooien.
Het heeft natuurlijk vooral te maken met de kwaliteit van de controle. Certificaten zijn duur, en dus is het van belang dat je als aanvrager een CA vind die zo goedkoop mogelijk is.

Echter, de goedkopere CA's hebben niet de mankracht om echt goed te controleren.
De betere validatie (Extended Validation (EV) Certificaten) zijn dus ook veel duurder, maar die kan je dan ook echt vertrouwen(Althans, dat is het idee ervan :P )
Het is gewoon belachelijk dat een CA extra geld gaat vragen voor een EV certificaat terwijl ze sowieso gewoon moeten controleren of de aanvrager ook echt degene is die hij zegt dat hij is.
Het is gewoon belachelijk dat een CA extra geld gaat vragen voor een EV certificaat terwijl ze sowieso gewoon moeten controleren of de aanvrager ook echt degene is die hij zegt dat hij is.
Nee, je hebt domweg gradaties aan verificatie. De simpelste is: beheert de aanvrager een administratieve (postmaster, oid) mailbox op het domein waarop het cert wordt aangevraagd? Dat is een verificatie die enkele euro's kost. Een EV verificatie is dagen aan werk, met diepgaande controlle's van identiteit en authoriteit binnen de organisatie, die aan de hand van diverse bronnen gechecked wordt.

[Reactie gewijzigd door arjankoole op 7 april 2011 22:45]

Dan is het toch zeer jammer dat browsers dat niet weergeven.

Nu is het alleen 'wel' of 'geen' SSL, misschien zou een 'scoresysteem' beter zijn, een soort 'punt' voor betrouwbaarheid.

De meeste websurfres die volgens mij SSL zien (of een groen slotje), gaan er namelijk vanuit dat er diepgaande controle is geweest en de boel betrouwbaar is, ten onrechte.
Browsers geven dat weldegelijk aan. Zoals arjankoole al aangaf zijn er verschillende gradaties. De meeste brouwsers geven keurig weer wanneer de adresgegevens van een bedrijf niet gecontrolleerd zijn. Wanneer deze wel zijn gecontroleerd, geeft Chrome bijv. lins van de URL de bedrijfsnaam en de locatie (bijv. US) aan. Wanneer EV verificatie is toegepast, veranderd de kleur in vrijwel alle browsers van blauw naar groen. Je beweert dus ten onrechte dat browsers dit niet weergeven.
Dat heet Commercie :)
Als je het gelinkte artikel zou gelezen hebben, zou je weten dat ze dergelijke ongequalificeerde domeinen zelfs bij de EV-certificaten gevonden hebben. Dat maakt meteen duidelijk hoeveel zo'n EV-certificaat waard is...
Er is al langer twijfel over de uitgevende instanties (CAs) die kun klanten zouden moeten controleren. SSL zit technisch wel goed in elkaar, alleen lijkt het administratief een gatenkaas. http://security.nl/artike...n_geldig_certificaat.html
toch bijzonder, want administratie is het enige waar je een CA voor betaalt :) Knap dat ze het enige wat ze zouden moeten doen niet goed doen.

[Reactie gewijzigd door Spider.007 op 7 april 2011 15:34]

Aangezien de bedragen die sommige CA's vragen is het inderdaad bijzonder dat ze er zo'n zooitje van maken.
Kijk naar een stichting thuiskopie, dat is toch net zo'n bende terwijl er geld genoeg is. Dat is volgens mij ook de kern van het probleem: de klanten betalen toch wel, zelfs als je broddelwerk aflevert. Dat stimuleert niet echt tot een effectieve en correcte bedrijfsvoering. Dat terwijl het halve internet van deze CAs afhankelijk is voor secure transacties.
Inderdaad, nog erger gesteld is het met onze Staat...
Probleem is, dat CA's vziw worden betaald voor aantal verstrekte certificaten, en niet voor de kwaliteit van het werk dat ze leveren.

Beetje als patentbureau's, waarmee systemen een enorme pleuriszooi worden - aangezien alle aanvragen maar gehonoreerd worden - en de systemen bijna onder hun eigen gewicht / misbruik bezwijken.
Zo zie je maar wat een dikke onzin dat commerciële SSL gebeuren is, als de CA al niet eens controleert wat ze uitgeven. Kost namelijk best veel geld om zo'n mooie groene adres-balk te krijgen. Gelukkig draai ik geen commerciële website op het moment en gebruik gewoon self-signed certificaatjes.
Beetje overtrokken: Er wordt niet gecontroleerd (of gewoon erg slecht) op certificaten die niet gekoppeld zijn aan een domeinnaam die niet via buitenaf geresolved kan worden.

Let wel: Ik vind dat de CA's veel strenger moeten zijn met uitgeven, maar het risico is vrij klein met dit soort zaken.
Ik heb nog nooit enig bewijs gezien dat ze andere domeinnamen wel goed controleren.

Als zo'n CA z'n werk zou doen dan zouden ze deze certificaten nooit ondertekenen maar de aanvrager uitleggen dat het een slecht idee is. Maar men wil de kip met de gouden eieren niet slachten dus gaat men door met onzin-certificaten te verkopen aan iedereen die wil betalen.
Valt wel mee, er bestaan zelfs CA's die ze gratis uitgeven zoals Startcom. En deze certificates worden ook vertrouwd door Windows/IE.
Er zijn certificaten uitgebracht die geregistreerd zijn op het localhost adres... dat wil je niet. Ook een fout van de uitgever.
Wat is er eigenlijk mis met een localhost domein?
Www.localhost.nl bestaat ook gewoon.
Dat staat toch los van 127.0.0.1?
Er staat nergens localhost.nl, er staat localhost. Zonder tld toevoeging. En daar zit hem nu juist de crux.
http://www.localhost.nl staat inderdaad los van 127.0.0.1 maar dit staat ook los van het artikel het gaat om http://localhost

[Reactie gewijzigd door Precision op 7 april 2011 17:13]

Ja maar ik heb nog nooit gehoord van domeinen die slechts uit een woord bestaan zonder puntje in de naam... Zeker een hyaat in mijn kennis. 8)7
Nog nooit iemand http://exchange of http://tech zien intikken in de browser... :)
doe eens 'ping localhost' op je eigen machine in een dosbox of shell?
Hosts op een klein netwerk bij voorbeeld, die resolven via wins/netbieu of een default domain suffix.
Wat als een developer op zijn desktop/laptop een service heeft draaien die hij benaderd via localhost en die een certificaat nodig heeft?
Er moet gewoon nog maar 1 centrale wereldwijde organisatie zijn die überhaupt certificaten mag verkopen.
Een monopolie op certificates? Gunstig voor de prijzen ook... :(

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