Oblivious DoH, OPAQUE passwords, Encrypted Client Hello: Cloudflare's protocol proposals to protect privacy Web infrastructure company Cloudflare is pushing for the adoption of new internet protocols it says will enable a "privacy-respecting internet." These include an updated secure DNS service that hides the identity of the client, a password protocol that means a password is never transmitted to the server, and an encrypted " …
Offline brute force with enough compute and time perhaps.
I guess it’s almost like putting the encrypted password file on pastebin, if it’s encrypted securely enough it should resist attack.
As you suggest, knowing someone’s login should provide access to that envelope, you still need to decrypt that envelope to access the site.
Put another way, it removes the need for hackers to break into a site to steal the password file as it’s effectively readily available for each user.
It could be used to determine if a user name has an account on that protected service unless new dummy envelopes will be sent to queries where accounts don’t exist.
I’m sure they’ve thought of the potential privacy implications, just not detailed in the report.
"I guess it’s almost like putting the encrypted password file on pastebin, if it’s encrypted securely enough it should resist attack."
It's not the encryption that's the problem, it's the users password used to decrypt it. Before trying would require the remote server to validate and then after multiple tries lock the account. Now the attacker can just brute force at will, the site be none the wiser. Crappy passwords still (re)used.
It doesn't really solve the actual problem, the secret usually being easy to guess, it appears to make it worse.
Proper PAKE does NOT enable brute force attacks by an eves dropper or man in the middle. Through the magic of the algorithms each attempt requires a protocol iteration, and any sensible server would stop after a few attempts.
If the server's secrets become known then brute force is possible.
yes, I also thought the same (offline brute force).
However, it can *potentially* eliminate phishing -- but only with browser support I guess. It could even prevent "active MITM" -- the type of phishing that snarfs OTP codes also, from working
I'll have to refresh my memory / understanding of PAKE but if it has an internal Diffie-Hellman type component triggered by the actual password, then the man in the middle cannot learn the session key.
But all this requires browser support. Without browser support -- meaning the password entry window clearly looks different -- the user would have no way to differentiate a phishing site from the normal one.
OPAQUE is, broadly speaking, resistant to offline brute-forcing. It's more resistant than most password-verifier systems in use today, because it uses an oblivious PRF. That not only prevents the server from learning the client's password (as with the best-known and most widely deployed PAKE, Tom Wu's SRP), but also prevents the client from learning the server's salt.
Matt Green has a good write-up on PAKEs, OPAQUE, and why OPAQUE is superior to SRP.
Note that OPAQUE can be implemented with any PRF, so it can be used with scrypt or (better) Argon2 or some other memory-hard PRF, which makes brute-forcing far more expensive than just using something like a salted message-digest function. And the workload is mostly on the client, so it scales.
As with SRP or any other improvement to web authentication, the problem is browser support - because obviously you can't trust a Javascript implementation you download from the server; that has the same threat model as a compromised server harvesting your credentials.
Why is the talk always about DoH and not DoT (DNS over TLS), it is established, many DNS providers use it and it uses, you know, the DNS protocol, it doesn't abuse a different protocol that shouldn't be doing that!
I've been using DoT for a few years now, along with DNSSEC. It works very well and you don't need to break the OS chain of control. Having normal DNS at the OS level and the browser ignoring the DNS settings and using its own DoH settings makes it much harder to track down problems.
My understanding is that the reason the talk is all about DoH is that it solves a problem with DoT which is probably exactly the reason you prefer to use DoT: DoT allows the network operator to force the use of particular DNS servers (which they control).
DoH and DoT are solutions to different problems (in particular, to different threat models).
In practice, now that the idea of DoH exists, DoT is probably dead. In the future, apps/devices/users will either not care about secure name lookups (think cheap IoT devices) and just use unencrypted DNS or they will care and will use DoH to a server they trust (mostly built in to the code). If you try to block DoH they will just tweak it do the same thing but use a less obvious server.
Controlling DNS lookups is, unfortunately, now a dead idea - it was useful for several years but has had its time. That is unfortunate for those of us using DNS as part of securing our network/company/home but there is no point crying over spilt milk - the bad guys have all started using DoH or something functionally the same (e.g. accessing botnet command-and-control servers using HTTPS) so the solutions have to move on.
You haven't blocked my DoH server.
Similarly, you haven't blocked the DoH server for any malware, or for any crap IoT devices that may appear on your network.
In fact, I am guessing you have just blocked DoH servers used by software such as browsers, which tell you what they are using and mostly allow you to configure them to use a different DoH server, or turn it off completely.
So what, exactly, have you achieved?
This is nothing but a grab for your data. I think anyone who believes otherwise is being naive. The new proposal sounds good on the surface, but I strongly suspect all that will happen is a request identifier will start being entered into the query to uniquely and persistently identify most users all the way to the end server. (And source IP is hardly the only way to build such a profile).
Outside this forum, I see no one asking for DoH. Certainly no nontechnical people, and no one who works corporate, IT or security or development. It's a bunch of web advertising companies and CDNs who want to get that valuable DNS query information from you rather than let the ISP have it.
DoT is a lost cause because it's far too much hassle and management overhead to set up at both the client and server side.
There doesn't appear to be much interest from OS and browser vendors to support client-side DoT. Few DNS server implementations natively support DoT. It's also easy to detect and block DoT traffic - anything going to or from port 853 is an obvious giveaway. So why bother wih DoT when you can get the same or better security outcomes with much less hassle by using DoH?
If DoT floats your boat, good for you. But don't kid yourself it's going to go mainstream. The battle with DoH has been lost before it really got started. The browser vendors made sure of that.
I believe these are all stop-gap measures and that the real solution lies in transforming the internet into a high-speed onion routing network, called HORNET.
This is essentially the same as the Tor network, but with the speed of the regular internet. It will be impossible for nation states to block parts of HORNET, less they want to cut themselves off from the internet, with all the economic disadvantages that entails.
In my opinion companies proposing certain new protocols are always suspect. We've seen so-called privacy focused proposals from Google which merely resulted in them having an even larger unfair advantage as far as internet advertising is concerned.
Except the article is nothing to do with blocking / filtering and is, instead all about traffic security. Specifically about denying the servers you are accessing access to data that they do not really need.
Or, in other words, something that HORNET does bugger all about.
> adoption of the "always secure, always private" internet
Yeah, sure, dream along.
Seriously, there are hundreds of lobbyists and millions of dollars saying otherwise, and that's without mentioning the various governments suddenly waking up to the fact that Internet is bypassing their hitherto absolute control on information. The slope to basic privacy gets steeper and steeper by the day, and there is absolutely no interest (and thus money) in it, except from some rare oddballs like myself: The vast majority doesn't mind giving their most private details to Facebook, Google, or whoever else asks for them. They simply don't see the problem even if you try to explain it to them, and some are even flattered somebody is interested in their boring lives!..
So yes, privacy will increase, sure thing. And poverty, illness and starvation will vanish too. Now you'll please excuse me, my flying car is double-parked.
Cloudflare on VPN:
["Why not use a VPN if you want privacy protection? VPN, said Graham-Cumming, is about remaining anonymous from the target you are connecting to, which is a different problem. "Your bank needs to know who you are," he said. Although a VPN also protects privacy, "it's better that we have a widely adopted standard that makes this possible for everyone," he said.]
So wrong. VPN is not about remaining anonymous from the target. VPN is about connecting through an untrusted network, such as public WiFi, Hotel WiFi, Comcast, AT&T, etc. I cannot remain anonymous to the target if I am providing my credentials to login. The problem Cloudflare has is they have a network tool so every problem to them looks like it needs a network solution. How are the ODoH proxies paid? It seems like it may have to develop into another point of data collection to obtain ad revenue to stay afloat.
If browsers already have their secure DNS solution (DoH), how likely are they to adopt another? As alluded to earlier in the article, DNS really has to be a system level service anyway or all programs using names instead of addresses will have to be updated. Leave DNS to the system, implement improvements (not just changes) there. Any increase in complexity has to be justified by great benefit to the system user/owner.
"We've done a bunch of work around WebAuthn, which allows you to use [hardware] keys. We actually support that. But I think passwords are here for a long time because they're easy for people to work with."
While I like the idea of using a hardware key for day-to-day login, passwords aren't going away. After all, what do you do if the hardware key stops working?
Okay, I've not read the paper, so I'm trusting El' Reg's one-line description. I feel pretty safe about that.
If the servers are not storing passwords, but an "envelope", which sent to the client "to be opened", what can this mean in practice?
This is a challenge-response system, nothing more, nothing less. It's pretty easy to wrap PK around a nonce+message to get this effect. However:
1) Every device that a user connects to a service with has to implement the same system, AND must handle the same PK. For the general user, No Sale.
2) In order to prevent replay attacks and the like, the message has to be updated with each successful login. Because connections fail at the most inconvenient time, the client is going to have to store the prior message. This means that internet history CANNOT be wiped. For the security conscious, No sale.
FWIW we've tweaked the article with a link to a fuller description of how it works. It's all about the salts involved. Here's a key part from that explanation:
"OPAQUE gets around this with the following clever trick. They leave the password hash on the client’s side, but they don’t feed it the stored salt. Instead, they use a special two-party protocol called an oblivious PRF to calculate a second salt (call it salt2) so that the client can use salt2 in the hash function — but does not learn the original salt.
"The basic idea of such a function is that the server and client can jointly compute a function PRF(salt, password), where the server knows “salt” and the client knows “password”. Only the client learns the output of this function. Neither party learns anything about the other party’s input."
C.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
