Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
•Download as PPTX, PDF•
1 like•1,578 views
В этом году мы перевели наш портал на HTTPS. Это оказалось непростой задачей. Основными проблемами явились рост нагрузки, увеличение Round Trip Times (RTT) и Mixed Content. Мы опробовали различные известные механизмы, призванные нивелировать эти проблемы, но, как оказалось на практике, все они скрывают в себе особенности. Эти особенности стоило знать заранее, но их не удалось почерпнуть из открытых источников. В этом докладе мы хотим поделиться сложностями, с которыми мы столкнулись, а также тем, к каким выводам в итоге пришли. Надеемся, что набитые нами шишки будут полезны тем проектам, которые только планируют переход на HTTPS.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
Similar to Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники) (20)
More from Ontico
More from Ontico (20)
Неочевидные детали при запуске HTTPS в OK.Ru / Андрей Домась (Одноклассники)
- 1. Неочевидные детали при запуске HTTPS в OK.Ru Андрей Домась
- 2. Кто я такой? Андрей Домась Одноклассники Ведущий системный администратор
- 3. Нехорошие операторы и провайдеры
- 4. Нехорошие операторы и провайдеры Ускорение загрузки страниц
- 5. Нехорошие операторы и провайдеры Ускорение загрузки страниц Финансовые сервисы
- 6. Как устроен TLS Шифры Сертификат X.509 “Правильные” настройки сервера
- 7. Как устроен TLS Шифры Сертификат X.509 “Правильные” настройки сервера https://wiki.mozilla.org/Security/Server_Side_TLS
- 8. Неочевидные детали при запуске HTTPS в OK.Ru
- 9. Чего мы опасались? 1.Нужно еще больше серверов
- 10. Чего мы опасались? 1.Нужно еще больше серверов 2.Появится Mixed Content
- 11. Чего мы опасались? 1.Нужно еще больше серверов 2.Появится Mixed Content 3.Что-то начнет тормозить
- 13. Round-Trip Time (RTT) Client Server SYN SYN/ACK ACK New York: 200 ms 200 ms
- 14. Round-Trip Time (RTT) Client Server SYN SYN/ACK ACK ClientHello ServerHello Client Key Exchange Server Finish New York: 200 ms 200 ms 400 ms
- 15. Round-Trip Time (RTT) Client Server SYN SYN/ACK ACK ClientHello ServerHello Client Key Exchange Server Finish New York: 200 ms 200 ms 400 ms 0.6 sec
- 16. Round-Trip Time (RTT) Client Server SYN SYN/ACK ACK ClientHello ServerHello Client Key Exchange Server Finish New York: 200 ms 200 ms 400 ms 0.6 sec 1 mln MUA in US
- 17. 1. Нужно еще больше серверов 2. Появится Mixed Content 3. Что-то начнет тормозить Чего мы опасались?
- 18. CPU & RTT
- 21. Browser WEB-siteHTTPS Master Key Ciphers Ciphers Master Key Cert Cert Master Key Exchange
- 22. Browser WEB-siteHTTPS Master Key Ciphers Ciphers Master Key Cert Cert Master Key Exchange TLS session TLS session
- 23. Browser WEB-siteHTTPS Master Key Ciphers Ciphers Master Key Cert Cert Master Key Exchange Full Handshake
- 24. Browser WEB-siteHTTPS Master Key Ciphers Ciphers Master Key 1 Round-Trip CPU intensive! Cert Cert Master Key Exchange Full Handshake
- 27. Client Server Full Handshake TLS-session id: 12345 session-id: 12345TLS-session id: 12345
- 28. Client Server Full Handshake TLS-session id: 12345 session-id: 12345 session-id: 12345 TLS-session id: 12345 check/restore
- 29. Client Server Full Handshake TLS-session id: 12345 session-id: 12345 session-id: 12345 TLS-session id: 12345 check/restore Abbreviated Handshake
- 30. Client Server Full Handshake TLS-session id: 12345 session-id: 12345 session-id: 12345 TLS-session id: 12345 Server2 check/restore
- 35. Client Server Full Handshake TLS-sessionTLS-session keyticketticket check/restore Abbreviated Handshake
- 36. Client Server Full Handshake TLS-sessionTLS-session keyticketticket check/restore Abbreviated Handshake
- 37. Client Server Full Handshake TLS-sessionTLS-session keyticketticket check/restore Abbreviated Handshake rfc 5077
- 38. ,
- 39. APR one-nio
- 40. APR one-nio
- 54. Session Context “...it would be possible, to re-import a session generated from another context (e.g. another application), which might lead to malfunctions.”
- 55. Session Context • Apache Tomcat Native: “_default_:443” • nginx: “HTTP” • haproxy: “haproxy”
- 56. Client Server Full Handshake TLS-sessionTLS-session keyticketticket check/restore Abbreviated Handshake
- 58. FQDN + port
- 59. Что в итоге? Можно ли использовать везде один ключ?
- 60. Нужно еще меньше CPU!
- 61. AVX/AVX2
- 62. AVX/AVX2 + openssl 1.0.2
- 63. AVX (20%) Session Ticket (15%)
- 64. На что еще клиент тратит время?
- 72. Certificate authority (CA) Certificates Browser WEB-siteHTTPS revoked OCSP signature OCSP - Online Certificate Status Protocol
- 74. Certificate authority (CA) Certificates Browser WEB-siteHTTPS revoked OCSP signature OCSP Stapling
- 75. Каков выигрыш?
- 77. Каков выигрыш? 67 ms + 200 ms 25%
- 79. 1.Сломался механизм ротации OCSP: downtime
- 80. 1.Сломался механизм ротации OCSP: downtime 2.Плохой OCSP-ответ: downtime
- 81. 1.Сломался механизм ротации OCSP: downtime 2.Плохой OCSP-ответ: downtime 3.Меняем серверный сертификат: downtime
- 83. Механизм отключения OCSP Stapling
- 84. Mixed Content 1.Что в нем плохого? 2.В чем сложность борьбы с ним?
- 85. Mixed Content Active ● <script> (src attribute) ● <link> (href attribute) (this includes CSS stylesheets) ● <iframe> (src attribute) ● XMLHttpRequest requests ● All cases in CSS where a url value is used (@font-face, cursor, background-image, and so forth). ● <object> (data attribute) Passive ● <img> (src attribute) ● <audio> (src attribute) ● <video> (src attribute) ● <object> subresources
- 86. В чем сложность? 1.Он происходит в браузере
- 87. В чем сложность? 1.Он происходит в браузере 2.На странице много чужих ресурсов
- 91. POST { "blocked-uri": "http://homeland.ugo-games.com", "document-uri": "https://ok.ru/appsPreset/https_games/", "effective-directive": "img-src", "original-policy": "default-src data: blob: about: 'self' 'unsafe-inline' 'unsafe-eval' https:; report-uri /csp/report?always;", "referrer": "https://ok.ru/web/gwt/3e8af28/one.app.community.dk.gwt.dm.block.Block/BF2E365744786A7 4515E6A4678785A4A.cache.html", "status-code": 0, "violated-directive": "default-src data: blob: about: 'self' 'unsafe-inline' 'unsafe-eval' https:" }
- 92. { "blocked-uri": "safari-extension://com.evernote.safari.clipper-q79wdw8yh9", "document-uri": https://connect.ok.ru/dk?st.cmd=WidgetShare&st....", "original-policy": "default-src data: blob: about: 'self' 'unsafe-inline' 'unsafe-eval' https:; report-uri /csp/report?always;", "referrer": "http://fishki.net/1819857-chego-nelzja-delat-na-kube.html", "violated-directive": "default-src data: blob: about: 'self' 'unsafe-inline' 'unsafe-eval' https:" }
- 95. Редирект на HTTPS • Старые смартфоны
- 96. Редирект на HTTPS • Старые смартфоны: • Смартфон: RSA 1024 bits
- 97. Редирект на HTTPS • Старые смартфоны: • Смартфон: RSA 1024 bits • Наш TLS: RSA 2048 bits
- 98. Редирект на HTTPS • Старые смартфоны: • Смартфон: RSA 1024 bits • Наш TLS: RSA 2048 bits • SmartTV: тормозят
- 99. Редирект на HTTPS • Старые смартфоны: • Смартфон: RSA 1024 bits • Наш TLS: RSA 2048 bits • SmartTV: тормозят • Пароли не подходят!
- 100. • Лучше иметь отдельный ключ для шифрования TLS-тикетов
- 101. • Лучше иметь отдельный ключ для шифрования TLS-тикетов • Оперативное отключение OCSP Stapling
- 102. • Лучше иметь отдельный ключ для шифрования TLS-тикетов • Оперативное отключение OCSP Stapling • Mixed Content: используйте CSP-reports, но много мусора
- 103. • Лучше иметь отдельный ключ для шифрования TLS-тикетов • Оперативное отключение OCSP Stapling • Mixed Content: используйте CSP-reports, но много мусора • Надо что-то делать со старыми клиентами
- 104. • Лучше иметь отдельный ключ для шифрования TLS-тикетов • Оперативное отключение OCSP Stapling • Mixed Content: используйте CSP-reports, но много мусора • Надо что-то делать со старыми клиентами • Браузеры забудут сохраненные пароли
Editor's Notes
- не стесняясь, вырезали на нашем портале нашу же рекламу и подставляли на ее место свою
- Выступление на HL 2015 “Скорость с доставкой для пользователя” Анатолия Орлова
- Совокупность причин дала нам понять Момент настал - HTTPS
- Перед вами список тем в которые необходимо погрузиться.
- Не буду рассказывать Вместо этого...
- Вернемся немного назад в прошлое, когда мы только готовились взяться за проект. Что нас беспокоило?
- Криптография - дополнительные вычисления… нужно больше CPU!
- [Что это такое?] Все зеленое, но как победить?
- А как же ускорение, антивирусы и DPI?
- Это время приемо-передачи (время отправки + время получения подтверждения) TCP - HTTP
- Пинг до NY: 200 мс Медленно, но что ж поделать... В пустую 200 мс.
- Включаем HTTPS - еще 400 ms Что это значит?
- NY ждет первой порции данных через 0.6 сек. На сколько это проблема?
- 1 млн активных пользователей в США
- Мы закрыли все вопросы, но подводные камни. Хочу поделиться опытом и знаниями.
- Мы начали с этого.
- Клиент пришел - что происходит?
- Обменялись сертификатами, согласовали шифры и пр.
- Безопасно согласовали симм. мастер-ключ, которым потом все будет шифроваться.
- Набор данных с каждой стороны - это сессия.
- Это действо - Full Handshake. Это плохо. Почему?
- Тут 1 RTT и CPU из-за Diffie-Hellman Клиенту пофиг. Серверу нет.
- Итак, Full Handshake состоялся
- Образовались сессии с двух сторон
- Сервер сообщает клиенту id своей сессии Клиент ассоциирует этот серверный id со своей сессией
- Через какое-то время...
- Это называется Abbreviated Handshake - сессия используется повторно. Но у нас многие сотни фронтов….
- Можно расшарить хранилище сессий… Но… bottleneck ресурсы точка отказа А Интернет-проекты росли...
- И был придуман др. механизм. Опять Full Handshake, опять сесии.
- Сервер шифирует сессию - тикет. Отдает ее. Блоб - это тикет.
- Клиент ассоциирует
- Через какое-то время
- Это тоже Abbreviated Handshake
- Ключ должен быть одинаковый - stateless
- Это rfc 5077
- Все это известно, что дальше? Мы почитали rfc, стали тестировать
- А надо сказать, что у нас много разных фронтов.
- Их всех объединяет openssl и код примерно одинаковый
- Проводим эксперимент Клиент пришел к nginx и получил от него тикет
- С тикетом к др. nginx
- Ключ одинаковый
- Тикет подходит, сессия восстанавливается. Все работает!
- С эти же тикетом идем к haproxy Ключ такой же. Смотрим - восстановится ли сессия?
- Но тикет уже не подходит. Тикет будет портится. Мы стали изучать вопрос с двух сторон: серверной и клиентской.
- Фронт
- APP создает сессию
- Тикет Отдает клиенту
- При запуску устанавливается
- Начинает добавляться в новые сессии
- Проверяет совпадение Ни где не используется Зачем так?...
- Специально сломано Везде
- Из описания ф-ции openssl Да, специально
- В популярном софте
- С сервером разобрались. А что же клиент? Упустили...
- Как ассоциирует? В rfc5077 ничего про это нет. Посмотрели код браузеров...
- Банально Не значит, что в др. клиентах так Вывод...
- Теоретически - да, клиент сам разрулит. Практически - лучше не надо Вписаться в рамки стандарта.
- Уже понизили Но не скомпенсировали на 100% Что еще? AVX...
- расширение системы команд x86 - различные улучшения, новые инструкции Уже сейчас есть AVX512
- Почти год назад появилась LTS-версия 1.0.2. В популярных пока нет, придется собирать самим. Но частые дыры в openssl. Стоит ли овчинка выделки?
- Итого спасли 35%. Это почти полная компенсация TLS. AVX2 еще больше даст - 30% Не могу дать до HTTPS - у нас частые изменения Если упадет ЦОД - ЗАПАС
- CPU & RTT - OK На чем бы еще выиграть для пользователя? Есть на чем
- Напомню как устроена PKI. Есть CA
- Он выпустил сертификаты
- Один из сертификатов - это серт. на нашем сайте CA - инсталлирован в браузер
- Браузер приходит к web-сайту
- И проверяет... Это все очевидно… На долго - год - ½ года,...
- Но что если сертификат был отозван недавно?
- Браузер взаимодействует с CA и спрашивает у него статус сертификата
- Для этого есть протокол OCSP. Ответ подписан на стороне CA. А пользователь ждет!
- Ответ подписан Мы можем скэшировать его у себя и отдавать клиенту
- Это называется OCSP Stapling. Какой профит?
- Стоит ли поддерживать весь этот механизм?
- Firefox Много это или мало?
- Сама страница отдается за 200 ms, т.е. задержка +25% Справедливости ради: только первое обращение к серверу, браузер кэширует. Профит есть, но...
- Есть профит Но есть боль. Есть время жизни
- Разные браузеры переживут по разному: Opera & Firefox сломаются.
- Не контролируем CA
- Это точно придется делать
- Вот недавно
- Что делать? Вообще лучши уметь откл. все. Mixed Content….
- Напомню, он бывает двух типов...
- Active - имеет доступ ко всей странице (DOM) Passive - только к той части где отображается
- Не контролируем и не можем посмотреть
- Например баннерная сеть отдает баннер, внутри MC и это не их баннер.
- Типичный MC. Желтое - warning Красное - какой-то отчет, что за отчет...
- Задает браузеру политику откуда какие ресурсы можно загружать.
- Его собрат Атрибут с адресом
- Туда POST’ом прилетают такие отчеты
- Мусор Мы его фильтруем Что делаем с отчетами?
- Мониторим Автоматика
- Все работает, все зеленое Догадывались, что будут интересные моменты
- Они сломались
- Раньше криптостойким был ключ длиной 1024
- Сейчас 2048 Старые смартфоны просто так не умеют
- Многие используют браузер в SmartTV. Он стал сильно тормозить. Сделали искл. по UA для этих кейсов - не редиректим.
- СП засыпало жалобами Не авторизация Как думаете что было?
- Просто чтобы вписаться в стандарты
- Весьма опасная штука Примеры приводил
- Работает, но мусор
- Кто-то сломается
- Придется помогать пользователям
- Надеюсь было интересно и полезно. Готов ответить на вопросы.