Обнаружение, когда пользователи преднамеренно обходят ошибки сертификата https-сервера

Есть ли на сервере заголовок https или метод JavaScript в браузере, который позволит нам определить, когда пользователь преднамеренно обошел сертификат безопасности, или какой-либо другой способ обнаружить и сообщить о такой ситуации? (Мы используем Linux/Apache/jQuery.)

В Интернете полно способов регулярно пропускать предупреждение, но я не смог найти ни одной информации об обнаружении, когда пользователи пропускают его — только ужасающая статистика, согласно которой 70% пользователей обходят предупреждение. так быстро, как они могут. (Как они это измеряют?)

Мы используем веб-приложение, которое позволяет учителям создавать и администрировать тесты. Учителя подключаются к неавторизованным сетям Wi-Fi, получают предупреждения о недействительном сертификате и нажимают на функцию браузера «все равно принять», чтобы получить доступ к нашему приложению, несмотря на то, что у них есть неаутентифицированный сертификат. Мы хотим понять, как часто это происходит и кто это делает, и перейти к прекращению этого.

Я должен отметить, что есть школы, которые запрашивают прокси через свой собственный сервер с собственным сертификатом, и мы согласны с этим - это соединения типа «игнорировать и все равно подключаться», которые мы хотим измерить и смягчить, потому что это те, которые студенты настраивают, без доступа к собственному центру сертификации, но с широким доступом для ленивых пользователей.


ssl https man-in-the-middle
person JTW    schedule 06.03.2015    source источник
comment
Я закрываю это. Ответ, кажется, нет никакого способа обнаружить это. Стыд. Клиент должен иметь возможность обойти защиту, но сервер также должен отказаться от обслуживания. Если мы можем отказаться обслуживать Internet Explorer 8, то мы должны быть в состоянии отказаться обслуживать явно скомпрометированные соединения. Но я оставлю это комитетам по стандартам.   -  person JTW    schedule 16.03.2015
comment
Я искал HSTS. [Вот как это работает и как это реализовать.][1] TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains" [1]: imperialviolet.org/2012/07/19/hope9talk.html   -  person JTW    schedule 17.07.2015

Ответы (4)


arrow_upward
0
arrow_downward

Не уверен, что вы подразумеваете под обходом HTTPS. Если вы имеете в виду, что они могут посещать ваш URI без HTTPS, это означает, что вам нужно заблокировать доступ HTTP в Файлы конфигурации .htaccess, httpd.conf или default-ssl Apache. Сломанный замок может означать несколько разных вещей, поэтому неясно, какая у вас проблема. Вы можете проверить свой сайт на наличие проблем с безопасностью SSL здесь:

https://www.ssllabs.com/ssltest/

Изменить:

Вы можете сравнить отпечаток сертификата SSL на на сервере и на клиенте, чтобы убедиться, что они совпадают (если клиент может получить отпечаток пальца). Это должно предотвратить атаки посредника с поддельными сертификатами.

Статья

и вот ответ на выполнение это на стороне сервера вещей. Похоже, что лучший способ избежать перехвата — аутентифицировать клиента с помощью собственного сертификата.

person Alex W    schedule 06.03.2015
comment
Я уточнил свой вопрос, чтобы объяснить, что они, похоже, подключаются к несанкционированным сетям Wi-Fi, получают предупреждения о недействительном сертификате и нажимают на функцию браузера «Все равно принять», чтобы они могли получить доступ к нашему приложению. HTTP давно заблокирован. - person JTW; 06.03.2015
comment
@JTW Вы можете прочитать отпечаток пальца SSL-сертификата в клиентском веб-приложении? Если это так, вы можете сообщить серверу, если два отпечатка пальца не совпадают. - person Alex W; 06.03.2015
comment
Да, использование отпечатка SSL будет работать, но, похоже, у JavaScript нет способа добраться до этого. В упомянутой вами статье Gibson Research предполагается, что пользователь использует диалоговое окно безопасности браузера, но это снова ставит ответственность на конечном пользователе. Stack Exchange даже сбит с толку. - person JTW; 06.03.2015
comment
@JTW здесь есть несколько ответов о том, как обнаруживать MITM-атаки на стороне сервера, поскольку вы не можете обнаружить их с помощью JavaScript. - person Alex W; 06.03.2015
comment
Спасибо за исследование, информация XHTTP, вероятно, является воротами к этой информации, но это только для Firefox. Это ближе. В любом случае, есть школы, в которых есть собственный законный прокси-сервер https, настроенный с самозаверяющими сертификатами. Именно поэтому пользователи не должны игнорировать предупреждение браузера! Я хочу, чтобы браузер сообщал мне, когда пользователь обошел предупреждение браузера. Я обновлю свой вопрос, чтобы сделать это более ясным. - person JTW; 07.03.2015

arrow_upward
0
arrow_downward

Обнаружить это невозможно — пользователь — единственный, кто может видеть, является ли замок зеленым и закрытым или красным и сломанным.

Firefox сделает это по расширению и через xhtml, но на данный момент это единственный браузер, поддерживающий это.

person JTW    schedule 16.03.2015

arrow_upward
0
arrow_downward

Я искал HSTS. Вот как это работает и как это реализовать.

TL;DR: Header add Strict-Transport-Security "max-age=15768000 includeSubDomains"

person JTW    schedule 30.05.2015

arrow_upward
0
arrow_downward

Один из способов убедиться, что клиент видел отправленный вами сертификат сервера, — это использовать аутентификацию на основе сертификата клиента. Один из последних шагов рукопожатия SSL/TLS при использовании аутентификации на основе сертификата клиента состоит из хэша всех сообщений рукопожатия, подписанных закрытым ключом клиента.

Побочным эффектом этого является то, что если клиент не увидит точно такой же сертификат сервера, сервер не сможет проверить этот подписанный хэш, исходящий от клиента.

Это, конечно, не обязательно означает, что клиент проверил сертификат, как он должен был (т.е. был ли сертификат доверенным и принадлежал ли серверу, с которым клиент намеревался связаться), но, по крайней мере, у сервера есть способ, чтобы не было поддельного сертификата в середина.

В HSTS (о котором вы упоминаете) также есть способ заставить клиента принудительно выполнять эти проверки (см. раздел 8.4). RFC 6797). Однако это работает только в том случае, если клиент уже знает, что HSTS необходимо использовать (либо в качестве предварительно загруженного хоста, либо после первого посещения), и, конечно же, полагается на то, что клиент поддерживает HSTS (поддержка браузеров по-прежнему ограничена).

person Bruno    schedule 30.05.2015