Microsoft runs a bug bounty program. NightmareEclipse (that’s the researcher’s handle) allegedly participated and Microsoft did not honor their part of the bug bounty program terms.
This is a completely different situation - a company evaluates the security of a prospective vendor prior to entering a business agreement.
Minority of sites have global traffic. This is especially true for non-English sites.
So, while average request may have to travel quarter (not half) of the Internet globe, median request from the set of requests that matter has much lower latency.
Barcelona to Stockholm is about 65ms, ~35ms to Amsterdam, ~43ms to Frankfurt.
HTTP/3 is ubiquitous, you don’t get TCP handshake penalty anymore in major browsers.
nginx can do about 20krps per CPU for static files. You only need CDN if you want to improve time to DOM loaded in locations where time to first byte is over ~100ms and can be improved with local caching.
If all your users are in Spain and you don’t care how fast your site loads for a techbro in California, you indeed don’t need CDN.
I might be missing something: is this any conceptually different from using PKCS11 provider for TPM in OpenSSL?
Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.
> PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover.
You don’t need that if you include quote in CSR and then CA validates the quote and writes the validation result in the certificate. Certificate then contains proof that private key is in TPM.
I think your central thesis is that at the time of TLS establishment, why not use PKCS11 (with a cert signed by a CA that has validated a TPM certification), and I agree: services should probably integrate via PKCS11.
I just read your original comment "is this any conceptually different from using PKCS11 provider for TPM in OpenSSL?" and yes, I agree it's not conceptually different.
The whole post is a PR activity presented as some kind of analysis. It is bs.
First, long-living credentials are the standard because the machinery to rotate them is complicated and, in fact, via indirection requires another set of long-living credentials. Out of all problems that any security engineering team has to solve at an organisation, this one stands high on the cost of implementation, adds friction to everyone involved including end-users, and is low on the value provided (compare to, say, network segmentation).
Second, while proclaiming no long-living credentials, they, in fact argue for concentration of long living credentials in running software that will be the target of intrusion. They say, the options are “a vault that only issues short-lived creds based on long-lived creds that you insert once and that it never gives back” and “a credential-injecting proxy”. Both of those applications hold long-living credentials in memory. Recall, the attacker had root privileges on the node, so dumping the creds from the memory with a little disassembly if needed, was in reach of the AI agent.
Funny enough, they dismiss the working solution: “we had to turn TPM storage off by default on Linux and Windows” - because they could not figure out how to work with TPM? Resealing and the workings of configuration registers is non-trivial, I admit, but totally manageable.
To sum up, I feel the author bends backwards to preach for the religion of short-living credentials even when they are not a solution while providing contradictory arguments for their case. This is why I called it bs.
44 bits of security is not “pretty good”. The post author used Python, but anything more performant would result almost real-time decryption.
There are no performance implications of using a proper 128 key because they are doing AES anyway. If they were resource constrained and choose a variant of TEA encryption due to constraints, it would be understandable, but no, the encryption is implemented in hardware.
There also seems there is no message authentication, a rookie mistake.
44 bits is horrible obviously, but maybe it's fine for this use case?
The attack vector is: an adversary can get close to your water meter and after brute forcing the key, wirelessly read the numbers they could have just physically looked at the water meter to read anyway.
Meanwhile the device owner can decrypt the signal and locally get access to their own data without being tied to the cloud or a proprietary vendor app. I think that's a win.
I have encountered a particular radio bridge type device that by default uses the CSS key as its encryption key to hide its messages from the inquisitive user with an RTLSDR.
I feel like there was some sort of Heated Discussion over whether or not the OTA traffic should be encrypted to enhance shareholder value or not, and someone took the chaotic good route.
Last I tried in my small city in Ohio, it seemed like all of the natural gas meters as well as all of municipal water meters were broadcasting their readings and messages in-the-clear for anyone within RF earshot to decode as long as they had an inexpensive SDR dongle and a copy of (IIRC) rtl_433.
It was summertime and the gas meters were boring, but the water meters were pretty chatty.
If someone eats junk food at McDonald’s it does not mean I should eat junk food at Burger King. If someone does not encrypt their radio comms, it does not mean I should be satisfied with breakable encryption.
SPF allows to say “these IPs are authorised to send emails as example.com”, where DMARC allows to say “I as domain owner recommend to quarantine emails that fail SPF and DKIM”, it also allows finer alignment (ie, matching between different “from” parameters) configuration and reporting by the receivers.
Of course, with absence of DNARC policies, receivers default to some internal defaults, or may ignore the policies altogether. But at least, the big ones send DMARC reports.
Three so-called “cribs” are typically mentioned in literature:
1. Weather reports that were encrypted with Enigma for the High Command and then sent again encrypted with a much weaker cipher for (if I recall correctly) merchant fleet.
2. “Keine besondere Nachrichten” or “Keine besondere Ereignesse” - depending on sources. It means “no important news” or “no important events”.
3. “Heil Hitler” at the end of the message. This one is maybe an anecdote. If something like that would be sent I suspect the radio operators would send “HH” at most.
This is a completely different situation - a company evaluates the security of a prospective vendor prior to entering a business agreement.
reply