Veiliger met Chrome

V

Google gaat het online leven weer wat veiliger maken.  Ze hebben namelijk onlangs in hun eigen blog aangekondigd dat vanaf versie 68 van Chrome websites die niet beveiligd zijn met HTTPS encryptie aangemerkt zullen gaan worden als onveilig.

Deze nieuwe versie wordt verwacht in juli van dit jaar en zoals altijd wordt deze versie automatisch update op het moment dat de nieuwe versie beschikbaar is.

Vanaf 2015 is Google al bezig gestart met een campagne om het gebruik van HTTPS encryptie te stimuleren.

Vorig jaar januari  hebben ze met de introductie van versie 56 van Chrome al de transitie gemaakt naar het markeren van webpagina’s zonder encryptie, die persoonlijke gegevens verwerken. Deze lijn wordt nu dus doorgevoerd naar alle websites en pagina’s.

Google streeft er daarnaast naar om 100% van haar diensten versleuteld aan te bieden. Tijdens het schrijven van deze blog zitten ze bij Google op 94%, dus die belofte maken ze op 6% na waar.

Waarom versleuteling?

Photo by Ken Treloar on Unsplash

Het gebruik van HTTPS zorgt ervoor dat de website en pagina’s de worden bekeken niet afgeluisterd of aangepast kunnen worden door anderen in het netwerk, zoals uw internetprovider.

Laten we versleutelen

Niet alleen Google trekt de HTTPS-kar, ook de Certificate Authority Let’s Encrypt is één van de koplopers op dit gebied.

Let’s encrypt is een relatief nieuwe CA die, in tegen stelling tot veel andere CA’s, gratis certificaten uitgeeft. Zij hebben vandaag aangekondigd om het productportofolio uit te breiden met de mogelijkheid om wildcard certificaten uit te geven.

https://community.letsencrypt.org/t/acme-v2-and-wildcard-certificate-support-is-live/55579

Google en Let’s encrypt zijn twee voorbeelden van bedrijven die je online wereld dus weer een stukje veiliger aan het maken zijn.

Hoe werkt deze versleuteling

Wanneer je met Chrome, of met welke andere browser dan ook (met uitzondering van Lynx…) zal de de versleuting opgezet worden met starten met een zogenaamde handshake

Stap 1

De browser zal vragen aan de website om zichzelf te identificeren en een hello (een zogenaamde ClientHello) sturen.

Stap 2

De server die de website host zal de browser een kopie sturen van het certificaat, de Certificate Exchange.

Stap 3

De browser zal controleren of het certificaat vertrouwd kan worden. Dit doet de browser aan de hand van de publieke sleutel van het van het certificaat. Deze wordt gebruikt om het certificaaat te controleren bij de instantie die het certificaat hebben uitgegeven, de Certificate Authority.

Wanneer het certificaat is orde is zal de browser dit melden aan de server.

Stap 4

De server zal nu een digitale goedkeuring sturen en de versleutelde verbinding op zetten, waardoor alle communicatie tussen de browser en de server versleuteld zal worden. Dit heet de Key Exchange

Netscaler en SSL

Om deze blog toch een beetje toe te spitsen op Citrix kun zal ik eindigen met twee commando’s die ook op de Netscaler gebruikt kunnen worden om de certificaten en de handshake te controleren.

Op de Netscaler kun je via de CLI het certificaat controleren met het OpenSSL commando

openssl s_client -connect fqdn:443

De handshake is te zien met het commando curl

curl -v fqdn

Je krijgt dan de onderstaand output te zien met de TLS handshake

 

Over de auteur

Eltjo van Gulik

Eltjo is een enthousiaste en gedreven technisch consultant met ruim 18 jaar ervaring in de IT met een sterke focus op server- en applicatie virtualisatie producten van onder andere Microsoft (RDS, App-v, etc) en Citrix (XenDesktop, XenApp) en het installeren, configureren en beheren van applicaties binnen deze omgevingen.

Door Eltjo van Gulik

Over

Eltjo van Gulik

Eltjo is een enthousiaste en gedreven technisch consultant met ruim 18 jaar ervaring in de IT met een sterke focus op server- en applicatie virtualisatie producten van onder andere Microsoft (RDS, App-v, etc) en Citrix (XenDesktop, XenApp) en het installeren, configureren en beheren van applicaties binnen deze omgevingen.

Contact