Chasing Cyber - #31 - Myth Busting
Public Wi-Fi, QKD confusion, and Amazon's big decision.
Does Coffee Shop Wi-Fi Give You Jitters?
Unpopular opinion: you don't need a VPN to use public Wi-Fi.
Consumer VPN vendors want you to fear the Starbucks Wi-Fi. However, with recent enhancements to cryptographic protocols, the risks are dwindling.
For years it's been safe to exchange confidential data using public Wi-Fi. TLS protects every important service you access, including online banking and work emails. The data is end-to-end encrypted, offering no option for an evil employee to spy on it.
Now, privacy is a different matter. Some folks don't want the Wi-Fi owner to know which websites they are visiting. There are two ways this information can leak, and both routes are becoming less viable.
The first is through DNS queries. Historically, these have been sent in plaintext, which exposes the website you want to visit. However, modern browsers support encrypted DNS queries, which plugs this gap.
The second leak is via TLS handshakes. One of the messages sent during the handshake is the ClientHello, which exposes plaintext information about the server you want to connect to. However, a solution is on the way, called encrypted ClientHello (ECH). A draft RFC is nearing completion, and major players, including Cloudflare and Mozilla, are supporting the initiative.
Once all these pieces are in place, public Wi-Fi will be risk-free. Even today, the biggest risk is that a skilled hacker might figure out which domains you visit, but they won’t be able to see the specific pages you access. For most of us, that's not a big deal.
If you're paranoid enough to worry about that, what makes you think you can trust a $5/month VPN provider?
P.S. Thanks to Prof Bill Buchanan for writing about this recently - I wasn't aware of ECH until then.
Myth-Busting Quantum Key Distribution
“Quantum key distribution doesn't improve security because it relies on a classical authentication channel.”
I still hear this viewpoint being touted by people who, frankly, ought to know better. To explain why this is wrong, we need to consider something called "everlasting security".
A key exchange protocol that exhibits everlasting security is immune to future advances in cryptanalysis. Even if the algorithms used in the key exchange are broken, the keys will not be revealed.
QKD offers everlasting security, provided the authentication channel is not broken during the execution of the protocol. Said another way, an attacker would have to possess a zero-day exploit for the classical channel and execute it during the time it takes for the QKD protocol to complete. If this is not accomplished, the keys remain secure indefinitely.
This is a stronger guarantee than offered by key exchanges that rely on public-key cryptography. Here, an attacker could record the exchange and attack it in the future, using advances in cryptanalysis. For example, if ECDSA was broken in two years, an attacker could decrypt the recorded key exchange and steal the key. This would not be possible if QKD were used.
That being said, QKD faces many challenges that prevent its widespread adoption. So we will continue with classical key exchanges for quite some time!
Amazon’s Subtle But Important Decision
AWS services now prioritise post-quantum security over performance.
If a connecting client advertises support for PQC algorithms, the server will select them, even if it introduces additional round-trip times.
This decision is more important than it seems.
AWS could have taken a different path, preferring well-established classical algorithms unless the client forced the selection of PQC algorithms. However, they've opted to use PQC by default.
If AWS left it to clients to mandate PQC algorithms, the global migration would be slower, and we would discover errors and issues further down the path.
I hope other service providers follow suit so the transition to PQC will be as seamless as possible.
You can read more about Amazon's work here: https://aws.amazon.com/blogs/security/customer-compliance-and-security-during-the-post-quantum-cryptographic-migration/.