2009-04-13 libssl

by Vasil Kolev

Нещо, в което съм се блъсвал поне десетина пъти – libssl:

Този прекрасен lib, основна част на openssl, е боза (или просто повечето програмисти не го ползват правилно). Примерен ефект – пускате си php с curl (който ползва SSL), след което си пускате и php-pgsql към някоя база (която па по default идва настроена със ssl=true). Резултат – php-то core dump-ва като гламаво. Решение (най-лесното, което съм видял за момента) – спира се ssl-а на базата (така и така смисъла от него не е особено голям).
Виждал съм хиляди вариации на тоя проблем, например с OpenSIPS, TLS и модула им за xcap client, който ползва curl, който па от своя страна идва като вариант с openssl (в debian-базираните неща има и вариант с gnutls), или пък нещо, което е статично link-нато с openssl, и което по някакъв начин link-ва динамично нещо друго, което па от своя страна закача някакъв локален libssl. Бам. Почти невъзможно е да се открие проблема с неща като strace, ltrace май също не се справяше много добре (а и ако някой е пробвал да ltrace-ва php, знае колко ужасно е), а coredump-а е почти невъзможен за разгадаване. Аз май го хванах съвсем на късмет първия път.
Извод – МНОГО внимавайте с libssl, избягвайте динамични модули, които го зареждат, и … абе внимавайте. Има само един заместител на libssl – gnutls – и той май не се радва на толкова доверие.

(Аз лично не обичам libssl. Има ужасен интерфейс, странни идеи, а core dump-овете след него са почти винаги намазани.)

Tags:

9 Responses to “2009-04-13 libssl”

  1. kay Says:

    Странна библиотека си е, но отчасти самата TLS спецификация е виновна за това – с всичките си слоеве от функционалност в протокола, не е никак лесно да и хванеш края. Програмирането с openssl си е кошмар!

  2. Георги Чорбаджийски Says:

    Да не забравяме и разликите между разните малки версии 0.9.8abcde….вгъзъ. За да избегна линкване към тази библиотека в едно наше софтуерче просто си намерих ползвам public domain sha1, md5 и проверка на rsa подпис и се отървах от едно постоянно правещо проблеми #include :)

  3. Vasil Kolev Says:

    @Георги, то можеш да ползваш libcrypto, то няма тия проблеми.

  4. Alex Stanev Says:

    cryptlib на Peter Gutmann ли имаш предвид?

  5. Vasil Kolev Says:

    @Alex Stanev, не, librcypto от openssl пакета – тоя lib си е reentrant и всичко останало (тука колегите го ползват доста усилено за разни неща). Само libssl прави проблеми.

  6. joe Says:

    Малко офф но: МД5 май беше кракнат в началото на годината и дори Верисайн минаха на Ша1. Или се лъжа :/

  7. K I Says:

    Паролите в shadow file-a също вече са Sha512 , а не MD5

  8. teh Says:

    @joe: “кракнат” май не е правилната дума. Върши работа в дадени ситуации и без притеснения за колизиите.

    @K I: къде ги видя sha512?

  9. Петър Пенчев Says:

    ManiaX, по въпроса с PHP, curl и PostgreSQL: най-лесният начин всъщност е друг: да промениш малко реда, в който се зареждат модулите :) Ако накараш едното да се зарежда преди другото, а не обратно, както е по подразбиране (забравих вече точно кое как беше, а адски много ме мррррзи да се логвам по машините да проверявам), всичко е наред.

    Проблемът с това? В дистрибуцията, която вероятно и ти ползваш, това изисква промяна на конфигурационни файлове (package conffiles) в /etc/, която ще се обърне да те захапе при следващото обновяване. Един вид, трябва да помниш защо си го направил, за да няма после “абе кой идиот тука е сложил PostgreSQL extension-а да се зарежда във файла, който зарежда curl?!” и после PHP-то пак да почне да гърми :)

Leave a Reply