Omdat bg0204-berichten veelal vertrouwelijke informatie bevatten lijkt het zeer wenselijk om het gebruik van https (dat is http inclusief encryptie en betrouwbare identificatie) verplicht voor te schrijven. Bovendien voorkomt dit veel integratieproblemen. Als de ene partij wel met SSL/TLS werkt en ander niet dan kunnen ze niet koppelen. Zie ook de discussie "https versus http" op het StUF 3 forum en de discussie "HTTPS verplicht maken voor StUF-EF?" op het StUF-EF forum.
ma, 15-03-2010 - 11.09u
#1
https voor bg0204
Ik heb er problemen mee als https verplicht wordt gemaakt voor StUF-bg 02.04. Centric heeft ongeveer 220 klanten in productie met StUF-bg 02.04 http. Bij verplichting zadelen we deze klanten op met een implementatietraject van https. Wat ook weer kosten voor de klant met zich meebrengt.
Centric applicaties kunnen ondertussen ook StUF-bg https communiceren. Incidenteel kunnen we dit dan implementeren bij klanten de het nodig hebben omdat ze bijvoorbeeld moeten aansluiten op de gegevensmakelaar van Pink Roccade. Betekent dat de implementatieproblemen voorbij zijn.
Centric is wel voornemens om voor StUF-bg 03.10 alleen https te ondersteunen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0115.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Technisch gezien zie ik geen problemen bij HTTPS in plaats van HTTP. Wel voordelen en nadelen.
Keuze lijkt me primair aan de gebruiker, omdat de keuze samenhangt met beveiligingsbeleid maar ook met performance, systeembelasting, inrichtingskosten en (jaarlijkse) onderhoudskosten.
Kortom: keuze niet vastleggen in de standaard, maar de keuze wel beperken tussen HTTP en HTTPS.
Ik ben het eens met Han. Ondersteuning van zowel HTTPS als HTTP voor alle StUF-berichten. Maar dan ook eisen stellen aan TLS en cyphers. Vraag is alleen hoe je dit soort snel muterende veiligheidsinstellingen borgt in een standaard.
Ik ben het eens met Erik en Han. HTTPS valt onder transport security. Buiten StUF standaard houden. Als de gegevens via HTTPS worden ontsloten, bijvoorbeeld een eis ivm hoge data classificatie, zal afnemer (gebruiker) HTTPS moeten gebruiken. In mijn optiek moet gebruiker beide ondersteunen. En als je HTTPS gebruikt zal zowel aanbieder als gebruiker mee moeten met snel muterende eisen mbt TLS en cyphers die wereldwijd, meestal veroorzaakt door een security incident en opgelost via patches en beperken cyphers. Evenzo zal de gebruiker 2-way SSL moeten ondersteunen als de aanbieder daar om vraagt. Voor zover ik weet ondersteunen leveranciers dit ook.
Tijdens de StUF Expertgroep van 21 september 2016 heeft de StUF Expertgroep geconcludeerd dat deze RFC inmiddels achterhaald is. Er is daarom besloten dit RFC af te voeren.