Как я могу быть уверен, что получу достоверный ответ на запрошенный IP-адрес?

Обычно вы выполняете вход в систему к своему Интернет-провайдеру, используя указанные учетные данные пользователя. Затем вы получаете IP-адрес и получаете доступ к их внутренним серверам имен, так что вы можете запросить определенное доменное имя и получить IP-адрес в ответ.

Но как я могу быть уверен, что я получу нужный мне сайт? Как я могу быть уверен, что мой провайдер не использует поддельные IP-адреса или что они не перенаправляют меня на «поддельные внутренние серверы» (с одинаковым IP-адресом или без него)? Например: если я спрашиваю для example.com, получите его IP, и они покажут мне простой клон этого сайта.

Как сделать так, чтобы IP существовал только один раз? Можно изменить IP-адрес localhost на что-то другое, так что же происходит с веб-адресами?

Конечно, если интернет-провайдер подделает пункт назначения, это повлияет и на других пользователей, если они запросят тот же результат. Но даже в этом случае: разве нельзя будет отфильтровать пользователей по их учетным данным провайдера и взломать их?

Возможно, в моем понимании есть какое-то недопонимание. Но я не понимаю, чего мне не хватает.

— NgwVLHUeang
источник

Если ваш провайдер является вредоносным, вы, вероятно, очень мало можете сделать - вы не можете ни с кем разговаривать, не пройдя через него, поэтому вы в его власти. Но пока вы имеете дело с крупным авторитетным провайдером, это маловероятно. (Хотя, если суд прикажет им связываться с вами, они могут.) Атаки третьих сторон представляют большую угрозу; увидеть ответы.

— Скотт

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

— NgwVLHUeang

Ответы:

Да, DNS небезопасен. Если вы действительно хотите знать, что вы разговариваете с нужным вам сервером, вы должны аутентифицировать сервер. Вот что мы делаем. Мы не доверяем DNS как безопасному, и мы реализуем необходимую нам безопасность где-то еще, например, TLS (Transport-Layer Security).

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

Чтобы доказать, что сервер является законным владельцем сертификата (а не какого-либо самозванца, который украл действительный сертификат), подтверждение связи TLS позволяет ему доказать, что ему известен секретный закрытый ключ, который образует соответствующий набор с открытым ключом в сертификате. Конечно, это делается без раскрытия самого секретного ключа.

Существует предложение по обеспечению безопасности DNS, которое называется DNSsec, но оно существует уже много лет и, похоже, никуда не денется. Это может никогда не стать широко развернутым. В настоящее время существует предложение для «DNS через HTTP» (DoH, произносится «D'oh!»), Которое могло бы защитить DNS, делая это по HTTPS.

— Spiff
источник

Я говорю об уровне 3 OSI, а не уровне 5. Пожалуйста, проверьте мой комментарий к mshafer. Это не контролируется, как интернет-провайдер направляет ваш запрос, не так ли? ru.wikipedia.org/wiki/IP_routing

— NgwVLHUeang

@NgwVLHUeang, вы правы, интернет-провайдер может направить вас куда угодно. Вот почему мы используем такие вещи, как TLS, чтобы проверить пункт назначения, а не маршрут, как говорится в ответе.

— Кик

Там много вопросов. Я постараюсь заняться парой.

Но как я могу быть уверен, что я получу нужный мне сайт? Как я могу быть уверен, что мой провайдер не использует поддельные IP-адреса или что они не перенаправляют меня на «поддельные внутренние серверы» (с одинаковым IP-адресом или без него)? Например: если я спрашиваю для example.com, получите его IP, и они покажут мне простой клон этого сайта.

Итак, это называется атакой «человек посередине» ( https://en.wikipedia.org/wiki/Man-in-the-middle_attack ). Плохая новость заключается в том, что они довольно распространены (по крайней мере, в отелях и других местах с открытым Wi-Fi, хотя это также трудно доказать, - https://www.theregister.co.uk/2016/06/01/teamviewer_mass_breach_report/ ). Но один из способов защиты от этого - не использовать DNS-сервер отеля (или, в вашем случае, вашего интернет-провайдера). Есть несколько хороших: https://www.howtogeek.com/122845/htg-explains-what-is-dns/

Я был бы удивлен, если бы авторитетный провайдер сделал это (и был пойман), но хорошей идеей является использование вашего собственного DNS (опять же, вы все еще доверяете кому-то) и / или VPN, когда вы не в домашней сети.

— mshafer
источник

@Spiff - У меня недостаточно кредитных баллов, чтобы поднять ваш ответ, но: thumbs_up:

— mshafer

Я больше обращался к настройке IP-адресов, а не к реальной системе доменных имен. В небезопасных местах, таких как отели, аэропорты и т. Д. Я знаю, что небезопасно просматривать без HTTPS или защищенного соединения, такого как VPN, для защиты паролей и конфиденциальности. Что я думаю: доступ к «8.8.8.8» из вашей домашней сети никогда не будет безопасным, так как вы никогда не сможете получить достоверный ответ Google. Вы должны доверять своему провайдеру, чтобы получить реальную страницу, а не зеркальный клон. Вы не можете подтвердить, что означает 8.8.8.8. Поскольку это зависит от вашего интернет-провайдера, какой маршрут данных он выберет.

— NgwVLHUeang

И HTTPS не спасет вас от этого. Как провайдер мог настроить свой собственный CA, чтобы получить зеленый замок для клонированного веб-сайта.

— NgwVLHUeang

@NgwVLHUeang Похоже , HTTPS бы спасти вас от этого, так как вы должны идти на оригинальный сайт , который соответствует доверенному сертификату от вашего доверенного центра сертификации - это поддельный сайт клона потерпит неудачу проверки ЦСА.

— Xen2050

@NgwVLHUeang Вы никогда не разговариваете с ЦС, поэтому злой интернет-провайдер не может связываться с этим. Сертификат CA (и, следовательно, его открытый ключ) был предварительно установлен в вашей ОС или браузере. Он не скачивается вживую. Вы используете открытый ключ CA, который вы уже знаете и которому доверяете, для проверки существующей ранее криптографической подписи CA на сертификате сервера, к которому вы подключаетесь.

— Spiff