Standaarden:Beveiligd Gegevenstransport/protocollen

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

• Alleen TLS versie 1.2 mag worden toegestaan
• Aan deze eis moet aan zowel de vragende (client) als wel de leverende (server) kant binnen de keten voldaan worden

Verklaring

TLSv1.2 is het beste protocol 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 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.
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 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
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:

<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>

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

Eisen

Verplichte lijst: De volgende ciphersuites moeten ondersteund worden:

1. 0x30 ECDHE-RSA-AES256-GCM-SHA384
2. 0x2F ECDHE-RSA-AES128-GCM-SHA256
3. 0x28 ECDHE-RSA-AES256-SHA384
4. 0x27 ECDHE-RSA-AES128-SHA256

Keuze lijst: De volgende ciphersuites mogen ondersteund worden:

1. 0x2C ECDHE-ECDSA-AES256-GCM-SHA384
2. 0x2B ECDHE-ECDSA-AES128-GCM-SHA256
3. 0x2B ECDHE-ECDSA-CHACHA20-POLY1305
4. 0x13 ECDHE-RSA-CHACHA20-POLY1305
5. 0x24 ECDHE-ECDSA-AES256-SHA384
6. 0x23 ECDHE-ECDSA-AES128-SHA256

Keuze lijst: De volgende ciphersuites mogen ondersteund worden, maar wel met een opmerking:

1. 0x9E DHE-RSA-AES128-GCM-SHA256
2. 0x6B DHE-RSA-AES256-SHA256
3. 0x67 DHE-RSA-AES128-SHA256

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.

Als alle bovenstaande ciphersuites worden toegepast moet onderstaande volgorde worden aangehouden:

1. ECDHE-ECDSA-AES256-GCM-SHA384
2. ECDHE-RSA-AES256-GCM-SHA384
3. ECDHE-ECDSA-CHACHA20-POLY1305
4. ECDHE-RSA-CHACHA20-POLY1305
5. ECDHE-ECDSA-AES128-GCM-SHA256
6. ECDHE-RSA-AES128-GCM-SHA256
7. ECDHE-ECDSA-AES256-SHA384
8. ECDHE-RSA-AES256-SHA384
9. ECDHE-ECDSA-AES128-SHA256
10. ECDHE-RSA-AES128-SHA256
11. DHE-RSA-AES128-GCM-SHA256
12. DHE-RSA-AES256-SHA256
13. DHE-RSA-AES128-SHA256

Mochten bepaalde ciphers uit de niet-verplichte lijsten niet gehanteerd worden, dan deze uit deze lijst verwijderen.
Ciphersuites welke niet genoemd zijn mogen niet gebruikt worden door zowel client als server.

Verklaring

Genereer altijd eigen Diffie-Hellman parameters! Gebruik niet de standaard parameters zoals deze zijn 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.

Genereer altijd een DH sleutel 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

Eigen DH parameters zijn bijvoorbeeld te genereren middels openssl. Een werkende oplossing:

 openssl dhparam -out dhparams.pem 2048

In Apache 2.4.8 en nieuwer kan vervolgens de file 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.