Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-18 Diskussionsfäden Rene Luria
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.
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-17 Diskussionsfäden Matthias Leisi
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.


  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.

ACK.

  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).

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


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-17 Diskussionsfäden Michael Naef

Hi Daniel

On 9/17/06, Daniel Lorch [EMAIL PROTECTED] 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
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-17 Diskussionsfäden Martin Ebnoether
On the Sun, Sep 17, 2006 at 11:33:22AM +0200, Michael Naef blubbered:
 Hi Daniel
 
 On 9/17/06, Daniel Lorch [EMAIL PROTECTED] 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

-- 
Martin Ebnöther, [EMAIL PROTECTED] http://www.semmel.ch/
Videogamer, Techno Musician, Gourmet, R-Typer, Beer drinker, Lefty
Symlinker, Playstationeer, Chilihead, Honda driver, Paranoia GM 
   This space for rent. Call 0800-Semmel-Ads

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-17 Diskussionsfäden Daniel Lorch
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

___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


[swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Matthias Leisi
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
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Kirill Ponazdyr
 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
Technical Director
Codeangels Solutions GmbH
Tel: +41 (0)43 844 90 10
Fax: +41 (0)43 844 90 12
http://www.codeangels.ch
http://www.codeangels.com


___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Tonnerre LOMBARD
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


pgpR1hJmTi8T6.pgp
Description: PGP signature
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Jean-Pierre Schwickerath

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


-- 
HILOTEC Engineering + Consulting AG
Energietechnik und Datensysteme
Tel: +41 34 402 74 00 - http://www.hilotec.com/
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Daniel Roethlisberger
Kirill Ponazdyr [EMAIL PROTECTED] 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

-- 
Daniel Roethlisberger [EMAIL PROTECTED]
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog


Re: [swinog] Providers supporting TLS (for SMTP, POP, IMAP, ...)?

2006-09-16 Diskussionsfäden Daniel Lorch
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
___
swinog mailing list
swinog@lists.swinog.ch
http://lists.swinog.ch/cgi-bin/mailman/listinfo/swinog