Hi all,
The subject says it all: do you know which providers support TLS (the technology formerly known as SSL) for SMTP, POP and/or IMAP for their residential or small-office dialup/broadband customers?
If you are a provider yourself and you do not offer it: Are there particular reasons? Is it a conscious decision not to offer it or is it that just nobody asked yet?
Thanks, -- Matthias
Hi all,
The subject says it all: do you know which providers support TLS (the technology formerly known as SSL) for SMTP, POP and/or IMAP for their residential or small-office dialup/broadband customers?
TLS for SMTP makes no sence since this will only protect your message enroute from your machine to SMTP server but after that it is all open again.
POP3 and IMAP with TLS (AKA POP3s and IMAPs) are available from number of providers such as Bluewin but not largely advertized.
Why? I think the main reason is because compared to POP and IMAP, it is harder to set up this correctly within the MTA and can introduce many additional problems and errors. Providers are afraid of extra support calls. If user explicitly asks for this, then it can be assumed he knows what it is all about and will be able to set it up correctly himself.
Regards
Kirill Ponazdyr swinog@codeangels.com 2006-09-16:
The subject says it all: do you know which providers support TLS (the technology formerly known as SSL) for SMTP, POP and/or IMAP for their residential or small-office dialup/broadband customers?
TLS for SMTP makes no sence since this will only protect your message enroute from your machine to SMTP server but after that it is all open again.
Of course TLS does not offer end to end security like S/MIME and PGP do, but still there are plenty of reasons for supporting TLS:
* Protection of SMTP AUTH credentials, especially when using insecure auth methods
* TLS between MTAs requires no action on behalf of end users and still offers additional protection compared to no TLS, while TLS between MUA and MSA/MTA is still a lot easier to set up for customers than S/MIME or PGP
* Given todays many open or insecure wireless networks, TLS on the first hop (MUA <-> MSA/MTA) helps to better protect messages when they are most vulnerable -- it seems to be considerably more difficult for third parties to read messages in transit between MTAs than to read messages on the first (or last) hop on wifi or shared / public access networks
* TLS protects the RFC 2822 headers and RFC 2821 envelope too, which S/MIME and PGP cannot
Salut,
On Sat, Sep 16, 2006 at 03:43:09PM +0200, Matthias Leisi wrote:
If you are a provider yourself and you do not offer it: Are there particular reasons? Is it a conscious decision not to offer it or is it that just nobody asked yet?
From a cryptographical point of view, this would be a dangerous setup. You're transmitting the same message encrypted (local MX <-> Client) as well as unencrypted (sending MX <-> local MX). This leaves you open to a known plaintext attack against your server's private key, because it gives you an opportunity to gain more and more information about the key in use, and all you have to do is send regular-looking SPAM to the user.
If every mail server on the Internet encrypted its transmissions, this method would be sure, but as long as this is not the case, there is no transport security. All the user can do is to use PGP in order to keep the contents of his/her mail secret.
Of course, SSL can be used nicely for authentication of mail servers though... But this would mean that communication with arbitrary peers is impossible, because one needs to pre-trust the public key of the communicating server (Otherwise the spammers would simply get themselves a key as well).
Tonnerre
Hi Tonnerre,
From a cryptographical point of view, this would be a dangerous setup. You're transmitting the same message encrypted (local MX <-> Client) as well as unencrypted (sending MX <-> local MX). This leaves you open to a known plaintext attack against your server's private key, because it gives you an opportunity to gain more and more information about the key in use, and all you have to do is send regular-looking SPAM to the user.
What kind of explanation is this? If the local MX is relaying the message it will add Received headers which will modify the message, thus starting a known plaintext attack on that communication is an adventurous thing. And you still have to interceipt both communications. And even then, given timestamps and nonces I guess you're heading nowhere...
But basically what you say is that every website that is available though HTTP and HTTPS is subject to an attack against its private key.
We offer STARTTLS over SMTP and SMTP over SSL for our custommers that want to relay their mail over our mailservers (with authentication). We also offer POP3 over SSL and Webmail over HTTPS in order to protect the passwords of our custommers. We recommend everyone to use it but we can't force it.
Regards. Jean-Pierre
Hi
From a cryptographical point of view, this would be a dangerous setup. You're transmitting the same message encrypted (local MX <-> Client) as well as unencrypted (sending MX <-> local MX). This leaves you open to a known plaintext attack against your server's private key, because it gives you an opportunity to gain more and more information about the key in use, and all you have to do is send regular-looking SPAM to the user.
Are you sure? Isn't that exactly the point of asymmetric cryptography? The way I see it, TLS and SSL work like this (analogous to PGP):
1. The client connects to the server and obtains the server's public key. The public key is a mathematical recipe to encode (but not decode) a message for a specific recipient.
2. Using this public key, the client encodes the message (cleartext -> ciphertext). Now the interesting part is, that the client isn't able to decode this cipher text he just encoded, because he doesn't have the private key (that's why it is also necessary to always encrypt PGP messages to yourself, otherwise you won't be able to read them later on in your "sent" box).
3. The cipher text is transmitted to the server where it is decoded using the private key.
I could now connect to the mail server, obtain the public key and generate as many cleartext/ciphertext pairs as I want and I still would not be able to guess the private key from that information.
If what you are saying were true, we at least had an explanation for all that nonsense spam. But it would leave is with a lot of other problems.
Daniel
Daniel Lorch wrote:
Are you sure? Isn't that exactly the point of asymmetric cryptography? The way I see it, TLS and SSL work like this (analogous to PGP):
You're almost right.
- The client connects to the server and obtains the server's public key. The public key is a mathematical recipe to encode (but not decode) a message for a specific recipient.
ACK.
- Using this public key, the client encodes the message (cleartext -> ciphertext). Now the interesting part is, that the client isn't able to decode this cipher text he just encoded, because he doesn't have the private key (that's why it is also necessary to always encrypt PGP messages to yourself, otherwise you won't be able to read them later on in your "sent" box).
SMTP/TLS does not encrypt individual messages - as it's name implies, it works on the *transport* layer. And there, the public key exchange is used to agree on a symmetric session key.
Btw., neither server nor client public keys would technically be required; anonymous DH would work as well (although it would not make much sense...).
I could now connect to the mail server, obtain the public key and generate as many cleartext/ciphertext pairs as I want and I still would not be able to guess the private key from that information.
Of course, known-plaintext, replay and similar attacks on TLS and SSL are theoretically possible. However, I have not heard of practically possible or generally successful attacks.
-- Matthias
Hi
SMTP/TLS does not encrypt individual messages - as it's name implies, it works on the *transport* layer. And there, the public key exchange is used to agree on a symmetric session key.
PGP works the same way. The data is encrypted using a random symmetric key, then this symmetric key is encrypted asymmetrically for each recipient. That's why it's possible to send the same message to multiple recipients, without having to encrypt the same data multiple times. Symmetric encryption is also significantly faster.
Therefore, everything that applies to SSL/TLS should also apply to PGP - at least from my understanding.
Daniel
Hi Daniel
On 9/17/06, Daniel Lorch daniel@lorch.cc wrote: [..]
Are you sure? Isn't that exactly the point of asymmetric cryptography? The way I see it, TLS and SSL work like this (analogous to PGP):
[1.2.3.]
Almost. The asymetric encryption is only used to negotiate a symetric session key between the peers for various reasons.
Michi
On the Sun, Sep 17, 2006 at 11:33:22AM +0200, Michael Naef blubbered:
Hi Daniel
On 9/17/06, Daniel Lorch daniel@lorch.cc wrote: [..]
Are you sure? Isn't that exactly the point of asymmetric cryptography? The way I see it, TLS and SSL work like this (analogous to PGP):
[1.2.3.]
Almost. The asymetric encryption is only used to negotiate a symetric session key between the peers for various reasons.
Mostly it's performance reasons.
SSH (which uses SSL as well) does the same. The session key is renewed frequently, default of OpenSSH is 3600 Seconds (1 hour)
I'm not sure whether session keys are only negotiated over asymmetric encryption initially or at renewal too. Anyone can clarify this?
CU, Ventilator
Matthias Leisi wrote:
The subject says it all: do you know which providers support TLS (the technology formerly known as SSL) for SMTP, POP and/or IMAP for their residential or small-office dialup/broadband customers?
We do offer smtp/tls, imap/tls and imaps, pop3/tls and pop3s.
-
Daniel Lorch -
Daniel Roethlisberger -
Jean-Pierre Schwickerath -
Kirill Ponazdyr -
Martin Ebnoether -
Matthias Leisi -
Michael Naef -
Rene Luria -
Tonnerre LOMBARD