Сайт моего клиента предоставляет сертификат своим клиентам для каждого IP-адреса, когда эти серверы проходят наш тест. Эта сертификация действительна только для IP, который был протестирован. Поэтому мы должны быть теми, кто будет обслуживать сертификат, чтобы мы могли подтвердить, что сайт, на котором отображается наш сертификат, действительно был протестирован нами. Поэтому, когда пользователи клиента нажимают на ссылку на сертификат, они могут быть уверены, что этот сайт действительно был протестирован нами (что сайт не обслуживается другим сервером, который не был протестирован нами, но утверждает, что был) .
Пользователь попадает на наш сайт по ссылке, которая выглядит примерно так:
siteB.com/certificate.php?companyid=1234&serverid=4321
Процесс упростился:
- Пользователь находится на сайте А
- Пользователь щелкает ссылку, ведущую на мой сайт (сайт B), чтобы просмотреть сертификат сайта A.
- Мой сайт, сайт B должен подтвердить, что это действительно сайт A, который пытается отобразить сертификат, полученный сайтом A.
Первоначально я думал, что переменная $_SERVER может иметь значение, указывающее, кто является ссылающимся сервером, но ответы, которые я получил на публикацию вопроса об этом, показали, что, хотя эта информация хранится в $_SERVER["HTTP_REFERER"], она не ненадежен (плагины или пользователь могут изменить это значение).
Поскольку я не могу полагаться на это, мне нужен другой способ проверить, что ссылающийся сервер является тем, за кого он себя выдает. Я рассматривал возможность использования одноразового токена, но тогда действующий сервер мог бы просто распространять токены на другие серверы, принадлежащие клиенту (которые не были протестированы), и таким образом клиент мог заявить, что любое количество его серверов сертифицировано. нами всего за цену одного теста (а также нарушение целостности сертификата).
Мне интересно, невозможно ли для этой проблемы сделать надежное решение, и что лучшее, что можно сделать, - это запутать средства неконтролируемой конечной точки (сервера клиента) для публикации ключа для указания, что они являются тем сертификатом предназначен для (например, подлый клиент должен будет прочитать какой-нибудь запутанный запутанный javascript или дизассемблировать клиентскую программу с закрытым исходным кодом, чтобы обмануть систему).
Моя идея до сих пор такова (и это ужасно):
Мне нужно создать программу с закрытым исходным кодом для запуска на стороне клиента, возможно, через собственный клиент, который будет инициирован при нажатии на ссылку сертификата на веб-сайте клиента (сайт A), который сначала проверит себя на моем сайте (сайт B), а затем откроет трехстороннюю линию связи с сервером сайта A, сайтом B сервер, и пользователь, в котором сайт B будет проверять, что сайт A является тем, за кого они себя выдают, а затем возвращает пользователю либо сертификат, либо сообщение об ошибке, в котором указывается, почему сертификат не может быть загружен (например, время ожидания соединения истекло). ).
Сценарий на сайте B с открытым потоком для пользовательской программы NaCl будет использовать curl чтобы получить IP-адрес(а) сервера(ов) сайта А и проверить.
Для меня это ужасно грубое решение (если это вообще решение), и хотя большинству пользователей не нужно смотреть на чей-то сертификат, заставляя пользователей, которым это небезразлично, проходить через обручи (установка и запуск программы NaCl) просто смотреть на сертификат просто безумие.
Это кажется немного глупым вопросом, но будет ли запуск этого как флэш-памяти таким же безопасным / небезопасным, как запуск программы NaCl?
Конечно, есть лучший способ сделать все это...
