Re: pop 110/995, imap 143/993 ?

[Peter]

On 23/08/17 11:13, Joseph Tam wrote:
> You don't need plaintext to use CRAM-MD5: there's no problem have *both*
> CRAM-MD5 and SSL (it's overkill, but works).  And mail data is worth
> protecting too.

The problem is, as I already pointed out, that using CRAM-MD5 or any
other form of challenge-response password mechanism requires that the
password be stored on the server in plain text.  Furthermore just the
advertisement of CRAM-MD5 in a response advertises to an attacker that
you do indeed store the passwords as plain text.  I would much rather
store the password as a hash on the server and only offer up the PLAIN
and LOGIN types on an encrypted connection.

> No argument here about using end-to-end encryption, but protecting mail
> data and metadata is important too.  Don't forget also, it's not just
> about the privacy (reading) of mail data, but it's also important to
> guarantee the authenticity of mail data from tampering.

Right, the most common means of doing that is to properly authenticate
to the submission server and check TLS validity, then the submission
server DKIM signs the message.  Of course, this implies trust of the
submission server.

> By the way, if we assume a hostile network where MITM is possible, then
> even closing STARTTLS ports will not guarantee confidential transport:
> the MITM attacker can merely open up a fake plaintext-only service port,
> then proxy that to the target server.  The client must deny non-secured
> transport to be fully protected.

Yes, exactly!  If the client accepts a non-secure connection then it
doesn't matter what the server does.  It's the client that must be
vigilant here.

That said, a client that is configured to port 465 would require a
config change in order to accept a plaintext connection, but then so
would a client that is configured to port 587 and mandatory encryption.


Peter

Re: pop 110/995, imap 143/993 ?

[Joseph Tam]

Robert Wolf wrote:


else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you
have enabled something like cram-md5.


Hi,

exactly, this is the reason, why plain-text is still needed. You don't need
encryption for authentication, if you have secure authentication. Without
knowing original password, the MITM cannot generate correct hash for login, so
the connection can be plain-text.


You don't need plaintext to use CRAM-MD5: there's no problem have *both*
CRAM-MD5 and SSL (it's overkill, but works).  And mail data is worth
protecting too.


Of cource, if you then download your emails, the MITM can still read these
emails too, if these emails are plain-text (not encrypted using e.g. SMIME or
GPG). But he cannot misuse your login.


No argument here about using end-to-end encryption, but protecting mail
data and metadata is important too.  Don't forget also, it's not just
about the privacy (reading) of mail data, but it's also important to
guarantee the authenticity of mail data from tampering.

By the way, if we assume a hostile network where MITM is possible, then
even closing STARTTLS ports will not guarantee confidential transport:
the MITM attacker can merely open up a fake plaintext-only service port,
then proxy that to the target server.  The client must deny non-secured
transport to be fully protected.

Joseph Tam 

Re: pop 110/995, imap 143/993 ?

[Peter]

On 22/08/17 20:07, Robert Wolf wrote:
> On Tue, 22 Aug 2017, Aki Tuomi wrote:
> 
>> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you
>> have enabled something like cram-md5.
> 
> exactly, this is the reason, why plain-text is still needed. You don't need 
> encryption for authentication, if you have secure authentication. Without 
> knowing original password, the MITM cannot generate correct hash for login, 
> so 
> the connection can be plain-text.

In order to support non plain-text login types the passwords themselves
have to be stored in plain-text.  If you use PLAIN but only allow
authentication over a secure channel then you get the best of both
worlds, you can store your passwords as a hash and they are not
transmitted as plain text over the internet.


Peter

Re: pop 110/995, imap 143/993 ?

[Peter]

On 22/08/17 18:24, Aki Tuomi wrote:
> Dovecot, by default, requires STARTTLS before accepting plaintext
> authentication when SSL is configured and you are not connecting from
> localhost. You can verify this by telnetting to port 143 from somewhere
> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you
> have enabled something like cram-md5.
> 
> I think postfix, by default, will also prevent authentication without
> transport security.

No:
$ postconf -d smtpd_tls_auth_only
smtpd_tls_auth_only = no

The commented submission service in master.cf contains it, though, so if
you uncomment the service as a whole it will be set:
#  -o smtpd_tls_auth_only=yes

> Also, you should probably using 587/tcp (submission) for sending mail,
> instead of 25. Some reputable ISPs prevent connecting to random MX
> servers to port 25 to make life harder for spambots.

Right, you should never use port 25 for submission, for several reasons.


Peter

Re: pop 110/995, imap 143/993 ?

[Robert Wolf]

On Tue, 22 Aug 2017, Ivan Warren wrote:

> Le 8/22/2017 à 10:03 AM, Robert Wolf a écrit :
> >
> > WRONG!!! The email is stored plain-text on the first server and then it can
> > be
> > sent to other few MX servers over plain-text connection. I.e. encrypted
> > connection does not protect emails, but the authentication credentials.
> >
> >
> Indeed.
> 
> Encrypted (SSL/TLS) SMTP/IMAP/POP3 sessions only server 1 purpose : To encrypt
> authentication. Once a message is sent through a MTA, there is no guarantee of
> privacy whatsoever.
> 
> End to End privacy can only be achieved through actual e-mail signing and
> encryption (PGP, S/MIME) (but only the message body is encrypted, not the
> headers).


Hello Ivan

yes, headers are not encrypted in plain-text SMTP, the same way as TCP and IP 
and DNS Requests are not encrypted. One can only hide behind some anonymization 
system (TOR, Proxy, VPN for TCP, IP, DNS) or some non-presonal mail system to 
anonymize mail headers to not be able to connect real persones with mail 
sender/recipient.

Regards,

Robert.

Re: pop 110/995, imap 143/993 ?

[Robert Wolf]

On Tue, 22 Aug 2017, Aki Tuomi wrote:

> else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you
> have enabled something like cram-md5.


Hi,

exactly, this is the reason, why plain-text is still needed. You don't need 
encryption for authentication, if you have secure authentication. Without 
knowing original password, the MITM cannot generate correct hash for login, so 
the connection can be plain-text.

Of cource, if you then download your emails, the MITM can still read these 
emails too, if these emails are plain-text (not encrypted using e.g. SMIME or 
GPG). But he cannot misuse your login.


Regards,

Robert Wolf.

Re: pop 110/995, imap 143/993 ?

[Robert Wolf]

On Mon, 21 Aug 2017, Gary wrote:

> If I read this correctly, starttls will fail due to the MITM attack. That is 
> the client knows security has been compromised. Using SSL/TLS, the MITM can 
> use SSL stripping. Since most Postifx conf use "may" for security, the 
> message would go though unencrypted. Correct???

Hi,

many people think, the email is encrypted (secured), because it is sent through 
encrypted submission connection to client's smtp/submission server. I know some 
case, where one users sends credit card numbers over encrypted channel to SMTP 
server and he thinks the card numbers are protected!

WRONG!!! The email is stored plain-text on the first server and then it can be 
sent to other few MX servers over plain-text connection. I.e. encrypted 
connection does not protect emails, but the authentication credentials.

Users should know, that they have to encrypt the email itself, if they want 
protect it.

Regards,

Robert Wolf.

Re: Re: pop 110/995, imap 143/993 ?

[Jochen Bern]

On 08/22/2017 12:42 AM, Gary wrote:
> If I read this correctly, starttls will fail due to the MITM attack. That
> is the client knows security has been compromised. [...] Since most Postifx
> conf use "may" for security, the message would go though unencrypted. 
> Correct???

Yup.

FWIW, one doesn't need to be a large provider or do full traffic
analysis to play this kind of game. A couple years back, my MUA failed
to send e-mails while I was using the wifi of a Belgian camping ground.
Looking into it, I found that SMTP was transparently redirected to an
entirely different server - which did not offer the STARTTLS that I had
my MUA insist on, either.

Kind regards,
-- 
Jochen Bern
Systemingenieur

Fon:+49 6151 9067-231
Fax:+49 6151 9067-290
E-Mail: jochen.b...@binect.de

www.binect.de
www.facebook.de/binect

Binect ist ausgezeichnet:
Sieger INNOVATIONSPREIS-IT 2017 | Das Büro: Top 100 Büroprodukte 2017

Binect GmbH

Robert-Koch-Straße 9, 64331 Weiterstadt, DE

Geschäftsführung: Dr. Frank Wermeyer, Nils Manegold
Unternehmenssitz: Weiterstadt
Register: Amtsgericht Darmstadt, HRB 94685
Umsatzsteuer-ID:  DE 221 302 264

MAX 21-Unternehmensgruppe
✁
Diese E-Mail kann vertrauliche Informationen enthalten. Wenn Sie nicht
der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben,
informieren Sie bitte sofort den Absender und vernichten Sie diese
E-Mail. Das unerlaubte Kopieren, sowie die unbefugte Weitergabe dieser
Mail oder von Teilen dieser Mail ist nicht gestattet. Jede von der
Binect GmbH versendete Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu
einer irgendwie gearteten Verpflichtung zu Lasten der Binect GmbH
ausgelegt werden. Wir haben alle verkehrsüblichen Maßnahmen unternommen,
um das Risiko der Verbreitung virenbefallener Software oder E-Mails zu
minimieren, dennoch raten wir Ihnen, Ihre eigenen Virenkontrollen auf
alle Anhänge an dieser Nachricht durchzuführen.
Wir schließen, außer für den Fall von Vorsatz oder grober
Fahrlässigkeit, die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mail aus.

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of contents of this
e-mail is strictly prohibited. All Binect GmbH emails are created
thoroughly, nevertheless we do not accept any legal obligation for the
information and wording contained herein. Binect GmbH has taken
precautionary measures to reduce the risk of possible distribution of
virus infected software or emails. However, we advise you to check
attachments to this email for viruses. Except for cases of intent or
gross negligence, we cannot accept any legal obligation for loss or
damage by virus infected software.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 22/08/17 01:56, Peter wrote:

Lest anyone think STARTTLS MITM doesn't happen,

https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/


Right, the attack does happen, but it can be prevented by properly
configuring the server and client.


Not only for security, I prefer port 993/995 as it's just plain
simpler to initiate SSL from the get-go rather than to do some
handshaking that gets you to the same point.


Simpler from a protocol perspective, yes, but not from a configuration
perspective.  A separate port requires more firewall configuration,
requires listening on more one port if you need to accept both plain
text and encrypted connections and requires that port to be allocated by
IANA. 


Seriously? So one more port to allow through the firewall is somehow 
more complex than making sure the server and/or the client is configured 
to refuse falling back to plaintext communication - and testing various 
clients and server flavours to make absolutely sure that they do what 
they are supposed to be doing and don't fall for a MITM attack? At least 
with plain SSL/TLS ports, you know for sure that if you are connected, 
it is definitely encrypted.







It would
appear that STARTTLS is significantly more vulnerable to MITM attacks
than plain SSL/TLS for all the above protocols. Is the slight extra
convenience of opportunistic encryption really worth the substantial
loss in security?


I would not say significantly.  If the client is configured to require
encryption and to validate the resulting cert from the server then any
MITM vulnerability of STARTTLS is fully mitigated.  A MITM attack is
only an issue if the client is configured for opportunistic encryption.
Note that the server side should be configured to require encryption on
as well, but the important thing is that the client requires it.


Yes - and you have a lot of "if's" above - and that is exactly what 
makes it more vulnerable in practice - where you have to make absolutely 
sure that your particular version of your particular software definitely 
behaves like that - while with plain SSL/TLS it just works and there is 
no checking needed or "if's". In real life, that makes STARTTLS less secure.

Re: pop 110/995, imap 143/993 ?

[Aki Tuomi]

On 22.08.2017 03:56, Peter wrote:
>>> Lest anyone think STARTTLS MITM doesn't happen,
>>>
>>> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/
> Right, the attack does happen, but it can be prevented by properly
> configuring the server and client.
Dovecot, by default, requires STARTTLS before accepting plaintext
authentication when SSL is configured and you are not connecting from
localhost. You can verify this by telnetting to port 143 from somewhere
else (NOT LOCALHOST) and you can see it says LOGINDISABLED unless you
have enabled something like cram-md5.

I think postfix, by default, will also prevent authentication without
transport security.

Also, you should probably using 587/tcp (submission) for sending mail,
instead of 25. Some reputable ISPs prevent connecting to random MX
servers to port 25 to make life harder for spambots.

Aki

Re: pop 110/995, imap 143/993 ?

[Peter]

>> Lest anyone think STARTTLS MITM doesn't happen,
>> 
>> https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/

Right, the attack does happen, but it can be prevented by properly
configuring the server and client.

>> Not only for security, I prefer port 993/995 as it's just plain
>> simpler to initiate SSL from the get-go rather than to do some
>> handshaking that gets you to the same point.

Simpler from a protocol perspective, yes, but not from a configuration
perspective.  A separate port requires more firewall configuration,
requires listening on more one port if you need to accept both plain
text and encrypted connections and requires that port to be allocated by
IANA.  Since dovecot, postfix and many other servers already support
STARTTLS out of the box, sometimes with *less* configuration for it than
the corresponding TLS-only protocol, I would certainly say it's not any
simpler from a configuration perspective.  That said, neither one is
terribly difficult to configure.

> Frankly, after reading the above link and some more info on the
> internet on the subject, I am now wondering why do we bother at all
> with STARTTLS for imap, pop3

Certainly I would agree that it's not needed here, but I do not have a
real issue with it, either.

> and even smtp

...because SMTP never worked over port 465.  465 is an alternate
submission port (despite the name) and no MX server will connect to it.
MX to MX traffic always has to happen on port 25 and so the only way to
encrypt the stream is via STARTTLS.

> (and by the way, port 465
> for SMTP + SSL/TLS *is* indeed deprecated officially)?

Yes it is, and I think there was some confusion in this thread earlier
about 993/995 not being official, they *are* official, but 465 is not
which is probably what led to the confusion.

> It would
> appear that STARTTLS is significantly more vulnerable to MITM attacks
> than plain SSL/TLS for all the above protocols. Is the slight extra
> convenience of opportunistic encryption really worth the substantial
> loss in security?

I would not say significantly.  If the client is configured to require
encryption and to validate the resulting cert from the server then any
MITM vulnerability of STARTTLS is fully mitigated.  A MITM attack is
only an issue if the client is configured for opportunistic encryption.
Note that the server side should be configured to require encryption on
as well, but the important thing is that the client requires it.

I would like to point out that Thunderbird has not offered opportunistic
encryption in its setup for a number of years now, and I think that
other clients likely do not as well, so the MITM attack vector is only
an issue on older clients that are likely insecure for other reasons as
well.  Even on those (older) clients you can likely configure them to
require encryption, though.

> If I read this correctly, starttls will fail due to the MITM attack.
> That is the client knows security has been compromised.

No, the attack vector is for a client that has encryption set to may.
The MITM will either do a plain text connection to the server and strip
the STARTTLS capability from the initial server response so that the
client does not see it and degrades to plain text, or it will connect
via STARTTLS but tunnel that connection to plain text itself, not
offering STARTTLS to the client.  In either case the client, if
configured for opportunistic encryption will happily make the plain text
connection to the MITM, or it will refuse the connection if it's
configured to require encryption.

> Using
> SSL/TLS, the MITM can use SSL stripping. Since most Postifx conf use
> "may" for security, the message would go though unencrypted.
> Correct???

Not really, no.  Postfix is set to "may" by default, but this setting is
only really used for MX to MX connections because of the number of MX
servers that do not support TLS at all.  If you look at master.cf at the
commented submission service, which is what you would uncomment for
submission, you will see that it is configured to not only require
encryption but it also will refuse to offer or accept SASL AUTH on a
plain text connection.

> Is there something to enable for perfect forward security with
> starttls?

This is actually a client-side issue, but it is pretty much mitigated by
the vast majority of modern clients by the fact that they no longer
support opportunistic encryption.  You either have to select plain text
or encrypted, there is no, "encrypt if it is supported" setting any more.


Peter

Re: pop 110/995, imap 143/993 ?

[Joseph Tam]

Gary  writes:


If I read this correctly, starttls will fail due to the MITM attack.
That is the client knows security has been compromised.


I'm not sure what you man by "fail".  STARTTLS is prone to MITM attacks
if a client has not been configured to refuse non-STARTTLS/SSL sessions.
For clients that will allow both secured and plaintext session (like
most MTAs), an attacker can strip out the server's STARTTLS capability
declaration and fool the client into using an unencrypted session.


Using SSL/TLS, the MITM can use SSL stripping.  Since most Postifx conf
use "may" for security, the message would go though unencrypted.
Correct???


If it's what I described above, then yes.


Is there something to enable for perfect forward security with starttls?


PFS is enabled using a particular choice of encryption algorithms (in
particular, use of ephememeral keys algorithms like ECDHE-*), but this
happens after SSL initiaton, whether by STARTTLS, or by connection to
SSL ports.

Joseph Tam 

Re: pop 110/995, imap 143/993 ?

[Gary]

If I read this correctly, starttls will fail due to the MITM attack. That is 
the client knows security has been compromised. Using SSL/TLS, the MITM can use 
SSL stripping. Since most Postifx conf use "may" for security, the message 
would go though unencrypted. Correct???

Is there something to enable for perfect forward security with starttls?



  Original Message  
From: s.ar...@open-t.co.uk
Sent: August 21, 2017 3:07 PM
To: dovecot@dovecot.org
Reply-to: dovecot@dovecot.org
Subject: Re: pop 110/995, imap 143/993 ?

On 21/08/17 22:18, Joseph Tam wrote:
> 
> Lest anyone think STARTTLS MITM doesn't happen,
> 
>  
>https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/
> 
> Not only for security, I prefer port 993/995 as it's just plain simpler
> to initiate SSL from the get-go rather than to do some handshaking that
> gets you to the same point.

Frankly, after reading the above link and some more info on the internet 
on the subject, I am now wondering why do we bother at all with STARTTLS 
for imap, pop3 and even smtp (and by the way, port 465 for SMTP + 
SSL/TLS *is* indeed deprecated officially)? It would appear that 
STARTTLS is significantly more vulnerable to MITM attacks than plain 
SSL/TLS for all the above protocols. Is the slight extra convenience of 
opportunistic encryption really worth the substantial loss in security?

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 21/08/17 22:18, Joseph Tam wrote:


Lest anyone think STARTTLS MITM doesn't happen,

 
https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/

Not only for security, I prefer port 993/995 as it's just plain simpler
to initiate SSL from the get-go rather than to do some handshaking that
gets you to the same point.


Frankly, after reading the above link and some more info on the internet 
on the subject, I am now wondering why do we bother at all with STARTTLS 
for imap, pop3 and even smtp (and by the way, port 465 for SMTP + 
SSL/TLS *is* indeed deprecated officially)? It would appear that 
STARTTLS is significantly more vulnerable to MITM attacks than plain 
SSL/TLS for all the above protocols. Is the slight extra convenience of 
opportunistic encryption really worth the substantial loss in security?

Re: pop 110/995, imap 143/993 ?

[Joseph Tam]

Lest anyone think STARTTLS MITM doesn't happen,


https://threatpost.com/eff-calls-out-isps-modifying-starttls-encryption-commands/109325/3/

Not only for security, I prefer port 993/995 as it's just plain simpler
to initiate SSL from the get-go rather than to do some handshaking that
gets you to the same point.

Joseph Tam 

Re: pop 110/995, imap 143/993 ?

[Gedalya]

Bottom line, a server operator's view can be a lot narrower than this, 
especially in the scenario where you serve the general public and do not 
control the clients.
There is definitely no reason why you wouldn't want to serve ports 993/995. The 
MITM thing can be used to argue against serving ports 110/143, and some servers 
indeed do not offer those.
But you'll always deal with people who would insist 110/143 is the "right" 
away. It's nice to provide more than option and you can expect many modern 
clients to default to requiring STARTTLS, and do proper certificate validation. 
On my own server I provide only 143, and I control all the clients. So you know 
my taste on the matter :)

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 21/08/17 16:25, Robert Wolf wrote:

On Mon, 21 Aug 2017, Sebastian Arcus wrote:


On 21/08/17 13:39, Robert Wolf wrote:


On Mon, 21 Aug 2017, Sebastian Arcus wrote:



On 21/08/17 10:37, Gedalya wrote:

On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:

is there a 'preferred way'?  should I tell users to use 143 over 993 ?
or
993 over 143? or?

There is no concrete answer. There are various opinions and feelings
about
this.
The opinion againt 993/995 is that these are not standard ports,


Out of curiosity, is there a source for this? It's the first time I hear
that
993/995 are not standard ports - and searching on the Internet, I can't
find
any evidence to back it up? Also, pretty much all email software has been
using them for the past 20 years or so. It seems like a curiously high
rate of
adoption for a non-standard :-)



Hello,

IMHO the "not standard ports" is meant as "old, useless ports now".


So in short, ports 993/995 are IANA officially approved, and thus "standard".
Further to this, they are in use by the vast majority of email providers, and
as far as I can tell, there are no functional or security disadvantages to
using SSL over 993/995 - instead of STARTTLS over 110/143.



Hello Sebastian,


there are no functional disadvantages


*** As I have written, only if some protocol can be used in just plain-text
mode, then the SSL ports generate additional encryption load. CPU is probably
no problem today, but I have seen some slower SSL connection on higher latence
network. I am not SSL profi, but it looks like there is some ACK in SSL after
some "SSL packet" which makes slower connection on high latency network,
because SSL must wait for packet ACK. In plain-text connection, TCP requires
ACK too, but TCP can open big window and send many data at once and wait only
for the last ACK.



there are no security disadvantages


*** Exactly, there is really no security disadvantage to use SSL ports, the
encryption is same, resp. there is security advantage to use SSL ports to be
sure that every communication is encrypted from start and client cannot send
anything plaintext.


Hi Rob - thank you for the clarification. It is interesting information.

Re: pop 110/995, imap 143/993 ?

[Robert Wolf]

On Mon, 21 Aug 2017, Sebastian Arcus wrote:

> On 21/08/17 13:39, Robert Wolf wrote:
> > 
> > On Mon, 21 Aug 2017, Sebastian Arcus wrote:
> > 
> > >
> > > On 21/08/17 10:37, Gedalya wrote:
> > > > On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
> > > > > is there a 'preferred way'?  should I tell users to use 143 over 993 ?
> > > > > or
> > > > > 993 over 143? or?
> > > > There is no concrete answer. There are various opinions and feelings
> > > > about
> > > > this.
> > > > The opinion againt 993/995 is that these are not standard ports,
> > >
> > > Out of curiosity, is there a source for this? It's the first time I hear
> > > that
> > > 993/995 are not standard ports - and searching on the Internet, I can't
> > > find
> > > any evidence to back it up? Also, pretty much all email software has been
> > > using them for the past 20 years or so. It seems like a curiously high
> > > rate of
> > > adoption for a non-standard :-)
> > 
> > 
> > Hello,
> > 
> > IMHO the "not standard ports" is meant as "old, useless ports now".
> 
> So in short, ports 993/995 are IANA officially approved, and thus "standard".
> Further to this, they are in use by the vast majority of email providers, and
> as far as I can tell, there are no functional or security disadvantages to
> using SSL over 993/995 - instead of STARTTLS over 110/143.


Hello Sebastian,

> there are no functional disadvantages

*** As I have written, only if some protocol can be used in just plain-text 
mode, then the SSL ports generate additional encryption load. CPU is probably 
no problem today, but I have seen some slower SSL connection on higher latence 
network. I am not SSL profi, but it looks like there is some ACK in SSL after 
some "SSL packet" which makes slower connection on high latency network, 
because SSL must wait for packet ACK. In plain-text connection, TCP requires 
ACK too, but TCP can open big window and send many data at once and wait only 
for the last ACK.


> there are no security disadvantages

*** Exactly, there is really no security disadvantage to use SSL ports, the 
encryption is same, resp. there is security advantage to use SSL ports to be 
sure that every communication is encrypted from start and client cannot send 
anything plaintext.


Regards,

Robert Wolf.

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 21/08/17 13:39, Robert Wolf wrote:


On Mon, 21 Aug 2017, Sebastian Arcus wrote:



On 21/08/17 10:37, Gedalya wrote:

On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:

is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
993 over 143? or?

There is no concrete answer. There are various opinions and feelings about
this.
The opinion againt 993/995 is that these are not standard ports,


Out of curiosity, is there a source for this? It's the first time I hear that
993/995 are not standard ports - and searching on the Internet, I can't find
any evidence to back it up? Also, pretty much all email software has been
using them for the past 20 years or so. It seems like a curiously high rate of
adoption for a non-standard :-)



Hello,

IMHO the "not standard ports" is meant as "old, useless ports now".


So in short, ports 993/995 are IANA officially approved, and thus 
"standard". Further to this, they are in use by the vast majority of 
email providers, and as far as I can tell, there are no functional or 
security disadvantages to using SSL over 993/995 - instead of STARTTLS 
over 110/143.

Re: pop 110/995, imap 143/993 ?

[Robert Wolf]

On Mon, 21 Aug 2017, Sebastian Arcus wrote:

> 
> On 21/08/17 10:37, Gedalya wrote:
> > On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
> > > is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
> > > 993 over 143? or?
> > There is no concrete answer. There are various opinions and feelings about
> > this.
> > The opinion againt 993/995 is that these are not standard ports, 
> 
> Out of curiosity, is there a source for this? It's the first time I hear that
> 993/995 are not standard ports - and searching on the Internet, I can't find
> any evidence to back it up? Also, pretty much all email software has been
> using them for the past 20 years or so. It seems like a curiously high rate of
> adoption for a non-standard :-)


Hello,

IMHO the "not standard ports" is meant as "old, useless ports now".

AFAIK at the begining there were only plain-text ports 80, 389, 110, 143, 25,
5222 (XMPP) etc without any encryption. Then SSL was implemented on ports 443,
636, 993, 995, 465, 5223 etc. Later, the STARTTLS feature has been introduced
and servers and clients has implemented STARTTLS sometime. Since STARTTLS is
used in most clients and servers nowdays, there is no need for SSL port. There
is even RFC 2817 for STARTTLS in HTTP. So IMHO all SSL ports are meant to be
old, useless now, some Jabber clients describe SSL encryption on port 5223 as
"legacy".


Pros of STARTTLS is, that you CAN start encryption, if you need it. E.g. for 
SMTP or LDAP you can use plain text connections without expensive encryption 
for 
normal mail transfer (MX-MX) or for searching (LDAP), and client can start 
encryption, if needed for username+password or cert authentication (SMTP submit 
or LDAP edit with auth).

Of cource for IMAP+POP you have to authenticate everytime, i.e. you need
encryption everytime.


Pros of SSL port is, you now everytime exactly, that your connection is 
encrypted, so your password is never sent over plain-text channel.

Some servers (services) can be configured to fail correct login, if the login
is made through plain-text channel. This is good, because MITM cannot
instantly see, if the password is correct or not, but the password goes
already plain-text and MITM can test it on secure connection later.


Regards,

Robert Wolf.

Re: pop 110/995, imap 143/993 ?

[Jerry]

On Mon, 21 Aug 2017 11:04:40 +0100, Sebastian Arcus stated:

>On 21/08/17 10:37, Gedalya wrote:
>> On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:  
>>> is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
>>> 993 over 143? or?  
>> There is no concrete answer. There are various opinions and feelings about
>> this. The opinion againt 993/995 is that these are not standard ports,   
>
>Out of curiosity, is there a source for this? It's the first time I hear 
>that 993/995 are not standard ports - and searching on the Internet, I 
>can't find any evidence to back it up? Also, pretty much all email 
>software has been using them for the past 20 years or so. It seems like 
>a curiously high rate of adoption for a non-standard :-)

One of the places I have found extremely useful over the years is:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

It lists the port number, TCP & UDP, description and IANA Status. It also
lists multiple use ports; such as 465.

Port TCP UDP  Description   IANA 
status


143  TCP Assigned Internet Message Access Protocol (IMAP) managementOfficial

465  TCP  URL Rendezvous Directory for SSM (Cisco protocol) Official
465  TCP  Authenticated SMTP over TLS/SSL (SMTPS)   
Unofficial

993  TCP Assigned Internet Message Access Protocol over TLS/SSL (IMAPS) Official
995  TCP UDP  Post Office Protocol 3 over TLS/SSL (POP3S)   Official

-- 
Jerry

Re: pop 110/995, imap 143/993 ?

[Gedalya]

On 08/21/2017 06:04 PM, Sebastian Arcus wrote:
>
> On 21/08/17 10:37, Gedalya wrote:
>> On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
>>> is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
>>> 993 over 143? or?
>> There is no concrete answer. There are various opinions and feelings about 
>> this.
>> The opinion againt 993/995 is that these are not standard ports, 
>
> Out of curiosity, is there a source for this? It's the first time I hear that 
> 993/995 are not standard ports - and searching on the Internet, I can't find 
> any evidence to back it up? Also, pretty much all email software has been 
> using them for the past 20 years or so. It seems like a curiously high rate 
> of adoption for a non-standard :-)

What kind of evidence would support a negative? I don't understand.

Evidence could demonstrate that something is indeed a standard.
"Standard" and common practice are not the same thing. A "Standrd" is a 
document that describes what practice ought to look like.
C has a (series of) standard(s), Perl 5 is not exactly standardized. It's just 
implemented and documented.

Either way, at this point these ports are indeed listed here:

https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

So perhaps it can be said that those still arguing against it on the basis of 
it being "non-standrd" are still arguing against officially assigning these 
port numbers, because the old ports are perfectly good, even after the 
assignment has already been listed by IANA.

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 21/08/17 10:37, Gedalya wrote:

On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:

is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
993 over 143? or?

There is no concrete answer. There are various opinions and feelings about this.
The opinion againt 993/995 is that these are not standard ports, 


Out of curiosity, is there a source for this? It's the first time I hear 
that 993/995 are not standard ports - and searching on the Internet, I 
can't find any evidence to back it up? Also, pretty much all email 
software has been using them for the past 20 years or so. It seems like 
a curiously high rate of adoption for a non-standard :-)

Re: pop 110/995, imap 143/993 ?

[Gedalya]

On 08/21/2017 07:28 AM, voy...@sbt.net.au wrote:
> is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
> 993 over 143? or?
There is no concrete answer. There are various opinions and feelings about this.
The opinion againt 993/995 is that these are not standard ports, and there is no
need to allocate new ports for the secure version of each protocol since we can
use STARTTLS.

The problem with 110/143 is that security depends on settings on both ends:
The client must be configured to negotiate STARTTLS as mandatory, and refuse
to talk to the server when that doesn't work.
The server must also refuse to talk to clients without STARTTLS.
Since some mail clients support "opportunistic" STARTTLS, that is, use port 143
and use STARTTLS *if / when* available, some people feel there are too many
subtleties involved, and ports 993/995 just make all this go away.

Requiring STARTTLS on the server side doesn't prevent a man-in-the-middle
attack. The client must be configured to insist on negotiating STARTTLS with a
server with a verified certificate.

> my current understanding is that some (MS?) clients might not support
> StartTLS/143 ? so best to offer both ?
Their newest clients do support STARTTLS. I don't remember exactly but maybe
Outlook 2003 or so didn't support it.
> I think? some public WiFi block 993/995 but allow 143/110, hence, another
> advantage for using 143/110

Never heard of this either.

Re: pop 110/995, imap 143/993 ?

[Sebastian Arcus]

On 21/08/17 00:28, voy...@sbt.net.au wrote:

just setting a new Dovecot server to migrate from older system, but, I
have a general question:

1. I've set the server with self issued cert, and both pop/imap
StartTLS/110/143 SSL/993/995 (apologies if I'm using wrong naming
terminology)

is there a 'preferred way'?  should I tell users to use 143 over 993 ? or
993 over 143? or?


I believe the recommended way for years has been to use the 
encrypted/SSL versions of both IMAP and POP3 - so ports 993 and 995 
respectively. Otherwise you are effectively sending data in plain text 
over the internet.




my current understanding is that some (MS?) clients might not support
StartTLS/143 ? so best to offer both ?


As far as I know, all popular email clients of the last 15 years, that I 
can think of, support POP3 on 995 and IMAP on 993 with SSL.


I think? some public WiFi block 993/995 but allow 143/110, hence, another
advantage for using 143/110


I never heard about his, Maybe others have. I guess this would be even 
more of a reason to use the encrypted versions of the protocols.

Re: pop 110/995, imap 143/993 ?

[Steffen Kaiser]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 21 Aug 2017, voy...@sbt.net.au wrote:


1. I've set the server with self issued cert, and both pop/imap
StartTLS/110/143 SSL/993/995 (apologies if I'm using wrong naming
terminology)


That's fine.

- -- 
Steffen Kaiser

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEVAwUBWZp0pnz1H7kL/d9rAQIHfgf+Jj+y5Tm2h+13bI3qdsMTo5Yih6fCJlUl
pK5Gunj1o4TNKVDQFq4xa0GUTs5G9+uWyfCiOyIwe8GH6auMxmOKqGTScwjdjRxg
FVbmzxrLEB1XLoSCVpnuyoCIDZHTBJNdLBWvABBSnSDGV9ZusDvb0/5TzaEoFhlE
kLrSj+wGiBMGlAaYoVAECy0oIakzCvV6InSk/c3A09RlwKUxypCdUqYXM01Eba1j
EavikirKdL1YYMe7tXhsuomiA4gk9wSpDTzHhQgvZyTrESsrnFgm2rI+6Hnir8Iz
cT8C9evkLQVYj8gNqXiTYadj2rutG5G9lotvMlQLcnobpFynvRf7hw==
=T5a0
-END PGP SIGNATURE-