On 30.10.2011 20:03, Ben Kennedy wrote: > On 30 Oct 2011, at 7:50 am, Alessandro Vesely wrote: > >> We don't need to actually trust the certificate if all what is wanted >> is to encrypt the channel for privacy. > > I bet Sam is going to say: if you don't trust the cert, how can you be > sure that a man in the middle did not provide it and that your > conversation isn't actually being observed?
I looked up a known name and connected to that IP. As far as I trust the DNS, I can trust I'm connected to the correct server. Although this is not unbreakable, I don't see how using TLS could make things worse. I don't understand why a message must be returned as undeliverable if, for example, a MITM attack is underway. A notification is certainly due, but what's wrong with keeping the message queued until the attack is cleared? > Therefore, such privacy is a total illusion. > > On an emotional level I agree with you, however, and certainly an > encrypted (read: obfuscated) byte stream would at least deter a casual > packet-sniffer. Untrusted encryption is still stronger than obfuscation. It can cause systematic server monitoring to become apparent, because systematic DNS changes are visible. An intermediate approach could be to have a "starttls-something" database anyway, where each host's entry contains the state of the last handshake, any of "known CA", "auto-trusted" with fingerprint and dates, or "broken", with suitable rules for state changes -- ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
