2 ms·

> An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the

> An unencrypted webby stream does not expose a browser to anything nastier than an encrypted webby stream. The eventual payload is the same, regardless of the transport. No, my point is that an unencrypted payload is controlled by anyone on your network path (your ISP, anyone on the same open WiFi, ...), so it can be nastier than an encrypted payload. Remember that TLS provides not just encryption, but also authentication.

gerdesj 3y ago
We are now in the realms of risk management etc. An unencrypted TCP stream still has sequence numbers - famously abusable in the past. You can still use them to be reasonably sure that your stream is untampered with, with care. I'm talking about integrity - ie what I sent is what you received or what I requested you to send is what I received. TLS does only provide encryption, it does not authenticate anything. You can use TLS as a wrapper for auth - to make the exchange private or you could pre-arrange a swap of public keys (certificates) via a method that is mutually agreed. That mutually agreed bit is the authentication part but it has nothing to do with TLS per se. You click on a website link that starts with https:// https://, most people allow their browser to use its trust store to decide whether to proceed. Increasingly, browsers are becoming opinionated about this, which is bloody annoying for IT bods. Should you trust MS/Google/Apple/KDE/Mozilla int al to tell you who is trustworthy? No and they don't really (tell you who is trustworthy! All they do is tell you which certification authorities follow the rules. There are not too many rules and they certainly do not ensure anything as such. What you are nearly guaranteed is that if you use things like "Perfect Forward Secrecy" (which cannot be perfect, by definition) and a few other tricks ... your conversation is probably private. Authentication is a whole new ball game as they say several thousand miles to my left and down a bit!

gerdesj 3y ago

We are now in the realms of risk management etc. An unencrypted TCP stream still has sequence numbers - famously abusable in the past. You can still use them to be reasonably sure that your stream is untampered with, with care. I'm talking about integrity - ie what I sent is what you received or what I requested you to send is what I received. TLS does only provide encryption, it does not authenticate anything. You can use TLS as a wrapper for auth - to make the exchange private or you could pre-arrange a swap of public keys (certificates) via a method that is mutually agreed. That mutually agreed bit is the authentication part but it has nothing to do with TLS per se. You click on a website link that starts with https:// https://, most people allow their browser to use its trust store to decide whether to proceed. Increasingly, browsers are becoming opinionated about this, which is bloody annoying for IT bods. Should you trust MS/Google/Apple/KDE/Mozilla int al to tell you who is trustworthy? No and they don't really (tell you who is trustworthy! All they do is tell you which certification authorities follow the rules. There are not too many rules and they certainly do not ensure anything as such. What you are nearly guaranteed is that if you use things like "Perfect Forward Secrecy" (which cannot be perfect, by definition) and a few other tricks ... your conversation is probably private. Authentication is a whole new ball game as they say several thousand miles to my left and down a bit!