Как стать автором
Обновить

Комментарии 33

Расскажите плиз, какие ресурсы выделены под проксю, которая ходит по редиректам?
Много ли запросов которые требуют более 1го редиректа?
И какая нагрузка по запросам в секунду?
Около 10 серверов. Запросов с более чем одним редиректом мало, но они есть, к сожалению. А с одним редиректом (например, ссылка была с www редиректит на без www) — полно.
Нагрузка порядка несколько тысяч rps на один сервер.
/dev/random => /dev/urandom… вы серьезно?

Когда я последний раз проводил тестирование, большая часть браузеров поддерживала TLS Session tickets, гораздо большая чем те, что поддерживали SSL Sessions. Насколько сильно кеширование увеличило производительность?
Процентов на 20-30% ускорил.
А трюк с рандомом — вообще чуть ли не в два раза дал эффект.
Неспроста, уровень энтропии в urandom намного ниже. Не боитесь за безопасность?
Это далеко не самое потенциально узкое место в безопасности. Про взлом SSL путем подбора рандомного числа я еще не слышал.
Не самое узкое, SSL как раз и взламывают из-за таких вещей. Это одно из самых уязвимых мест. Если атакующий сможет предсказать следующее случайное число — он может применить MITM.
Это правда. Но энтропии в urandom достаточно, чтобы нельзя было угодать следующее случайное число. Тот кто угадает, может не ломать нашу почту, а смело ехать в Монте-Карло.
Тем не менее, такие техники применяются.
На 20-30%, по сравнению с чем? Средним временем handshake у всех клиентов (включая session tickets и тех, кто вообще не поддерживает ни то, ни другое)?
Речь о среднем времени коннекта на сервер сайде (среди всех коннектов, и с поддержкой session tickets и без). По сравнению с отсутствием SSL-кэша.
Интересно! Видимо, играет роль специфика клиентов. На rackspace.com и нескольких других серверах, в основном, преобладали Session Tickets. Спасибо за ответ!
а как вы в баннерке проверяете безопасность flash содержимого? он же может подтягивать произвольные ресурсы? этот же вопрос касается и JS баннеров, которые могут по цепочке партнер->субпартнер->субпартнер подтягивать всякий раз разный код
Браузер не ругается на то, что флэш тянет что-то снаружи по небезопасному протоколу. А поскольку защищать, как вы сами понимаете, в рекламном баннере нечего (этот контент вообще никак не связан с пользователем), то проблемы, как таковой, нет.
Внешние javascript'ы залить в нашу баннерную систему нельзя (грубо говоря, форма ввода для партнеров не позволяет их вводить). Поэтому мы можем автоматом проверять код и понимать, если в нем небезопасное содержимое.
а какой вообще выигрыш от введения SSL был? насколько уменьшилось количество жалоб на взломы ящиков? т.е. была ли какая то выгода от введения SSL кроме репутационных бонусов (в среде гиков знающих что такое SSL)?
Пока рано делать выводы. SSL в почте — это стратегическая задача. Вообще, проблема безопасности в Интертене — более менее общая и только одним сервисом целиком не решается. Если у пользователя одинаковый пароль от почты и от какой-либо соцсети, то ломают соцсеть — ломают и почту.
К огромному сожалению, SSL имеет очень запутанные настройки и много тонкостей в реализации. Шаг влево, шаг вправо — можно получить противоположный безопасности результат. При запуске SSL сервера обязательно нужно делать независимые проверки или хотя бы пользоваться сторонними сервисами тестирования.
Если сейчас взглянуть на mail.ru через www.ssllabs.com/ssltest/analyze.html?d=mail.ru (Пример для одного из серверов в кластере: www.ssllabs.com/ssltest/analyze.html?d=mail%2eru&s=94%2e100%2e191%2e241 ) то можно увидеть несколько серьезных проблем:
Разрешение использовать SSL v.2.0, подверженность атаке CRIME и атаке BEAST, DDoS атаке CVE-2009-3555

Все проблемы закрываются корректными настройками веб-серверов, но естественно нужно дополнительно протестировать как поведет себя сервис под нагрузкой.

Почему стоит обратить на это внимание — хотя CRIME и BEAST сложны в исполнении, но есть внутреннее ощущение, что низкая энтропия urandom делают возможность атаки более, чем вероятной.
IMHO при такой нагрузке имеет смысл использовать аппаратный генератор случайных чисел — это сильно разгружает CPU и сохраняет высокий уровень энтропии.

Почему стоит закрывать возможность для DDoS — говорить не стоит :)
Вы смотрите не на mail.ru, а на e.mail.ru: www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru&s=94.100.184.17
Почта отдается именно с домена e.mail.ru. А c mail.ru отдается главная страница, где https мы еще не анонсировали и только экспериментируем с ним.
В таком случае это плохое поле для экспериментов. Процесс Apache обслуживает как 80 так и 443 порт, который подвержен атаке CVE-2009-3555, в случае которой вы получите не работоспособность обоих протоколов.
Пожалуйста, обратите этому моменту достаточное внимание.
У нас на главной странице нет apache. Там самописный сервер. Но за совет спасибо, внимание уже обратили!
Привет Денис,
а вы не пробовали сравнить затраты на разработку, поддержку и сервера с покупкой готовых решений вроде F5?
Маг, привет.
Смотря, о какой задаче идет речь. Если о поддержке https, то, как я написал в статье, проблема не в готовом или не готовом решении, а в том, что даже, если все решения уже есть (SSL поддержан везде, писать собственные алгоритмы шифрования не надо), то сделать так, чтобы все заработало на высоконагруженном проекте — это определенный челендж.
Да, я говорю именно про задачу отдачи контента через HTTPS на нагруженном проекте. Интересно было бы сравнить стоимость вашего решения с готовыми железками, которые делает например F5.
Про то, что это челендж согласен :)
У меня на железки есть аллергия. Если программа рабоатет неправильно, то я ее пофикшу. А если железка работает неправильно, то ее только выкинуть и рвать волосы на голове)
И напоследок расскажу о небольшом хаке, который тоже существенно увеличил производительность. Мы сделали линк с /dev/random на /dev/urandom. Работает быстрее, потому что /dev/random блокирующий, /dev/urandom не блокирующий. Следовательно, I/O wait сокращается. А поскольку на наших веб-серверах диски достаточно загружены (из-за логирования, приезжающей статики, сохранения атачей и т.д.), то дополнительный I/O wait оказывает существенное влияние на работу сервера в целом.

Денис, поясните, пожалуйста, как связанны ввод-вывод random/urandom и загруженные диски?
Алексей, связаны достаточно просто. Загруженные диски напрягают в целом всю подсистему ввода-вывода. И поэтому любая блокировка на файловом вводе выводе (даже не связанная с дисками, например чтение из /dev/random) может оставаться на больший срок, чем требуется для поступления данных.
жуть какая, и вы правда в это верите? чтобы перегрузить стек ввода-вывода надо сделать что-то невероятное, чтобы при этом упереться в процессор. Если вы хотите сломать мою картину мира, дайте пруф-линк пожалуйста, может это баг в ядре какой. Вобщем это заявление равносильно тому, что если я на высоконагруженном сервере по io вставлю флоппик и начну с него читать, производительность сервера упадет.
Если это будете обращаться к флоппи параллельно из 1000 потоков, то у вас все остальные io операции могут легко замедлиться. Но я сам флоппи вставлять в сервер не пробовал.
А трюк с рандомом реально помогает.
> Если это будете обращаться к флоппи параллельно из 1000 потоков, то у вас все остальные io операции могут легко замедлиться.

Из-за чего? в чем физика процесса? Может трюк с рандомом работает не из-за подсистемы ввода-вывода, а по каким-то другим причинам?
Я физику вам сходу не расскажу. По идее, io wait не должен влиять на поедание цпу, переключения контекстов не в счет, т.к. они случаются только при пробуждении. Но то, что много io wait'а тормозит весь сервер, это медицинский факт, который я наблюдаю за все свои 10 лет опыта работы с high load'ом.
Если у вас есть другие более менее обоснованные гипотезы, то дайте их в студию, плиз.
Ну просто вы путаете вещи, тем самым еще и других запутываете. Да, при обращении к /dev/random процесс будет в uninterruptible sleep на ожидание ввода-вывода из него, да это увеличит показания iowait в системе, да, ваше приложение будет тормозить, потому что блокируются на чтении из /dev/random, но диски здесь совершенно не причем. Приложение которое работает с диском не будет при этом тормозить. Система — не будет тормозить. la в linux будет большим, но это говорит только о количестве процессов в uninterruptible sleep.
Вы все верно говорите. Но это теория. На практике иначе.
Давайте пример, у меня другая практика почему-то. Меня, как инженера, любопытство разбирает, когда теория с практикой расходится, давайте разбираться, можно в личке. Это либо баг в ядре, либо какая-то странная особенность, которая может заафектить продакшн в самый неудобный момент.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий