Standaarden:Beveiligd Gegevenstransport/protocollen: verschil tussen versies
| (7 tussenliggende versies door dezelfde gebruiker niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| + | '''Let op, deze voorschriften worden vervangen door de [https://www.edustandaard.nl/standaard_afspraken/uniforme-beveiligingsvoorschriften/uniforme-beveiligingsvoorschriften-transport-layer-security-tls-v1-1/ Uniforme Beveiligingsvoorschriften]''' |
||
| + | |||
== HTTPS == |
== HTTPS == |
||
==== Eisen ==== |
==== Eisen ==== |
||
| Regel 23: | Regel 25: | ||
=== Versie === |
=== Versie === |
||
==== Eisen ==== |
==== Eisen ==== |
||
| + | * TLSv1.2 '''moet''' ondersteund worden. TLSv1.3 '''mag''' ondersteund worden |
||
| − | * '''Alleen''' TLS versie 1.2 en 1.3 mogen worden toegestaan |
||
| ⚫ | |||
* Aan deze eis '''moet''' aan zowel de vragende (client) als wel de leverende (server) kant binnen de keten voldaan worden |
* Aan deze eis '''moet''' aan zowel de vragende (client) als wel de leverende (server) kant binnen de keten voldaan worden |
||
==== Verklaring ==== |
==== Verklaring ==== |
||
TLSv1.3 en TLSv1.2 zijn de beste protocollen beschikbaar om communicatie tussen publieke http based webservices te beveiligen. SSLv2 en SSLv3 zijn al langere tijd niet meer veilig, echter zal dit ook [https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf niet lang meer duren] voor TLSv1.<br/> |
TLSv1.3 en TLSv1.2 zijn de beste protocollen beschikbaar om communicatie tussen publieke http based webservices te beveiligen. SSLv2 en SSLv3 zijn al langere tijd niet meer veilig, echter zal dit ook [https://www.pcisecuritystandards.org/documents/Migrating_from_SSL_Early_TLS_Information%20Supplement_v1.pdf niet lang meer duren] voor TLSv1.<br/> |
||
| − | De belangrijkste voordelen van TLSv1.2 en hoger boven TLSv1.1 zijn dat er in v1.2 een flink aantal [https://www.wolfssl.com/wolfSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html verbeteringen] zijn doorgevoerd in de hashing functies, de requirements binnen het protocol een stuk strakker zijn gemaakt en er een aantal sterke AES gebaseerde ciphers bij zijn gekomen die meteen gebruikt worden binnen de keten. |
+ | De belangrijkste voordelen van TLSv1.2 en hoger boven TLSv1.1 zijn dat er in v1.2 een flink aantal [https://www.wolfssl.com/wolfSSL/Blog/Entries/2010/10/7_Differences_between_SSL_and_TLS_Protocol_Versions.html verbeteringen] zijn doorgevoerd in de hashing functies, de requirements binnen het protocol een stuk strakker zijn gemaakt en er een aantal sterke AES gebaseerde ciphers bij zijn gekomen die meteen gebruikt worden binnen de keten. In TLS1.3 is daarnaast afscheid genomen van veel verouderde ciphers. Waar TLSv1.2 nog backward compatible is gehouden, is dit voor TLSv1.3 niet meer zo.<br/> |
Zowel de client als server moeten aan dezelfde TLS specificaties voldoen om te voorkomen dat een [https://nl.wikipedia.org/wiki/Man-in-the-middle-aanval Man in the Middle] aanval kan slagen door gebruik te maken van zwaktes aan een van beider zijden. |
Zowel de client als server moeten aan dezelfde TLS specificaties voldoen om te voorkomen dat een [https://nl.wikipedia.org/wiki/Man-in-the-middle-aanval Man in the Middle] aanval kan slagen door gebruik te maken van zwaktes aan een van beider zijden. |
||
==== Mogelijke oplossing ==== |
==== Mogelijke oplossing ==== |
||
'''Serverside''' |
'''Serverside''' |
||
| − | * De webserver staat in de configuratie van de webserver (bijvoorbeeld IIS of Apache) bij TLS alleen TLSv1.2 toe, waardoor clients andere versies nooit een verbinding kunnen opzetten |
+ | * De webserver staat in de configuratie van de webserver (bijvoorbeeld IIS of Apache) bij TLS alleen TLSv1.2 toe, waardoor clients met andere versies nooit een verbinding kunnen opzetten |
| − | * '''Legacy''': (OSO specifiek) De webserver filtert de TLS versie op de applicatielaag en staat voor de webservices alleen TLSv1.2 toe. Deze optie is de workaround en verdient niet de voorkeur. |
||
| − | |||
| − | '''Onderstaande geldt alleen voor systemen binnen de OSO keten''' <br/> |
||
| − | Een bronsysteem controleert bij een binnenkomende aanvraag (documentRequest), voordat de aanvraag wordt afgehandeld, op welk TLS-niveau wordt gecommuniceerd. Wanneer dit niet TLSv1.2 is (maar bijv. TLSv1 of TLSv1.1) dan mag er geen dossier worden uitgeleverd(!). |
||
| − | In plaats daarvan moet er een HTTP 400 fout worden terug gegeven en de volgende SOAP envelop: |
||
| − | <syntaxhighlight lang="xml" enclose="div"> |
||
| − | <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> |
||
| − | <soap:Body> |
||
| − | <soap:Fault> |
||
| − | <faultcode>soap:Server</faultcode> |
||
| − | <faultstring>TLS version not supported, use 'TLSv1.2'</faultstring> |
||
| − | </soap:Fault> |
||
| − | </soap:Body> |
||
| − | </soap:Envelope> |
||
| − | </syntaxhighlight> |
||
| − | Dit geeft de aanvragende partij voldoende informatie over het mislukken van de aanvraag om maatregelen te treffen en deze af te vangen voor de eindgebruiker. |
||
=== Ciphersuites en PFS === |
=== Ciphersuites en PFS === |
||
==== Eisen ==== |
==== Eisen ==== |
||
| − | + | Kennisnet ondersteunt alleen de volgende ciphersuites (IANA naamgeving): |
|
| + | # 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
||
| − | # 0x30 ECDHE-RSA-AES256-GCM-SHA384 |
||
| + | # 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
||
| − | # 0x2F ECDHE-RSA-AES128-GCM-SHA256 |
||
| + | # 0xC0,0x28 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 |
||
| − | # 0x28 ECDHE-RSA-AES256-SHA384 |
||
| + | # 0xC0,0x27 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 |
||
| − | # 0x27 ECDHE-RSA-AES128-SHA256 |
||
| + | # 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 |
||
<br/> |
<br/> |
||
| + | |||
| ⚫ | |||
| + | Kennisnet ondersteunt voor DHE '''alleen''' de voorgedefinieerde DHE groepen uit [https://tools.ietf.org/html/rfc7919 RFC 7919].<br/> |
||
| − | # 0x2C ECDHE-ECDSA-AES256-GCM-SHA384 |
||
| + | Als een systeem DHE hanteert moet deze ondersteuning bieden voor '''minimaal''' 2048bit DHE groepen. |
||
| − | # 0x2B ECDHE-ECDSA-AES128-GCM-SHA256 |
||
| + | |||
| − | # 0x2B ECDHE-ECDSA-CHACHA20-POLY1305 |
||
| ⚫ | |||
| − | # 0x13 ECDHE-RSA-CHACHA20-POLY1305 |
||
| − | # 0x24 ECDHE-ECDSA-AES256-SHA384 |
||
| − | # 0x23 ECDHE-ECDSA-AES128-SHA256 |
||
| − | <br/> |
||
| − | Keuze lijst: De volgende ciphersuites '''mogen''' ondersteund worden, maar wel met een opmerking: |
||
| − | # 0x9E DHE-RSA-AES128-GCM-SHA256 |
||
| − | # 0x6B DHE-RSA-AES256-SHA256 |
||
| − | # 0x67 DHE-RSA-AES128-SHA256 |
||
| − | <br/> |
||
| − | Opmerkingen bij DHE: |
||
| − | * '''Vereist''' zelf gegenereerde DH parameters |
||
| − | * '''Vereist''' DH sleutel lengte van tenminste 2048bit (gelijk aan RSA privé sleutel) |
||
| − | * Lange DH sleutels genereren een behoorlijke performance hit op de systemen die ze gebruiken. Wanneer sterke versleuteling vereist is zou ECDHE ingezet moeten worden. ECDHE is vele malen lichter in gebruik. |
||
| − | <br/> |
||
| − | Als alle bovenstaande ciphersuites worden toegepast '''moet''' onderstaande volgorde worden aangehouden: |
||
| − | # ECDHE-ECDSA-AES256-GCM-SHA384 |
||
| − | # ECDHE-RSA-AES256-GCM-SHA384 |
||
| − | # ECDHE-ECDSA-CHACHA20-POLY1305 |
||
| − | # ECDHE-RSA-CHACHA20-POLY1305 |
||
| − | # ECDHE-ECDSA-AES128-GCM-SHA256 |
||
| − | # ECDHE-RSA-AES128-GCM-SHA256 |
||
| − | # ECDHE-ECDSA-AES256-SHA384 |
||
| − | # ECDHE-RSA-AES256-SHA384 |
||
| − | # ECDHE-ECDSA-AES128-SHA256 |
||
| − | # ECDHE-RSA-AES128-SHA256 |
||
| − | # DHE-RSA-AES128-GCM-SHA256 |
||
| − | # DHE-RSA-AES256-SHA256 |
||
| − | # DHE-RSA-AES128-SHA256 |
||
| − | Mochten bepaalde ciphers uit de niet-verplichte lijsten niet gehanteerd worden, dan deze uit deze lijst verwijderen. |
||
| − | <br/> |
||
| ⚫ | |||
==== Verklaring ==== |
==== Verklaring ==== |
||
| − | + | Het gebruik van de in RFC 7919 voorgedefinieerde groepen heeft sterk de voorkeur boven eigen gegenereerde of "built in" ciphers zoals gedefinieerd in RFCs 2409, 3526, of 5114. Bijvoorbeeld Apache t/m 2.2 maakt hier gebruik van. Als eigen parameters niet zijn in te stellen, gebruik dan '''niet''' de DHE ciphers.<br/><br/> |
|
| − | + | Gebruik bij DHE groepen altijd een groep welke tenminste dezelfde lengte heeft als de RSA privésleutel die gebruikt wordt voor het certificaat. |
|
De ciphersuite lijst is gebaseerd op de [https://wiki.mozilla.org/Security/Server_Side_TLS aangeraden configuratie] van de Mozilla Foundation. Alleen de DSS gebaseerde ciphers zijn hier nog uit verwijderd aangezien deze inherent onveilig zijn (max 1024bit).<br/><br/> |
De ciphersuite lijst is gebaseerd op de [https://wiki.mozilla.org/Security/Server_Side_TLS aangeraden configuratie] van de Mozilla Foundation. Alleen de DSS gebaseerde ciphers zijn hier nog uit verwijderd aangezien deze inherent onveilig zijn (max 1024bit).<br/><br/> |
||
De ciphersuites welke zijn toegestaan of zelfs verplicht zijn, ondersteunen allen [https://nl.wikipedia.org/wiki/Perfect_forward_secrecy PFS]. Hierdoor zijn de verstuurde versleutelde datastromen ook in de toekomst nog veilig, ook al zou onverhoopt toch een keer ergens een privésleutel uitlekken. Het verschil tussen traditionele versleuteling en "vluchtige" (ephemeral) versleuteling is dat in plaats van 1 sleutel voor alle versleutelde communicatie (de RSA privésleutel), er per communicatiesessie er een nieuwe sleutel (middels [https://www.youtube.com/watch?v=YEBfamv-_do Diffie-Hellman]) wordt gegenereerd. Deze sleutel is alleen geldig zolang deze sessie duurt. Na het verlopen van deze sessie heeft zowel de client als de server de sleutel niet meer en zal eventueel opgeslagen data uit de datastroom vrijwel onmogelijk nog teruggehaald kunnen worden. Ephemeral ciphersuites zijn te herkennen aan de suffix E in ECDHE en DHE. |
De ciphersuites welke zijn toegestaan of zelfs verplicht zijn, ondersteunen allen [https://nl.wikipedia.org/wiki/Perfect_forward_secrecy PFS]. Hierdoor zijn de verstuurde versleutelde datastromen ook in de toekomst nog veilig, ook al zou onverhoopt toch een keer ergens een privésleutel uitlekken. Het verschil tussen traditionele versleuteling en "vluchtige" (ephemeral) versleuteling is dat in plaats van 1 sleutel voor alle versleutelde communicatie (de RSA privésleutel), er per communicatiesessie er een nieuwe sleutel (middels [https://www.youtube.com/watch?v=YEBfamv-_do Diffie-Hellman]) wordt gegenereerd. Deze sleutel is alleen geldig zolang deze sessie duurt. Na het verlopen van deze sessie heeft zowel de client als de server de sleutel niet meer en zal eventueel opgeslagen data uit de datastroom vrijwel onmogelijk nog teruggehaald kunnen worden. Ephemeral ciphersuites zijn te herkennen aan de suffix E in ECDHE en DHE. |
||
| Regel 104: | Regel 62: | ||
==== Mogelijke oplossing ==== |
==== Mogelijke oplossing ==== |
||
| ⚫ | |||
| − | Eigen DH parameters zijn bijvoorbeeld te genereren middels openssl. Een werkende oplossing: |
||
| − | openssl dhparam -out dhparams.pem 2048 |
||
| − | |||
| ⚫ | |||
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}" |
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}" |
||
Huidige versie van 21 jun 2021 om 11:46
Let op, deze voorschriften worden vervangen door de Uniforme Beveiligingsvoorschriften
HTTPS
Eisen
- Er moet gebruik gemaakt worden van HTTPS
- Er moet gebruik gemaakt worden van een Fully Qualified Domain Name
- Er moet gebruik gemaakt worden van TCP port 443
- Er mag geen gebruik gemaakt worden van redirects die vanaf http (port 80) redirecten naar https (port 443).
Verklaring
De verbindingen binnen de keten moeten van A tot Z beveiligd verlopen, hiervoor wordt HTTPS gebruikt. Om betrouwbaar te communiceren met partijen hebben deze een server certificaat nodig welke deze in de markt aanschaffen. Dit certificaat bevat de, of meerdere, domeinnaam of -namen. De betrouwbaarheid wordt vergroot door alleen gebruik te maken van volledige en traceerbare domeinnamen, Fully Qualified Domain Names (FQDN). HTTPS is door het IANA gestandaardiseerd op port 443, waar bij elke keten dan ook gebruik van wordt gemaakt. Hiervan mag om compatibiliteitsredenen niet afgeweken worden.
Er mag geen redirect beschikbaar zijn welke de webservice calls redirect vanaf port 80 naar port 443. Als er op dezelfde host zowel http als https beschikbaar is, moet er een foutmelding teruggegeven worden als er webservice calls op http binnenkomen.
400 Bad Request Plain text http not supported, use https.
De reden hiervoor is dat een call over http direct al payload bevat waar datalekken risicovol kunnen zijn. Om te voorkomen dat verkeerd geconfigureerde clients toch kunnen doorgaan met het gebruik maken van deze onveilige redirect functie, mag er helemaal geen redirect gedaan worden. De client is hierdoor gedwongen zijn configuratie aan te passen.
HSTS
Eisen
- Het gebruik van de HSTS HTTP header is niet verplicht
- De maatregelen die door HSTS worden voorgeschreven, worden al expliciet vereist in andere delen van het de eisen
Verklaring
HSTS wordt alleen gebruikt door webbrowsers, waardoor verplichte implementatie en validatie niet het gewenste effect zal opleveren. Echter, de meeste eisen die HSTS oplegt worden al door het PvE afgedekt.
TLS
Versie
Eisen
- TLSv1.2 moet ondersteund worden. TLSv1.3 mag ondersteund worden
- Lagere TLS versies mogen niet ondersteund worden
- Aan deze eis moet aan zowel de vragende (client) als wel de leverende (server) kant binnen de keten voldaan worden
Verklaring
TLSv1.3 en TLSv1.2 zijn de beste protocollen beschikbaar om communicatie tussen publieke http based webservices te beveiligen. SSLv2 en SSLv3 zijn al langere tijd niet meer veilig, echter zal dit ook niet lang meer duren voor TLSv1.
De belangrijkste voordelen van TLSv1.2 en hoger boven TLSv1.1 zijn dat er in v1.2 een flink aantal verbeteringen zijn doorgevoerd in de hashing functies, de requirements binnen het protocol een stuk strakker zijn gemaakt en er een aantal sterke AES gebaseerde ciphers bij zijn gekomen die meteen gebruikt worden binnen de keten. In TLS1.3 is daarnaast afscheid genomen van veel verouderde ciphers. Waar TLSv1.2 nog backward compatible is gehouden, is dit voor TLSv1.3 niet meer zo.
Zowel de client als server moeten aan dezelfde TLS specificaties voldoen om te voorkomen dat een Man in the Middle aanval kan slagen door gebruik te maken van zwaktes aan een van beider zijden.
Mogelijke oplossing
Serverside
- De webserver staat in de configuratie van de webserver (bijvoorbeeld IIS of Apache) bij TLS alleen TLSv1.2 toe, waardoor clients met andere versies nooit een verbinding kunnen opzetten
Ciphersuites en PFS
Eisen
Kennisnet ondersteunt alleen de volgende ciphersuites (IANA naamgeving):
- 0xC0,0x30 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- 0xC0,0x2F TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- 0xC0,0x28 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- 0xC0,0x27 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
- 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Kennisnet ondersteunt voor DHE alleen de voorgedefinieerde DHE groepen uit RFC 7919.
Als een systeem DHE hanteert moet deze ondersteuning bieden voor minimaal 2048bit DHE groepen.
Ciphersuites welke niet genoemd zijn mogen niet gebruikt worden.
Verklaring
Het gebruik van de in RFC 7919 voorgedefinieerde groepen heeft sterk de voorkeur boven eigen gegenereerde of "built in" ciphers zoals gedefinieerd in RFCs 2409, 3526, of 5114. Bijvoorbeeld Apache t/m 2.2 maakt hier gebruik van. Als eigen parameters niet zijn in te stellen, gebruik dan niet de DHE ciphers.
Gebruik bij DHE groepen altijd een groep welke tenminste dezelfde lengte heeft als de RSA privésleutel die gebruikt wordt voor het certificaat.
De ciphersuite lijst is gebaseerd op de aangeraden configuratie van de Mozilla Foundation. Alleen de DSS gebaseerde ciphers zijn hier nog uit verwijderd aangezien deze inherent onveilig zijn (max 1024bit).
De ciphersuites welke zijn toegestaan of zelfs verplicht zijn, ondersteunen allen PFS. Hierdoor zijn de verstuurde versleutelde datastromen ook in de toekomst nog veilig, ook al zou onverhoopt toch een keer ergens een privésleutel uitlekken. Het verschil tussen traditionele versleuteling en "vluchtige" (ephemeral) versleuteling is dat in plaats van 1 sleutel voor alle versleutelde communicatie (de RSA privésleutel), er per communicatiesessie er een nieuwe sleutel (middels Diffie-Hellman) wordt gegenereerd. Deze sleutel is alleen geldig zolang deze sessie duurt. Na het verlopen van deze sessie heeft zowel de client als de server de sleutel niet meer en zal eventueel opgeslagen data uit de datastroom vrijwel onmogelijk nog teruggehaald kunnen worden. Ephemeral ciphersuites zijn te herkennen aan de suffix E in ECDHE en DHE.
Ciphers die niet op de toegestane lijst staan mogen niet gebruikt worden. Legacy ciphers waarbij gebruik gemaakt wordt van bijvoorbeeld RC4 of 3DES zijn onveilig en als vanzelfsprekend niet toegestaan te gebruiken. Lees meer over de problemen met RC4 en 3DES op respectievelijk in CVE-2015-2808 en in CVE-2016-2183
Mogelijke oplossing
In Apache 2.4.8 en nieuwer kunnen DHE parameters worden ingeladen.
SSLOpenSSLConfCmd DHParameters "{path to dhparams.pem}"
In sommige oudere versies van Apache kan ook de inhoud van dhparams.pem toegevoegd worden onderaan in het certificaat bestaand (appenden).
Lees meer voorbeelden op de deployment guide
Cipher volgorde
Eisen
- De server moet de cipher order bepalen
- De sterkste ciphersuite moet bovenaan de keuzelijst staan, aflopend naar de 'zwakste' onderaan de lijst
Verklaring
De server in een communicatieproces bepaalt uiteindelijk hoe sterk de versleuteling van de verbinding met de client wordt. De server wijst eventueel zelfs de verbinding met de client af als er geen sterke versleuteling tussen beide overeengekomen kan worden. De server moet dan ook garant staan voor de sterkst mogelijke configuratie die binnen de keten nodig wordt geacht.
De server heeft een statische lijst met cipher suites die worden toegestaan en bepaalt hoe deze lijst in onderhandeling met de client wordt afgelopen. De sterkste match tussen server en client moet gekozen worden.
Binnen de keten worden alleen sterke ciphers toegestaan, echter is er ook nog een performance verschil tussen verschillende suites. Dit heeft voor zowel client als server impact, dus ook hier heeft de server, in opvolging van de eisen, invloed op de keuze van de snelste ciphers.
Mogelijke oplossing
In Apache kan de cipher volgorde geforceerd worden middels
SSLHonorCipherOrder on
In IIS kan dit geregeld worden zoals beschreven in deze guide
Renegotiation
Eisen
- Secure renegotiation moet worden ondersteund
- Insecure client-renegotiation mag niet ondersteund worden
- Secure client-renegotiation mag niet ondersteund worden
Verklaring
Heronderhandeling over de TLS parameters mag nooit geïnitieerd worden vanuit de client, alleen vanuit de server. De server bepaalt of en zo ja wanneer dit moet gebeuren.
Compression
Eisen
- TLS compression moet uitgeschakeld zijn op de server en aan de client kant
Verklaring
In de meeste TLS modules is dit inmiddels functioneel al uitgeschakeld en daardoor onmogelijk te gebruiken. Mits dit toch bruikbaar is, is het voor een aanvaller mogelijk om achter geheime informatie te komen die versleuteld is in het berichten verkeer. De precieze werking gaat te diep voor deze wiki, maar is hier terug te lezen.
Sessie hervatting
Eisen
- Sessie hervatting mag ondersteund worden
- Sessie hervatting kan extra risico's met zich meebrengen, gebruik het alleen als bewuste keuze!
Verklaring
Sessie hervatting heeft als doel een stuk van de TLS handshake over te slaan omdat de sessieparameters aan zowel client als server kant in cache gehouden worden. Verbindingen tussen client en server die veelvuldig geopend en gesloten worden hebben hiermee een performance voordeel. Er dient wel rekening gehouden te worden met cachingtijden en de opslag van deze cache. Op het moment dat de sessie opgeslagen wordt, worden tijdelijke sleutels welke alleen gedurende de lifetime van de sessie bestaan toch gepersisteerd. Hierdoor is het mogelijk dat een derde deze cache op de server of zelfs een shared storage systeem kan uitlezen. Sessiesleutels kunnen hierdoor dan ook alsnog gecompromitteerd worden. Het veiligst doch traagst is het volledig uitschakelen van sessie hervatting.
ServerNameIndication
Eisen
- ServerNameIndication (SNI) moet door elk systeem dat acteert als client geïmplementeerd zijn
- ServerNameIndication (SNI) mag door elk systeem dat acteert als server geïmplementeerd zijn
Verklaring
Een SSL certificaat wordt geïnstalleerd om een http verbinding te beveiligen. Hierbij wordt de volledige verbinding versleuteld op sessie niveau. Dit vindt plaats nog voordat er middels HTTP uitgewisseld is om welke hostname het gaat. Hierdoor is het voor de webserver onmogelijk om te bepalen voor welke domein het certificaat opgevraagd wordt. De webserver geeft het standaard certificaat of zelfs helemaal geen certificaat terug.
SNI zorgt ervoor dat op sessie niveau, tijdens het opzetten van de versleutelde verbinding, al een extensie wordt meegestuurd met de hostname erin. TLS kan hierdoor bepalen voor welk certificaat een client de verbinding opzet en het juiste certificaat mee terugsturen.
Dit ziet er als hiernaast uit: 
Elke client moet dit binnen de keten ondersteunen omdat er reeds leveranciers zijn die server-side SNI nodig hebben om het juiste certificaat te kunnen retourneren aan de client.
Ter illustratie schematisch weergegeven hoe de communicatiestroom er met en zonder SNI uitziet:
Zonder SNI:
Met SNI:
Weblinks over SNI-configuratie
- Artikel over het configureren van SNI op IIS 8 (Windows Server 2012)
- Artikel over het configureren van SNI op Apache2.x
Certificate Authorities (issuers)
Eisen
- In de TLS handshake fase is het wenselijk dat de server naar client een lijst met geaccepteerde CA's (issuers) teruggeeft
Verklaring
Het is in een communicatieproces wenselijk dat een server richting een client aangeeft wat er van deze wordt verwacht. Binnen TLS bestaat er in de handshake procedure de mogelijkheid de client middels het 'certificate_authorities' veld mee te geven welke certificaat leveranciers geaccepteerd worden als uitgever van het client certificaat. Een client kan hierdoor automatisch in de keystore het gewenste certificaat selecteren of juist vroegtijdig constateren dat het niet over een certificaat beschikt wat de server accepteert. Het veld is echter niet verplicht binnen TLS en zo ook niet voor de partijen binnen de keten.
Wanneer het veld gevoerd wordt door een server, moet het zich houden aan de lijst van leveranciers.
Kennisnet voert voor de keten webservices zelf altijd het 'certificate_authorities' veld in de handshake.
Fallback SCSV (protocol downgrade attack prevention)
Eisen
- Fallback SCSV wordt niet vereist
Verklaring
Het gebruik van Fallback SCSV is nuttig als er TLS protocol versie downgrades mogelijk zijn naar bijvoorbeeld TLSv1 of SSLv3. Binnen de keten is dit echter niet het geval. Alleen TLSv1.2 wordt toegestaan.
Public key pinning
Eisen
- Public key pinning wordt niet ondersteund / vereist
Verklaring
Public key pinning (Public key pinning / Linux Implementatie) wordt niet ondersteund.