• by davidfiala on 3/21/2025, 7:37:18 PM

    This is great news.

    I love thinking about exploit scenarios that remain.

    Very niche, but attackers on a LAN or in the path to cloudflare's edge servers probably have a small window to still exploit this.

    In my case, I have about 25 millis before the RST packet arrives from CF:

    ip=$(getent ahosts api.cloudflare.com | awk '$1 ~ /^[0-9.]+$/ { print $1; exit }') && time bash -c "exec 3<>/dev/tcp/$ip/80"

    (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)

    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.

    Another niche idea/risk: TCP Fast Open might also provide an avenue for the HTTP data to get sent before the CF'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.

  • by everfrustrated on 3/21/2025, 9:25:40 PM

    While this is a direction of travel I like to see, I have mixed thoughts on the true security benefit.

    If you can MITM the http connection, you can still intercept the TCP RST.

    Still, it's an improvement and will hopefully help drive other CDNs to offer it.

  • by tracker1 on 3/21/2025, 8:10:59 PM

    It's definitely an interesting idea and one I'm not opposed to. Slightly annoyed that when entering $NAMEONLY and hitting enter in a browser it doesn't default to trying https first.