Работоспособность WNAM тесно связана с возможностью надежной, удобной авторизации абонентского устройства в беспроводной сети.
В настоящее время большинство мобильный устройств используют функцию "автовход". Она заключается в попытке устройством самостоятельно провести идентификацию и подключение к открытой беспроводной сети, проверив доступность подключения к Интернет.
Когда абонент выбирает для подключения гостевую сеть, подключается к ней, устройство получает IP адрес и другие параметры, производится автоматическая попытка определить наличие доступа в Интернет.
- Устройства Android запрашивают ссылку http://www.gstatic.com/generate_204
- Устройства iOS запрашивают (в зависимости от версии) ссылки из доменов www.ibook.info, www.appleiphonecell.com, captive.apple.com и т.п.
Если ответ по этим ссылкам приходит, устройство считает себя подключенным к Интернет. Если ответа нет, открывается специальный браузер (мини-браузер), в котором предполагается провести авторизацию в сети. Это называется Captive Network Assistant (CNA).
С сложными системами, в которых предполагается ввод авторизационного СМС или совершения звонка, CNA может работать плохо. В некоторых беспроводных контроллерах (Cisco, Aruba) можно включить функцию CNA Bypass, что позволяет при подключении абонентского устройства "обманывать" его, заставляя считать, что интернет уже предоставлен. В таком случае абоненту необходимо вручную открыть браузер, и перейти на какую-то вебстраницу.
За включение CNA в iOS отвечает настройка "автовход", но обычно про неё пользователи не знают:
Если отключен CNA, или абонент пытается подключиться к Wi-Fi сети при помощи ноутбука, авторизация проводится обычным браузером. При этом абонент, скорее всего, будет пробовать перейти на свой любимый сайт, указанный как стартовый, либо будет пользоваться стартовой страницей поисковой системы (google, yandex). В подавляющем большинстве случаев такие сайты работают по протоколу HTTPS, что в обычных условиях делает невозможным редирект (перенаправление) на портал авторизации. Для такого перенаправления пользователь должен перейти по обычной, HTTP ссылке.
Однако, большинство из порталов перехвата в оборудовании (беспроводные контроллеры, Linux-маршрутизатор, Mikrotik и т.п.) могут проводить перехват и перенаправление и HTTPS-сессии. Для этого необходимо, как минимум, иметь установленный SSL-сертификат как в устройство доступа, так и в сервер WNAM.
При попытке перехода браузером по HTTPS-ссылке портал перехвата производит подстановку своего сертификата вместо сертификата сервера. Большинство браузеров на такую операцию выдают предупреждение, вынуждая пользователей принять риск:
Фактически, портал перехвата проводит атаку типа MITM (Man-In-The-Middle), так что предупреждение браузера уместно.
Внимание! Данное поведение - не следствие ошибки или недоработки WNAM, это свойство самой технологии SSL и работы браузеров с HTTPS-сайтами. Это невозможно ни изменить, ни исправить.
В большей части случаев возможно добиться непрозрачного для абонентов (с предупреждением, как выше) перенаправления на авторизацию и для HTTPS-сайтов. Для этого вам будет необходимо:
- Настроить и протестировать работу WNAM в режиме HTTP-перехвата и авторизации
- Получить годные, подписанные и проверяемые HTTPS-сертификаты
- Установить HTTPS-сертификат в веб-сервер tomcat, который исполняет приложение WNAM и который служит порталом авторизации
- Установить HTTPS-сертификат в устройство, осуществляющее функции портала перехвата
Внимание! Даже, если вы настроите контроллер или хотспот на перехват HTTPS-трафика и перенаправление его на авторизацию WNAM, в любом случае абоненту будет показано окно ошибки сертификата. Вы можете пойти таким путем, а можете отключить перехват HTTPS, что приведет к появлению белого экрана или ошибки доступа у абонентов, пытающихся перейти по HTTPS-ссылке без участия CNA.
Получение сертификатов
Для работы HTTPS-авторизации вам потребуется легально выписанный, авторизованный сертификат SSL. Вы можете:
- Выписать так называемые "самоподписанные" сертификаты, однако браузеры абонентских устройств не смогут проверить их подлинность и всегда будут отображать сообщение об ошибке
- Приобрести сертификаты у сторонних организаций, таких как Synamtec, Thawte, Verisign, Comodo и т.п. Сертификаты покупаются на 1 год
- Выписать бесплатный сертификат при помощи сервисов типа Let's Encrypt (обновления вручную каждые 90 дней) или WoSign
В любом случае у вас будут приватный ключ и публичный сертификат, а также цепочка сертификатов. Для получения сертификатов типа Letsencrypt применяется проверка принадлежности имени, указываемом в сертификате, вам. Такая проверка производится путем запроса к имени, указанному в сертификате, извне. Таким образом вы должны либо организовать работу сервера доступа либо на публичных IP-адресах, в которые преобразуются DNS-имена из сертификатов, либо использовать технологию Split DNS и специальный DNS-сервер для Wi-Fi абонентов.
В нашем примере далее предположим, что у сервера доступа типа Mikrotik внешний адрес 172.16.130.9 и имя mk.k18.netams.com, а у сервера WNAM адрес 172.16.130.13 и имя debian64.k18.netams.com. Все сказанное ниже справедливо и для доменов 2-го уровня, и для Wildcard-сертификатов (типа *.mydomain.ru).
Сертификат, полученный у Letsencrypt, имеет вид:
# openssl x509 -in cert.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
03:0c:ab:c8:e6:3a:0c:7e:5a:e5:ff:23:ab:5f:cf:9b:15:a5
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3
Validity
Not Before: May 15 14:45:00 2016 GMT
Not After : Aug 13 14:45:00 2016 GMT
Subject: CN=mk.k18.netams.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
...
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
C4:B9:60:6C:08:8E:00:AB:9D:F9:40:59:09:1A:16:B3:62:3C:71:36
X509v3 Authority Key Identifier:
keyid:A8:4A:6A:63:04:7D:DD:BA:E6:D1:39:B7:A6:45:65:EF:F3:A8:EC:A1
Authority Information Access:
OCSP - URI:http://ocsp.int-x3.letsencrypt.org/
CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Alternative Name:
DNS:mk.k18.netams.com
X509v3 Certificate Policies:
Policy: 2.23.140.1.2.1
Policy: 1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
User Notice:
Explicit Text: This Certificate may only be relied upon by Relying Parties and only in accordance with the Certificate Policy found at https://letsencrypt.org/repository/
Signature Algorithm: sha256WithRSAEncryption
...
Вы можете установить сертификат в nginx, если вы оставили tomcat на порту 8080, и используете nginx в качестве фронт-сервера. Подробнее здесь.
Установка сертификата в tomcat
Необходимо преобразовать сертификат и закрытый ключ к нему в формат JKS, распознаваемый веб-сервером.
Помещаем полный сертификат из файла fullchain1.pem и закрытый ключ из файла privkey1.pem в контейнет PKCS#12 с именем debian64.p12. При конвертации укажем пароль на контейнер: Password
openssl pkcs12 -export -in fullchain1.pem -inkey privkey1.pem -out debian64.p12 -name tomcat
Создаем ключевое хранилище в формате JKS c этим контейнером и таким же паролем:
keytool -importkeystore -deststorepass Password -destkeypass Password -destkeystore debian64.jks -srckeystore debian64.p12 -srcstoretype PKCS12 -srcstorepass Password -alias tomcat
Копируем хранилище в каталог конфигурации вебсервера tomcat:
cp debian64.jks /etc/tomcat7/
Редактируем файл конфигурации вебсервера /etc/tomcat7/server.xml так, чтобы в нем появился блок:
<Connector port="443" protocol="org.apache.coyote.http11.Http11Protocol" URIEncoding="UTF-8" keystoreFile="/etc/tomcat7/debian64.jks" keystorePass="Password" keyAlias="tomcat" keyPass="Password"
maxThreads="150" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />
Добавляем возможность вебсерверу работать на привелигированном порту HTTPS (443):
touch /etc/authbind/byport/443
chmod 500 /etc/authbind/byport/443
chown tomcat7 /etc/authbind/byport/443
После этого перезапускаем веб-сервер:
/etc/init.d/tomcat7 restart
После запуска в лог-файле /var/log/tomcat7/catalina.out должны появиться следующие строки:
INFO: Deployment of web application archive /var/lib/tomcat7/webapps/ROOT.war has finished in 52,197 ms
май 15, 2016 6:58:21 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-80"]
май 15, 2016 6:58:21 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-443"]
май 15, 2016 6:58:21 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 54766 ms
Если после этого административный интерфейс WNAM открывается по ссылке https://имявашегосервера/wnam/home, и браузер показывает на корректно установленное SSL-соединение, то установка сертификата прошла успешно:
Установка сертификата в портал перехвата
В данном примере описана установка и настройка маршрутизатора Mikrotik. Для других типов устройств доступа воспользуйтесь соответствующей инструкцией производителя.
- Переместите файлы с сертификатом и ключом на файловую систему маршрутизатора. Для этого удобно использовать утилиту Winbox:
- Импортируйте сертификаты через Winbox или HTTP Web интерфейс в меню "System-Certificates". Пароль при импорте указывать не требуется:
- Включите HTTPS режим в меню "System-Services", www-ssl, выберите сертификат cert_1 и порт 443:
- После этого административный интерфейс Mikrotik должен быть доступен по имени и по порту HTTPS:
- В настройках профиля сервера хотспота необходимо указать DNS-имя (как в сертификате), перехват по HTTPS, сертификат:
- В файле перенаправления hotspot/rlogin.html, который вы должны отредактировать и загрузить в Mikrotik, необходимо изменить редирект на HTTPS-версию портала с обращением по DNS-имени, а также адрес сервера:
<form name="wnamlogin" action="https://debian64.k18.netams.com/cp/mikrotik" method="post">
<input type="hidden" name="server-address" value = "mk.k18.netams.com:443" />
Теперь необходимо протестировать подключение абонента и перенаправление его сессии с изначально запрошенной HTTPS-страницы на HTTPS-портал авторизации и обратно на Mikrotik. В случае успеха авторизация пойдет по шифрованному SSL-каналу:
Если вы забудете указать имя сервера в шаблоне rlogin.html, то на последнем шаге авторизации возникнет ошибка:
Внимание: на вашей ответственности следить за тем, чтобы установленные сертификаты не закончили свой строк действия! Бесплатные сертификаты Let's Encrypt выдаются на срок 90 дней, платные на 1 год.