Насколько безопасный SSL?
Никогда не бывает такого большого класса, когда интерпретатор PHP читает ваш код, он компилируется в один большой исполняемый код, поэтому разделение их на части мало влияет на производительность.
НО:
Когда дело доходит до программирования, вам никогда не нужно больше 40+ методов в одном классе, и их нужно разделить на эти энтиты.
Например,
class HTTP
{
/*
* Base functions for HTTP Fetching / transferring / Sending
* so when it comes to single responsibility this would be the the fetch / set in HTTP
*/
}
, тогда вы будете более конкретны со своими подклассами, такими как
class YoutubeUploader extends HTTP
{
/*
* This class is responsible for uploading to youtube only
*/
}
class YoutubeDownload extends HTTP
{
/*
* This class is responsible for downloading to youtube only
*/
}
class CronRunner extends HTTP
{
/*
* This class is responsible for Running your HTTP Cron Tasks
*/
}
нет, если у вас нет этого базового HTTP-класса, вам придется определять методы в все три подкласса для передачи данных по протоколу HTTP.
Разделение ваших классов на отдельные обязанности дает более структурированную структуру, приводящую к меньшему количеству кода и большему результату.
Все уже упоминали: Принцип единой ответственности , но это то, что вы должны действительно понять.
Есть также способы уменьшить код в классах, возьмите этот пример
class User
{
public function getUsername()
{
return $data['username'];
}
public function getPermissions()
{
return $data['permissions'];
}
public function getFirstname()
{
return $data['firstname'];
}
}
, в действительности это не нужно, когда вы можете сделать:
class User
{
public function __call($method,$params = array())
{
if(substr(0,3,$method) == "get")
{
$var_name = substr(3,strlen($method),$method);
return $data[$var_name];
}
}
}
Это займет автомобиль любого метода. Вызванный, который начинается с 'get', он берет последнюю часть строки и ищет массив.
9 ответов
Предполагая, что все настроено / защищено должным образом, и мы говорим о 128-битных ключах, значительно дольше возраста Вселенной .
Я бы отметил, что предыдущие взломы в SSL основывались на «дыре» в MD5 , что приводило к изменению некоторых методов проверки.
Я также хотел бы отметить, что это не освобождает вас от man-in -the-middle , или даже кто-то захватывает частный сертификат целевой компании (обратите внимание, что закрытые ключи должны быть защищены с помощью надежного пароля, хотя, чтобы уменьшить такой риск, а затем ключ отозван, если такое событие происходит). Прочтите общий обзор того, как работает SSL, здесь .
Зависит от длина ключа, алгоритм и ферма серверов для его расшифровки.
Стив Гибсон объяснил, как именно работает этот протокол, в недавнем подкасте Security Now . Если вас интересуют подробности, определенно стоит послушать.
С математической точки зрения, предполагая, что у вас есть правильная реализация, и игнорируя возможность неизвестного в настоящее время побочного канала атаки или неизвестные в настоящее время математические уязвимости, перебор закрытого ключа должен занять гораздо больше времени, чем возраст Вселенной.
Однако атаки по побочным каналам и другие формы атак на реализацию очень реальны, и к ним нужно относиться серьезно. Это включает в себя такие вещи, как атаки типа "человек посередине", паршивые сертификаты SSL, физические атаки на хост и т. Д.
Что ж, у SSL v2 были некоторые недостатки, SSL v3 вполне безопасен. Время будет зависеть от длины ключа сертификата и от того, насколько быстро вы сможете расшифровать SHA-1 с помощью шифрования RSA.
Достаточно безопасно, я бы сказал:)
Вы упомянули «отправить пароль» через SSL.
Возможно, вопрос в том, как вы
- Защитите пароли (хранятся в виде хеша, открытого текста и т. Д.)
- Ограничьте количество попыток входа в систему (например, если вы разрешите максимум 1 грубую силу в секунду из внешних источников, это займет очень много времени)
- Важная вещь о SSL: где и как хранится ваш закрытый ключ (зашифрованный на диске, внутри специального не читаемое оборудование)?
Потому что часто упускается из виду тот факт, что угрозы от локальных атак могут быть намного выше, чем атаки на уровне шифров.
Например, если кто-то взломает ваш сервер и получит закрытый ключ (худший случай если он не зашифрован на диске) - с помощью закрытого ключа можно будет расшифровать сохраненные сообщения в зависимости от используемого механизма обмена ключами.
Также, как только кто-то получит ваш закрытый ключ, легко настроить сервер, который кажется пользователю исходным сервером, потому что он имеет правильный сертификат.
Так что я полагаю, что безопасность установленных протоколов не должна быть первое, о чем нужно беспокоиться.
У SSLv2 были проблемы с атаками MITM, которые могли приводить к согласованию шифров низкого качества. В те дни это обычно включало в себя подробный список шифров «экспортного качества», которые были намеренно слабыми и которые можно было взломать только с помощью грубой силы.
SSLv3 / TLSv1 эффективно решил проблему согласования, и вскоре после этого многие из шифров более слабого качества были с тех пор был удален из доступности теперь, когда были сняты экспортные ограничения в США, и появились различные сканеры соответствия.
Генерация PRF в SSL использует как MD5, так и SHA1 в попытке предотвратить взлом системы, если один из хешей алгоритмы были достаточно скомпрометированы. Одним из способов атаки на SSL является взлом обоих алгоритмов, используемых в функции PRF. IIRC - это просто своего рода XOR входных данных, проходящих через оба.
Шифры шифрования динамически доступны и согласовываются, поэтому любой анализ качества самих зашифрованных сеансов должен учитывать выбор шифров или сосредоточиться на механизмах, ведущих к созданию исходного ключа шифрования сеанса.
(Вы можете скомпрометировать шифр (RSA, AES ... и т. д.), но это не обязательно приведет к взлому самого SSL)
На мой взгляд, наиболее практичными крипто-атаками на SSL являются атаки по побочным каналам на определенные шифры. В частности, известно, что AES уязвима для атак по времени. Обычно для их работы требуются высококачественные сети с малой задержкой (локальный Ethernet). средства во многих системах, которые просто добавляют искусственную задержку к процессу, чтобы уменьшить вероятность успеха тайминговых атак. (Обычно время, необходимое для выполнения определенных последовательностей кода, может быть использовано для восстановления достаточного количества информации для компрометации системы)
И, наконец, моя любимая слабость SSL - это атаки на «надежность» системы. Независимо от используемых алгоритмов / шифров, шифрование бесполезно без доверия.
Конечно, вы можете установить безопасный зашифрованный сеанс, но если вы не знаете, разговариваете ли вы с законным лицом или злоумышленником, вся эта безопасность становится бесполезным пресс-папье.
В наши дни мы имеем ситуацию, когда десятки центров сертификации перечислены практически в каждом браузере на планете. Под каждым из них находятся несколько промежуточных подписывающих органов, которыми управляет каждый из ЦС / нижестоящих структур.
Были случаи, когда системные ошибки или просто ленивые ЦС и посредники приводили к тому, что система была широко открыта, позволяя подписывать запросы сертификатов для домены, которые не должны быть авторизованы.
Требуется только компрометация одного CA, промежуточного звена, торгового посредника и т. д., чтобы эффективно скомпрометировать весь якорь доверия (фактически, планета Земля). Это можно и делали: иногда случайно, иногда намеренно. Если вы используете IE, убедитесь сами:
Инструменты-Свойства обозревателя-Сертификаты-Недоверенные издатели ..
Были случаи, когда системные ошибки или просто ленивые центры сертификации и посредники приводили к тому, что система была широко открытой, позволяя подписывать запросы сертификатов для доменов, которые не должны были быть авторизованы.
Требуется только компрометация любого из них. CA, промежуточный уровень, торговый посредник и т. Д., Чтобы эффективно поставить под угрозу весь якорь доверия (фактически, планета Земля). Это можно и делали: иногда случайно, иногда намеренно. Если вы используете IE, убедитесь сами:
Инструменты-Свойства обозревателя-Сертификаты-Недоверенные издатели ..
Были случаи, когда системные ошибки или просто ленивые центры сертификации и посредники приводили к тому, что система была широко открытой, позволяя подписывать запросы сертификатов для доменов, которые не должны были быть авторизованы.
Требуется только компрометация любого из них. CA, промежуточный уровень, торговый посредник ... и т. Д., Чтобы эффективно поставить под угрозу весь якорь доверия (фактически, планета Земля). Это можно и делали: иногда случайно, иногда намеренно. Если вы используете IE, убедитесь сами:
Инструменты-Свойства обозревателя-Сертификаты-Недоверенные издатели .. иногда намеренно. Если вы используете IE, убедитесь сами:
Инструменты-Свойства обозревателя-Сертификаты-Недоверенные издатели .. иногда намеренно. Если вы используете IE, убедитесь сами:
Инструменты-Свойства обозревателя-Сертификаты-Недоверенные издатели .. Упс ...
Существуют смягчающие факторы: даты истечения срока действия сертификатов, списки отзыва ... и т. Д., Но, на мой взгляд, проблема доверия остается главной уязвимостью всей системы.
Решительный человек или группа с хорошими навыками социальной инженерии или автоматическое оружие, я думаю, с большей вероятностью получат какой-либо сертификат, который они хотят подписать.
пока яркая искра не увидит дыру.
Мы думали, что ssl был безопасным до скончания веков - извините, altCognito => затем недавно некоторые поняли, что md5 может быть небезопасным.
Ваша безопасность настолько же безопасна, насколько и криптовалюта, используемая для ее защиты, и только потому, что она считается сложной с вычислительной точки зрения, т.е. требует много времени для грубой силы, которая не влияет на инновации, см. Ссылку ps3.
Помните, что об этом всегда думают люди, реализованные затем люди управляются компьютерами.
Вы видите 2 проблемы?
Также недавно
http://www.schneier.com/blog/archives/2008/12/forging_ssl_cer.html
и для обсуждения SSL3 читайте у экспертов - http://www.schneier.com/paper-ssl.html
http://www.darkreading.com/security/attacks/showArticle.jhtml? articleID = 212700234
При условии, что то, что «мы» знаем о некоторых основах криптографии, верно (например, очень сложно разложить очень большие числа на множители), современный SSL - безопасным способом.
Реальная угроза заключается не в том, что кто-то собирается взломать SSL - гораздо лучше, что будет найден другой способ получить интересные данные.