OpenSSL
OpenSSL — відкритий програмний продукт, розроблений як універсальна бібліотека для криптографії, що використовує протоколи Secure Sockets Layer і Transport Layer Security. Використовується, зокрема, в бібліотеці cUrl для реалізації роботи за протоколом https. Доступна для більшості UNIX-подібних операційних систем (включаючи Solaris/OpenSolaris, Linux, Mac OS X, QNX4[1], QNX6 і чотирьох операційних систем BSD з відкритим початковим кодом), а також для OpenVMS і Microsoft Windows. ІсторіяOpenSSL заснований на SSLeay, написаної Еріком Янгом (Eric A. Young) і Тімом Гадсоном (Tim Hudson), які неофіційно закінчили працювати над ним в грудні 1998 року, коли вони почали працювати в проєкті RSA Security. Влітку 2012 проєкт OpenSSL отримав для версії бібліотеки 1.0 сертифікат відповідності стандарту безпеки FIPS 140-2, що визначає вимоги до криптографічних модулів, необхідні для їхнього використання в державних установах США.[2][3] Сертифікат виданий Американським інститутом стандартів і технологій (NIST) після проведення відповідного аудиту коду проєкту. Виданий сертифікат примітний тим, що він виданий на початковий код продукту, а не конкретну бінарну збірку, що розширює область використання OpenSSL в державних проєктах. В січні 2018 року проєкт отримав нагороду Макса Левчіна (англ. The Levchin Prize) за істотне покращення якості початкового коду бібліотеки[4]. Дати виходу основних релізівВерсії, що більше не підтримуються
Поточні версії
АлгоритмиРеалізує наступні алгоритми шифрування:
ІнцидентиHeartbbleedУ квітні 2014 дослідниками компаній Google і Codenomicon в OpenSSL була виявлена одна з найсерйозніших вразливостей (CVE-2014-0160)[7] в історії проєкту, яка зачіпає величезне число сайтів, серверних систем і клієнтських застосунків, що застосовують OpenSSL 1.0.1 для організації обміну даними через захищене з'єднання. Суть проблеми проявляється в можливості доступу до 64Кб пам'яті клієнтського або серверного процесу, з яким встановлено шифроване з'єднання. Практична небезпека вразливості пов'язана з тим, що у схильній до витоку області пам'яті можуть розміщуватися закриті ключі або паролі доступу, які потенційно можуть бути отримані віддаленим зловмисником. У разі особливої атаки зловмисник може отримати вміст серверного ключа, що застосовується для організації шифрованого доступу до сервера, і потім організувати перехоплення захищеного трафіку (на транзитному вузлі). Також не виключений витік паролів, ідентифікаторів сесій і інших закритих даних клієнтських застосунків при спробі їх з'єднання з підконтрольними зловмисникам серверними системами. Причиною проблеми є відсутність перевірки виходу за допустимі межі в коді реалізації TLS-розширення heartbeat (RFC 6520), що дозволяє віддаленій стороні ініціювати відправлення до 64Кб даних з області за межею поточного буфера. За деякими оцінками проблема охоплювала до половини серверних систем, які підтримували захищене з'єднання в Мережі, включаючи зібрані з OpenSSL 1.0.1 вебсервери (Apache httpd, nginx), поштові сервери, XMPP-сервери, VPN-системи, шлюзи і приховані сервіси анонімної мережі Tor.[8] Пов'язана з атакою активність не фіксується в серверних логах, що утруднює виявлення фактів експлуатації уразливості. На думку Брюса Шнаєра,[9] відомого експерта в області комп'ютерної безпеки, Heartbeat-уразливість в OpenSSL слід зарахувати до категорії катастрофічних вразливостей, рівень небезпеки якої становить 11 балів, якщо розглядати існуючу 10-бальну шкалу ступенів небезпеки з урахуванням того, що OpenSSL є найпоширенішою криптографічного бібліотекою в Мережі. Завдяки широкому висвітленню проблеми за два дні з моменту її оприлюднення близько 1/3 всіх серверів встигли застосували оновлення з усуненням уразливості. Проте, за попередніми даними в Мережі ще залишалися уразливими близько 600 тисяч серверів. Але проблема далека від свого вирішення — незрозуміло, що робити з вбудованими та мобільними продуктами, схильними до вразливості, але такі що не передбачають можливість автоматичного оновлення прошивки. В умовах можливості непомітного проведення атаки, без залишення слідів в балці, також чекає тривалий процес зміни SSL-сертифікатів, ключів шифрування і звичайних паролів, відсутність витоку яких неможливо гарантувати. Потенційно будь-який пароль і сертифікат міг потрапити в руки зловмисників, і незрозуміло, коли й де подібні витоки можуть проявитися.[10] Примітки
Посилання
|
Portal di Ensiklopedia Dunia