OSO:2017/beveiliging/protocollen: verschil tussen versies
< OSO:2017 | beveiliging
Naar navigatie springen
Naar zoeken springen
(Nieuwe pagina aangemaakt met '== HTTPS == ==== Eisen ==== * Er '''moet''' gebruik gemaakt worden van HTTPS * Er '''moet''' gebruik gemaakt worden van een Fully Qualified Domain Name * Er '''moet...') |
(De pagina is leeggehaald) |
||
| (6 tussenliggende versies door 2 gebruikers niet weergegeven) | |||
| Regel 1: | Regel 1: | ||
| − | == 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.<br/> |
||
| − | 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 [https://nl.wikipedia.org/wiki/HTTP_Strict_Transport_Security 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 [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 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 OSO.<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. |
||
| − | |||
| − | ==== 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.'''<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 === |
||
| − | ==== 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 |
||
| − | # 0x13 ECDHE-RSA-AES128-SHA |
||
| − | # 0x28 ECDHE-RSA-AES256-SHA384 |
||
| − | # 0x14 ECDHE-RSA-AES256-SHA |
||
| − | <br/> |
||
| − | Keuze lijst: De volgende ciphersuites '''mogen''' ondersteund worden: |
||
| − | # 0x2B ECDHE-ECDSA-AES128-GCM-SHA256 |
||
| − | # 0x2C ECDHE-ECDSA-AES256-GCM-SHA384 |
||
| − | # 0x23 ECDHE-ECDSA-AES128-SHA256 |
||
| − | # 0x09 ECDHE-ECDSA-AES128-SHA |
||
| − | # 0x24 ECDHE-ECDSA-AES128-SHA256 |
||
| − | # 0x0A ECDHE-ECDSA-AES256-SHA |
||
| − | <br/> |
||
| − | Keuze lijst: De volgende ciphersuites '''mogen''' ondersteund worden, maar wel met een opmerking: |
||
| − | # 0x9E DHE-RSA-AES128-GCM-SHA256 |
||
| − | # 0x67 DHE-RSA-AES128-SHA256 |
||
| − | # 0x33 DHE-RSA-AES128-SHA |
||
| − | # 0x6B DHE-RSA-AES256-SHA256 |
||
| − | # 0x39 DHE-RSA-AES256-SHA |
||
| − | <br/> |
||
| − | Opmerkingen bij DHE: |
||
| − | * '''Vereist''' zelf gegenereerde DH parameters |
||
| − | * '''Vereist''' DH sleutel lengte van tenminste 2048bit (gelijk aan RSA privé sleutel) |
||
| − | <br/> |
||
| − | Als alle bovenstaande ciphersuites worden toegepast '''moet''' onderstaande volgorde worden aangehouden: |
||
| − | # ECDHE-RSA-AES128-GCM-SHA256 |
||
| − | # ECDHE-ECDSA-AES128-GCM-SHA256 |
||
| − | # ECDHE-RSA-AES256-GCM-SHA384 |
||
| − | # ECDHE-ECDSA-AES256-GCM-SHA384 |
||
| − | # DHE-RSA-AES128-GCM-SHA256 |
||
| − | # ECDHE-RSA-AES128-SHA256 |
||
| − | # ECDHE-ECDSA-AES128-SHA256 |
||
| − | # ECDHE-RSA-AES128-SHA |
||
| − | # ECDHE-ECDSA-AES128-SHA |
||
| − | # ECDHE-RSA-AES256-SHA384 |
||
| − | # ECDHE-ECDSA-AES256-SHA384 |
||
| − | # ECDHE-RSA-AES256-SHA |
||
| − | # ECDHE-ECDSA-AES256-SHA |
||
| − | # DHE-RSA-AES128-SHA256 |
||
| − | # DHE-RSA-AES128-SHA |
||
| − | # DHE-RSA-AES256-SHA256 |
||
| − | # DHE-RSA-AES256-SHA |
||
| − | Mochten bepaalde ciphers uit de niet-verplichte lijsten niet gehanteerd worden, dan deze uit deze lijst verwijderen. |
||
| − | <br/> |
||
| − | 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.<br/><br/> |
||
| − | 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 [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. |
||
| − | |||
| − | '''Toevoeging 17-11-2016''' |
||
| − | Legacy ciphers waarbij gebruik gemaakt wordt van RC4 of 3DES zijn onveilig en als vanzelfsprekend niet toegestaan te gebruiken. Lees meer over de problemen met RC4 en 3DES op respectievelijk in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2808 CVE-2015-2808] en in [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2183 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).<br/> |
||
| − | Lees meer voorbeelden op de [https://weakdh.org/sysadmin.html 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. <br/> |
||
| − | 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 [http://www.howtogeek.com/221080/how-to-update-your-windows-server-cipher-suite-for-better-security/ 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 [http://security.stackexchange.com/questions/19911/crime-how-to-beat-the-beast-successor 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. <br /> |
||
| − | 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.<br/> |
||
| − | Dit ziet er als hiernaast uit: [[Bestand:Tls-sni.png]]<br/> |
||
| − | 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. |
||
| − | <br/> |
||
| − | Ter illustratie schematisch weergegeven hoe de communicatiestroom er met en zonder SNI uitziet: |
||
| − | <br/>'''Zonder''' SNI: |
||
| − | [[Bestand:Client-server-wo-sni.png]]<br/> |
||
| − | <br/>'''Met''' SNI: |
||
| − | [[Bestand:Client-server-sni.png]]<br/> |
||
| − | Weblinks over SNI-configuratie |
||
| − | * [http://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx Artikel over het configureren van SNI op IIS 8 (Windows Server 2012)] |
||
| − | * [https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI Artikel over het configureren van SNI op Apache2.x] |
||
| − | |||
| − | === Certificate Authorities (issuers) === |
||
| − | ''Aanvulling naar aanleiding van een maildiscussie over de kwalificatie procedure, juli 2016'' |
||
| − | ==== 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 [[OSO:2017/beveiliging/client_certificaten#Leverancier_van_certificaten|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 [https://wiki.openssl.org/index.php/SSL_MODE_SEND_FALLBACK_SCSV 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 ([https://timtaubert.de/blog/2014/10/http-public-key-pinning-explained/ Public key pinning] / [https://bjornjohansen.no/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. |
||
| − | |||
| − | [[Categorie:Overstapservice Onderwijs]] |
||
| − | [[Category:Book OSO|841]] |
||