blocks|key|1372901|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|entityMap^0^^$0|@$1|2|3|-4|4|5|6|B|7|@]|8|@]|9|$]]]|A|$]]

HTTPS does not prevent DNS spoofing, since these two protocols work at different layers and in fact HTTPS, because of the X.509 certificates that underline the Web PKI, need the DNS (both at certificate issuance time and also at client verification time), while the DNS does not need HTTPS to work (of course when you do not use it explicitly like with the newer &quot;DNS over HTTPS&quot; trend).
DNSSEC instead does prevent DNS spoofing.
Why? Because it is easy to get DV certificate nowadays, and those are delivered after a check either on some HTTP or DNS resource, and if the underlying IP is spoofed, then the certificate is issued without problems.
So, given <code>www.example.com</code> that has a very nice certificate (even an EV one), if <code>example.com</code> is handled by nameservers <code>ns1.example.net</code> and <code>ns2.example.net</code>, then:
<ul>
<li>anyone getting access to <code>example.net</code> domain (controlling it),</li>
<li>or anyone being able to change records on <code>ns1.example.net</code> or <code>ns2.example.net</code></li>
<li>or anyone controlling <code>example.com</code> at its registrar and being able to change its nameservers</li>
<li>or anyone being able to change DNS resolution on the fly for <code>www.example.com</code> at least locally</li>
</ul>
even temporarily, will be able to map <code>www.example.com</code> to an IP address of its choosing (either directly, or indirectly by controlling the nameservers IP addresses instead), and then go to whatever automated DV-issuing well known CA to get a proper validated certificate, that will be recognized as fully trusted by any modern HTTPS client.
Using HTTPS here does not guarantee in any way that the remote end is really what it is: it &quot;guarantees&quot; the hostname but certainly not the IP address!
Exactly to mitigate these attacks (the third point of the list about), good CAs employ the following two techniques (or should employ them) at certificate issuance time:
<ul>
<li>use a DNSSEC validating resolver: if the domain name is DNSSEC enabled, then any on the fly change of records will get detected</li>
<li>use multiple vantage points and correlate the response: for domain names not being DNSSEC enabled, checking their resolution almost at the same time from diverse source will lower (but never render to 0) the risk of someone being able to change the response in-flight (because it would need either to do it in multiple places at the same time, or do it very closely to the nameservers, in which case the attacker is kind of already in the second point listed above, that is the control of the nameservers)</li>
</ul>
And in fact things are even worse than that because an attack can still happen with full proper DV certificate allowance even without any IP address change, if IP addresses are hijacked, as it happen &quot;regularly&quot; with BGP either as an error or an attack. In such cases, it means that someone is able to get all the traffic for a given IP address (or block) and study it exactly at it wants (and it can even be almost impossible to detect - except for some added latencies - if then the traffic is redirected properly to the legitimate owner of the IP). If it asks a CA to deliver the certificate, the DNS or HTTP validation mechanism will end up to the &quot;true&quot; IP except that the traffic to this IP will go to the attacker, and hence the validation will pass.
All of the above happens &quot;regularly&quot;, some recent cases:
<ol>
<li><a href="https://web.archive.org/web/2018/dyn.com/blog/bgp-hijack-of-amazon-dns-to-steal-crypto-currency/" rel="nofollow noreferrer">https://dyn.com/blog/bgp-hijack-of-amazon-dns-to-steal-crypto-currency/</a></li>
</ol>
<blockquote>
Yesterday morning we posted a tweet (below) that Amazon’s
authoritative DNS service had been impacted by a routing (BGP) hijack.
Little did we know this was part of an elaborate scheme to use the
inherent security weaknesses of DNS and BGP to pilfer crypto currency,
but that remarkable scenario appears to have taken place.
[..]
However, the users of networks that accepted the hijacked routes
(evidently including Google’s recursive DNS service) sent their DNS
queries to an imposter DNS service embedded within AS10297.
</blockquote>
<ol start="2">
<li><a href="https://web.archive.org/web/2018/dyn.com/blog/bgp-dns-hijacks-target-payment-systems/" rel="nofollow noreferrer">https://dyn.com/blog/bgp-dns-hijacks-target-payment-systems/</a></li>
</ol>
<blockquote>
As in the Amazon case, these more recent BGP hijacks enabled imposter
DNS servers to return forged DNS responses, misdirecting unsuspecting
users to malicious sites. By using long TTL values in the forged
responses, recursive DNS servers held these bogus DNS entries in their
caches long after the BGP hijack had disappeared — maximizing the
duration of the attack.
[..]
Passive DNS observations between the 10th and 13th of July showed
*.datawire.net domains resolving to 45.227.252.17 – IP address space registered as being in Dutch Caribbean island of Curaçao, but routed
out of breakaway region of Luhansk in eastern Ukraine.
</blockquote>
<ol start="3">
<li><a href="https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/" rel="nofollow noreferrer">https://www.theregister.co.uk/2018/04/24/myetherwallet_dns_hijack/</a></li>
</ol>
<blockquote>
Victims had to click through a HTTPS error message, as the fake
MyEtherWallet.com was using an untrusted TLS/SSL certificate. The
bandits have amassed $17m in Ethereum in their own wallet over time.
[..]
Crucially, this DNS hijacking was possible after miscreants pulled off
a classic BGP hijacking attack on AWS. MyEtherWallet.com uses Amazon's
Route 53 DNS service so that when people try to visit the dot-com, AWS
looks up and returns to web browsers the IP addresses of the wallet
website's web servers.
Between 11am and 1pm UTC today, someone was able to send BGP – Border
Gateway Protocol – messages to the internet's core routers to convince
them to send traffic destined for some of AWS's servers to a renegade
box in the US.
</blockquote>
That last case shows that, even where HTTPS should have helped (the attacker did not even go all the way to generate a DV certificate while they could technically, they just used a simple self signed one, that triggers alerts in any HTTPS client in its default configuration of trusting only a specific list of CAs), finally it does not because people just bypass the warnings. But here it is clearly a UI/UX problem and not the underlying TLS protocol error.

Someone recently boasted about adware which can inject ads from most networks, and using DNS spoofing would make the providers think that the ads were on a website owned by me (i.e. <code>www.myscamsite.com</code>), while the ads are actually on a normal website (i.e. <code>www.stackoverflow.com</code>). This sounds dubious to me, because most websites these days use HTTPS to prevent DNS spoofing. 

My questions:

<ul>
<li>Could this method work on HTTP sites?</li>
<li>Could this method work on HTTPS sites (somehow?)</li>
</ul>

I know the ISP's did it to routers years ago, but that was before HTTPS.

DNS Spoof Adware

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

最近有人吹嘘广告软件可以从大多数网络注入广告，使用DNS欺骗会使供应商认为广告是在我拥有的网站(即www.myscamsite.com)上，而广告实际上是在一个正常的网站上(即www.stackoverflow.com)。这听起来很可疑，因为现在大多数网站都使用HTTPS来防止DNS欺骗。我的问题：这种方法能在HTTP站点上工作吗？这种方法能在HTTPS位点(不知何故)起作用吗？我知道ISP几年前

问DNS欺骗广告软件
EN

回答 1

Security用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问DNS欺骗广告软件EN