Upgrade to Pro — share decks privately, control downloads, hide ads and more …

HTTP and HTTPS

Viacheslav Biriukov
August 13, 2015
0
92

HTTP and HTTPS

• http 1.0 vs 1.1;
• keep alive why and when;
• http 1.1 less known features;
• ssl and tls;
• cipher suites;
• false start;
• tls tickets.

Viacheslav Biriukov

August 13, 2015
Tweet

More Decks by Viacheslav Biriukov

See All by Viacheslav Biriukov
Linux Memory Management
brkov
1
120

Featured

See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
265
13k
Product Roadmaps are Hard
iamctodd
PRO
49
11k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Done Done
chrislema
181
16k
How to train your dragon (web standard)
notwaldorf
88
5.7k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
26
1.4k
GraphQLとの向き合い方2022年版
quramy
43
13k
VelocityConf: Rendering Performance Case Studies
addyosmani
325
24k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
26
2.1k

Transcript

  1. None

  2. HTTP и HTTPS Вячеслав Бирюков

  3. HTTP краткая история • HTTP/0.9 – 1991 г.; • HTTP/1.0

    – 1996 г.; • HTTP/1.1 первый вариант – 1999 г. (RFC 2616); • HTTP/1.1 текущий вариант – 2014 г. (RFCs 7230, 7231, 7232, 7233, 7234, и 7235); • HTTP/2.0 – есть черновик стандарта, основывается на SPDY. 3

  4. HTTP протокол • Клиент-серверная архитектура. • Обмен сообщениями идёт по

    схеме «запрос-ответ». • Протокол без сохранения состояния (stateless protocol). • Текстовый протокол с разделителем: <CR><LF> (“\r\n”). 4

  5. HTTP пример запроса 5 GET yandsearch?text=raccoon HTTP/1.1
 Host: www.yandex.ru
 Connection:

    keep-alive
 Cache-Control: no-cache
 Pragma: no-cache
 Accept: text/html,application/xhtml+xml
 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4)
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: ru,en;q=0.8
 Cookie: foo=bar; foo2=bar3 Метод Версия протокола Запрашиваемый ресурс Передаваемые куки Заголовок • Заголовок может содержать данные к примеру для POST метода

  6. HTTP пример ответа 6 HTTP/1.1 200 OK
 Server: nginx
 Content-Type:

    text/html; charset=UTF-8
 Content-Length: 205
 Connection: close
 Cache-Control: no-cache,no-store,max-age=0,must-revalidate
 Expires: Mon, 15 Sep 2014 10:36:06 GMT
 Last-Modified: Mon, 15 Sep 2014 10:36:06 GMT
 Set-Cookie: p=123; Expires=Fri, 17-Sep-2004 10:36:05 GMT; Domain=.www.yandex.ru; Path=/
 Content-Encoding: gzip
 
 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN”>
 <html><head>
 <title>302 Found</title>
 </head><body>
 <h1>Found</h1>
 <p>Yandex</p>
 </body></html> Код ответа и версия протокола Тип возвращаемого ресурса и кодировка Закрываем соединение Устанавливаем куки Пустая строка <CR><LF> Тело ответа

  7. HTTP/1.1 • Виртуальные хосты (virtual host); • все соединения постоянные

    (keep-alive/persistent connections); • chunked transfer encoding; • range request (byte serving); • широкие возможности работы с кешем; • сжатие. 7

  8. Виртуальные хосты (virtual host) Документация по виртуальным хостам Apache: Термин

    виртуальный хост относится к практике размещения более чем одного веб-сайта (например, www.example.com и www.example.org) на одной машине. Виртуальный хост может быть как «привязанным к IP-адресу», что означает использование отдельного IP адреса для каждого сайта, либо «привязанным к имени», позволяя вам иметь несколько различных имён для каждого IP-адреса. Факт того, что эти сайты работают на одном и том же физическом сервере, не очевиден конечным пользователям. 8

  9. Пример виртуального хоста 9 Apache Listen 80
 NameVirtualHost *:80
 


    <VirtualHost *:80>
 DocumentRoot /var/www/example1
 ServerName www.example.com
 </VirtualHost>
 
 <VirtualHost *:80>
 DocumentRoot /var/www/example2
 ServerName www.example.org
 </VirtualHost> Nginx server {
 listen 80 default_server;
 server_name www.example.com;
 root /var/www/example1;
 } server {
 listen 80;
 server_name www.example.org;
 root /var/www/example2;
 }

  10. Постоянные соединения • В HTTP/0.9 и 1.0 не было официальной

    поддержки постоянных соединений – соединения закрывались сразу после пары запрос/ ответ; • В процессе добавили реализацию на уровене приложений через заголовок Connection: Keep-Alive. Клиент посылает заголовок: Connection: Keep-Alive Если сервер также поддерживает расширение – он в свою очередь тоже должен добавить в ответ заголовок: Connection: Keep-Alive 10

  11. Без использования постоянных соединений 20 ms Клиент Сервер ① ③

    ④ 4 RTT = 160ms HTTP response TCP ACK HTTP request TCP SYN TCP SYN-ACK ② HTTP response TCP ACK HTTP request TCP SYN TCP SYN-ACK Первый запрос Второй запрос ①, ②, ③, ④ – полные RTT 1 RTT = 40ms

  12. Постоянные соединения HTTP/1.1 В HTTP/1.1 сделали все соединения постоянными. •

    уменьшить время задержки, т.к. не нужно переустанавливать TCP соединение (TCP 3-Way-Handshake). • увеличить пропускную способность соединения, т.к. из-за существования в TCP механизма для управления перегрузками сети – “медленный старт” (TCP slow start), значение TCP окна стартует с маленьких единиц и растёт в течении передачи данных. 12

  13. Пример постоянного соединения 20 ms Клиент Сервер ① ③ 3

    RTT = 120ms HTTP response TCP ACK HTTP request TCP SYN TCP SYN-ACK ② HTTP response HTTP request Первый запрос Второй запрос ①, ②, ③ – полные RTT 1 RTT = 40ms

  14. Включаем в серверах Apache KeepAlive On
 KeepAliveTimeout 120 Nginx keepalive_requests

    1000;
 keepalive_timeout 120s; 14

  15. Chunked transfer encoding Механизм позволяет отправлять ответ ещё не зная

    его размера и не буферезируя его на стороне сервера. HTTP/1.1 200 OK
 Server: nginx
 Content-Type: text/html
 Transfer-Encoding: chunked
 
 23
 This is the data in the first chunk
 1A
 and this is the second one
 3
 con
 8
 sequence
 0
 
 15

  16. Range request (byte serving) Позволяет запрашивать только часть ресурса. Запрос:

    GET /raccoon-video.avi HTTP/1.1
 Range: bytes=100- Ответ HTTP/1.1 206 Partial Content
 Content-Type: video/mp4
 Content-Length: 64656927
 Accept-Ranges: bytes
 Content-Range: bytes 100-64656926/64656927
 X-Content-Duration: 63.23
 Content-Duration: 63.23
 
 16

  17. Кеширование – когда? Заголовки, которые говорят когда нужно перезапросить ресурс:

    • Cache-Control – разрешает кеширование, устанавливает параметры; • Expires – устанавливает дату, после которой кеш невалидный. Кешируем ресурс: Cache-Control:public
 Expires: Mon, 25 Jun 2012 21:31:12 GMT Запрещаем кеширование: Cache-Control:no-cache, no-store 17

  18. Кеширование – как? Заголовки, которые говорят как перезапрашивать ресурс (conditional

    requests). Если ресурс не изменился – получим ответ с кодом 304 Not Modified. Делятся на две категори: • зависят от времени (time-based): Cache-Control:public, max-age=31536000
 Last-Modified: Mon, 03 Sep 2014 17:45:57 GMT If-Modified-Since: Mon, 03 Sep 2014 17:45:57 GMT • зависят от содержания (сontent-based, ETag): Cache-Control:public, max-age=31536000
 ETag: "d41d8cd98f00b204e9800998ecf8427e"
 
 If-None-Match: "d41d8cd98f00b204e9800998ecf8427e" 18

  19. Сжатие Сжатию подлежит только тело ответа – заголовки передаются в

    текстовом виде. GET /raccoon-page.html HTTP/1.1
 Host: www.example.com
 Accept-Encoding: gzip, deflate HTTP/1.1 200 OK
 Content-Length: 438
 Content-Type: text/html; charset=UTF-8
 Content-Encoding: gzip Nginx модуль ngx_http_gzip_static_module позволяет отдавать заранее подготовленные сжатые файлы. 19

  20. HTTPS – должен быть везде! 20

  21. SSL, TLS и HTTPS Secure Sockets Layer (SSL) был разработан

    компанией Netscape для проведения безопасной электронной коммерции в сети Интернет. Когда SSL проходил стандартизацию у IETF он был переименован в Transport Layer Security (TLS). Многие используют SSL и TLS как синонимы, однако на самом деле они описывают разные версии протокола. 21

  22. Зачем нам HTTPS? • Аутентификация – на том конце точно

    тот, с кем я говорю. • Целостность данных – никто не может вмешаться в процесс передачи. • Шифрование – никто не может видеть какие именно данные передаются. 22 TCP IP TLS HTTP HTTPS

  23. Вопросы системного администратора • Как правильно настроить HTTPS? • Как

    улучшить и оптимизировать скорость? 23

  24. Типы сертификатов Сертификаты: • RSA (2048-bit); • DSA; • ECDSA

    (256-bit) – Windows XP 3SP. 24

  25. Сертификаты и домены Разновидности сертификатов: • на отдельный домен: example.com;

    • на несколько доменов (Subject Alternative Names SAN): example.com, www.example.com и www.example.org; • wildcard на несколько доменов по маске: *.example.com (покрывает www.example.com, mail.exmaple.com, но НЕ example.com и НЕ w2.www.example.com). 25

  26. Версии протокола SSL/TLS • SSLv2 – небезопасен • SSLv3 –

    небезопасен (POODLE) • TLSv1.0 • TLSv1.1 • TLSv1.2 Пример для nginx: ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 26

  27. Как выбрать шифры (ciphersuite)? Не используйте копи-паст со странных/устаревших сайтов!

    Важен баланс между безопасностью и скоростью. Мозилла предоставляет отличную вики с примерам настройки: https://wiki.mozilla.org/Security/Server_Side_TLS ssl_prefer_server_ciphers on; 27

  28. Просядем ли по СPU? TLS использует два типа шифрования: •

    симметричное шифрование (AES, RC4) – может запросто прогрузить сетевой интерфейс); • асимметричное шифрование (public-key cryptography) – в разы тяжелее чем симметричное. 28

  29. Аппаратная поддержка AES Процессоры с аппаратной поддержкой AES-NI позволяют ускорить

    работу с AES в несколько раз. OpenSSL версий 1.0+ Проверяем: cat /proc/cpuinfo | grep aes 29

  30. Асимметричное шифрование и CPU Twitter (https://blog.twitter.com/2013/forward-secrecy-at-twitter): We found that enabling

    and prioritizing ECDHE cipher suites actually caused negligible increase in CPU usage. HTTP keepalives and session resumption mean that most requests do not require a full handshake, so handshake operations do not dominate our CPU usage. Facebook (http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/ 0251.html): We have found that modern software-based TLS implementations running on commodity CPUs are fast enough to handle heavy HTTPS traffic load without needing to resort to dedicated cryptographic hardware. Всё это касается последних версий OpenSSL > 1.0 30

  31. Perfect Forward Secrecy (PFS/FS) До FS использовался RSA метод генерации

    сессионных ключей – небезопасен т.к. в случае компрометированная приватного ключа, можно расшифровать всю сессию. В наши дни необходимо использовать PFS – так как в этом случае для каждой сессии генерируются новый ключ. Пример из TLS 1.2: ECDHE-RSA-AES128-GCM-SHA256 31

  32. Ускоряем и оптимизируем HTTPS 32

  33. TLS установка соединения (1) 20 ms Клиент Сервер ① ServerHello

    Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③, ④ – полные RTT ClientHello ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ③ HTTP response HTTP request ④ TCP + TLS + Данные = 4 RTT = 160ms + X сек для проверки сертификата 1 RTT = 40ms

  34. TLS установка соединения (2) 34 20 ms Клиент Сервер ①

    TCP ACK TCP SYN TCP SYN-ACK ② ClientHello 1. Установили TCP соединение. 2. Клиент посылает в текстовом формате: • версию TLS протокола; • список cipher suites; • другое. ① ① 1 RTT = 40ms

  35. TLS установка соединения (3) 35 20 ms Клиент Сервер ①

    ServerHello Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ClientHello ③ ① ① 3. Сервер в ServerHello: • выбирает версию протокола; • выбирает шифры; • другое. В секции Certificate: • добавляем сертификат в ответ; • добавляет полную цепочку Intermidate CA (если есть); • корневые сертификаты не передаются (уже в браузере). 1 RTT = 40ms

  36. TLS установка соединения (4) 36 20 ms Клиент Сервер ①

    ServerHello Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ClientHello ClientKeyExchange ChangeCipherSpec Finished ③ ④ ① ① ② 4. Клиент: • проверяет сертификат (+X секунд); • начинает обмен ключами (RSA или Diffie-Hellman для PFS). 1 RTT = 40ms

  37. TLS установка соединения (4) 37 20 ms Клиент Сервер ①

    ServerHello Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ClientHello ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ① ① ③ ④ ⑤ 5. Сервер: • принимает обмен ключами; • проверяет message authentication code (MAC); • и возвращает зашифрованное сообщение “Finished”. 1 RTT = 40ms

  38. TLS установка соединения (5) 20 ms Клиент Сервер ① ServerHello

    Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③, ④ – полные RTT ClientHello ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ③ HTTP response HTTP request ④ TCP + TLS + Данные = 4 RTT = 160ms + X сек для проверки сертификата 1 RTT = 40ms

  39. Ускоряем установку соединения 39 1. Уменьшить количество RTT. 2. Уменьшить

    время X – которое требуется на проверку сертификата.

  40. RTT – важное ограничение 40 RTT 60-80ms А ещё есть

    мобильные клиенты по медленным каналам! Москва Париж

  41. Уменьшаем количество RTT 41 1. Session ID ("abbreviated handshake”). 2.

    TLS Session Ticket. 3. False Start.

  42. Установка соединения и Session ID 20 ms Клиент Сервер ①

    ServerHello SessionID Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③, ④ – полные RTT ClientHello ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished ③ HTTP response HTTP request ④ 1 RTT = 40ms TCP + TLS + Данные = 4 RTT = 160ms + X cекунд

  43. TLS повторное соединение (1) 43 20 ms Клиент Сервер ①

    ServerHello Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③ – полные RTT ClientHello SessionID ③ HTTP response HTTP request TCP + TLS + Данные = 3 RTT = 120ms + X cекунд ClientKeyExchange ChangeCipherSpec Finished 1 RTT = 40ms 1 RTT = 40ms

  44. TLS повторное соединение (2) Session ID позволяет нам: • убрать

    1 RTT; • убрать оверхед public key cryptography (asymmetric) который используется для генерации shared secret key; Nginx: ssl_session_cache shared:SOME_UNIQ_PER_CERTIFICATE_CACHE_NAME:128m;
 ssl_session_timeout 28h; 44

  45. TLS повторное соединение (3) Недостатки Session ID: Если у нас

    больше одного сервера – нужно синхронизировать хранилище Session ID, что само по себе дорого по времени и безопасности. Решение – TLS Session Ticket rfc5077. Поддержка Яндекс Браузере, Chrome и Firefox. Nginx: ssl_session_ticket_key current.key;
 ssl_session_ticket_key previous01.key;
 ssl_session_ticket_key previous02.key; Ключи должны переодически меняться, т.к. в противном случае знание ключа делает уязвимым даже Perfect Forward Secrecy. 45

  46. Session Ticket 20 ms Клиент Сервер ① ServerHello Certificate ServerHelloDone

    TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③, ④ – полные RTT ClientHello SessionTicket ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec NewSessionTicket Finished ③ HTTP response HTTP request ④ 1 RTT = 40ms

  47. TLS “False Start” Техника Sesssion ID и TLS Session Ticket

    хороши для работы с клиентами, которые пришли к нам повторно, но не помогает в случае с новыми или с теми у кого закончилось время действия сессии. “False Start” не изменяет протокол, а изменяет время когда данные HTTP могут быть отправлены. Необходимо на стороне сервера: • PFS; • NPN. 47

  48. Пример TLS “False Start” 48 20 ms Клиент Сервер ①

    ServerHello Certificate ServerHelloDone TCP ACK TCP SYN TCP SYN-ACK ② ①, ②, ③ – полные RTT ClientHello ③ HTTP response HTTP request TCP + TLS + Данные = 3 RTT = 120ms ChangeCipherSpec Finished ClientKeyExchange ChangeCipherSpec Finished 1 RTT = 40ms

  49. Проверка сертификата (1) Сертификат может быть аннулирован (Certificate Revocation): •

    приватный ключ скомпрометирован; • CA был скомпрометирован; • нужно перевыпустить сертификат; • и т.д. 49

  50. Проверка сертификата (2) 50 Certificate Revocation List (CRL) : •

    довольно большие; • нет механизма инвалидации кеша. Online Certificate Status Protocol (OCSP): • онлайн проверка; • CA должен иметь возможность обрабатывать запросы; • uptime; • клиент блокируется на OCSP; • приватность.

  51. Проверка сертификата (3) OCSP stapling – как решение проблемы проверки

    сертификата: • добавляем к сертификату OCSP ответ от CA; • кешируем ответ от CA на стороне сервера. Однако нужно иметь в ввиду: • OCSP ответ может быть вплоть до 4K – важно не перегрузить TCP окно (смотрим в настройки initcwnd). 51

  52. Server Name Indication (SNI) TLS соединение устанавливается между двумя точками

    – для этого клиенту необходимо знать только IP адрес другой стороны. Но, что если мы хотим на одном и том же IP поднять разные виртуальные хосты с SSL? • Использовать новый IP • Использовать SNI SNI по аналогии с HTTP – на этапе хендшейка клиент посылает имя хоста для которого хочет получить сертификат. Поддержка: нет полной поддержки на Windows XP IE 6,7 и Android 2.2. 52

  53. Что ещё важно знать при внедрении • Меняем ссылки на

    схемо-независимые. Было: <a href="http://example.com/bar"> Стало: <a href="//example.com/bar"> • HTTP Strict Transport Security (HSTS) – заголовок, который говорит браузеру что необходимо устанавливать только защищённые соединения для всех ресурсов страницы: Strict-Transport-Security: max-age=31536000 53

  54. Не забыть напоследок • Мониторинг сертификатов по времени (expiration time);

    • Выставить правильные права на сертификаты (400); • Произвести аудит сторонними утилитами:
 https://www.ssllabs.com/ssltest 54

  55. Что дальше? • HTTP/2.0 • SPDY • QUIC – SPDY

    over UDP 55

  56. Спасибо за внимание! Спасибо!