Regels voor verstrekken ssl-certificaten zijn aangescherpt
Vanaf 1 juli zijn er strengere regels ingegaan voor de uitgifte van ssl-certificaten. Interne domeinen krijgen alleen een certificaat met een beperkte geldigheidsduur. Ook komt er een telefonische validatie voor certificaten met bedrijfsgegevens.
De nieuwe richtlijnen, die vanaf zondag zijn ingegaan, zijn opgesteld door het CA/Browser Forum, een organisatie waarin alle grote certificaatautoriteiten zijn vertegenwoordigd. Een van de aangescherpte regels betreft de uitgifte voor certificaten met bedrijfsgegevens. Bij dergelijke certificaten zal voortaan altijd een telefonische validatie uitgevoerd moeten worden, terwijl dit voorheen alleen vereist was voor zogenaamde EV-certificaten met een groene adresbalk.
Volgens de nieuwe validatieprocedure zal de certificaatautoriteit of de leverancier van het certificaat telefonisch contact opnemen met de aanvrager. Daarvoor wordt gebruik gemaakt van een algemeen telefoonnummer van het bedrijf, bijvoorbeeld het nummer dat in de KvK-database is opgenomen. Vervolgens moet de klant aangeven of hij instemt met de uitgifte. Deze controle wordt toegepast om na te gaan of het certificaat aan de juiste partij wordt verstrekt en moet de kans op misbruik van ssl-certificaten verkleinen.
Per 1 juli zullen certificaatautoriteiten ook geen ssl-certificaten meer verstrekken voor interne domeinen met een einddatum na 1 november 2015. Omdat met name Exchange-servers problemen kunnen krijgen als de certificaten vervallen, blijft het voorlopig nog mogelijk om .local-certificaten aan te vragen met een verloopdatum voor 1 november 2015. Verder zullen ssl-certificaten met interne domeinnamen die voor 1 juli 2012 zijn uitgegeven en op 1 oktober 2016 nog geldig zijn, door de certificaatautoriteiten worden ingetrokken.
De strengere regels voor de uitgifte van ssl-certificaten zijn mede ingevoerd onder druk van de browserbouwers Mozilla en Microsoft. Zij stellen dat .local-certificaten voor interne domeinen onveilig zijn omdat deze geen unieke locatie beschrijven en dus op meerdere locaties gebruikt kunnen worden. Een onderzoek van de EFF wees vorig jaar nog uit dat er tienduizenden onveilige ssl-certificaten in omloop zijn die in een lokaal domein gebruikt kunnen worden.
Reacties (34)
Betekent dat dat er ná 1 november 2015 intern in zijn geheel geen SSL meer mogelijk is, als er geen certificaten meer verkrijgbaar zijn die na die tijd nog geldig zijn? Of wordt er een alternatief geboden zodat ook na die tijd intern nog een vorm van beveiliging kan plaatsvinden?Per 1 juli zullen certificaatautoriteiten ook geen ssl-certificaten meer vertrekken voor interne domeinen met een einddatum na 1 november 2015.
Want om na die datum nu geheel onbeveiligd verder te gaan lijkt me ook niet heel erg wenselijk...
Of je neemt gewoon een ".local.mydomain.nl" DNS ipv een ".local" ? Kan je ook intern houden 
[Reactie gewijzigd door TvdW op zondag 1 juli 2012 13:51]
Dat is idd verstandig als je nu een AD structuur aan het opzetten ben. Maar als je al een AD domein heb met tig servers en een paar honderd gebruikers is het niet eenvoudig om even naar een nieuw domein te migreren.
Dan had je dat vanaf het begin goed op moeten zetten natuurlijk. Maar da's dus waarom je tot 2015 hebt om dat aan te passen.
Microsoft KB artikel 254680 (DNS Namespace Planning) beschrijft een aantal regels waaraan een goede domeinnaam moet voldoen. In het verleden werd daarbij .local niet alleen als valide beschouwd, maar zelfs geadviseerd. Bij veel bedrijven is een dergelijke DNS domain name dan ook in gebruik. Inmiddels is het artikel aangepast, en is dit advies dus niet meer van toepassing voor 'gewone' omgevingen.
Het artikel voor Small Business Server, KB296250, is echter nooit aangepast, en hier kun je de voordelen van een dergelijke naam nog steeds terugvinden.
Het aanpassen van een domeinnaam is niet iets wat je al te licht moet oppakken, en zal dan ook alleen gebeuren als er zwaarwegende argumenten zijn. In de praktijk is dit zelden om technische redenen maar vooral in verband met gevoeligheden omtrent naamgeving en dus vanuit management-perspectief gedreven, bijvoorbeeld bij fusies en/of overnames.
Het artikel voor Small Business Server, KB296250, is echter nooit aangepast, en hier kun je de voordelen van een dergelijke naam nog steeds terugvinden.
Het aanpassen van een domeinnaam is niet iets wat je al te licht moet oppakken, en zal dan ook alleen gebeuren als er zwaarwegende argumenten zijn. In de praktijk is dit zelden om technische redenen maar vooral in verband met gevoeligheden omtrent naamgeving en dus vanuit management-perspectief gedreven, bijvoorbeeld bij fusies en/of overnames.
Bij de normale installatie van SBS 2011 blijkt het zelfs niet mogelijk on .local te omzeilen. Dit lukt alleen als je een custom-installatie doet d.m.v. een zogenaamde answer-file. De SBS doelgroep zal zich waarschijnlijk aan de standaardinstelling houden.
Helaas is dat niet overal goed in gecommuniceerd. Systeembeheer @job was goed over de zeik en had het idee dat ze voor 1 juli 25 nieuwe certificaten moesten regelen. Nadat 3 mensen de mail gelezen hadden kwam het door dat de huidige certificaten niet per de 1ste vervielen. 
Classic.
Classic.
Haha, nee MS raad je echt niet aan een publieke DNS naam te gebruiken voor een intern netwerk hoor. Kijk maar eens naar 1 van de honderden voorbeelden van MS whitepapers.
Contoso.local anyone?
Je kunt heel eenvoudig je eigen Certficaat Organistatie opzetten binnen AD en dan helemaal je eigen beheer over certificaten houden met elke extensie waar jij je goed mee voelt (.local .intern .ikbendeman). Zie hier voor meer info:
http://technet.microsoft....ry/cc772393(v=WS.10).aspx
Contoso.local anyone?
Je kunt heel eenvoudig je eigen Certficaat Organistatie opzetten binnen AD en dan helemaal je eigen beheer over certificaten houden met elke extensie waar jij je goed mee voelt (.local .intern .ikbendeman). Zie hier voor meer info:
http://technet.microsoft....ry/cc772393(v=WS.10).aspx
Het was sowieso al goedkoper, en misschien ook wel handig, om voor intern, intranet, gebruik een eigen CA op te zetten.
Het lijkt erop dat dit nu wel héél erg handig is ...
Het lijkt erop dat dit nu wel héél erg handig is ...
Goedkoper om een eigen CA op te zetten? Een SSL certificaaat kost tussen de ¤20 en ¤1800 per jaar. Wat denk je dat het kost om een interne PKI omgeving op te bouwen en te onderhouden? Dan heb ik het niet over een OPENSSL actie, maar conform regels waarbij auditting, functiescheiding, backup, security e.d. geregeld zijn?
Voor dat geld kan je een heleboel dure certificaten aanschaffen hoor.
Het klopt dat je binnen enkele minuten een complete Microsoft AD Integrated Enterprise PKI omgeving kan optuigen, maar die dingen worden standaard niet door derden vertrouwd (alleen voor intern gebruik dus). Voor die partijen moet je weer aangeven hoe ze een Root CA moeten vertrouwen om op het Intranet te komen (ik ga niet zomaar een RootCA van een partij vertrouwen).
Al snel volgen de SSL en/of VPN oplossingen voor eigen gebruikers en worden vervolgens in/verkoop systemen voorzien van die certificaten voor transacties van klanten e.d.
En dan verloopt het root certificaat, of de CRL (als die er ueberhaupt is) wordt niet meer geupdate en degene die het allemaal 'wist' is op vakantie (of erger; werkt ergens anders). Gevolg is dat de business stopt.
Klinkt misschien als over de top, maar ik heb het bij twee bedrijven (>700 medewerkers) meegemaakt.
Helemaal terug redenerend is dat allemaal de oorzaak geweest doordat een beheerder ooit eens een keer de aanschaf van een regulier SSL certificaat te duur vond en dus wel even zelf iets bakte in zijn AD....
Overigens, die controle op basis van het telefoon nummer conform KvK deed KPN destijds al (voor dat de PKI toko werd samengevoegd met die van Getronics). Da's voor de VeriSign wederverkopers/affiliates op zich niet nieuw.
Voor dat geld kan je een heleboel dure certificaten aanschaffen hoor.
Het klopt dat je binnen enkele minuten een complete Microsoft AD Integrated Enterprise PKI omgeving kan optuigen, maar die dingen worden standaard niet door derden vertrouwd (alleen voor intern gebruik dus). Voor die partijen moet je weer aangeven hoe ze een Root CA moeten vertrouwen om op het Intranet te komen (ik ga niet zomaar een RootCA van een partij vertrouwen).
Al snel volgen de SSL en/of VPN oplossingen voor eigen gebruikers en worden vervolgens in/verkoop systemen voorzien van die certificaten voor transacties van klanten e.d.
En dan verloopt het root certificaat, of de CRL (als die er ueberhaupt is) wordt niet meer geupdate en degene die het allemaal 'wist' is op vakantie (of erger; werkt ergens anders). Gevolg is dat de business stopt.
Klinkt misschien als over de top, maar ik heb het bij twee bedrijven (>700 medewerkers) meegemaakt.
Helemaal terug redenerend is dat allemaal de oorzaak geweest doordat een beheerder ooit eens een keer de aanschaf van een regulier SSL certificaat te duur vond en dus wel even zelf iets bakte in zijn AD....
Overigens, die controle op basis van het telefoon nummer conform KvK deed KPN destijds al (voor dat de PKI toko werd samengevoegd met die van Getronics). Da's voor de VeriSign wederverkopers/affiliates op zich niet nieuw.
Dat geneuzel hoor ik altijd. Hoe veel veiliger/beter is het om het buiten de deur te doen? Remember diginotar, verisign (microsoft.com actie) en recent het MS certificaat? Het is duur om het buiten de deur te doen en oncontroleerbaar (en dat is de eerste vereist voor veiligheid).
Ik zeg niet dat je even met OpenSSL oid. aan de slag moet, maar bezint voor je begint: de security pipo roept dat iedere server een eigen cert moet hebben, dat wordt gelezen als iedere service moet een eigen cert en voor je het weet moet je 1000+ certificaten aanschaffen. Dan loont het dus wel om niet voor x dollar per keer naar een ander te moeten (en certificaten van 1800+ per jaar: damn. welke CA durft dit te vragen?)
Ik zeg niet dat je even met OpenSSL oid. aan de slag moet, maar bezint voor je begint: de security pipo roept dat iedere server een eigen cert moet hebben, dat wordt gelezen als iedere service moet een eigen cert en voor je het weet moet je 1000+ certificaten aanschaffen. Dan loont het dus wel om niet voor x dollar per keer naar een ander te moeten (en certificaten van 1800+ per jaar: damn. welke CA durft dit te vragen?)
Private certificates zijn NIET onveiliger dan publieke/CA getekende. Ze worden alleen standaard niet vertrouwd en daar zit dan ook het probleem, je kunt ze namelijk ook niet zo makkelijk valideren (of het het juiste certificaat is). Daarvoor moet je dus CA's installeren of op z'n minst checksums vergelijken.
De keys verschillen echter in het geheel niet tussen private en public certs en laten die nou de encryptie regelen.
Het vervelende is dat niemand zin heeft om op 700 mobieltjes een CA certificaat te zetten. Als medewerkers hun eigen spullen meenemen is dat nog lastiger, want wie zegt dat een medewerker jouw gehele CA certificaat wil vertrouwen.
Nou accepteren veel telefoontjes tegenwoordig ieder certificaat... of je daar vrolijk van wordt moet ook nog blijken. Mijn vertrouwen in CA's is iig klein. Al helemaal omdat er standaard 60+ in m'n browser zitten en ik bij god niet weet wat ik bijv. met de turkmenistan CA moet. Voegt voor mij niks toe, als hij gehacked wordt wel een enorm risico. En zij denken vast hetzelfde over onze Staat der Nederlanden CA (en terecht).
De keys verschillen echter in het geheel niet tussen private en public certs en laten die nou de encryptie regelen.
Het vervelende is dat niemand zin heeft om op 700 mobieltjes een CA certificaat te zetten. Als medewerkers hun eigen spullen meenemen is dat nog lastiger, want wie zegt dat een medewerker jouw gehele CA certificaat wil vertrouwen.
Nou accepteren veel telefoontjes tegenwoordig ieder certificaat... of je daar vrolijk van wordt moet ook nog blijken. Mijn vertrouwen in CA's is iig klein. Al helemaal omdat er standaard 60+ in m'n browser zitten en ik bij god niet weet wat ik bijv. met de turkmenistan CA moet. Voegt voor mij niks toe, als hij gehacked wordt wel een enorm risico. En zij denken vast hetzelfde over onze Staat der Nederlanden CA (en terecht).
Na 2015 zullen alleen de certificaten uitgefaseerd zijn uitgegeven voor interne domeinen. Zoals in het artikel staan zijn deze zogenaamde .local-certificaten inherent onveilig, maar levert het problemen op om ze per direct af te schaffen.
SSL-verkeer met behulp van reguliere certificaten zal hierna gewoon blijven bestaan.
SSL-verkeer met behulp van reguliere certificaten zal hierna gewoon blijven bestaan.
Op de meeste plaatsen die ik gezien heb, werd er intern gewoon self-signed certificate gebruikt. Die werden via een GPO dan ook in de browser geinstalleerd.
Ik zie niet direct een reden waarom je een intern certificaat door een "echte" CA zou laten tekenen.
Ik zie niet direct een reden waarom je een intern certificaat door een "echte" CA zou laten tekenen.
Er is software die geen self-signed certificaten accepteert, en dit is wegens veiligheidsredenen niet altijd via een instelling uit te schakelen.
Je moet geen checks uitschakelen. Je moet het public certificate van je eigen CA opnemen in de certificate store van de software. Ik ken geen software waarbij dit niet mogelijk is. Bij MS heb je een globale certificate store en ook runtime environments van bijvoorbeeld Java hebben een centrale store waar je het certificate aan kan toevoegen.Er is software die geen self-signed certificaten accepteert, en dit is wegens veiligheidsredenen niet altijd via een instelling uit te schakelen.
Als de software enkel hoeft te communiceren met SSL/TLS systemen welke certificaten hebben welke door jouw uitgegeven zijn is het theoretisch gezien zelfs veiliger om de rest eruit te mikken. Aangezien Thawte, De staat der Nederlanden en DigiNotar..... eigenlijk nooit een certificaat voor een server van mij mogen uitgeven.
Een "echte" CA is niks anders dan een CA wiens root certificate standaard opgenomen word in software. Uiteraard willen deze partijen je doen geloven dat er heel veel magie om heen hangt maar technisch gezien is het niks anders dan zelf EJBCA of DogTag runnen.
[Reactie gewijzigd door JUDGExKTF op zondag 1 juli 2012 15:12]
Ja dat kan inderdaad maar voor zover ik weet, en hoe ik het nu vaak doe bij klanten, en hoe Xolphin dit volgens mij ook zelf adviseert, is een Exchange UCC multi domain certificaat aanvragen. Met daarin 3 domeinen, waarvan de interne server naam en bijv. mail.domein.nl.
Volgens mij kan je op een Exchange applicatie maar 1 certificaat kiezen, toch?
Het is toch niet mogelijk intern verkeer te laten verbinden met een certificaat van de AD Cert Authority en het externe verkeer te laten verbinden met bijv een Comodo signed cert?
Hoe moeten we dit dus doen in de toekomst...?
Volgens mij kan je op een Exchange applicatie maar 1 certificaat kiezen, toch?
Het is toch niet mogelijk intern verkeer te laten verbinden met een certificaat van de AD Cert Authority en het externe verkeer te laten verbinden met bijv een Comodo signed cert?
Hoe moeten we dit dus doen in de toekomst...?
je hoeft niet de hele lokale namespace te veranderen. Je kan een dns zone aanmaken die bv exchangeserver.externednsnaam.nl heeft en daar een a record in zetten met je interne ip adres van de exchange server.Dan wordt zowel intern als extern gebruik gemaakt van de externe dns naam. (split brain dns).
Omdat intern de externe dns naam wordt gebruikt blijft het certificaat gewoon werken.
Omdat intern de externe dns naam wordt gebruikt blijft het certificaat gewoon werken.
Dank voor je input!
Ik weet dat dat kan wat jij noemt inderdaad maar volgens mij is dat ook geen Microsoft DNS recommendation. Ik heb altijd geleerd publieke hostnames niet als een interne zone aan te maken. Maar misschien is dat alweer achterhaald?
Opzich werkt het wel prima natuurlijk...
Ik weet dat dat kan wat jij noemt inderdaad maar volgens mij is dat ook geen Microsoft DNS recommendation. Ik heb altijd geleerd publieke hostnames niet als een interne zone aan te maken. Maar misschien is dat alweer achterhaald?
Opzich werkt het wel prima natuurlijk...
Voor ondere andere Exchange en OCS/Lync kan je gebruik maken van zogenaamde SAN certificates, een certificaat waar meerdere FQDN's in vermeld zijn. Specifieker dan een wildcard en kan verschillende TLD's bevatten.
Om verschillende redenen is het noodzakelijk om een externe FQDN (bijv. webmail.klant.nl) en een interne FQDN (bijv. exchange01.klant.local) te gebruiken. Ik zal even nazoeken of deze strengere regels ook hiervoor gelden, of de .local regels dan ook hiervoor lijdend zijn...
Om verschillende redenen is het noodzakelijk om een externe FQDN (bijv. webmail.klant.nl) en een interne FQDN (bijv. exchange01.klant.local) te gebruiken. Ik zal even nazoeken of deze strengere regels ook hiervoor gelden, of de .local regels dan ook hiervoor lijdend zijn...
Toen ik dit artikel op t.net las dacht ik ook meteen aan het SAN SSL certificaat. Mijn inziens komt dat dus te vervallen na 1 november 2015.Voor ondere andere Exchange en OCS/Lync kan je gebruik maken van zogenaamde SAN certificates, een certificaat waar meerdere FQDN's in vermeld zijn. Specifieker dan een wildcard en kan verschillende TLD's bevatten.
[Reactie gewijzigd door OhMyGod op zondag 1 juli 2012 18:07]
SAN certificaat vervallen? Neuh, ik denk dus eerder dat men daarin echter geen .local meer accepteert. Niet geheel onoverkomelijk.
Zal ook tijd worden. Enige dat je hoefde te doen, is een zak geld neerleggen en je hebt een certificaat. Op de een of andere manier heb ik dat nooit echt vertrouwenswaardig gevonden.
Let ook op dat het dus lastiger wordt (en vanaf 1-11-2015 onmogelijk) om hostnames in certificaten te zetten.
Wat bijvoorbeeld handig is voor exchange servers waarbij gebruikers dan simpel https://exchange kunnen intypen.
Oplossing wordt dan of gebruikers aanleren om volledige url in te typen of een apparte website neerzetten met een certificaat uitgegeven door een interne ca server. (die trusted is door je ad clients) die dan redirect naar de daadwerkelijke site/server.
Wat bijvoorbeeld handig is voor exchange servers waarbij gebruikers dan simpel https://exchange kunnen intypen.
Oplossing wordt dan of gebruikers aanleren om volledige url in te typen of een apparte website neerzetten met een certificaat uitgegeven door een interne ca server. (die trusted is door je ad clients) die dan redirect naar de daadwerkelijke site/server.
[Reactie gewijzigd door DDX op zondag 1 juli 2012 16:39]
Je kunt ook een redirect maken op poort 80 (geen SSL, dus geen foutmeldingen over verkeerde hostnames en geen eigen certificaat nodig).
Da's niet altijd even handig. Bijv. als je ActiveSync extern gebruikt, maar ook intern via WiFi wilt gebruiken. Wil je dezelfde FQDN gebruiken en eigenlijk ook dezelfde poort. Anders moet je je telefoon anders configureren als je binnen zit.
Wanneer je Exchange / Sharepoint enkel intern zou gebruiken, kun je een eigen CA opzetten in je domain controllers. Die verspreidt je, zodat de clients het certificaat vertrouwen. Het probleem kan daarmee opgelost worden.
Shit, Google heeft .lol al aangevraagd (zie hier), maar ik denk dat ik nog een hoop lol ga beleven zodra .local aan mij is toegewezen...
Mijn werkgever ontsleuteld al het SSL verkeer van medewerkers (bijvoorbeeld ook dat van Gmail, ING en Rabobank) en versleuteld het dan weer met een SHA1 certificaat voor die domein onder haar eigen root.
Omdat een normale browser dat niet accepteert als betrouwbaar zorgt de werkgever er voor dat alle browsers die op de computer draaien automatisch hun Root Certificaat accepteert voor alle domeinen.
Als DigiNotar al gehackt kon worden, waarom denkt mijn werkgever dat deze SSL nog veilig is voor gebruik door werknemers? En:
1) morgen ze wel voor ING een certificaat uitgeven?
2) mogen ze mijn browser zo modificeren?
Wat vinden jullie hier van? Mag dit? Kan dit zomaar in de NL wet en zijn er andere manieren om malware dat ook over SSL kan komen te onderschepen?
Omdat een normale browser dat niet accepteert als betrouwbaar zorgt de werkgever er voor dat alle browsers die op de computer draaien automatisch hun Root Certificaat accepteert voor alle domeinen.
Als DigiNotar al gehackt kon worden, waarom denkt mijn werkgever dat deze SSL nog veilig is voor gebruik door werknemers? En:
1) morgen ze wel voor ING een certificaat uitgeven?
2) mogen ze mijn browser zo modificeren?
Wat vinden jullie hier van? Mag dit? Kan dit zomaar in de NL wet en zijn er andere manieren om malware dat ook over SSL kan komen te onderschepen?
[Reactie gewijzigd door djwice op zondag 1 juli 2012 22:30]
Je hebt als werknemer een bepaalde mate van privacy, monitoring van je communicatie mag alleen als daar een specifieke aanleiding of zwaarwegende reden voor is. Maar het staat een werkgever vrij de infrastructuur zo in te richten dat monitoring altijd mogelijk is.
Als er malware op je pc staat (of op de server waarmee je communiceert) dan maakt SSL niets meer uit, de malware kan immers bij de unencrypted data.
Als er malware op je pc staat (of op de server waarmee je communiceert) dan maakt SSL niets meer uit, de malware kan immers bij de unencrypted data.
@SirBlade Voor mijn werkgever gaat het er om dat ze de malware kunnen herkennen en blokkeren voordat het mijn pc berijkt. Vandaar de ontsleuteling, scan en indien ok versleuteling en doorgifte.
-- thanks admin :-)
-- thanks admin :-)
[Reactie gewijzigd door djwice op dinsdag 3 juli 2012 06:48]
Ontsleutelen? Lijkt me erg sterk. Dan zou je baas de private sleutels van Google en Rabo moeten hebben. Denk het niet.
Of er (opnieuw) in SHA1 gewrapped wordt, is iets anders. SHA1 is trouwens ook (net als SHA-0 en MD5) gebroken, dus niet veilig.
[edit: linkje naar SHA pdf toegevoegd]
Of er (opnieuw) in SHA1 gewrapped wordt, is iets anders. SHA1 is trouwens ook (net als SHA-0 en MD5) gebroken, dus niet veilig.
[edit: linkje naar SHA pdf toegevoegd]
[Reactie gewijzigd door The Van op maandag 2 juli 2012 11:56]
Jawel, dat kan wel. Je hebt de private keys niet nodig
Als je bijvoorbeeld naar je bank surft, zal de proxyserver van het bedrijf de versleuteling met de bank opzetten (met het 'bankcertificaat' wat je ook in je Browser hebt)
Het verkeer wordt dan op de proxyserver ontsleuteld zoals op je eigen browser. Dan wordt het opnieuw versleuteld met het certificaat van je bedrijfsdomein en doorgestuurd naar je browser.
Normaal zou je browser gaan gillen, dat er een Man In The Middle aanval heeft plaatsgevonden en dat je de gegevens niet meer kunt vertrouwen.
Maar omdat het bedrijfscertificaat via policy als betrouwbare Certificate Authority in je browser is gezet, zal die het nu wel slikken.
Ter leering ende vermaeck: http://crypto.stanford.edu/ssl-mitm/
[edit en nog meer off topic]
Daarom moet een website met inlogfunctie er ook voor zorgen, dat je wachtwoord nooit plaintext verzonden mag worden. De bankwebsite bijvoorbeeld heeft een of andere hash van jouw wachtwoord in zijn database. Als je in je browser een wachtwoord intypt, zal dat ook eerst door je browser gehashed worden*, voordat het naar de website verzonden wordt. De bank vergelijkt dan de hashes en als deze gelijk zijn, klopt je wachtwoord. De proxyserver zal dus nooit je wachtwoord zien, maar alleen de hash.
*Als het goed is.
Als je bijvoorbeeld naar je bank surft, zal de proxyserver van het bedrijf de versleuteling met de bank opzetten (met het 'bankcertificaat' wat je ook in je Browser hebt)
Het verkeer wordt dan op de proxyserver ontsleuteld zoals op je eigen browser. Dan wordt het opnieuw versleuteld met het certificaat van je bedrijfsdomein en doorgestuurd naar je browser.
Normaal zou je browser gaan gillen, dat er een Man In The Middle aanval heeft plaatsgevonden en dat je de gegevens niet meer kunt vertrouwen.
Maar omdat het bedrijfscertificaat via policy als betrouwbare Certificate Authority in je browser is gezet, zal die het nu wel slikken.
Ter leering ende vermaeck: http://crypto.stanford.edu/ssl-mitm/
[edit en nog meer off topic]
Daarom moet een website met inlogfunctie er ook voor zorgen, dat je wachtwoord nooit plaintext verzonden mag worden. De bankwebsite bijvoorbeeld heeft een of andere hash van jouw wachtwoord in zijn database. Als je in je browser een wachtwoord intypt, zal dat ook eerst door je browser gehashed worden*, voordat het naar de website verzonden wordt. De bank vergelijkt dan de hashes en als deze gelijk zijn, klopt je wachtwoord. De proxyserver zal dus nooit je wachtwoord zien, maar alleen de hash.
*Als het goed is.
[Reactie gewijzigd door Vaan Banaan op maandag 2 juli 2012 13:42]
Maar als je met de hash kan inloggen maakt dat dus niets uit...
Wel als de hash wordt gezout met info over de sessie en het client certificaat, maar goed als dat op de client gebeurd kan de man in de middle dit ook nabootsen. Maar zou kun je wel een deceypt recrypt detecteren...
Bij welke info van een certificaat kun je met client script?
Edit: antwoord; https://developer.mozilla...n_XMLHTTPRequest_over_SSL
Wel als de hash wordt gezout met info over de sessie en het client certificaat, maar goed als dat op de client gebeurd kan de man in de middle dit ook nabootsen. Maar zou kun je wel een deceypt recrypt detecteren...
Bij welke info van een certificaat kun je met client script?
Edit: antwoord; https://developer.mozilla...n_XMLHTTPRequest_over_SSL
[Reactie gewijzigd door djwice op dinsdag 3 juli 2012 06:52]
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Tablets Samsung Websites en communities Mobiele telefoons Google Sony Microsoft Games Politiek en recht Consoles
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
