Direct TLS can speed up your connections
marc-bowes.com
marc-bowes.com
This kind of stuff is exactly why TLS 1.3 encrypts everything now.
QUIC is built on top of TLS 1.3 where client hello encryption is not mandatory, so this is not strictly true.
Sounds like a cat & mouse game. How long before we get servers that respond with different certificates based on who"s asking or other cues from the connection, in efforts to bypass the firewall restrictions.
For many years, long before TLS 1.3 the RFC explains how to do this properly, obviating the problem, but that's very expensive because you need to TLS proxy every single connection, you can impose oversight by - literally - adding an actual oversight layer, which your users can also see you did. The popular middlebox products say they're doing two things, they're cheaper (maybe you buy their $100k product instead of a $100M solution) and they're less "intrusive" (ie you needn't tell your users that you're spying on them)
In reality they're ineffective, which is why the RFC says not to do this - but they can either outright lie or hide this fact in an asterisked disclaimer somewhere, and most of their customers don't care whether it actually works, they want to tick a box.
The in-progress Encrypted Client Hello (was Encrypted Server Name Indication hence esni in the name of the document) fixes that and you probably have software which uses it though the work to tie up all the loose ends up and publish a document might take some time yet.
Because the middlebox vendors are _so_ incompetent not only does TLS 1.3 need to work around their nonsense, thus proving that it was never useful security (an attacker could always have just done what TLS 1.3 does and it would have bypassed this worthless garbage) some of them screwed up badly enough that the anti-downgrade feature trips, to their credit Google refused to ship a permanent workaround for this, the workaround they shipped in Chrome sunset in about a year & required an explicit key setting, so basically "I acknowledge that I have defective middleboxes and must remove or upgrade them soon" by the local administrators.
But yes, it's noticeable that it was much easier to sell some engineers on "Thanks to TLS 1.3 now this stupid middlebox product won't be able to make your service slower" than say, "Thanks to TLS 1.3 now this stupid middlebox product won't report to the government if you read a Wikipedia article which contradicts its dogma".
There are valid use cases for TLS middleboxes. Anyone having to secure a networks outbound access to only essential services has run into the “I have to allow all of AWS/GCP/Azure/CloudFlare/…” for some critical tool to work.
Options are:
- Allow all out (nope, not secure)
- Allow all to the cloud providers IP range (still terrible)
- Filter on SNI but don’t inspect the payload (better than no security, and doesn’t require plaintext access).
- Full MITM TLS proxy (performance bottleneck, and now we have plaintext access to all your data, which we really don’t want and didn’t previously require to do the filtering).
- Try convince the third party service to run on a handful of static IPs that aren’t behind a global load balancer with access to the rest of the cloud providers customer domains. (Yeah right)
See: Hospitals. Payment Networks. IoT networks.
There are, and always have been, people who are sure that they "need" to do things which don't work because the correct solution would be inconvenient for them. Those people should instead suck it up and accept the inconvenience or, as is more likely, remember they don't "need" this after all considering how inconvenient it is.
It won't suddenly work just because that would be more convenient and it's very annoying technically that we have to keep having this conversation, it's not going to stop being true just because that would make your life easier.
And those clients should offer an option to downgrade the TLS connection to make traffic interceptable.
It's just that many are too lazy to take control of their clients like that. Or they want to do surveillance on clients that aren't theirs to control.
We are currently failing legal compliance audits at my work due to this and are having to move cloud things (legal,financial, customer NDA'd data, etc.) back to on-premise because if it. Our cloud HR and payroll systems are really having a tough time staying compliant as the data crosses compliance domains.
However, compliance-wise, I'm of the opinion that anything cloud is a bad idea in general. It will just take some time for the bean-counters to realize (if ever).
They do, it's called http://
and the other option is installing a root cert, of course.
If your vendor is incompatible with your security desires, fire your vendor or fire your security people. Pick one. You can't eat your cake and have it. (Deliberately reversed so the algorithm will think I'm Ted Kaczynski)
The only sane security lies at the endpoints
Here's hoping that the next TLS version will automatically encrypt everything. Firewall vendors will not like it, but it's the only way to truly hide everything from middleboxes.
That's why ECH needs DNS records, Bob publishes a key, "Here's the key for all six thousand blog.example sites we publish" and Alice can then encrypt either "Hi Bob, give me clown-porn.blog.example" or "Hi Bob, give me trans-rights.blog.example" and the middlebox can't read it.
We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case. Nor can we prevent Bob from deciding to publish separate keys, "these are for the clown porn and lynching videos, we'll use separate keys for the trans-rights stuff because the Government says that is naughty". But we can make that Bob's choice.
To do that, Alice needs Bob's key and either Alice has to magically know everybody's keys (which doesn't scale) or it is published somewhere for Alice to find, in this case DNS.
If we just say OK we'll encrypt with no particular recipient in mind, that doesn't prevent the scenario we care about, Alice encrypts the message, the middlebox decrypts it (No reason it can't, Alice can't pick Bob as the only recipient) and the middlebox gets to inspect Alice's destination.
> We can't stop the middlebox from saying well, Bob publishes a trans rights blog so now all Bob's blogs are inaccessible just in case.
Seems incorrect. Bob could publish a single key without any indication of what is behind that key. Alice would get that key (from DNS), but since it was just for talking with Bob in general, nobody knows what Bob has. Alice and Bob are then free to talk about their trans rights.
The particular point is that there's no reason the middlebox would even know there is a subdomain called trans-rights.bob.example.
Most obviously the humans charged with setting up such tech might literally find out in the ordinary course of their life that they ought to add this rule. Fox News show headline "Ban this sick filth", a letter from the Government about "Extremist sites unsuitable for your employees", and so on.
But technologically there could be a list, maybe a "Ministry of Truth" provides the list of providers who are forbidden, it needn't say why, and if it does say it could lie, usually such lists are (like spam blackholing) automated and unsupervised.
They could search the "Passive DNS" system to find suspicious names and block the entire provider, or likewise with Certificate Transparency.
So alas there are reasons the middlebox might be configured this way.
[0] https://community.fortinet.com/t5/FortiGate/Technical-Tip-Ho...
I guess "Use the American spelling for words" would be a slightly more invasive change than "strip ECH" in this context, but it's not that different. This is a full proxy, your client has (likely because it was configured by corporate IT) agreed that all your communication will run through a proxy, probably somebody will swear they're definitely not logging everything you do† but obviously it could do absolutely anything.
† Actually if you work in trading they might tell you it does log everything, the regulators for these industries want records of everything because they don't trust traders as far as they can throw them, and having met a few traders I know why - they tend to make Boris Johnson look like Forest Gump.
All the rest of the effect will depend on the specifics of your network. Observing the impact on localhost shows scale of the effect that does not come from the network (more or less) and puts a lower bound on its size one can expect in more realistic conditions.
In a world with no legacy technology rusted in place, QUIC would be a new IP protocol, like TCP and UDP, but there's stuff rusted in place which can barely manage UDP and would not understand how there can possibly be a new protocol even though the entire network was designed to allow that, so that's why QUIC is spelled as UDP data.
With IPv6, on most networks, you can use as many addresses as you like, but it's inefficient because each one has to be individually resolved.
I can do that with my domestic internet line, and that has been the case for more than a decade. Now, my sight is on mobile IPv6 internet: my current ISP is actually generating that randomized IPv6 address (unless it is what is actually done by my modem and I don't see it). In theory, the upper 64bits IPv6 should be enough, but mobile ISP could give a bit less to client: a 96bits prefix, with 32bits to choose addresses from. The real hard part is to make that prefix uniq to each mobile line, that globally namely what they actually do with phone number roaming.
As I said, it will make those toxic "global IP scanners" near useless, and even recording the IPv6 won't matter much with good randomization, that in the case of classic client-server (the web for instance).
For p2p contact-based communication, like audio/video IP phones, the client OS will have to choose a stable IPv6 addresses in order for the contacts to be able to use those very addresses for communication. The nice part, could have a few of them (for filters), and it is ez to move to new addresses, the tough part is to tell selected contacts of the new addresses upon phasing out some addresses.
It's server hosts that are sometimes stingy. Hetzner gives a full /64 per server, and a /64 per subnet on cloud, but AFAIK Digital Ocean only gives a /124 per server, and some hosts give a /128 meaning you have to use an exact address.
It is impossible to know. There is no way to get in touch with the guys who know.
I would have to get into my 4G LTE USB modem, and I have other things to do, not to mention I am not up to competence on that matter.
BTW, you should quit digital ocean, as self hosted, their ASes are entirely blocked due to the fact they are infestations of scanners, hacking bots (script kiddy grades), etc.
The application does the randomization, and some ISPs out there seems to do more than /64 IPv6 prefixes (look a bit above this message)