Почему браузеры запрещают не-SSL-соединения, когда веб-страница уже обслуживалась по HTTPS?

Question

После того, как веб-страница обслуживается по HTTPS, мы можем быть совершенно уверены, что они именно те, которые мы намеревались.

На данный момент единственной угрозой безопасности остается то, что сам сайт является вредоносным или имеет уязвимость безопасности .

Например, вы можете ввести данные своей кредитной карты, которые отправляются на их сервер, и их сервер может передать эти данные в общедоступные c.

---

I'm теперь пытаемся выяснить причины, по которым браузеры не разрешают соединения без SSL, когда веб-страница уже обслуживалась по протоколу HTTPS?

Например, браузеры перестают разрешать контент HTTP и WS без SSL и не выставлять API сокетов UDP или TCP.

Для меня существует точно такой же риск, что они все равно не используют SSL на своем сервере. Во всяком случае, HTTPS теперь может давать ложное чувство безопасности.

Я мог бы определить только две причины:

1. Чтобы предотвратить случайное использование веб-страниц без соединений SSL. Поэтому я могу понять, что форма или изображение должны разрешать только HTTPS. Но я считаю, что браузеры должны разрешать, например, UDP-сокеты, но должны создаваться следующим образом (подтверждая, что программист знает о рисках безопасности):

udp = new SomeBrowserAPI.CreateUDPSocket()
udp.amAwareThat("Nothing is encrypted over UDP and I should not send any sensitive data here")
udp.amAwareThat("I cannot confirm the identity of who I am sending data to or receiving data from")

Разработчик на стороне клиента должен заботиться не о рисках безопасности, а о UI et c. Будучи вынужденным связываться с сервером через SSL, бэкэнд-разработчики должны заботиться только о безопасности. Тем не менее, это уже не тот случай. Если вы являетесь разработчиком на стороне клиента, вы можете легко написать вредоносный код на стороне клиента, который считывает ввод пароля и отправляет его на ваш собственный сервер, если ваш собственный сервер также использует SSL (хотя SSL может, по крайней мере, позволить вам идентифицировать кто был ответственным).

Есть ли другие причины? Мои причины / решения / информация верны?

Answer 1

В основных принципах Google есть базовая запись c: Что такое смешанный контент?

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

Когда вы подключаетесь по UDP, вы не знаете

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

Смешанный контент разрушает концепцию безопасных веб-страниц.