Vanaf Chrome 77 wordt de verificatie van SSL-certificaten op dezelfde manier weergegeven

Vorige week google-ontwikkelaars die verantwoordelijk zijn voor het Google Chrome-webbrowserproject heeft de beslissing genomen om afzonderlijke etikettering van certificaten op EV-niveau uit te schakelen (Uitgebreide validatie) in Google Chrome.

Si voorheen werd voor sites met vergelijkbare certificaten de geverifieerde bedrijfsnaam weergegeven door het certificatiecentrum in de adresbalk, nu wordt voor deze sites dezelfde beveiligde verbindingsindicator weergegeven dan voor certificaten met verificatie van domeintoegang. En het is dat vanaf wat de volgende versie van Google Chrome 77 wordt, de informatie over het gebruik van EV-certificaten alleen wordt weergegeven in het vervolgkeuzemenu dat wordt weergegeven wanneer u op het pictogram voor beveiligde verbinding klikt.

Door deze stap als referentie te nemen, namen de mensen bij Apple vorig jaar (in 2018) een soortgelijke beslissing voor de Safari-browser en implementeerden ze deze in iOS 12 en macOS 10.14.

Het is belangrijk om te benadrukken dat EV-certificaten de geclaimde identificatieparameters bevestigen en vereisen dat het certificeringscentrum de documenten in het domein en de fysieke aanwezigheid van de eigenaar van de bron verifieert.

Waarom worden de entiteiten die de certificaten uitgeven niet langer weergegeven in de browserbalk?

Deze stap door Google-ontwikkelaars is afgeleid van een onderzoek uitgevoerd door Google, waar werd aangetoond dat de indicator werd gebruikt voorheen bood het voor EV-certificaten niet de verwachte bescherming voor gebruikers die niet op het verschil letten en het niet gebruikten bij het nemen van beslissingen over het invoeren van gevoelige gegevens op sites.

Permanentie in het Google-onderzoek Het bleek dat 85% van de gebruikers niet werd belet om binnen te komen met de aanwezigheidsreferenties in de adresbalk URL «accounts.google.com.amp.tinyurl.com" in plaats van "accounts.google.com«, Als het verschijnt op de typische interfacepagina van de Google-site.

Door ons eigen onderzoek en een overzicht van eerder academisch werk, heeft het Chrome Security UX-team vastgesteld dat de EV-gebruikersinterface gebruikers niet beschermt zoals bedoeld.

Gebruikers lijken geen veilige beslissingen te nemen (zoals het niet invoeren van wachtwoord of creditcardgegevens) wanneer de gebruikersinterface wordt gewijzigd of verwijderd, aangezien de EV-gebruikersinterface aanzienlijke bescherming zou moeten bieden.

Bovendien neemt de EV-badge waardevolle schermruimte in beslag, kan actief misleidende bedrijfsnamen worden weergegeven in een prominente gebruikersinterface en wordt de productsturing van Chrome naar een neutraal, in plaats van positief, scherm voor veilige verbindingen verstoord.

Vanwege deze problemen en het beperkte nut ervan, denken we dat dit het beste bij de informatie op de pagina past.

De wijziging van de EV-gebruikersinterface maakt deel uit van een bredere trend onder browsers om de oppervlakken van hun beveiligingsgebruikersinterface te verbeteren in het licht van recente vorderingen bij het begrijpen van deze problematische ruimte.

Om bij de meeste gebruikers vertrouwen te wekken in de site, bleek het voldoende te zijn om de pagina op het origineel te laten lijken.

Als gevolg hiervan Er werd geconcludeerd dat positieve veiligheidsindicatoren niet effectief zijn en dat het de moeite waard is om te focussen op het organiseren van de output van expliciete waarschuwingen over de problemen.

Een soortgelijk schema is bijvoorbeeld onlangs toegepast op HTTP-verbindingen die expliciet als onveilig zijn gemarkeerd.

Al mismo tiempo, de informatie die wordt weergegeven voor EV-certificaten neemt te veel ruimte in beslag in de adresbalk, kan het extra verwarring veroorzaken bij het bekijken van de bedrijfsnaam in de browserinterface, en het schendt ook het principe van productneutraliteit en wordt gebruikt voor spoofing.

De Symantec Certification Authority gaf bijvoorbeeld een Identity Verified EV-certificaat uit, waarvan de naam bedrogen gebruikers liet zien, vooral wanneer de echte naam van het open domein niet in de adresbalk paste.

bron: https://blog.chromium.org


Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: AB Internet Networks 2008 SL
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.