При предотвращении SSL “Вы собираетесь быть перенаправленными к соединению, которое не безопасно”. сообщение

  1. тестируют функции; это обычно означает тестировать открытый интерфейс - на, не должен все функции быть доступным через открытый интерфейс? если они не, то они не функции! Могут быть исключения к этому, но я не могу думать ни о ком.

  2. тестируют открытый интерфейс; любые методы, которые не называют прямо или косвенно от открытого интерфейса, не необходимы . Мало того, что они не должны быть протестированы, они не должны существовать вообще.

9
задан Glorfindel 1 April 2019 в 07:59
поделиться

8 ответов

Атака, против которой это предотвращает, представляет собой полосу сеанса SSL «человек посередине». Сообщение отправлено по уважительной причине.

1
ответ дан 4 December 2019 в 12:20
поделиться

Некоторое время назад я столкнулся с той же проблемой. Итак, я заглянул внутрь fiddler, чтобы увидеть, как это делает почта Yahoo. Вот шаг, который я видел (и использовал на своем сайте):

Пользователь заполняет зашифрованную форму SSL и отправляет POST на сервер. Сервер аутентифицируется и выдает какой-то сценарий для перенаправления клиента

<script language="JavaScript">
<!--
window.location.replace("~~ non-SSL URL ~~");
// -->
</script>

Я полагаю, что код на стороне клиента существует, чтобы избежать этого диалога.

8
ответ дан 4 December 2019 в 12:20
поделиться

«Как мне этого избежать?»

Не стоит!

Хотя вы можете попробовать это с помощью JavaScript. Это может работать в одних браузерах и не работать в других.

«Какова цель этого диалога?»

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

«SSL приведет к увеличению трафика / вычислительной мощности»

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

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

«Yahoo делает это. Yahoo - большая техническая компания. Вы умнее Yahoo?»

Некоторые риторические встречные вопросы :

  • Вы такая крупная техническая компания, как Yahoo?
  • Помешало ли то, что крупная техническая компания Microsoft выпускать дрянное программное обеспечение?
  • Вы должны поддерживать дрянные старые браузеры (со взломанным SSL), как Yahoo. ?
5
ответ дан 4 December 2019 в 12:20
поделиться

В первую очередь используйте SSL для всей страницы !

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

1
ответ дан 4 December 2019 в 12:20
поделиться

Что касается цели: чтобы вы знали, что ваше соединение не будет быть зашифрованным SSL больше. Возможно, вы уже видели, что соединение зашифровано, и можете подумать, что оно все еще есть, поэтому в этом предупреждении говорится «Для ясности, любые данные, которые вы отправляете отсюда, будут в виде открытого текста» .

Как о том, как его подавить: AFAIK, вы не можете, это дело браузера, в чем бы смысл сообщения в противном случае? Несмотря на то, что существуют обходные пути, такие как перенаправление на стороне клиента, я не думаю, что вы следует попытаться обойти такие "проблемы" клиента. Если браузер хочет быть подробным, позвольте ему. Есть "Больше не показывать" Кроме того, IMHO, если бы браузер стоил своей соли, он все равно бы всплывал с этим предупреждением, даже если вы использовали уловки перенаправления на стороне клиента.

1
ответ дан 4 December 2019 в 12:20
поделиться

Gmail, Yahoo и т. Д. Используют SSL для зашифрованного iframe, который аутентифицируется, но нет никакого перенаправления на странице, о котором вы говорите. Для этих систем входа в систему вся страница не зашифрована.

0
ответ дан 4 December 2019 в 12:20
поделиться

Просто укажите вашему клиенту последние атаки на содержимое смешанного режима (см. CookieMonster на fscked.org ) и прокси-атаки (против сайтов, доступных как по http, так и по https, поиск Pretty-Bad-Proxy). Он мог бы пересмотреть свое решение.

Гораздо легче обеспечить правильную безопасность, если вы имеете дело только с одним протоколом, не смешивая два. SSL добавляет немного накладных расходов, но это ничто по сравнению со стоимостью взлома.

1
ответ дан 4 December 2019 в 12:20
поделиться

читать: http://support.microsoft.com/kb/883740 который говорит, что это исправлено в исправлении или с измененным параметром реестра. Однако не все процессоры IE6, которые мы используем, имеют эту проблему, и их настройки реестра не соответствуют тому, что говорится в этой статье. Также некоторые из них выдают сообщение - XPsp3 и IE6 sp3.

У нас есть экран входа в систему https, который использует код для входа в 15 других (http) доменов, и некоторые из наших пользователей IE6 должны нажать «Да» 15 раз. Для них это неприемлемо. Нет, мы не можем контролировать, какой браузер используют все наши пользователи. Некоторые из них несовместимы с обновлением до IE7.

Мы ищем атрибут конфигурации для каждого пользователя, который можно настроить, чтобы подавить это сообщение. Мы идентично настроили «плохой» браузер с настройками, соответствующими тому, который не выдает сообщение msg. Безопасность в Интернете и интрасети, а также дополнительные настройки и прокси (нет). Также сетевые подключения. Пока без радости.

Есть идеи?

0
ответ дан 4 December 2019 в 12:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: