e2e means you don't have to worry about transparent 3rd parties keeping secrets for you. It prevents casual abuses of your privacy and sets the bar for violating it (deserved or not)
If size is your only criteria then you might be right, but look at the company policies on privacy. Cloudflare has some pretty specific customer-oriented privacy policies. Comcast's policies are specifically set up to sell you and your information. That's a meaningful distinction and one with some (not much, but some) legal weight in the US.
The site icon is redundant though. Keybase wouldn't appear if they weren't verified on the site. If you meant "website icon" then that doesn't resolve the "mess" for people with multiple site proofs - I already have two and might be getting a third one soon. I know a few people who have four or five.
The as-a-dropdown-from-Keybase is probably the best solution.
It does not. There are some passive decryption tools that will no longer work because they functioned by having non-forward-secure connections and the server's private key installed in the decrypter. (But one can just not support TLS 1.3 at the server to keep them working.)
MITM proxies, which are trusted by the client and which terminate and recreate the TLS connection, will continue to function. (Assuming they implemented TLS 1.2 correctly, which some didn't.)
Does that assume that all of the components (browser and server) support 1.2 as well? In a theoretical future state if I disable 1.2 on my browser doesn't that mean I won't trust a MITM box.
Did banks and other network operators who require monitoring their traffic just deem the MITM proxies too expensive or complex, or what was the reason for their protest?
The main complaint seems to be that the proxy can no longer use the Triple Handshake attack to inspect only part of the connection and pass the rest through, it's instead forced to do a full MITM all the time: https://tools.ietf.org/html/draft-camwinget-tls-use-cases-00
Except they'll just start checking SNI instead to see what sites you're browsing. Getting rid of triple handshakes is good from a theoretical perspective, but it does nothing at all to increase your privacy against middle-boxes.
https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 is the current state of the effort to encrypt SNI. It's a good overview of which obvious ideas can't work and why, plus some complicated ideas that might work, with two of them expanded to a state where it's reasonable to start developing opinions about them as engineers or cryptographers.
Ultimately the destination is that one of these two (or potentially some upset newcomer if it's written up and presented soon) becomes the agreed way to do SNI encryption, and perhaps in 2019-2020 we start seeing clients & servers that can really do it.
For the short term it remains unclear which of the following three things will happen, both generally and in particular environments:
1. (Bad) Organisations bite the bullet and MitM Proxy everything, expenditure on MitM proxies sky-rockets, lawyers spend lots of time & money in court arguing that they _had_ to MitM proxy everything even though it violated employees legal rights.
2. (Good) Organisations suck it up and get rid of MitM proxies almost everywhere, preferring edge solutions that actually still work with TLS 1.3 without needing to spend loads of cash on MitM proxies for everything.
3. (Meh) Organisations refuse to use TLS 1.3, insisting on downgrading everything to TLS 1.2 and crossing their fingers that never becomes obsolete or insecure (see also Windows XP)
With SNI, they can't easily see whether you're looking at https://en.wikipedia.org/wiki/Cat or at https://en.wikipedia.org/wiki/Pornography (just looking at the size is not enough; Wikipedia has millions of pages, thousands of then are changed every day, it has a variable-sized HTML comment, and the HTML size also changes when you're logged in), while with the triple handshake attack, they can see the full HTTP request and response headers, while avoiding most of the cost of being "in the middle" during the actual content transfer.
Basically everybody selling middleboxes screwed up, some worse than others but even the workaround in TLS 1.3 could best be understood as a hint that most middleboxes are ineffective garbage.
Yes and no. Passive eavesdropping where the eavesdroppers has been given the servers' RSA keys no longer works, but that's about it. This was mainly something that banks did for very, very defective reasons.
Other types of MiTM still work, such as an active MiTM through a malicious root certificate.
This is not true. The client can simply skip the certificate verification, making the connection unauthenticated. Raw Public Keys (which are basically simplified X.509 certificates), can also lead to unauthenticated connections.
In fact, Appendix C5[1] reads:
Previous versions of TLS offered explicitly unauthenticated cipher
suites based on anonymous Diffie-Hellman. These modes have been
deprecated in TLS 1.3. However, it is still possible to negotiate
parameters that do not provide verifiable server authentication by
several methods, including:
- Raw public keys [RFC7250].
- Using a public key contained in a certificate but without
validation of the certificate chain or any of its contents.
It's fundamentally very similar to the sorts of issues you end up with if you compress then encrypt. If the attacker can make some educated guesses about the plaintext prior to the compression, the compression ratio can be a very powerful tool in their arsenal.
On the other hand, if you could do it, you'd probably have invented a convoluted speech-to-text (where text is a index into a dictionary of words). Note that you would also likely lose things like inflection, voice, accent etc - so while it might work as a texting system with voice input - it would be a poor substitute for voice chat..
This is HN. A link to an example would be appreciated.
Edit:
To clarify, I work with audio codecs too, and can't really
think of parameters (other than the compression level?)
that would make much sense to adjust on the fly.
If "AI" is used for more than just a buzzword here, then
I imagine the answer must be quite interesting.
They probably adjust the incoming / outgoing buffer sizes (and therefore the audio delay, since it's live) to account for packet loss.
They might also prioritize traffic depending on how full your buffers are.
I can only assume Youtube and Netflix do similar parameter tweaks to optimize their video delivery based on the connection (totally filling the buffer to a max size all the time would waste bandwidth, but if the client has lots of packet loss they need a larger safety net).
Most people will just ignore it and call a fluke. Just like everyone does when their servers signatures changes. everyone just save the new key and type their passwords away ;)
