A Stanfordi és Texasi egyetemek kutatói közzétettek egy érdekes tanulmányt a különböző SSL/TLS-t alkalmazó könyvtárak, middleware-ek és SDK-k minőségéről. Ezeket a komponenseket számos érzékeny adatot kezelő alkalmazásban megtaláljuk, találkozhatunk velük például banki mobilalkalmazásokban e-kereskedelmi site-ok fizetési moduljaiban, de a különböző cloud szolgáltatások eléréséhez is érdemes ezeket a kulcsrakész szoftvereket használni. 

A probléma az, hogy úgy tűnik, a szóban forgó szoftverek fejlesztői nem fordítottak kellő figyelmet az általuk használt alacsonyabb szintű API-k dokumentációjára, vagy egyenesen kiiktattak bizonyos ellenőrzéseket a kellemetlen felhasználói hibajelzések vagy éppen a könnyebb tesztelhetőség érdekében. 

Az egyik tipikus hiba a cURL könyvtár tanúsítványellenőrzést beállító opcióinak helytelen paraméterezése: a tanúsítványok "Common Name" attributumának vizsgálatához először is be kell állítani a CURLOPT_SSL_VERIFYPEER opciót igazra, ezen kívül a CURL_SSL_VERIFYHOST értékét 2-re kell állítani. A baj az, hogy a fejlesztők gyakran azt hiszik, hogy a második opció is egy boolean, így true-t adnak értékül neki, ami a legtöbb nyelvben az 1-es értékre fordítódik. Ilyen beállítás mellett azonban a könyvtár csak azt ellenőrzi, hogy létezik-e CN attributum a tanúsítványban, azt már nem, hogy az megegyezik-e az aktuális hosztnévvel. Ettől a problémától szenvedett a PayPal Payments Standard SDK korábbi verziója, valamint az Amazon Flexible Payments Service SDK-ja is. A ZenCart-tal szállított PayPal IPN modul simány False-ra állította a VERIFYPEER értéket, így gyakorlatilag semmilyen névellenőrzés nem történt. 

Egy másik érdekes példa az Apache HttpClient 3-as főverziója, ami a JSSE SSLSocketFactory-ját használja a kapcsolatok kialakítására, ez az alacsony szintű API (ahogy a dokumentációban is olvasható) nem végez hosztnév ellenőrzést, az Apache HttpClient pedig szintén megfeledhezik erről. Bár a legfrissebb 4-es főverzióban már orvosolták ezt a problémát (így a csomag esetenként érvényes tanúsítványokat is visszadob...), számtalan helyen (pl. az Axis 2-ben) még mindig a 3-as változatot használják, az újabb verzió ugyanis nem visszafele kompatibilis.  

Sajnos olyan is előfordul, hogy a hivatalos dokumentáció egy szót sem ír az SSL/TLS kapcsolatok ellenőrzéséről. Ilyen például a PHP fsockopen() függvénye, mely ugyan képes titkosított kapcsolatokat kezelni, a távoli hoszt tanúsítványán azonban nem hajt végre semmilyen ellenőrzést. Ezt az eljárást a már emlegetett ZenCart és PrestaShop rendszerek is használják, ha a cURL nem elérhető.

Végül, ahogy már említettem, előfordul, hogy a fejlesztők szándékosan kapcsolják ki a távoli hoszt hitelességének ellenőrzését. Ez történik többek között az Apache Libcloud 0.11.1-nél korábbi verzióiban, az Amazon Elastic Cloud Balancing API Toolsban, az osCommerce, a ZenCart, az Ubercart és a PrestaShop szinte összes fizetési szolgáltatást integráló moduljában, az AIM-ben és számos Andorid alkalmazásban. 

Népszerű tévhit, hogy ha a kapcsolatom titkosított, minden meg van oldva. Pedig a titkosítás hitelesítés nélkül általában nem sokat ér, az esetek többségében passzívan hallgatózó támadó könnyen aktív man-in-the-middle-é tudja varázsolni magát. Gyakori védekezés, hogy a hálózat alapvetően megbízható, ami internetes alkalmazásoknál eleve abszurd kijelentés, egyébként érdemes átgondolni, hogy ha tényleg sérthetetlenek az összeköttetések (általában nem azok), akkor miért is használunk SSL/TLS-t?

Az érintett szoftverek listájáért érdemes átolvasni a teljes dokumentumot, ökölszabályként pedig elmondható, hogy ha már elfogadunk kódot idegenektől, legyen gondunk rá, hogy teszteljük is azt.