WPA2 Enterprise: никаких рисков для предварительно настроенных клиентов, когда речь идет о незаконных точках доступа?
Мы используем по умолчанию PEAP и MS-CHAPv2 в качестве внутренней аутентификации.
I был обеспокоен рисками безопасности, когда дело доходит до несанкционированных точек доступа, но коллега сказал мне, что нет никаких рисков для предварительно настроенных клиентов.
Он сказал мне, что риски существуют только для клиентов с не настроенным предварительно настроенным Wi-Fi, потому что большинство пользователей доверяют поддельному сертификату . Вместо этого для предварительно сконфигурированных клиентов все соискатели будут разрывать или отклонять соединение, и пользователю не разрешается доверять поддельному сертификату. Но почему это? Может быть, из-за того, что соискатели проверяют, установлен ли уже сертификат для этого SSID?
Кроме того, соискатели всегда были настолько осторожны в этом вопросе? Или патчи были применены во время? В последнем случае как мне узнать, когда были применены исправления и в каких версиях ОС? Это было бы полезно, потому что, например, я мог бы предложить использовать мобильные устройства Apple только с iOS 7 и выше (я просто предположил, я не знаю, правильная ли это версия).
Есть три способа, которым предположить, что он говорит с законным сервером:
- Проверить, что атрибут сертификата, представленного сервером RADIUS, соответствует тому, что он ожидает. Обычно это CN.
- Проверка существования доверительных отношений между одним из его доверенных центров сертификации и сертификатом, представленным сервером RADIUS (обратите внимание, что сервер RADIUS может посылать дополнительные сертификаты, чтобы помочь завершить эту цепочку).
- Проверка того, что сервер послал сшивающий ответ OCSP, как часть рукопожатия. По сути, это сервер, выполняющий проверку OCSP от имени клиента и пересылающий ответ.
Профили/конфигурации обычно привязаны к SSID. Если конфигурация, соответствующая текущему SSID, найдена, конфигурация будет использоваться для определения того, какие проверки необходимо выполнить, и установки значений для таких вещей, как ожидаемый CN и CA.
Если эти проверки не удастся выполнить, то сессия TLS будет уничтожена до начала фазы2 метода EAP.
Если профиль/конфигурация не найдена для SSID, большинство предположений (проверенных с Win10 и macOS High Sierra), подскажут пользователю принять представленный сертификат, но не разрешат ни одну из вышеперечисленных проверок для результирующего эфемерного конфигурационного профиля. Если сертификат, предоставленный сервером RADIUS, изменится, то supplicant предложит пользователю зановоподтвердить, что они доверяют этому новому сертификату, не сказав им прямо, что сертификат изменился. Если пользователь принимает новый сертификат, предположим, что он изменит существующую эфемерную конфигурацию и запустит фазу2.
Так что ваш коллега прав по всем пунктам.
Что касается исправления, то на этот вопрос очень сложно ответить. Насколько я знаю, такое поведение было последовательным с тех пор, как оно было введено в различные операционные системы, но я не могу гарантировать этого. Я знаю, что, по крайней мере, в первоначальном релизе предположения Microsoft в Win 2K SP4 демонстрировали поведение, описанное выше, и знаю, что в Win 10 оно тоже проявляется, но помимо этого, я не знаю, было ли оно последовательным
.