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?
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
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 |
# openssl s_client -connect storefront.fqdn.local:443 CONNECTED(00000003) depth=2 CN = AA-SR-AAM-CA-01-CA verify error:num=19:self signed certificate in certificate chain --- Certificate chain 0 s:/CN=storefront.fqdn.local i:/DC=local/DC=FDQN/CN=FQDN-AA-SR-AAM-CA-02-CA-1 1 s:/DC=local/DC=FQDN/CN=FQDN-AA-SR-AAM-CA-02-CA-1 i:/CN=AA-SR-AAM-CA-01-CA 2 s:/CN=AA-SR-AAM-CA-01-CA i:/CN=AA-SR-AAM-CA-01-CA --- Server certificate -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- subject=/CN=storefront.fqdn.local issuer=/DC=local/DC=FQDN/CN=FQDN-AA-SR-AAM-CA-02-CA-1 --- No client certificate CA names sent --- SSL handshake has read 3506 bytes and written 649 bytes --- New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : AES256-SHA Session-ID: 10101C264628ED7AC9D95131FD7E3F24E981B4CC76A176E398CD3F0DEB998102 Session-ID-ctx: Master-Key: A43115AE6C495E51FED98C8CFD86E794CB0D000A63457CFF564828C034B018B8E9321607A40C218831DAC00770D4C3E Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1521029260 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) |
De handshake is te zien met het commando curl
curl -v fqdn
Je krijgt dan de onderstaand output te zien met de TLS handshake
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
# curl -v https://storefront.FQDN.local * Rebuilt URL to: https://storefront.FQDN.local/ * Trying X.X.X.X... * TCP_NODELAY set * Connected to storefront.FQDN.local (X.X.X.X) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /usr/local/share/certs/ca-root-nss.crt CApath: none * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (OUT), TLS alert, Server hello (2): * SSL certificate problem: self signed certificate in certificate chain * Closing connection 0 * TLSv1.2 (OUT), TLS alert, Client hello (1): curl: (60) SSL certificate problem: self signed certificate in certificate chain More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. |
