Posted on 2020-07-16 by overlord

A Cisco SPA502 asztali IP telefonommal szoktam tesztelni VOIP rendszereket. Stabil, jó minőséget produkáló készülék, kicsit talán öreg, de mindig stabilan működött, viszont a közelmúltban okozott nekem egy kis fejtörést. Azt tapasztaltam, hogy a beállított, és eddig jól működő VOIP fiókom nem regisztrál, a mellékem nem kapcsolható.

TLS transzportot használok a biztonság miatt, így a jelzésrendszer legalább megbízható, titkosított módon közlekedik a hálózaton. A készüléket egy teszt erejéig UDP-re állítva a probléma megszűnt, a mellékem életre kelt egyébként.

Telefon oldalról a hálózati szeparáció miatt kicsit nehezebb lett volna logolni és tesztelni, mivel külön voice VLAN-ban van az IP telefon készülék és nem tudtam oda egyszerűen syslog szervert belógatni, így először szerver oldalról kezdtem vizsgálni a problémát. Az Asterisk PBX-en ahová ez a mellék csatlakozik a logban ehhez hasonló üzenetekkel találkoztam tehát szerver oldalról:

[2020-07-16 22:54:50] ERROR[14737] tcptls.c: Problem setting up ssl connection with peer '188.36.105.142:5069': error:00000001:lib(0):func(0):reason(1), Internal SSL error
[2020-07-16 22:54:50] WARNING[14737] tcptls.c: FILE * open failed from peer '188.36.105.142:5069'!

Feltúrtam az internetet a megoldás után, hogy lássam a közösség hogy oldott meg hasonló problémákat, ki találkozott már hasonlóval, de mint olyan sokszot, most is számomra logikátlan megoldásokba ütköztem, amik a konfigurációban a TLS beállításait módosítgatták találomra. Annak ellenére, hogy nem hiszek a próbálgatásban párat én magam is kipróbáltam, de ezek természetesen nem oldották meg a gondot. Ezek után mérnöki módszerekkel álltam neki a problémát megoldani. Gyanakodtam én mindenre, régi firmware-re, túl új OpenSSL-re. A megoldás lépéseivel és a következtetésekkel nem untatnék senkit, az eredmény az lett, hogy a Cisco SPA502 – és valószínűleg legalábbis az egész SPA500 sorozat, ha nem a Cisco többi IP telefonja is érintett – nem tartalmazza megbízható tanúsító szervezetként a Let’s Encrypt root CA-ját és a titkosítás elbukik már az elején a handshake környékén.

Az a kézenfekvő első megoldás, hogy olyan tanúsítványt kell használni, aminek a root CA-ja benne van a készülék trusted listájában. Cisco készülék esetén tudtommal egyszerűen nincs mód megadni külső CA-t megbízhatóként, vagy legalábbis házi barkács módszerekkel nincs. A beállításokat teszteltem Windows softphone-al, illetve Yealink telefonokkal és ott ugyanez nem okozott problémát. Volt a Cisco-nak állítólag egy Trusted Certificate Authority listája, de vonatkozó pontos és naprakész listát én nem találtam.

Ez nem marketingoldal, úgyhogy konkrét tanúsítvány-kibocsájtót ide nem írok, de a probléma egy évre nagyjából 10 dollárból megoldható.

A másik, hosszabb távra előremutató megoldás az egyedi CA tanúsítvány feltöltése, amit egy sima, nem titkosított (HTTP) webszerveren kell elhelyezni, és az URL-jét megadni a készüléken. A következő újraindításnál azt a készülék letölti, és így az egyedi CA már megbízható lesz. Ez megoldást jelent a Let’s Encrypt tanúsítványai esetén is.

Fontos megjegyezzem, hogy a készülékek túlnyomó része End-Of-Life állapotú, azaz nem kap már újabb firmware-frissítéseket, ez akár komoly biztonsági problémákhoz is vezethet pár éven belül. Ugyanakkor nem szép, hogy a gyártó a tanúsítványokat ennyire támogatás nélkül hagyta, ezt igazán megoldhatták volna a gyári firmware részeként még pár évig.