NGINX и SSL: Одновременная работа ECDSA- и RSA-сертификатов для выигрыша в скорости и сохранения обратной совместимости

ECDSA- и RSA-сертификаты одинаково безопасны. Однако последнее время появляется всё больше сайтов c ECDSA-сертификатами. Почему? Потому что 256-битный открытый ключ основанный на элиптических кривых по безопасности равен 3248-битному RSA-ключу. Такое разительное отличие битного размера ключей, позволяет значительно выиграть в скорости хэндшейка. Компания Cloudflare ещё в далеком 2013 году проводила тестирование, сравнивая производительность RSA- и ECDSA-ключей:

Название и битность алгоритма Подписей в секунду
RSA (2048 bits) 1001.8
ECDSA (256 bits) 9516.8

По этой таблице можно увидеть, что 256-битный ключ на элиптических кривых примерно в 10 раз быстрее своего RSA-брата.

В плане безопасности никаких преимуществ у ECDSA-ключей нет. Однако в плане скорости ECDSA безусловный лидер

Поддержку двух сертификатов разного типа можно заметить по поддерживаемым шифрам:
ECDSA- и RSA-шифры

Читать Далее

NGINX и SSL: Поддержка ChaCha20-Poly1305 с приоритетом устройствам без AES-NI

Эту небольшую заметку можно назвать продолжением моей первой статьи о том, как же получить A+ на SSLLabs. Я продолжаю улучшать скорость и безопасности HTTPS соединения. Стоит понимать, что мой интерес носит скорее спортивный характер и моему сайту в принципе не нужна безопасность подобного уровня, но собственно почему бы и нет?

Перейдем к самому вопросу. Использовать и пересобирать мы будем Mainline-версию NGINX, на данный момент последняя версия имеет номер 1.11.6. Именно она поддерживает самый полный спектр технологий, однако при этом остается достаточно стабильной, чтобы использовать её на продакшене. К примеру корпоративные клиенты компании NGINX, использующие её NGINX Plus сейчас переходят на версию R11, которая является как раз-таки дополненной 1.11.6. Изменений относительно стабильной 1.10.2 там прилично, но самыми броскими для меня оказались:

  • Поддержка нескольких сертификатов. Например, можно использовать RSA- и ECC-сертификаты одновременно.
  • Поддержка нескольких видом элиптических кривых одновременно. К примеру, если клиент не поддерживает secp521r1, то сервер сможет спустится на secp384r1 или prime256v1.

Однако об этом мы поговорим немного позже в следующих заметках.

В этой статье речь пойдет про патч от Cloudflare, который привносит поддержку ChaCha20-Poly1305-шифров. Однако в отличии от OpenSSL 1.1.0c, где поддежка этих шифров также имеется, патч от Cloudflare позволяет отдавать приоритет при выборе шифров именно устройствам без AES-NI. То есть устройствам без хардварного ускорения AES-шифрования. Таких устройств нынче мало, но они всё-таки есть и в достаточно большом номинальном количестве. К примеру это почти все Android-устройства, кроме самых новых и флагманских. Учитывая, что мобильный рынок развивается очень быстро, то выиграть несколько миллисекунд во время SSL-хэндшейка весьма приятно.

Кстати в SSLLabs это выглядит вот так

Читать Далее

Windows 10 Mobile (Windows Phone) и Debian 8 через MTP

Windows 10 Mobile и Debian 8
Информации в интернете путной не нашел, почти вся давно устарела. Однако настроить поддержку оказалось весьма просто:

1
sudo apt-get install -t jessie-backports libmtp-common libmtp9 mtp-tools

В моем случае libmtp-runtime был уже установлен, но если проблемы останутся, можете поставить его и ещё jmtpfs. Однако вышеозначенных пакетов вроде хватает.

Настроить ALPN на Debian теперь проще простого

Я уже писал про настройку ALPN на Debian Jessie. Наконец мейнтейнеры Debian нас услышали и стали собирать Nginx с поддержкой OpenSSL 1.0.2i (да-да, в бэкпортах уже весьма давно лежит 1.0.2).

Воды лить смысла не вижу, так что сразу к делу.

Для тех кто пользовался моей предыдущей инструкцией:

1
2
sudo apt-get remove nginx-*
sudo apt-get install -t jessie-backports nginx-full

DPKG вас спросит, какой конфиг установить – отвечайте N, другими словами оставить свой nginx.conf, а не установить новый из пакета. Так вся ваша конфигурация сохранится.

По сути всё, после двух этих команд вы получите рабочий ALPN и стабильный Nginx (а не mainline, как нам приходилось использовать в случае с пакетом из Ubuntu).

Для тех, кто ставит систему с нуля:

1
sudo apt-get install -t jessie-backports nginx-full openssl

Короткая справка для тех, кто вообще не понимает о чем я:

ALPN это расширение над TLS и используется, в частности, для корректной работы HTTP2. Раньше использовался NPN, но Chrome его быстро удалил из своего браузера, поэтому если вы хотели рабочий HTTP2, то ALPN становился необходим. Google удалил NPN настолько быстро, что не дал разработчикам дистрибутивов достаточно времени, чтобы собрать новые версии. Поддержка ALPN как такового реализована была только в OpenSSL 1.0.2, тогда как на многих серверах до сих пор стоит 1.0.1.

Cоздание простого Telegram-бота на PHP

КДПВ (~280КБ)
Недавно назрела необходимость создать простого бота, который бы взаимодействовал с классами и методами из материнского проекта (сайта). В принципе можно было бы писать на любом языке, а потом написать некий коннектор, взаимодействие между этим всем. Но лично для меня было в разы проще написать самого бота также на PHP.

Впрочем приступим к делу. Первым делом обсудим что нам понадобится:

  1. PHP 5.6+
  2. NGINX или Apache в качестве веб-сервера.
  3. В случае с Nginx понадобится ещё php-fpm, например.
  4. Сертификат от LetsEncrypt (то есть без домена никак, но разве это проблема в 2016 году? Сейчас можно с легкостью купить домен в зоне .xyz за доллар-два).
  5. ОПЦИОНАЛЬНО: MySQL-совместимая база данных. То есть непосредственно MySQL или MariaDB.

То есть вам нужен готовый вебсервер, с настроенным PHP и SSL-соединением. База данных опциональна и будет использоваться для создания интерактивных диалогов, в которых бот будет учитывать прошлые сообщения. Как настроить SSL в случае с NGINX, вы можете прочитать здесь.

Для чего SSL спросите вы? Для того чтобы работать с Telegram, используя вебхуки. Они надежней и удобнее, классического Long Polling. Для тех кто совсем не понимает о чем я, поясняю:

  • Long Polling: Наш сервер бы постоянно опрашивал Telegram об обновлениях.
  • Webhooks: Telegram сам будет посылать эти обновления нам на сервер.

То есть ваш сервер будет отвечать как минимум быстрее, будет меньше нагружен и не будет делать лишнюю работу. Помимо этого этот метод надежнее в работе.

Итак, вы настроили сервер, для проверки можете создать в корне (к примеру у вас он может быть здесь: /var/www/project1) файл test.php и в теле написать:

1
2
3
<?php
phpinfo();
?>

Теперь перейдите в браузере на https://domain.xyz/test.php, вы должны получить страницу с конфигурацией вашего PHP. Помимо этого убедитесь, что SSL настроен корректно (к примеру на сайте SSLLabs).

Сервер готов, можно начинать создание бота.

Читать Далее

Настройка чистого IPsec посредством strongSwan с максимальной совместимостью


В интернете не так уж много хороших статей по поводу настройки чистого IPsec без использования L2TP. Несмотря на то, что гайды в интернете хоть и имеются, все они имеют какие-то недостатки. К примеру, большинство уже устарели и потеряли свою актуальность. Например, зачем нам поддержка IKEv1, если в текущих macOS и iOS уже добавили поддержку IKEv2? На момент публикации этой статьи IKEv2 поддерживается практически везде:

Мобильные ОС:

  • Android (через приложение strongSwan)
  • iOS8+
  • Windows Phone 8.1
  • Windows 10 Mobile
  • BlackBerry 10+

Настольные ОС:

Простой редирект c www-версии сайта при использовании HTTPS

Многие пользольватели зачастую по привычке вводят в начале любого адреса www. Поэтому целеособразно сделать редирект с www.domain.xyz на domain.xyz. Наоборот можно сделать аналогичным образом: Но зачем? Ведь более короткий адрес банально эстетически красивее.

Если сайт не использует HTTPS, то для редиректа достаточно простого рерайта (rewrite), однако в нашем случае понадобится дополнительный SSL-сертификат для www-версии (многие регистраторы предоставляют его беслпатно вместе с основным).

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

Переходим в директорию конфигов NGINX и создаем новый файл конфигурации:

1
2
cd /etc/nginx
sudo nano sites-available/www.domain.xyz.conf

Читать Далее

Настройка Nextcloud на базе NGINX

Nextcloud – форк проекта ownCloud. В принципе данный конфиг будет актуален и для него. Многим известно, что Nextcloud из коробки поддерживает только Apache, но я со своего сервера его удалил за ненадобностью и полностью перешёл на NGINX. Официальный конфиг с сайта не обновляется и на половину не рабочий. Поэтому пришлось разбираться самому.

По сути изначаельно у меня стояла цель получить красивые редиректы (которые, кстати, поддерживаются официально при работе с Apache). Например я не хочу видеть в строке:

1
https://cloud.domain.xyz/index.php

Я хочу видеть просто:

1
https://cloud.domain.xyz

Особенно это заметно, когда делишься ссылками:

1
https://cloud.domain.xyz/index.php/s/ASgj54jk2j32jds

Таким образом, одним из главных условий была поддержка так называемых Pretty URLs.

В целом большинство проблем возникает из-за отстувия некоторых редиректов. Собственно, перейдем сразу к делу. Сам конфиг постарался сопроводить подробными комментариями.

Читать Далее

NGINX и HTTP/2: Настройка ALPN в Debian Jessie

Совсем недавно Google бросили поддержку NPN. Теперь можно использовать только ALPN. Увы, браузер Chrome очень популярен и имеет множество сборок, вроде Яндекс.Браузера. Поэтому просто кинуть их мы не можем. Придется заводить ALPN, чтобы HTTP/2 работал везде.

Несмотря на то, что Google дал отсрочку полгода, пока из серверных ОС далеко не все смогли завести его поддержку “из коробки”. На данный момент этим похвастаться может, например, Ubuntu Server.

В контексте Debian всё не так радужно. Для поддержки ALPN нужен NGINX 1.9.5+, собранный с библиотекой OpenSSL 1.0.2h. Сам OpenSSL 1.0.2h завезли в jessie-backports буквально в конце июля. Однако NGINX пересобирать не стали. Его всё также собирают с 1.0.1t.

Я же постараюсь описать наиболее безопасный способ установки NGINX с поддержкой ALPN без пересборки исходников и затаскивания кучи зависимостей.

Приступим. Первым делом рекомендую удалить текущий NGINX из системы (разумеется конфиги остануться):

1
sudo apt-get remove nginx nginx-common

Читать Далее

NGINX и SSL: Получаем четыре сотни и А+ на SSLLabs.com

Собственно сразу перейдем к делу

Цель – А+ на SSLLabs, а в идеале вообще все четыре результата по сто баллов.
Оценка выводится на основе четырех шкал:

  1. Certificate
  2. Protocol Support
  3. Key Exchange
  4. Cipher Strength

Первый пункт, насколько мне известно, просто предполалагает наличие подлинного сертификата от известного CA.

Для второго пункта достаточно отключить все протоколы, кроме TLSv1.2. Другими словами пишем это:

1
ssl_protocols TLSv1.2;

Читать Далее