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> (“rn”).
4
5. HTTP пример запроса
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
5
Метод Запрашиваемый ресурс Версия протокола
Передаваемые куки
Заголовок
• Заголовок может содержать данные к примеру для POST метода
6. HTTP пример ответа
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>
6
Код ответа и версия протокола
Тип возвращаемого ресурса и кодировка
Закрываем
соединение
Устанавливаем
куки
Пустая строка
<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
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 SYN
TCP ACK
HTTP request
TCP SYN-ACK
②
HTTP response
TCP SYN
TCP ACK
HTTP request
TCP SYN-ACK
1 RTT = 40ms
Первый
запрос
Второй
запрос
샼, 샽, 샾, 샿 – полные RTT
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 SYN
TCP ACK
HTTP request
TCP SYN-ACK
②
HTTP response
HTTP request
1 RTT = 40ms
Первый
запрос
Второй
запрос
샼, 샽, 샾 – полные RTT
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
21. SSL, TLS и HTTPS
Secure Sockets Layer (SSL) был разработан компанией Netscape для
проведения безопасной электронной коммерции в сети Интернет.
Когда SSL проходил стандартизацию у IETF он был переименован в
Transport Layer Security (TLS).
Многие используют SSL и TLS как синонимы, однако на самом деле
они описывают разные версии протокола.
21
22. Зачем нам HTTPS?
• Аутентификация – на том конце
точно тот, с кем я говорю.
• Целостность данных – никто не
может вмешаться в процесс
передачи.
• Шифрование – никто не может
видеть какие именно данные
передаются.
22
HTTP
TLS
TCP
IP
HTTPS
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
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
47. TLS “False Start”
Техника Sesssion ID и TLS Session Ticket хороши для работы с
клиентами, которые пришли к нам повторно, но не помогает в случае
с новыми или с теми у кого закончилось время действия сессии.
“False Start” не изменяет протокол, а изменяет время когда данные
HTTP могут быть отправлены.
Необходимо на стороне сервера:
• PFS;
• NPN.
47
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
