TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

HTTPS-only for Cloudflare APIs: shutting the door on cleartext traffic

16 点作者 tech234a大约 2 个月前

3 条评论

davidfiala大约 2 个月前
This is great news.<p>I love thinking about exploit scenarios that remain.<p>Very niche, but attackers on a LAN or in the path to cloudflare&#x27;s edge servers probably have a small window to still exploit this.<p>In my case, I have about 25 millis before the RST packet arrives from CF:<p>ip=$(getent ahosts api.cloudflare.com | awk &#x27;$1 ~ &#x2F;^[0-9.]+$&#x2F; { print $1; exit }&#x27;) &amp;&amp; time bash -c &quot;exec 3&lt;&gt;&#x2F;dev&#x2F;tcp&#x2F;$ip&#x2F;80&quot;<p>(Long command because I wanted to separate the DNS resolution time from the time it takes to send a SYN and then get the RST)<p>An attacker observing network traffic for a SYN could spoof a single ACK and then quickly capture the Request HTTP headers including the auth payload. Often that fits in the first packet.<p>Another niche idea&#x2F;risk: TCP Fast Open might also provide an avenue for the HTTP data to get sent before the CF&#x27;s RST packet is sent, too. I imagine TFO would apply because any connection (even an https one) would have established TFO with api.cloudflare.com, and then one single accidental hit to http instead of https may include payload regardless of the RST? Hmm.
评论 #43440398 未加载
评论 #43440985 未加载
everfrustrated大约 2 个月前
While this is a direction of travel I like to see, I have mixed thoughts on the true security benefit.<p>If you can MITM the http connection, you can still intercept the TCP RST.<p>Still, it&#x27;s an improvement and will hopefully help drive other CDNs to offer it.
tracker1大约 2 个月前
It&#x27;s definitely an interesting idea and one I&#x27;m not opposed to. Slightly annoyed that when entering $NAMEONLY and hitting enter in a browser it doesn&#x27;t default to trying https first.
评论 #43440434 未加载