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

HTTP and HTTPS

Viacheslav Biriukov
August 13, 2015
0
90

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
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
328
21k
Music & Morning Musume
bryan
46
6.1k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Raft: Consensus for Rubyists
vanstee
136
6.6k
It's Worth the Effort
3n
183
27k
5 minutes of I Can Smell Your CMS
philhawksworth
202
19k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
A Philosophy of Restraint
colly
203
16k
Side Projects
sachag
452
42k
Embracing the Ebb and Flow
colly
84
4.4k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
360

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. Спасибо за внимание! Спасибо!