Работоспособность системы WNAM тесно связана с возможностью надежной удобной авторизации абонентского устройства в беспроводной сети. В настоящее время большинство мобильный устройств используют функцию "автовход". Она заключается в попытке устройством самостоятельно провести идентификацию и подключение к открытой беспроводной сети, предварительно проверив доступность подключения к сети Интернет.

Когда абонент выбирает для подключения гостевую сеть, подключается к ней, устройство получает IP-адрес и другие параметры, производится автоматическая попытка определить наличие доступа в сеть Интернет. Наличие доступа проверяется для устройств c ОС Android и iOS:

  • Устройства 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), поэтому предупреждение браузера уместно. Причина такого поведения браузера клиента в следующем:

  • Браузер запрашивает https-ссылку. При этом устройство клиента пробует установить HTTPS (т.е. SSL) соединение на IP-адрес ресурса, полученный после DNS-запроса, и порт 443.
  • Хотспот (контроллер беспроводных точек Mikrotik) обращают этот запрос на себя (на собственный встроенный веб-сервер), производя операцию трансляции адресов. 
  • Клиент успешно совершает TCP-соединение и затем пробует установить SSL-соединение, проверяя сертификат отвечающей стороны. Хотспот или контроллер, имея сертификат, выдают его для проверки.
  • Даже если этот сертификат "настоящий", т.е. купленный и валидный, всё равно в нём содержится имя (например, auth.provider.ru), не соответствующее запрошенному ресурсу (например, google.com). 
  • Устройство клиента, подключающееся к сети Wi-Fi, видя такое несоответствие, показывает предупреждение.
Данное поведение - не следствие ошибки или недоработки системы 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 или WoSign (обновлять такие сертификаты необходимо вручную каждые 90 дней).

В любом случае у вас будут приватный ключ и публичный сертификат, а также цепочка сертификатов. Для получения сертификатов типа 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. Для других типов устройств доступа следует воспользоваться соответствующей инструкцией производителя. 

  1. Переместить файлы с сертификатом и ключом на файловую систему маршрутизатора. Для этого удобно использовать утилиту Winbox.


  2. Импортировать сертификаты через Winbox или HTTP Web интерфейс в меню "System-Certificates". Пароль при импорте указывать не требуется.


  3. Включить HTTPS режим в меню "System-Services" (www-ssl), после чего выбрать сертификат cert_1 и порт 443.


  4. После этого интерфейс администратора Mikrotik должен быть доступен по имени и по порту HTTPS.


  5. В настройках профиля сервера хотспота необходимо указать DNS-имя (как в сертификате), перехват по HTTPS, сертификат.



  6. В файле перенаправления 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, то на последнем шаге авторизации возникнет ошибка.

Ответственность за срок действия установленных сертификатов лежит на компании, использующей систему WNAM. Бесплатные сертификаты Let's Encrypt выдаются на срок 90 дней, а платные на 1 год.

 


  • No labels