Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Google Chrome zonder URL?
Uit https://www.wired.com/story/google-wants-to-kill-the-url/ (bron: https://tweakers.net/nieuws/143037/google-wil-url-in-toekomst-niet-langer-weergeven-in-chrome.html):
TLDR? Scroll naar onderaan deze bijdrage.
Bij het uitwisselen van informatie is het, afhankelijk van de vertrouwelijkheid en geloofwaardigheid van die informatie, min of meer belangrijk dat je weet met wie je communiceert en daarnaast, of je jouw communicatiepartner voldoende vertrouwt.
Vertrouwen is iets dat moet worden opgebouwd en/of wij baseren op "wat anderen ervan zeggen". Anders dan met "ratings" (die gekleurd kunnen zijn, niet altijd betrouwbaar dus) ken ik geen goed technisch systeem om betrouwbaarheid objectief te bepalen. Besseffende dat het verhaal hiermee onvolledig is, focus ik verder op het wie.
Min of meer noodzakelijke stappen (afhankelijk van jouw belangen en risico's) bij het bepalen van wie zijn:
A) Identificatie: wie zegt mijn communicatiepartner dat hij of zij is;
B) Is die identificatie uniek, en zo niet, is deze voldoende nauwkeurig voor mijn belangen en risico's;
C) Authenticatie: hoe zeker weet je dat de communicatiepartner is wij hij/zij zegt dat hij/zij is.
Op internet gebruiken we IP-adressen ter identificatie van computers. Op het publieke internet horen IP-adressen uniek te zijn, maar door fouten en bewuste manipulatie van de wijze waarop informatie (in netwerkpakketjes) wordt gerouteerd naar een IP adres, is het, op basis van een IP adres, niet zeker dat je informatie uitwisselt met de bedoelde computer.
En omdat mensen moeite hebben met het onthouden van nummers (plus een aantal andere redenen) gebruiken we meestal domeinnamen om met remote computers te communiceren, waarbij DNS zorgt voor de vertaling van domeinnamen naar IP adressen. Ik heb altijd wat moeite met "domeinnaam" omdat dit zowel gebruikt wordt voor identificatie van iets waar helemaal geen computer achter hoeft te zitten (zoals .nl of .gov.uk), maar hier bedoel ik het type domeinnaam dat, middels een DNS request, resolvt (wordt vertaald in) een IP adres. Zoals www.security.nl, en als handigheidje, ook security.nl.
Ook domeinnamen horen uniek te zijn, in de zin van dat je met "één computer" communiceert. In de praktijk kan een domeinnaam resolven in meerdere IP adressen, meestal bedoeld voor het verspreiden van de belasting over meerdere servers en/of het vergroten van de beschikbaarheid mocht één van die servers uitvallen of onbereikbaar zijn.
DNS is echter eenvoudig te manipuleren (op verschillende manieren), nog even los van of netwerkpakketjes met die met het uit DNS afkomstige IP adres (of adressen) worden uitgewisseld, met een computer van de door jou bedoelde eigenaar worden uitgewisseld.
Hoe dan ook, een domeinnaam is een unieke identifier maar biedt geen garantie dat je communiceert met een computer van de bedoelde eigenaar.
Precies daarom zijn digitale https servercertificaten uitgevonden. In zo'n certificaat bevestigt een derde partij, middels een digitale handtekening, dat een public key en een domainnaam bij elkaar horen. Bij die -unieke- public key hoort een -eveneens unieke- private key die op de server staat en deze, in principe, nooit hoort te verlaten.
Bij het opzetten van een https verbinding bewijst de server (middels een rekenkundige truc) dat hij in het bezit is van de private key behorende bij de public key in het certificaat. Als de browser geen certificaatwaarschuwing geeft, heb je flinke zekerheid dat jouw browser verbinding heeft met een server met de, in de URL balk getoonde, domeinnaam.
BELANGRIJK: doordat de server moet bewijzen over de juiste private key te beschikken, zullen fouten in DNS en/of routering (per ongeluk of opzettelijk) tot certificaatwaarschuwingen of -foutmeldingen leiden! Hoewel certificaten ook hun betrouwbaarheidsproblemen hebben, elimineren zij wel een heel stel aanvalsmogelijkheden op internet en zijn daarom m.i. onmisbaar!
De eerdergenoemde eisen A) t/m C) en de vertrouwensvraag, vertalen dus in:
1) Klopt de domeinnaam in de URL balk (waarvan we weten dat deze uniek is);
2) Is er sprake van een https verbinding en heb ik geen cerificaatfoutmelding/waarschuwing gezien (een slotje kun je weglaten, maar velen zullen dit een tijd als verwarrend beschouwen);
3) Vertrouw ik alle certificaatuitgevers, of -als ik onderzoek wie de uitgever is van het https servercertificaat (bij de meeste browsers door op het slotje te klikken - dat er dan wel moet zijn natuurlijk, en die informatie moet opleveren), die specifieke certificaatuitgever;
4) Weet ik zeker dat, exact zo gespeld, die domeinnaam van de door mij bedoelde eigenaar is;
5) Vertrouw ik die eigenaar, inclusief dat hij/zij de server door betrouwbare personen laat beheren, zij die server goed beveiligen en voorkomen dat de private key in verkeerde handen valt.
TLDR:
Ik zie niet hoe je domeinnamen zou kunnen vervangen door iets anders dat uniek, compact en -in een deel van de gevallen- relevante identificerende geografische informatie bevat.
Meningen?
[...]
"People have a really hard time understanding URLs," says Adrienne Porter Felt, Chrome's engineering manager. "They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity."
[...]
"I don’t know what this will look like, because it’s an active discussion in the team right now," says Parisa Tabriz, director of engineering at Chrome. "But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck."
[...]
"People have a really hard time understanding URLs," says Adrienne Porter Felt, Chrome's engineering manager. "They’re hard to read, it’s hard to know which part of them is supposed to be trusted, and in general I don’t think URLs are working as a good way to convey site identity. So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity."
[...]
"I don’t know what this will look like, because it’s an active discussion in the team right now," says Parisa Tabriz, director of engineering at Chrome. "But I do know that whatever we propose is going to be controversial. That’s one of the challenges with a really old and open and sprawling platform. Change will be controversial whatever form it takes. But it’s important we do something, because everyone is unsatisfied by URLs. They kind of suck."
[...]
TLDR? Scroll naar onderaan deze bijdrage.
Bij het uitwisselen van informatie is het, afhankelijk van de vertrouwelijkheid en geloofwaardigheid van die informatie, min of meer belangrijk dat je weet met wie je communiceert en daarnaast, of je jouw communicatiepartner voldoende vertrouwt.
Vertrouwen is iets dat moet worden opgebouwd en/of wij baseren op "wat anderen ervan zeggen". Anders dan met "ratings" (die gekleurd kunnen zijn, niet altijd betrouwbaar dus) ken ik geen goed technisch systeem om betrouwbaarheid objectief te bepalen. Besseffende dat het verhaal hiermee onvolledig is, focus ik verder op het wie.
Min of meer noodzakelijke stappen (afhankelijk van jouw belangen en risico's) bij het bepalen van wie zijn:
A) Identificatie: wie zegt mijn communicatiepartner dat hij of zij is;
B) Is die identificatie uniek, en zo niet, is deze voldoende nauwkeurig voor mijn belangen en risico's;
C) Authenticatie: hoe zeker weet je dat de communicatiepartner is wij hij/zij zegt dat hij/zij is.
Op internet gebruiken we IP-adressen ter identificatie van computers. Op het publieke internet horen IP-adressen uniek te zijn, maar door fouten en bewuste manipulatie van de wijze waarop informatie (in netwerkpakketjes) wordt gerouteerd naar een IP adres, is het, op basis van een IP adres, niet zeker dat je informatie uitwisselt met de bedoelde computer.
En omdat mensen moeite hebben met het onthouden van nummers (plus een aantal andere redenen) gebruiken we meestal domeinnamen om met remote computers te communiceren, waarbij DNS zorgt voor de vertaling van domeinnamen naar IP adressen. Ik heb altijd wat moeite met "domeinnaam" omdat dit zowel gebruikt wordt voor identificatie van iets waar helemaal geen computer achter hoeft te zitten (zoals .nl of .gov.uk), maar hier bedoel ik het type domeinnaam dat, middels een DNS request, resolvt (wordt vertaald in) een IP adres. Zoals www.security.nl, en als handigheidje, ook security.nl.
Ook domeinnamen horen uniek te zijn, in de zin van dat je met "één computer" communiceert. In de praktijk kan een domeinnaam resolven in meerdere IP adressen, meestal bedoeld voor het verspreiden van de belasting over meerdere servers en/of het vergroten van de beschikbaarheid mocht één van die servers uitvallen of onbereikbaar zijn.
DNS is echter eenvoudig te manipuleren (op verschillende manieren), nog even los van of netwerkpakketjes met die met het uit DNS afkomstige IP adres (of adressen) worden uitgewisseld, met een computer van de door jou bedoelde eigenaar worden uitgewisseld.
Hoe dan ook, een domeinnaam is een unieke identifier maar biedt geen garantie dat je communiceert met een computer van de bedoelde eigenaar.
Precies daarom zijn digitale https servercertificaten uitgevonden. In zo'n certificaat bevestigt een derde partij, middels een digitale handtekening, dat een public key en een domainnaam bij elkaar horen. Bij die -unieke- public key hoort een -eveneens unieke- private key die op de server staat en deze, in principe, nooit hoort te verlaten.
Bij het opzetten van een https verbinding bewijst de server (middels een rekenkundige truc) dat hij in het bezit is van de private key behorende bij de public key in het certificaat. Als de browser geen certificaatwaarschuwing geeft, heb je flinke zekerheid dat jouw browser verbinding heeft met een server met de, in de URL balk getoonde, domeinnaam.
BELANGRIJK: doordat de server moet bewijzen over de juiste private key te beschikken, zullen fouten in DNS en/of routering (per ongeluk of opzettelijk) tot certificaatwaarschuwingen of -foutmeldingen leiden! Hoewel certificaten ook hun betrouwbaarheidsproblemen hebben, elimineren zij wel een heel stel aanvalsmogelijkheden op internet en zijn daarom m.i. onmisbaar!
De eerdergenoemde eisen A) t/m C) en de vertrouwensvraag, vertalen dus in:
1) Klopt de domeinnaam in de URL balk (waarvan we weten dat deze uniek is);
2) Is er sprake van een https verbinding en heb ik geen cerificaatfoutmelding/waarschuwing gezien (een slotje kun je weglaten, maar velen zullen dit een tijd als verwarrend beschouwen);
3) Vertrouw ik alle certificaatuitgevers, of -als ik onderzoek wie de uitgever is van het https servercertificaat (bij de meeste browsers door op het slotje te klikken - dat er dan wel moet zijn natuurlijk, en die informatie moet opleveren), die specifieke certificaatuitgever;
4) Weet ik zeker dat, exact zo gespeld, die domeinnaam van de door mij bedoelde eigenaar is;
5) Vertrouw ik die eigenaar, inclusief dat hij/zij de server door betrouwbare personen laat beheren, zij die server goed beveiligen en voorkomen dat de private key in verkeerde handen valt.
TLDR:
Ik zie niet hoe je domeinnamen zou kunnen vervangen door iets anders dat uniek, compact en -in een deel van de gevallen- relevante identificerende geografische informatie bevat.
Meningen?
Reacties (15)
Wil Google dit vanwege de PHISHING op Google-accounts via data-uri's?
Waarom wil men steeds meer in de browser laten aflopen ten koste van de webs server?
Dit bijvoorbeeld werd al in 2015 voorgesteld: https://arstechnica.com/information-technology/2015/05/web-served-how-to-make-your-site-all-https-all-the-time-for-everyone/
Waarom niet alles ook via de browser als https encrypted "herschrijven".
Voor wat betreft de herschrijfregels, zie https everywhere atlas en de static site generator: https://github.com/EFForg/https-everywhere-atlas
Het laatste buzz-word van Google: https://www.digitaltrends.com/web/google-wants-to-kill-urls-to-make-the-internet-safer/ Is Firebase Dynamic Links het laatste nieuwe in de plaats van de eigen shortener dienst, die opgeheven is?
Komt Google met een uri-oplossing, die en veilig en begrijpelijk is voor elke Jip en Janneke-netizen (en werkt dan zo'n "dumbed down" model naar behoren? We horen en zien het wel - of in de herfst of volgend voorjaar. Gaat het bedrag dat cybercrime binnenharkt elk jaar substantieel naar beneden? Ik betwijfel het,
luntrus
Waarom wil men steeds meer in de browser laten aflopen ten koste van de webs server?
Dit bijvoorbeeld werd al in 2015 voorgesteld: https://arstechnica.com/information-technology/2015/05/web-served-how-to-make-your-site-all-https-all-the-time-for-everyone/
Waarom niet alles ook via de browser als https encrypted "herschrijven".
Enable HTTPS Switch Planner mode (reloads page).
Switch Planner mode helps prepare for your site's switch to HTTPS by generating a report of external HTTP resources that might not yet be available on HTTPS.
After enabling, navigate around your site and try to exercise all functionality in order to get a comprehensive list of external resources.
For each group of resources listed as "Unrewritten," find out whether they are available on HTTPS. If so: add a rule to HTTPS Everywhere! If not: try to make them available over HTTPS or use a different resource or provider. Otherwise your site will generate Mixed Content (passive or active) errors when you turn on HTTPS.
For most accurate results, disable ad blockers before using. Closing this panel will deactivate Switch Planner mode and clear stored data.
Switch Planner mode helps prepare for your site's switch to HTTPS by generating a report of external HTTP resources that might not yet be available on HTTPS.
After enabling, navigate around your site and try to exercise all functionality in order to get a comprehensive list of external resources.
For each group of resources listed as "Unrewritten," find out whether they are available on HTTPS. If so: add a rule to HTTPS Everywhere! If not: try to make them available over HTTPS or use a different resource or provider. Otherwise your site will generate Mixed Content (passive or active) errors when you turn on HTTPS.
For most accurate results, disable ad blockers before using. Closing this panel will deactivate Switch Planner mode and clear stored data.
Voor wat betreft de herschrijfregels, zie https everywhere atlas en de static site generator: https://github.com/EFForg/https-everywhere-atlas
Het laatste buzz-word van Google: https://www.digitaltrends.com/web/google-wants-to-kill-urls-to-make-the-internet-safer/ Is Firebase Dynamic Links het laatste nieuwe in de plaats van de eigen shortener dienst, die opgeheven is?
Komt Google met een uri-oplossing, die en veilig en begrijpelijk is voor elke Jip en Janneke-netizen (en werkt dan zo'n "dumbed down" model naar behoren? We horen en zien het wel - of in de herfst of volgend voorjaar. Gaat het bedrag dat cybercrime binnenharkt elk jaar substantieel naar beneden? Ik betwijfel het,
luntrus
06-09-2018, 14:27 door
-karma4
Bah, bah, Google begint zo op Microsoft te lijken, met hun standaard niet weergeven van file extensions in Windows. Hopelijk wordt het wel een optie die je kan uitzetten, zodat je de volledige URL kan blijven zien.
Ik las het ook op tweakers, en ik vroeg mij af wat er dan met mijn e-mail adressen gebeuren gaat? Klinkt mij in de oren als een heel stom plan van Google. Maar ze hebben vast al een draft rfc liggen, anders kom je niet met zoiets in het nieuws.
Stom. Dom. Ik zie enkel één puntje. Dat als ik zelf bijvoorbeeld op deze site kom, en ik denk dat ik dat veel beter en heel anders kan, dat dan die mooie domeinnaam al bezet is. En dat wordt toenemend vervelend, ondanks al die leuke mooie nieuwe TLD's. Bak je een app, dan heb je wat dat betreft al wat minder problemen met de naam. Alleen dat hele app gebeuren gaat snel verdwijnen (voorspel ik), omdat je daarna geen vat noch zicht hebt wat die app allemaal doet.
Het zou misschien wel een aardig idee zijn om de Page Title eens wat beter zichtnbaar te maken. Dat bungelt maar bovenaan bij al die browsers. Afgekapt en zo. Lelijk.
Blijft natuurlijk belangrijk dat je de URL altijd kunt blijven zien. Want om bij mijn suggestie te blijven dat ik even deze site veel beter kan, is het wel belangrijk dat je goed kunt zien dat het wel om een andere site gaat. Dat je weet, ha, dat is die sufferd die alles beter denkt te kunnen. Blijft belangrijk. En daar heb je dan toch een uniek gegeven voor nodig. Zoals een URL.
Los van alles, die apps die maar aan rotzooien wat je niet mag weten (dat je es OK hebt geklikt maakt dat niet goed, ik wil weten wat ze NU uitspoken natuurlijk), dat je URL's niet mag weten, dat je vooral van alles niet meer hoeft te weten, dat is het begin van het einde. En van het nieuwe begin.
Waarom? De "baas" van internet bestaat niet. Daar zijn al meer zichzelf grootgedachte firma's mee op hun plaat gegaan. En die geschiedenis herhaalt zich weer. De Amerikaanse senaat maakt zich zorgen. Dus die nofigen dan maar de drie "machtigsten" uit. Waarvan er eentje dan ook gewoon niet eens komt! Ze willen met de "baas" van internet spreken. En die bestaat niet. Jammer maar helaas.
Je mag van Google niet meer dit, je mag van Facebook niet meer dat, en Twitter probeert de kerk in het midden te houden. Mooie showvertoning. Maar het internet is helemaal niet van hullie. En zodra ze regeltjes gaan stellen, en dingetjes verstoppen, wegwezen. Ze kunnen namelijk niemand stoppen op het net die zich daar niks van aantrekt. Het zijn allemààl keizers zonder kleren, daar in dat Amerika! Zoveel waard, letterlijk, als de gek ervoor geeft.
Er zijn alternatieve browsers zat. En hoe meer vanaf de Explorers tot de Chromes, men gaat uitmaken wat dan wel niet goed voor je is, hoe sneller er meer alternatieven komen. Want die "grote jongens" smijten zelf de deur dicht. Dus komt er weer ruimte voor nieuw en beter!
Het zou misschien wel een aardig idee zijn om de Page Title eens wat beter zichtnbaar te maken. Dat bungelt maar bovenaan bij al die browsers. Afgekapt en zo. Lelijk.
Blijft natuurlijk belangrijk dat je de URL altijd kunt blijven zien. Want om bij mijn suggestie te blijven dat ik even deze site veel beter kan, is het wel belangrijk dat je goed kunt zien dat het wel om een andere site gaat. Dat je weet, ha, dat is die sufferd die alles beter denkt te kunnen. Blijft belangrijk. En daar heb je dan toch een uniek gegeven voor nodig. Zoals een URL.
Los van alles, die apps die maar aan rotzooien wat je niet mag weten (dat je es OK hebt geklikt maakt dat niet goed, ik wil weten wat ze NU uitspoken natuurlijk), dat je URL's niet mag weten, dat je vooral van alles niet meer hoeft te weten, dat is het begin van het einde. En van het nieuwe begin.
Waarom? De "baas" van internet bestaat niet. Daar zijn al meer zichzelf grootgedachte firma's mee op hun plaat gegaan. En die geschiedenis herhaalt zich weer. De Amerikaanse senaat maakt zich zorgen. Dus die nofigen dan maar de drie "machtigsten" uit. Waarvan er eentje dan ook gewoon niet eens komt! Ze willen met de "baas" van internet spreken. En die bestaat niet. Jammer maar helaas.
Je mag van Google niet meer dit, je mag van Facebook niet meer dat, en Twitter probeert de kerk in het midden te houden. Mooie showvertoning. Maar het internet is helemaal niet van hullie. En zodra ze regeltjes gaan stellen, en dingetjes verstoppen, wegwezen. Ze kunnen namelijk niemand stoppen op het net die zich daar niks van aantrekt. Het zijn allemààl keizers zonder kleren, daar in dat Amerika! Zoveel waard, letterlijk, als de gek ervoor geeft.
Er zijn alternatieve browsers zat. En hoe meer vanaf de Explorers tot de Chromes, men gaat uitmaken wat dan wel niet goed voor je is, hoe sneller er meer alternatieven komen. Want die "grote jongens" smijten zelf de deur dicht. Dus komt er weer ruimte voor nieuw en beter!
Volgend idee na amp waar Google denkt te weten, wat gebruikers willen en hun eigen sub-HTML doordrukken.
Krant zonder "amp", kom je wel onder op de hoop.
Nog minder mensen gaan uri's direct ingeven of url's en gebruiken dan hiervoor de Google zoekfunctie.
Alleen moet men nog content uitwisselen automatiseren (Google identifiers?), direct linken verbieden,
want niet goed voor het Google business model.
Google toont slechts copies van het te verwachten echte zoekresultaat en gaat deer weer meer aan verdienen.
Ze rijden je browser verder of het een rolstoel is.
Als Google een alternatief weet voor DNS en dat afdwingt,
dan hebben we in essentie het gehele Internet aan Google weggegeven.
Kunnen ze dat en komen ze daar bij onwetende klikkers mee weg?
Worden we straks nog meer door Google "geleefd"?
Krant zonder "amp", kom je wel onder op de hoop.
Nog minder mensen gaan uri's direct ingeven of url's en gebruiken dan hiervoor de Google zoekfunctie.
Alleen moet men nog content uitwisselen automatiseren (Google identifiers?), direct linken verbieden,
want niet goed voor het Google business model.
Google toont slechts copies van het te verwachten echte zoekresultaat en gaat deer weer meer aan verdienen.
Ze rijden je browser verder of het een rolstoel is.
Als Google een alternatief weet voor DNS en dat afdwingt,
dan hebben we in essentie het gehele Internet aan Google weggegeven.
Kunnen ze dat en komen ze daar bij onwetende klikkers mee weg?
Worden we straks nog meer door Google "geleefd"?
Je krijgt het nooit voor iedereen goed. Ik heb meegemaakt dat iemand dacht dat je URLs in het zoekvakje van Google (ingesteld als startpagina) moest invullen en dat de zoekresultaten de gezochte website waren, ongeacht of de links naar de gezochte website verwezen of niet. Ik heb geprobeerd die persoon uit te leggen wat de URL-balk is en dat je het daar in kan typen. Blanco. Ik kon de URL-balk op het scherm met mijn vinger aanwijzen en de aanwezigheid ervan drong domweg niet door. Dat is iemand aan wie je het slotje niet uit kan leggen, de groene naam van je bank niet, URLs niet, en wat je ook gaat bedenken om URLs te vervangen evenmin, want die sluit dingen compleet buiten waarvan hij besloten heeft dat ze te moeilijk zijn.
Wat je ook verzint, het moet een enorm aantal verschillende websites en resources binnen websites kunnen identificeren. Hoe ga je dat ooit terugbrengen tot iets dat minder is dan het aantal dat het nou eenmaal is? Dat lijkt mij fundamenteel onmogelijk.
Wat wel kan is de kritische delen ervan benadrukken. Zowel Firefox als Chromium laten nu al een deel van een URL donkerder zien dan de rest, voor deze pagina is dat bij Firefox "security.nl" en Chromium kiest "www.security.nl". Ik heb een voorkeur voor de kleinere selectie van Firefox, maar wat ze beiden beter kunnen doen is het nog een stuk sterker benadrukken. Maak de selectie niet alleen zwart maar ook vet, bijvoorbeeld. En er zijn presentatievormen denkbaar waar je tussen een simpele en een volledige weergave kan wisselen. Maar het web is nou eenmaal zo groot als het is, je moet dingen uniek kunnen identificeren en een gebruiker moet daar bijkunnen.
Wat je ook verzint, het moet een enorm aantal verschillende websites en resources binnen websites kunnen identificeren. Hoe ga je dat ooit terugbrengen tot iets dat minder is dan het aantal dat het nou eenmaal is? Dat lijkt mij fundamenteel onmogelijk.
Wat wel kan is de kritische delen ervan benadrukken. Zowel Firefox als Chromium laten nu al een deel van een URL donkerder zien dan de rest, voor deze pagina is dat bij Firefox "security.nl" en Chromium kiest "www.security.nl". Ik heb een voorkeur voor de kleinere selectie van Firefox, maar wat ze beiden beter kunnen doen is het nog een stuk sterker benadrukken. Maak de selectie niet alleen zwart maar ook vet, bijvoorbeeld. En er zijn presentatievormen denkbaar waar je tussen een simpele en een volledige weergave kan wisselen. Maar het web is nou eenmaal zo groot als het is, je moet dingen uniek kunnen identificeren en een gebruiker moet daar bijkunnen.
Simpel
Nu
Nieuwe stijl urlbarweergave
Alles ervoor en erachter niet meer weergegeven.
In de marge layout wel nieuwe plaats voor informatie icoontjes als een slotje en de titel van de pagina.
Mocht het een pdf / doc / exe etc link betreffen dan eerst altijd een waarschuwing en geen automatische download.
De basis url is niet het probleem, dat was nou juist een oplossing voor een groter probleem, namelijk de abstractie van ip-adressen.
De basis url als naamweergave van hoe de website heet is prima, de voor velen onbegrijpelijk lange technische rotzooi die er toch webdeveloper dev's en microsoft en cs achter wordt gefietst is het probleem.
Afkappen die weergave en desnoods in de voorkeuren weer ont-afkappen als je de volledige url wel graag wil zien.
opgelost.
Nu
https://www.security.nl/posting/575983/Google+Chrome+zonder+URL%3F
Nieuwe stijl urlbarweergave
www.security.nl
Alles ervoor en erachter niet meer weergegeven.
In de marge layout wel nieuwe plaats voor informatie icoontjes als een slotje en de titel van de pagina.
Mocht het een pdf / doc / exe etc link betreffen dan eerst altijd een waarschuwing en geen automatische download.
De basis url is niet het probleem, dat was nou juist een oplossing voor een groter probleem, namelijk de abstractie van ip-adressen.
De basis url als naamweergave van hoe de website heet is prima, de voor velen onbegrijpelijk lange technische rotzooi die er toch webdeveloper dev's en microsoft en cs achter wordt gefietst is het probleem.
Afkappen die weergave en desnoods in de voorkeuren weer ont-afkappen als je de volledige url wel graag wil zien.
opgelost.
Door Anoniem: Je krijgt het nooit voor iedereen goed. Ik heb meegemaakt dat iemand dacht dat je URLs in het zoekvakje van Google (ingesteld als startpagina) moest invullen en dat de zoekresultaten de gezochte website waren, ongeacht of de links naar de gezochte website verwezen of niet. Ik heb geprobeerd die persoon uit te leggen wat de URL-balk is en dat je het daar in kan typen. Blanco. Ik kon de URL-balk op het scherm met mijn vinger aanwijzen en de aanwezigheid ervan drong domweg niet door. Dat is iemand aan wie je het slotje niet uit kan leggen, de groene naam van je bank niet, URLs niet, en wat je ook gaat bedenken om URLs te vervangen evenmin, want die sluit dingen compleet buiten waarvan hij besloten heeft dat ze te moeilijk zijn.
Wat je ook verzint, het moet een enorm aantal verschillende websites en resources binnen websites kunnen identificeren. Hoe ga je dat ooit terugbrengen tot iets dat minder is dan het aantal dat het nou eenmaal is? Dat lijkt mij fundamenteel onmogelijk.
Wat wel kan is de kritische delen ervan benadrukken. Zowel Firefox als Chromium laten nu al een deel van een URL donkerder zien dan de rest, voor deze pagina is dat bij Firefox "security.nl" en Chromium kiest "www.security.nl". Ik heb een voorkeur voor de kleinere selectie van Firefox, maar wat ze beiden beter kunnen doen is het nog een stuk sterker benadrukken. Maak de selectie niet alleen zwart maar ook vet, bijvoorbeeld. En er zijn presentatievormen denkbaar waar je tussen een simpele en een volledige weergave kan wisselen. Maar het web is nou eenmaal zo groot als het is, je moet dingen uniek kunnen identificeren en een gebruiker moet daar bijkunnen.
Wat je ook verzint, het moet een enorm aantal verschillende websites en resources binnen websites kunnen identificeren. Hoe ga je dat ooit terugbrengen tot iets dat minder is dan het aantal dat het nou eenmaal is? Dat lijkt mij fundamenteel onmogelijk.
Wat wel kan is de kritische delen ervan benadrukken. Zowel Firefox als Chromium laten nu al een deel van een URL donkerder zien dan de rest, voor deze pagina is dat bij Firefox "security.nl" en Chromium kiest "www.security.nl". Ik heb een voorkeur voor de kleinere selectie van Firefox, maar wat ze beiden beter kunnen doen is het nog een stuk sterker benadrukken. Maak de selectie niet alleen zwart maar ook vet, bijvoorbeeld. En er zijn presentatievormen denkbaar waar je tussen een simpele en een volledige weergave kan wisselen. Maar het web is nou eenmaal zo groot als het is, je moet dingen uniek kunnen identificeren en een gebruiker moet daar bijkunnen.
Zulke mensen heb je inderdaad. Als ik dit aan iemand uit moet leggen vermijd ik altijd moeilijke termen en zeg dus gewoon internetadres. En ik zeg dan: Het internetadres is net zoiets als een teletext pagina. Wil je op teletext de stand van de eredivisie zien dan tik je 819 in. Wil je weten of het gaat regenen dan tik je het internetadres van buienradar in de adresbalk, en dat is https://www.buienradar.nl/ Dan begrijpen ze het meestal wel.
Function creep
Waar niemand het over heeft is natuurlijk dat het werkelijke voordeel voor Google ergens anders ligt.
Als de urlbar verdwijnt moet iedereen het webadres standaard in de zoekmachine intikken en dat levert veel informatie op.
Dat gebeurt op zich nu al veel, zoals bijvoorbeeld bij Firefox zonder dat de gemiddelde gebruiker dat doorheeft.
Alleen al daarom is Firefox geen, of dan toch een heel erg fake, dus slechte privacybrowser.
Afschaffen van die urlbar levert google waarschijnlijk dus nog meer voordeel op, en Firefox weer centjes van Google.
Waar niemand het over heeft is natuurlijk dat het werkelijke voordeel voor Google ergens anders ligt.
Als de urlbar verdwijnt moet iedereen het webadres standaard in de zoekmachine intikken en dat levert veel informatie op.
Dat gebeurt op zich nu al veel, zoals bijvoorbeeld bij Firefox zonder dat de gemiddelde gebruiker dat doorheeft.
Alleen al daarom is Firefox geen, of dan toch een heel erg fake, dus slechte privacybrowser.
Afschaffen van die urlbar levert google waarschijnlijk dus nog meer voordeel op, en Firefox weer centjes van Google.
Nog een voorbeeld van waarom het google niet slecht uitkomt als die urls verdwijnen of flink worden ingekort.
https://www.security.nl/posting/text/javascript
https://ssl/
http://www/
https://www.security.nl/posting/.google-analytics.com/ga.js
Aan de andere kant kan je het ook zien als een voordeel.
Een voordeel bij een nadeel.
Maar goed, dat oom-G hier actief was wisten we al wel want de laatste regel kenden we allang, die eerste niet, jij?
https://www.security.nl/posting/_gat._anonymizeIp
https://www.security.nl/posting/text/javascript
https://ssl/
http://www/
https://www.security.nl/posting/.google-analytics.com/ga.js
Aan de andere kant kan je het ook zien als een voordeel.
Een voordeel bij een nadeel.
Maar goed, dat oom-G hier actief was wisten we al wel want de laatste regel kenden we allang, die eerste niet, jij?
Mijn vraag en ik denk indirect die van topicstarter, Bitwiper, is hoe verhouden zich qua "trust & security" de bestaande methode
en het nieuwe Google chrome model zich. Wordt het veiliger en is de winst van het klikken op de "cloaking resultaten" van Google een toegevoegde bonus voor Google, waar goed over is nagedacht n.a.v. hun core-business?
Is het onveiliger als het huidige gebruik met DNS en certificering en beveiligde verbinding? Als het voorgestelde niet beter en veiliger is, moeten we helemaal niet aan willen beginnen met dat voor te stellen Google alternatief. Dat Google als monopolistische corporatie het Internet opnieuw gaat uitvinden ten behoeve van wat eigenlijk, is natuurlijk al op zich een gotspe. Ik dacht dat daar andere instanties voor waren, maar als men die al "in de zak en in de tas" heeft, dan zijn onze opmerkingen een beetje pruttelend gezeur in de ruimte. Dan zal blijken dat beleidsinstanties horig zijn gemaakt aan de groot commercie, dankzij de onnadenkende acceptatie van een steeds groter publiek.
Iets met mijn 12 jaar "3rd party cold reconnaissance website security scanning & error-hunting" ervaring zegt me dat ik toch dat Google niet helemaal vertrouw. Wie legt eens uit, waarom ik denk gelijk te krijgen?
luntrus
en het nieuwe Google chrome model zich. Wordt het veiliger en is de winst van het klikken op de "cloaking resultaten" van Google een toegevoegde bonus voor Google, waar goed over is nagedacht n.a.v. hun core-business?
Is het onveiliger als het huidige gebruik met DNS en certificering en beveiligde verbinding? Als het voorgestelde niet beter en veiliger is, moeten we helemaal niet aan willen beginnen met dat voor te stellen Google alternatief. Dat Google als monopolistische corporatie het Internet opnieuw gaat uitvinden ten behoeve van wat eigenlijk, is natuurlijk al op zich een gotspe. Ik dacht dat daar andere instanties voor waren, maar als men die al "in de zak en in de tas" heeft, dan zijn onze opmerkingen een beetje pruttelend gezeur in de ruimte. Dan zal blijken dat beleidsinstanties horig zijn gemaakt aan de groot commercie, dankzij de onnadenkende acceptatie van een steeds groter publiek.
Iets met mijn 12 jaar "3rd party cold reconnaissance website security scanning & error-hunting" ervaring zegt me dat ik toch dat Google niet helemaal vertrouw. Wie legt eens uit, waarom ik denk gelijk te krijgen?
luntrus
07-09-2018, 09:17 door
Krakatau
Door Anoniem: Simpel
Nu
Nieuwe stijl urlbarweergave
Nu
https://www.security.nl/posting/575983/Google+Chrome+zonder+URL%3F
Nieuwe stijl urlbarweergave
www.security.nl
Maar ik wil wel die bovenste URL kunnen kopiëren en plakken als ik naar een specifieke post wil verwijzen. Als er meer informatie is dan moet je die niet gaan verbergen. Zet er desnoods wat puntjes achter waarop je kan klikken als je het hele ding wil zien. Best of both worlds.
Dank voor alle recaties tot zover!
Terug naar de techniek. Uitgaande van https verbindingen is het, voor maximale vertrouwelijkheid en authenticiteit van informatie (sowieso voor de bezoeker, maar als die persoon inlogt, ook voor de eigenaar), noodzakelijk dat je weet:
A) Wie de eigenaar van een website is;
B) Of die eigenaar (en iedereen met "schrijftoegang" tot die website) te vertrouwen is.
Voor punt B ken ik geen technische oplossing. Voor punt A bestaan 2 gangbare oplossingen:
1) Bij een website met een EV certificaat zou je, naast de domeinnaam van een website, ook moeten zien wie de eigenaar is. Helaas is dat tweede gegeven geen gegarandeerde unieke identifier (denk aan "Jansen B.V. (NL)").
2) Bij een website met elk ander type certifcaat zie je uitsluitend de domeinnaam. In een OV certificaat hoort te staat vermeld wie de eigenaar is, maar vaak is dat zo nietszeggend dat je er weinig tot niets aan hebt, zoals deze:
Als daar gestaan had "O = Rijksoverheid" en "OU=DigiD" (desnoods "OU =Logius, afd. DigiD") had een leek er wellicht nog wat aan gehad, want who the fuck is Logius, en hoe is dat duidelijker dan hun oude naam "GBO.overheid"? En als dit een EV certificaat was geweest, wat had je dan aan de toevoeging "Logius (NL)" in de URL balk gehad? Wat als een crimineel een website voor OnLogius o.i.d. registreert en daar een EV certificaat voor weet te vergkrijgen? Hoe moeilijk kan het zijn om daar "Rijksoverheid (NL)" te laten zien?
Kortom, een domeinnaam is de belangrijkste unieke identifier voor een website; als je die niet checkt voordat je informatie serieus neemt en vooral voordat je vertrouwelijke gegegevens (zoals een wachtwoord of zelfs een e-mail adres) prijsgeeft, ben je gewoon een sukkel. Ik zie werkelijk niet hoe je veilig zou kunnen surfen zonder betrouwwbare unieke identificatie van websites.
Vanuit (gephishte) gebruikers bezien is het echter een groot probleem dat uit een gegeven domeinnaam niet valt af te leiden of het daarbij om een website van de gesuggereerde eigenaar/organisatie gaat (voorbeeld: icscards.nl versus verbasteringen daarvan), en het voor criminelen een koud kunstje is om lijkt-op domeinnamen te registreren - en om daar een DV-certificaat voor te verkrijgen. Neem daarbij de stompzinnigheid van vele beheerders die maar lukraak alternatieve domeinen registreren (no thanks for that) - met onze overheid voorop.
Sowieso zijn DV certificaten nagenoeg waardeloos (je kunt ze naar verluidt -nog te publiceren onderzoek- voor elke gewenste domeinnaam krijgen, dus ook voor bijv. digid.nl: https://www.theregister.co.uk/2018/09/06/boffins_break_cas_domain_validation/). Met het gebruik van DV certificaten zouden we dus gewoon op moeten houden, in elk geval voor sites waarbij zowel de bezoeker als de eigenaar vertrouwelijkheid en authenticiteit belangrijk vindt. En omdat normale surfers geen onderscheid zien tussen DV- en OV certificaten, kan die laatste categorie de ook vuilnisbak in zolang we DV certificaten blijven gebruiken.
Voor die gevoelige sites ken ik geen minder slechte oplossing dan een EV certificaat. Je hebt dan als unieke identifier de domeinnaam, en als aanvullende (vaak niet unieke) identifier, de naam van de eigenaar. Maar dan moeten beiden wel in beeld staan, of (bij kleine schermpjes) hebben gestaan voordat je verder gaat. En je moet die aanvullende identifier natuurlijk niet stom kiezen (dat lijkt me logius ;-).
Nb. ik vind de certificatendiscussie hier niet off-topic omdat domainnames veel te eenvoudig te spoofen zijn en https servercertificaten (beter dan DV) een vereiste zijn om dat risico te mitigeren. Daarbij is het een vereiste voor https servcercertificaten dat een -gegarandeerd unieke- identifier van een website gekoppeld wordt aan een public key van de eigenaar (die hoort bij een private key op de server). Je hebt dus, linksom of rechtsom, een herkenbare en unieke identifier nodig voor websites.
Er zullen vast alternatieve unieke identifiers voor domeinnamen te bedenken zijn, maar verzin maar eens iets dat compact, niet verwarrend en gegarandeerd uniek is (lokale domeinnamen zoals eindigend op .local buiten beschouwend laten, maar daar hoor je geen publiek https servercertificaat voor te kunnen krijgen).
Omkeren zou best logisch zijn (nl.security.www), maar aangezien we recentelijk de puinhoop hebben vergroot met het toevoegen van een heel stel nieuwe TLD's (Top Level Domains), en daarnaast veel talen doorspekt zijn met onlogische volgordes (dag-maand-jaar, month-day-year i.p.v. de ISO volorgde, achtundneunzig versus ninety-eight versus quatre-vingt-dix-huit, etcetera) zou ik bij voorkeur deze wereld niet op z'n kop willen zetten, want je schiet er weinig tot niets mee op.
Wel lijkt het mij zinvol om eens te kijken of er duidelijker kan worden aangegeven als het om een IDN (International Domain Name) en/of RTLO (Right To Left Override) gaat - wat een aantal aanvallen zou bemoeilijken of onmogelijk zou maken. Maar dan hebben we het over aanvullende metadata - die weer schermruimte kosten en mogelijk afleiden van andere belangrijke informatie.
En natuurlijk is het wat veiliger en overzichtelijker als je alles vóór en achter de domeinnaam (soms nietszeggend met bijv. met GUIDs of andere nietszeggende identifiers erin, zoals https://msdn.microsoft.com/en-us/library/windows/desktop/aa373931(v=vs.85).aspx) uit de URL kunnen weglaten, maar dan krjig je precies wat Krakatou aangeeft - je kunt dan niet simpelweg een URL kopiëren, bijv. om deze in een andere website op te nemen (zoals naar deze pagina, genoemd in de post van Krakatau). En je zult wel duidelijk moeten maken welk protocol wordt gebruikt. Eventueel kan https:// worden weglaten, maar dan zul je wel alle andere protocollen prominent in beeld moeten brengen.
Door Anoniem (luntrus): Mijn vraag en ik denk indirect die van topicstarter, Bitwiper, is hoe verhouden zich qua "trust & security" de bestaande methode en het nieuwe Google chrome model zich. Wordt het veiliger en is de winst van het klikken op de "cloaking resultaten" van Google een toegevoegde bonus voor Google, waar goed over is nagedacht n.a.v. hun core-business?
Ik heb geen idee van het belang van Google hierin, maar aangezien ik Google nog nooit heb kunnen betrappen op een "vernieuwend" idee dat hen uiteindelijk geheel geen reclameinkomsten opleverde, zou het mij verbazen als er niets anders achter zit dan het "verbeteren van de gebruikerservaring".Terug naar de techniek. Uitgaande van https verbindingen is het, voor maximale vertrouwelijkheid en authenticiteit van informatie (sowieso voor de bezoeker, maar als die persoon inlogt, ook voor de eigenaar), noodzakelijk dat je weet:
A) Wie de eigenaar van een website is;
B) Of die eigenaar (en iedereen met "schrijftoegang" tot die website) te vertrouwen is.
Voor punt B ken ik geen technische oplossing. Voor punt A bestaan 2 gangbare oplossingen:
1) Bij een website met een EV certificaat zou je, naast de domeinnaam van een website, ook moeten zien wie de eigenaar is. Helaas is dat tweede gegeven geen gegarandeerde unieke identifier (denk aan "Jansen B.V. (NL)").
2) Bij een website met elk ander type certifcaat zie je uitsluitend de domeinnaam. In een OV certificaat hoort te staat vermeld wie de eigenaar is, maar vaak is dat zo nietszeggend dat je er weinig tot niets aan hebt, zoals deze:
CN = digid.nl
Object Identifier (2 5 4 5) = 00000004003214345001
OU = DigiD
O = Logius
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
Object Identifier (2 5 4 5) = 00000004003214345001
OU = DigiD
O = Logius
L = 's-Gravenhage
ST = Zuid-Holland
C = NL
Kortom, een domeinnaam is de belangrijkste unieke identifier voor een website; als je die niet checkt voordat je informatie serieus neemt en vooral voordat je vertrouwelijke gegegevens (zoals een wachtwoord of zelfs een e-mail adres) prijsgeeft, ben je gewoon een sukkel. Ik zie werkelijk niet hoe je veilig zou kunnen surfen zonder betrouwwbare unieke identificatie van websites.
Vanuit (gephishte) gebruikers bezien is het echter een groot probleem dat uit een gegeven domeinnaam niet valt af te leiden of het daarbij om een website van de gesuggereerde eigenaar/organisatie gaat (voorbeeld: icscards.nl versus verbasteringen daarvan), en het voor criminelen een koud kunstje is om lijkt-op domeinnamen te registreren - en om daar een DV-certificaat voor te verkrijgen. Neem daarbij de stompzinnigheid van vele beheerders die maar lukraak alternatieve domeinen registreren (no thanks for that) - met onze overheid voorop.
Sowieso zijn DV certificaten nagenoeg waardeloos (je kunt ze naar verluidt -nog te publiceren onderzoek- voor elke gewenste domeinnaam krijgen, dus ook voor bijv. digid.nl: https://www.theregister.co.uk/2018/09/06/boffins_break_cas_domain_validation/). Met het gebruik van DV certificaten zouden we dus gewoon op moeten houden, in elk geval voor sites waarbij zowel de bezoeker als de eigenaar vertrouwelijkheid en authenticiteit belangrijk vindt. En omdat normale surfers geen onderscheid zien tussen DV- en OV certificaten, kan die laatste categorie de ook vuilnisbak in zolang we DV certificaten blijven gebruiken.
Voor die gevoelige sites ken ik geen minder slechte oplossing dan een EV certificaat. Je hebt dan als unieke identifier de domeinnaam, en als aanvullende (vaak niet unieke) identifier, de naam van de eigenaar. Maar dan moeten beiden wel in beeld staan, of (bij kleine schermpjes) hebben gestaan voordat je verder gaat. En je moet die aanvullende identifier natuurlijk niet stom kiezen (dat lijkt me logius ;-).
Nb. ik vind de certificatendiscussie hier niet off-topic omdat domainnames veel te eenvoudig te spoofen zijn en https servercertificaten (beter dan DV) een vereiste zijn om dat risico te mitigeren. Daarbij is het een vereiste voor https servcercertificaten dat een -gegarandeerd unieke- identifier van een website gekoppeld wordt aan een public key van de eigenaar (die hoort bij een private key op de server). Je hebt dus, linksom of rechtsom, een herkenbare en unieke identifier nodig voor websites.
Er zullen vast alternatieve unieke identifiers voor domeinnamen te bedenken zijn, maar verzin maar eens iets dat compact, niet verwarrend en gegarandeerd uniek is (lokale domeinnamen zoals eindigend op .local buiten beschouwend laten, maar daar hoor je geen publiek https servercertificaat voor te kunnen krijgen).
Omkeren zou best logisch zijn (nl.security.www), maar aangezien we recentelijk de puinhoop hebben vergroot met het toevoegen van een heel stel nieuwe TLD's (Top Level Domains), en daarnaast veel talen doorspekt zijn met onlogische volgordes (dag-maand-jaar, month-day-year i.p.v. de ISO volorgde, achtundneunzig versus ninety-eight versus quatre-vingt-dix-huit, etcetera) zou ik bij voorkeur deze wereld niet op z'n kop willen zetten, want je schiet er weinig tot niets mee op.
Wel lijkt het mij zinvol om eens te kijken of er duidelijker kan worden aangegeven als het om een IDN (International Domain Name) en/of RTLO (Right To Left Override) gaat - wat een aantal aanvallen zou bemoeilijken of onmogelijk zou maken. Maar dan hebben we het over aanvullende metadata - die weer schermruimte kosten en mogelijk afleiden van andere belangrijke informatie.
En natuurlijk is het wat veiliger en overzichtelijker als je alles vóór en achter de domeinnaam (soms nietszeggend met bijv. met GUIDs of andere nietszeggende identifiers erin, zoals https://msdn.microsoft.com/en-us/library/windows/desktop/aa373931(v=vs.85).aspx) uit de URL kunnen weglaten, maar dan krjig je precies wat Krakatou aangeeft - je kunt dan niet simpelweg een URL kopiëren, bijv. om deze in een andere website op te nemen (zoals naar deze pagina, genoemd in de post van Krakatau). En je zult wel duidelijk moeten maken welk protocol wordt gebruikt. Eventueel kan https:// worden weglaten, maar dan zul je wel alle andere protocollen prominent in beeld moeten brengen.
https://www.wired.com/story/google-wants-to-kill-the-url/
Is dat moeilijk om te lezen? Vind ik niet.Maar het zijn een aantal sitebouwers die het de lezers moeilijk maakt.
Bijvoorbeeld "http://www.osti.gov/servlets/purl/594543-mUGcOH/webviewable/" maakt de meeste lezers niet veel wijzer.
De benaming is teveel naar binnen gericht.
Misschien moet elke url 2 benamingen hebben waarvan er 1 in de browser te selecteren is die in beeld komt in het url-veld. Eén technisch gericht (voor de systeembeheerder) en 1 naar buiten gericht (voor de simpele gebruikers)
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
