@
dingo35 Het is niet dat Joulo zijn servers moet herconfigureren. Gebruikmaken van SNI is niet vreemd en het probleem ligt elders.
Ik heb even met claude een heen-en-weer gehad. Goed nieuws: er is een fix mogelijk in de smartEVSE repo zonder changes of forks in upstream repo's. Deze fix zou ook een beveiligingsgat dichten, omdat er dan echte TLS cert verificatie plaatsvindt. Nu is het nog kwetsbaar voor MITM. SmartEVSE geeft ca = "*" → VERIFY_NONE → het servercertificaat wordt
nooit gecontroleerd. Dat geldt voor
élke wss://-backend, met of zonder SNI.
Met de versies 7.17 tm 7.21 van mongoose heb ik verbonden met verschillende ocpp backends. De bug is inderdaad niet gefixed bij een hoger niveau van mongoose. Waarom de fix van riberts dan wel werkt is omdat smartevse mbedTLS gebruikt (Via MicroOCPP), niet de ingebouwde TLS van mongoose. Door wat te schuiven lost riberts punt 2 hieronder op.
Het probleem samengevat:- SmartEVSE geeft geen CA mee (ca = "*") → "doe geen certificaatcontrole".
- In de code van Mongoose zit het versturen van SNI en het verifiëren in dezelfde functie-aanroep (mbedtls_ssl_set_hostname()), en die wordt alléén aangeroepen in de "wél verifiëren"-tak.
- Dus "geen verificatie" betekent óók "geen SNI versturen". Die twee zijn verbonden.
Gevolg voor de backends:
Backend die geen SNI nodig heeft → werkt prima (één server, één certificaat, geen SNI nodig om te kiezen).
Backend die SNI nodig heeft (zoals joulo)→ de server weet zónder SNI niet wélk certificaat hij moet aanbieden, dus hij breekt de handshake meteen af.
De oplossing:
Drie paden (zie pull request):
- Voor niet-SNI backends, die geen let's encrypt gebruiken kan gekozen worden om het (root)certificaat te pasten voor verificatie, of om TLS verificatie over te slaan (zo was het dus: smartevse deed nooit tls verificatie). Bij TLS verificatie overslaan heb je dus wel encryptie maar geen authenticatie. Gebruikt een backend let's encrypt, dan hoef je deze niet te pasten en gebruikt hij het ingebouwde certificaat van let's encrypt.
- SNI backends (zoals joulo) & Niet SNI backends, zoals vele anderen, waaronder tap, die let's encrypt gebruiken gaan nu automatisch goed, omdat hij gebruik maakt van het ingebouwde TLS certificaat van let's encrypt.
- SNI backends die geen let's encrypt gebruiken werken nog steeds niet zonder certificaat. Hierbij moet je dan het certificaat echt pasten. De skip TLS verification toggle werkt hierbij niet. Hier is voor gekozen zodat niet de upstream mongoose code aangepast hoeft te worden.
Een alternatief was om een bundel van certificaten in de firmware te zetten, maar dat maakt de build size wat groter. Het let's encrypt certificaat zat al in de code voor de MQTT, dus die is hergebruikt.
Ik heb de code op mijn smartevse lokaal getest en het werkt nu met joulo - met tls verificatie dus! omdat deze let's encrypt gebruikt gaat het goed zonder een certificaat te hoeven pasten in de UI (in code van PR mogelijk). Ik heb het niet getest met andere backends.
Mocht @
dingo35 vragen hebben stuur me gerust een PM!