OSO:2017/beveiliging/protocollen
Overstapservice Onderwijs: 2017/beveiliging/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 OSO 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 OSO 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 OSO 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 binnen OSO expliciet vereist in andere delen van het PvE
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 OSO 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 OSO.
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
- De webserver filtert de TLS versie op de applicatielaag en staat voor de OSO webservices alleen TLSv1.2 toe. Deze optie is de workaround en verdient niet de voorkeur.
De 'workaround variant' heeft wat uitleg nodig.
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:
- 0x2F ECDHE-RSA-AES128-GCM-SHA256
- 0x30 ECDHE-RSA-AES256-GCM-SHA384
- 0x27 ECDHE-RSA-AES128-SHA256
- 0x28 ECDHE-RSA-AES256-SHA384
Keuze lijst: De volgende ciphersuites mogen ondersteund worden:
- 0x2B ECDHE-ECDSA-AES128-GCM-SHA256
- 0x2C ECDHE-ECDSA-AES256-GCM-SHA384
- 0x13 ECDHE-RSA-CHACHA20-POLY1305
- 0x2B ECDHE-ECDSA-CHACHA20-POLY1305
- 0x23 ECDHE-ECDSA-AES128-SHA256
- 0x24 ECDHE-ECDSA-AES128-SHA256
Keuze lijst: De volgende ciphersuites mogen ondersteund worden, maar wel met een opmerking:
- 0x9E DHE-RSA-AES128-GCM-SHA256
- 0x67 DHE-RSA-AES128-SHA256
- 0x6B DHE-RSA-AES256-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:
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-GCM-SHA256
- ECDHE-RSA-CHACHA20-POLY1305
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-ECDSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-SHA256
- ECDHE-ECDSA-AES128-SHA256
- ECDHE-RSA-AES256-SHA384
- ECDHE-ECDSA-AES256-SHA384
- ECDHE-ECDSA-AES256-SHA
- DHE-RSA-AES128-GCM-SHA256
- DHE-RSA-AES128-SHA256
- DHE-RSA-AES256-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 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
Wijziging ten opzichte van OSO'16
Toegevoegde ciphers:
- Optioneel: ECDHE-RSA-CHACHA20-POLY1305
- Optioneel: ECDHE-ECDSA-CHACHA20-POLY1305
Een nieuwe cipher is CHACHA20-POLY1305. De reden om deze toe te voegen is omdat niet alle hardware (goede) AES-NI ondersteuning heeft. Het gebruik van AES gebaseerde ciphers kan hierdoor voor systemen zwaarder zijn dan noodzakelijk. De cipher CHACHA20-POLY1305 biedt hierbij uitkomst door geen specifieke hardware ondersteuning te vereisen, maar wel veel lichter (en dus sneller) te zijn. Wanneer een server CHACHA20-POLY1305 aanbiedt naast de AES gebaseerde ciphers, kan een client besluiten om CHACHA20-POLY1305 te gebruiken omdat deze hem performancewinst oplevert.
Qua beveiliging doen CHACHA20 en AES niet voor elkaar onder. Beide cipher typen zullen ook hun weg vinden richting TLS1.3 waardoor deze toekomstvast zijn.
Ondersteuning binnen OSO is nog optioneel omdat niet alle TLS implementaties de cipher ondersteunen.
Verwijderde ciphers:
- ECDHE-RSA-AES128-SHA
- ECDHE-RSA-AES256-SHA
- ECDHE-ECDSA-AES128-SHA
- ECDHE-ECDSA-AES256-SHA
- DHE-RSA-AES128-SHA
- DHE-RSA-AES256-SHA
Alle ciphers die gebruik maken van een SHA1 signature zijn verwijderd.
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 OSO 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 OSO 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 OSO 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 OSO 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 OSO.
Wanneer het veld gevoerd wordt door een server, moet het zich houden aan de lijst van leveranciers.
Het Traffic-center voert wel altijd het 'certificate_authorities' veld in de handshake.
Fallback SCSV (protocol downgrade attack prevention)
Eisen
- Fallback SCSV wordt niet geïmplementeerd
Verklaring
Het gebruik van Fallback SCSV is nuttig als er TLS protocol versie downgrades mogelijk zijn naar bijvoorbeeld TLSv1 of SSLv3. Binnen OSO is dit echter niet het geval. Alleen TLSv1.2 wordt toegestaan.
Public key pinning
Eisen
- Public key pinning wordt niet ondersteund
Verklaring
Public key pinning (Public key pinning / Linux Implementatie) is nog experimenteel en wordt voornamelijk door een aantal browsers ondersteund. Het zal in de toekomst mogelijk wel een eis gaan worden als ook andere software bibliotheken de pinning controle gaan uitvoeren.