Live data from Hacker News

Tell HN: Domain fronting to be blocked on Azure

news.ycombinator.com

71–80 of 132 posts

Re: Tell HN: Domain fronting to be blocked on Azure

#71

How does domain fronting negatively affect microsoft? Why do they care? Is this all just about making peoples lifes worse?

Domain fronting leads to collateral damage in terms of blocking. If I really want to block X and X is using domain fronting to blend in with traffic on a given CDN, that CDN is going to get blocked.

CDN customers that are having their stuff blocked because of that are not going to be happy, in general.

Re: Tell HN: Domain fronting to be blocked on Azure

#72
Google removed domain forwarding the day after a certain authoritarian government started blocking their cloud services back in 2018. Amazon removed domain forwarding a couple weeks later.

Much like back in the 1930s, various major corporations are sending a clear signal about how much they value human rights versus making money. Personally, I buy into the whole argument that we can keep capitalism ethical by "voting with our money" and it's up to the people to boycott unethical companies. I seem to be something of a radical though in today's society.

Re: Tell HN: Domain fronting to be blocked on Azure

#73
post #47

Earlier quoted context omitted.

In the UK if you're under age and you decided to buy a knife you will have a lot of difficulty unless it's a little folding (but non-locking) pocket knife, like the small Swiss Army type utility knives. Indeed legally as old as 17 you can't even buy a steak knife in England although you can in Scotland. Once you've bought a knife, it will usually be illegal to carry it in public unless you have a good reason, and "se…

I'm not trying to be an asshole, but we don't get much info from UK here besides things like the Queen dying, so I have to ask, Does it work? I mean, are instances of kids The reason I'm asking is because as a kid, if I had been told to not do something, I'd just find a way to do it. Not to use it, but to find loopholes and just say, _so what?, I can do x_

Another piece of anecdatum: a vague friend of mine once had a routine traffic stop by the police as he'd renewed his car insurance on the day it expired and the change hadn't made it onto the database they use yet. The police officer asked something like "just as a routine question, do you have anything on you that you might think you shouldn't have, like knives etc". He was (at the time) a professional chef and had a large roll of huge, high end kitchen knives on the back seat of the car. He also had chef's whites and was driving to work. The policeman said that apparently a few smarter drug dealers had started doing that (keeping them in a roll) as it was more plausible that they'd be cooking with them rather than stabbing their mates. The give away, apparently, was that they'd just have one massive one and not bother with the chef's job and still end up with a few years in prison.

My friend "got" a nice chat, and went on with his day, but did later comment that had he not had the outfit to go with them, and a vast array of obvious kitchen tools, he thought that they'd probably look at it a lot more seriously.

Re: Tell HN: Domain fronting to be blocked on Azure

#74

For anyone else wondering what domain fronting is: > Domain fronting is a technique for Internet censorship circumvention that uses different domain names in different communication layers of an HTTPS connection to discreetly connect to a different target domain than is discernable to third parties monitoring the requests and connections. https://en.wikipedia.org/wiki/Domain_fronting Cool, so we are bowing down furth…

It's been many years, and I am still angry and disappointed by Cloudflare's decision to block domain fronting and drop Lantern as a customer. Lantern was one of the most effective Great Firewall bypass proxies at the time, and Cloudflare was expanding in China. (I was at Cloudflare at the time, but I don't have private information on the deliberation. I strongly considered quitting over it, maybe I should have, but I…

The insinuation is that somehow we had to stop domain fronting because “China”. That’s false.

What actually happened was we started to get reports from customers that we were serving content from unrelated sites under their domains. Wasn’t happening a lot but for a reverse proxy that’s terrifying and about as bad as it can get. And what made it even weirder was that the domain fronting was connecting to other proxy servers outside Cloudflare and so we literally had situation where a Cloudflare customer's website suddenly served up google.com (not a customer).

The issue was domain fronting where SNI didn’t match Host causing us to handle the traffic incorrectly sometimes (infrequently but not zero). Since standard use of the Internet doesn’t need SNI and Host to not match we blocked the use of domain fronting very fast to ensure the integrity of our service. Lantern was domain fronting tickling this bug and causing our customers trouble.

Hence we dropped domain fronting.

I remember this well because I actually debugged it myself and reported the problem in Jira. You weren’t involved and inventing a story about “China” is dead wrong.

Re: Tell HN: Domain fronting to be blocked on Azure

#75

Earlier quoted context omitted.

It’s too late. Whole countries block all eSNI requests, so it’s always going to fail open.

Yeah, I believe China doesn't even allow TLSv1.3

Not allowing TLS 1.3 means nothing (no modern web sites) works. Modern browsers and servers both speak TLS 1.3 and if they can't they give up. Some things don't work in China, but China wouldn't have a thriving economy if nothing was working. So no, they did not block TLS 1.3 although it's interesting how this rumour seems to have self-popularised. China blocks certain popular sites, but it does not block whole protocols or protocol versions.

This is actually a small triumph for the people responsible for RFC 8446. With previous iterations of TLS it was always discovered shortly after release that idiots broke stuff and so a "fallback" was necessary to allow you to speak the previous version. Such fallback is dangerous because an adversary can thus forcibly downgrade you to an older protocol, and thus attack old protocols even if the new protocol is safe.

How is it done? That is, how does TLS 1.3 avoid downgrade attacks?

When a TLS 1.3 server finds itself talking to somebody over TLS 1.2 (for example maybe a rather archaic web browser is connecting) it scribbles over some of the bytes labelled "random" in its Hello message. It scribbles 44 4F 57 4E 47 52 44 01. Which in ASCII spells "DOWNGRD".

Those bytes don't mean anything special in TLS 1.2, they're just a strange coincidence. But if you're a TLS 1.3 client, seeing those bytes means a Downgrade attack was attempted. So you immediately give up, you are being attacked.

So you might think well, a bad guy could just change those bytes blind right? Nope. The "random" field is used by both parties to choose parameters they're going to verify in a moment to check everything is safe. If you can change the bytes the values will be different and the connection fails anyway.

Re: Tell HN: Domain fronting to be blocked on Azure

#76

Earlier quoted context omitted.

It's been many years, and I am still angry and disappointed by Cloudflare's decision to block domain fronting and drop Lantern as a customer. Lantern was one of the most effective Great Firewall bypass proxies at the time, and Cloudflare was expanding in China. (I was at Cloudflare at the time, but I don't have private information on the deliberation. I strongly considered quitting over it, maybe I should have, but I…

The insinuation is that somehow we had to stop domain fronting because “China”. That’s false. What actually happened was we started to get reports from customers that we were serving content from unrelated sites under their domains. Wasn’t happening a lot but for a reverse proxy that’s terrifying and about as bad as it can get. And what made it even weirder was that the domain fronting was connecting to other proxy s…

As I said above, I was not involved in the deliberation, so I don't know the reason domain fronting was blocked. I clearly remember it being an explicit decision though, not a bug mitigation, and Matthew's explanation on HN makes no mention of a technical issue.

I do remember one terrifying bug that Lantern was tickling which caused responses to cross streams, and I was involved in debugging that, but it was not due to the Host/SNI mismatch. It just happened around the same time that domain fronting was blocked. (I am going to respect my confidentiality agreement here, but if you want I can share what I remember here or in private.)

Re: Tell HN: Domain fronting to be blocked on Azure

#77

Some of the key people behind ECH (Encrypted Client Hello, work to hide SNI and other potentially sensitive information from the Client Hello in TLS) work for outfits which would be delivering basically the same functionality via ECH, such as Cloud companies and CDNs. Of course it is possible they don't intend to ever deploy this (but then they've wasted months of work which seems strange) or that their employers won…

How would this work? How is the name encrypted before the pubkey is known? I've seen that it uses DNS to fetch another pubkey, but there is no encrypted DNS (DNSSEC is signed DNS). DNS-over-HTTPS is only used in the last-mile --- recursive resolver to client, not NS to NS, so the request is still sent in plain. Besides, DNS-over-HTTPS still requires ... TLS ...

[deleted]

Re: Tell HN: Domain fronting to be blocked on Azure

#78

Some of the key people behind ECH (Encrypted Client Hello, work to hide SNI and other potentially sensitive information from the Client Hello in TLS) work for outfits which would be delivering basically the same functionality via ECH, such as Cloud companies and CDNs. Of course it is possible they don't intend to ever deploy this (but then they've wasted months of work which seems strange) or that their employers won…

How would this work? How is the name encrypted before the pubkey is known? I've seen that it uses DNS to fetch another pubkey, but there is no encrypted DNS (DNSSEC is signed DNS). DNS-over-HTTPS is only used in the last-mile --- recursive resolver to client, not NS to NS, so the request is still sent in plain. Besides, DNS-over-HTTPS still requires ... TLS ...

As I understand, the public key that is used for authenticity is not the same as the one being used for encryption — at least since TLS 1.3, before it depends. The scheme is known as forward secrecy. For the encryption, an ephemeral key pair is used on both sides. These pairs are only used for the Diffie-Helman (or similar) key exchange. Therefore an encrypted connection can be established, then SNI can be exchanged over the encrypted connection, and then the remote can provide the signed nonce together with it's PKI public key, with which it establishes trust respective to the SNI.

Re: Tell HN: Domain fronting to be blocked on Azure

#80

For anyone else wondering what domain fronting is: > Domain fronting is a technique for Internet censorship circumvention that uses different domain names in different communication layers of an HTTPS connection to discreetly connect to a different target domain than is discernable to third parties monitoring the requests and connections. https://en.wikipedia.org/wiki/Domain_fronting Cool, so we are bowing down furth…

We have ECH (previously known as ESNI) now, is that not just domain fronting in a new form?

No, because with ECH/ESNI the hostname in both layers (the TLS connection and the HTTP Host header) still matches. The only difference is that the hostname on the both layers is no longer visible on the wire, while without ECH/ESNI the hostname on one layer (the HTTP Host header) is hidden but the hostname in the other layer (the TLS connection) is visible. And you could still do domain fronting even with ECH/ESNI (making the hostname on each layer differ), though it would be kind of pointless.
Post reply on HN