Api.kadaster.nl geeft foutmelding: secure renegotiation

Na een lokale upgrade van Ubuntu 20.04 naar 22.04 loop ik tegen het probleem aan dat het niet meer mogelijk is om met de terugmeldingen API te communiceren.

Het loopt vast op de foutmelding error:0A000152:SSL routines::unsafe legacy renegotiation disabled

Dit blijkt te maken te hebben met de lokale OpenSSL library die inmiddels bijgewerkt is van 1.x naar 3.x waarin dit standaard niet meer veilig wordt geacht.

Als ik via SSLLabs of internet.nl kijk zie ik dat api server daar idd geen ondersteuning voor heeft.

Als workaround kan ik in openssl.cnf Options = UnsafeLegacyRenegotiation opnemen, maar dat zou niet nodig moeten zijn.

Kunnen jullie de webserver zo configureren zodat dat geen probleem meer is zonder lokale workarounds?

Alvast bedankt!

Vervelend! Ik zal er naar (laten) kijken om te zien wat hier aan gedaan kan worden.

Hoi Jan-Willem,

Hetzelfde lijkt het geval met de DKK API:

ERROR HTTPSConnectionPool(host=‘downloads.pdok.nl’, port=443): Max retries exceeded with url: /kadastralekaart/api/v4_0/full/custom (Caused by SSLError(SSLError(1, ‘[SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED] unsafe legacy renegotiation disabled (_ssl.c:1129)’)))

is dit vergelijkbaar? Waar ligt de fout precies? Aan onze kant of aan die van het Kadaster?

groeten,
Jelle Stuurman

Hey Sander en Jelle,

Dit lijkt een generiek probleem aan Kadasterzijde: op 5 december vindt er een upgrade naar TLS 1.3 plaats. Vanaf dan zou dit probleem zich niet meer moeten voordoen.

Nog even geduld dus en bedankt voor het melden!

1 like

@JWSjoukema
Dank voor het uitzoeken Jan-Willem.

Kun je aangeven of / wanneer update is doorgevoerd? Ik krijg in ieder geval de foutmelding nog steeds.

Hoi Jelle,

Ik ben het even nagegaan, maar ik heb helaas minder mooi nieuws. Deze upgrade is niet gelukt en uitgesteld. De verwachting is dat deze medio januari wel uitgevoerd gaat worden, maar dat duurt dus nog even. Tot die tijd moet er dus toch nog even met workarounds gewerkt worden.

Groet,

Jaap-Willem

Hoi Jan-Willem,

Dank voor je reactie en wederom navragen.

Ik hoor het graag van je wanneer de upgrade is uitgevoerd.

groeten,
Jelle

@SanderH Ik kreeg te horen dat de migratie naar TLS 1.3. voor het api.kadaster.nl endpoint is gelukt. Als het goed is zou dit endpoint nu dus ook zonder workaround te benaderen zijn. Ik hoor graag of dit het geval is.

Downloads.pdok.nl is nog niet over. Als deze zover is, zullen we het laten weten!

@JWSjoukema

De sites van SSLLabs en internet.nl opnieuw laten scannen en die geven aan dat het nog niet is opgelost:
image
image

Toch nog even de workaround verwijderd (je weet tenslotte maar nooit) maar helaas:
2023/01/03 19:41:23 [error] 1488#1488: *636 SSL_do_handshake() failed (SSL: error:0A000152:SSL routines::unsafe legacy renegotiation disabled) while SSL handshaking to upstream

Blijkbaar moet er nog iets extra’s gedaan worden om het goed te krijgen


Hmm dat is jammer

Dank voor het uitproberen @SanderH ! Het viel me ook dat de scanners inderdaad alsnog dit als fout rapporteerden


Ik ga er weer achteraan!

@SanderH Ik heb weer met de technische mannen geschakeld. Zij vermoeden doordat wij ook nog oude TLS versies zoals 1.2 ondersteunen met insecure renegotiation, dat dit probleem nog steeds optreed en scanners dit nog steeds niet ‘oke’ vinden.

Mogelijk dat dit probleem opgelost kan worden met een iets nettere workaround aan jouw kant, namelijk in jouw applicatie afdwingen dat er altijd minimaal via TLS 1.3 wordt gesproken. Bijvoorbeeld met de OpenSLL instelling: SSL_CTX_set_min_proto_version(TLS1_3_VERSION)

Laat maar weten of je dit eenvoudig kan proberen en zo ja, of dit dan inderdaad een oplossing is. Anders kijken we weer even verder.

@JWSjoukema
Goeie tip, maar het is me nog te vroeg om TLS 1.2 geheel te sluiten.
Heb nu in m’n reverse proxy configuratie afgedwongen dat enkel TLS 1.3 gebruikt wordt:
proxy_ssl_protocols TLSv1.3;
En dat werkt zowaar, dus daarmee is het probleem voor mij nu netjes genoeg opgelost.

1 like

Goed om te horen! Fijn dat dat een oplossing is!

Ik liep tegen dezelfde foutmelding aan op mijn.kadaster.nl t.b.v. BAG download, vanuit Python3 onder Ubuntu 22.04. curl -v https://mijn.kadaster.nl geeft dezelfde melding, bijv
SSL: UNSAFE_LEGACY_RENEGOTIATION_DISABLED].

Dit Ubuntu Bug Report geeft uitleg en workaround. Uitleg:

the root issue is that the server is using an outdated, insecure protocol that has been deemed so for more than a decade, and OpenSSL finally decided to disable it by default. The “proper” way to fix this would be for them to upgrade
. Dus Kadaster-servers zouden moeten upgraden. Is bekend, zie boven.

De workaround die ik in bovenstaand bug report vond is een wijziging in de laatste regel van /usr/lib/ssl/openssl.cnf. Namelijk:

[system_default_sect]
CipherString = DEFAULT:@SECLEVEL=2

moet worden:

[system_default_sect]
Options = UnsafeLegacyRenegotiation

Oftewel:

sed -i 's/CipherString = DEFAULT:@SECLEVEL=2/Options = UnsafeLegacyRenegotiation/g' /usr/lib/ssl/openssl.cnf

Dan werkt het ook in Python, met bijv requests package.
Disclaimer: ik gebruik dit in een dedicated Docker image voor BAG Download die maar even draait. Ik kan niet inschatten wat dit in een reguliere Ubuntu server, qua veiligheid, doet.

1 like

Dank voor het delen van je workaround @Just_OSGeo !

Ik heb nog het e.e.a. nagevraagd omdat het niet echt lekker voelt als alle gebruikers ‘UnsafeLegacyRenegotiation’ moeten opvoeren in hun applicatie.

Nu komt de plottwist: Het Kadaster netwerk ondersteunt helemaal geen ‘renegotiation’, zowel insecure niet als secure. Uit beveilingingsoverwegingen en technische beperkingen is dit voor alle domeinen uitgezet. De reden waarom tools en scanners hier wel op afgaan, is omdat ze geen ‘secure renegotiation’ kunnen vinden en dan de aanname doen dat dit dan ‘insecure’ gebeurt.

Gebruikers zijn bij ons (=Kadaster) niet kwetsbaar als ze ‘UnsafeLegacyRenegotiation’ toepassen binnen hun applicatie, maar als diezelfde applicatie ook gebruikt wordt bij andere aanbieders kan je inderdaad kwetsbaar zijn.

TLS1.3 heeft renegotiation er helemaal uitgegooid, vandaar dat het via TLS 1.3 “gewoon” werkt. De beste oplossing is dan ook om alleen (of minimaal) met 1.3 te verbinden indien mogelijk. Wanneer we TLS 1.2 niet meer ondersteunen, dan zal deze workaround niet meer nodig zijn.

Hoi Jan-Willem,

Ik volg het nog niet helemaal. Ik krijg de foutmelding in ieder geval nog wel via download.pdok.nl. Moet deze nog aanepast worden of is het niet maar van toepassing?

groeten,
Jelle