Re: [Ach] BetterCrypto guide - POSTFIX configuration mistake / missing parameter

[Christian Fischer]

Hi list,

On 15.10.2016 14:54, Christian Fischer wrote:
> In general its not planned to completely drop the check for old ciphers
> on mail servers. As explained at the linked OpenVAS mailinglist the
> first step is to not mark other servers then Webservers vulnerable for
> the HTTP(S) only attacks like BEAST, Lucky13 and Sweet32.
> 
> There will be also some reworks on the reporting of SSL issues itself in
> OpenVAS. After this is finished the finial step is to not mark MTAs with
> opportunistic TLS as running with weak ciphers.

just want to let you know that the mentioned reworks have been finished
(had to do a lot of rework on the base reporting first):

- SWEET32 / 3DES ciphers are now only reported for HTTPS services
- Weak ciphers for SMTP on 25/tcp with opportunistic TLS are now
reported without a severity (log level). People are still free to
overwrite the severity and mark a vulnerability for it.

I'm still unsure about BEAST and Lucky13 as i have read different
opinions about these attacks in the past. If these attacks are really
only practicable via HTTPS the reporting of weak ciphers could be also
moved to HTTPS services only.

As always, feedback is very welcome.

Regards,

-- 

Christian Fischer | Greenbone Networks GmbH | http://greenbone.net
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
___
Ach mailing list
Ach@lists.cert.at
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Re: [Ach] BetterCrypto guide - POSTFIX configuration mistake / missing parameter

[Christian Fischer]

Hi,

thanks for letting us know. Just want to give some more details on this:

On 10/15/2016 10:48 AM, Sebastian wrote:
> Seems they know about the issue and are planning to fix it. But it seems
> it is planned to completely drop the check for old ciphers on
> mailservers.

In general its not planned to completely drop the check for old ciphers
on mail servers. As explained at the linked OpenVAS mailinglist the
first step is to not mark other servers then Webservers vulnerable for
the HTTP(S) only attacks like BEAST, Lucky13 and Sweet32.

There will be also some reworks on the reporting of SSL issues itself in
OpenVAS. After this is finished the finial step is to not mark MTAs with
opportunistic TLS as running with weak ciphers.

Regards,
Christian

-- 

Christian Fischer | Greenbone Networks GmbH | http://greenbone.net
Neuer Graben 17, 49074 Osnabrück, Germany | AG Osnabrück, HR B 202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
___
Ach mailing list
Ach@lists.cert.at
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Re: [Ach] BetterCrypto guide - POSTFIX configuration mistake / missing parameter

[Sebastian]

Hi,

On 10/14/2016 02:19 PM, Guillaume REMBERT wrote:
> So I would not qualify it as a bad/weird practice to use port 25 for
> sending mail,
But it is. The RFC states that 25 may be abused for submission because
of backwards compatibility. But we want to leave the past behind us, as
we do with broken crypto. Also note the last sentence from the RFC you
cited:

> A site MAY choose to use port 25 for message submission by designating some 
> hosts to be MSAs and others to be MTAs.
A mixed setup with both MSA and MTA on Port 25 is not recommended/allowed.

> but as stated, then there should be reserved hosts for
> MTA and others for MSA (thus the problem of mixing configurations of TLS
> disappears).
>
> My references on allowed output ports might be too limited and
> it is true that for output TCP/25 port, in France, we have some FAI
> blocking it for botnets/SPAM fighting purposes.
Always depends on the provider.
> PS: I will discuss with OpenVAS team, so maybe they
> could decrease the security warning level of their TLS/SSL
> deprecated ciphers scan when it is linked to an SMTP/25 port?
See this thread:
https://lists.wald.intevation.org/pipermail/openvas-discuss/2016-August/009860.html
Continued in October:
https://lists.wald.intevation.org/pipermail/openvas-discuss/2016-October/010234.html
Seems they know about the issue and are planning to fix it. But it seems
it is planned to completely drop the check for old ciphers on
mailservers. The author of the linked mail is in now CC.
They have an invalid issuer for their certificate :/

Sebastian
> Le Fri, 14 Oct 2016 13:49:34 +0200,
> Gunnar Haslinger  a écrit :
>
>> Full-Quote of Guillaume's mail see below (mail was sent directly and
>> didn't go to the list). 
>>
>> My Opinion about this: Yes, you have to use dedicated
>> submission-ports, that's how it is defined to work. Misusing port 25
>> is a wideseen configuration, but that's not how it was designed in
>> the RFC's. You say popular IT-Networks don't allow outgoing
>> connections to the dedicated submission-ports but allow outgoing
>> connections to port 25? That's weird. My personal experience when
>> traveling and using Public/Hotel/Airport/University/Company-WLANs is,
>> that port 25 is almost everywhere blocked (to prevent outgoing spam
>> from these LANs) but using submission-ports usually works fine. 
>>
>> If you really have this problem feel free to configure your personal
>> client to use Port 25 or host an additional submission port on 443 to
>> go through these firewalls. 
>>
>> Am 2016-10-14 13:34, schrieb Guillaume REMBERT:
>>
>>> OK. I got it! This is driven by the master.cf config with -o
>>> smtpd_tls_security_level=encrypt.
>>>
>>> Thanks a lot for your feedbacks and for correcting me.
>>>
>>> One last question/remark to fully understand this topic and config.
>>>
>>> TLS is under the application layer SMTP. In my original setup,
>>> port 25 is used for both reception of Mail (MTA) and submission
>>> (MSA). How can be done the differenciation between a reception
>>> connexion and a submission connexion? It is not possible as TLS is
>>> done before any application exchange. So I need also to open a
>>> dedicated port reserved for submission as recommended in the doc -
>>> TCP/587?
>>>
>>> One problem that I see there is that most IT networks don't allow
>>> output traffic to port 587, thus it is not possible to directly send
>>> mail in most foreign corporate networks - example here-after of an
>>> access provided by a big european organisation:
>>> - HTTPTCP / 80
>>> - HTTPS   TCP / 443
>>> - SMTP*   TCP / 25
>>> - POP3TCP / 110
>>> - POP3s   TCP / 995
>>> - IMAPTCP / 143
>>> - IMAPs   TCP / 993
>>> - IPSEC   UDP / 500
>>> - IPSEC   UDP / 4500
>>> - OpenVPN UDP / 1194
>>>
>>> In that case I would have to establish a VPN in order to send my
>>> mail.
>>>
>>> What would be your position related to this strong limitation?
> ___
> Ach mailing list
> Ach@lists.cert.at
> http://lists.cert.at/cgi-bin/mailman/listinfo/ach

-- 
python programming - mail server - photo - video - https://sebix.at
cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers




signature.asc
Description: OpenPGP digital signature
___
Ach mailing list
Ach@lists.cert.at
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Re: [Ach] BetterCrypto guide - POSTFIX configuration mistake / missing parameter

[Guillaume REMBERT]

RFC6409 specifies port 587 as reserved, but allow port 25 to be used
also:
https://tools.ietf.org/html/rfc6409#section-3
"
Port 587 is reserved for email message submission as specified in
   this document.  Messages received on this port are defined to be
   submissions.  The protocol used is ESMTP [SMTP-MTA], with additional
   restrictions or allowances as specified here.

   Although most email clients and servers can be configured to use port
   587 instead of 25, there are cases where this is not possible or
   convenient.  A site MAY choose to use port 25 for message submission
   by designating some hosts to be MSAs and others to be MTAs.
"

So I would not qualify it as a bad/weird practice to use port 25 for
sending mail, but as stated, then there should be reserved hosts for
MTA and others for MSA (thus the problem of mixing configurations of TLS
disappears).

My references on allowed output ports might be too limited and
it is true that for output TCP/25 port, in France, we have some FAI
blocking it for botnets/SPAM fighting purposes.

I tried to search for surveys on most common output open ports, but
didn't find any good references. In case anybody know/have some doc on
this topic?

Anyway, I will switch to port 587 to follow best practices.

Thanks again for your time and clarifications!

PS: I will discuss with OpenVAS team, so maybe they
could decrease the security warning level of their TLS/SSL
deprecated ciphers scan when it is linked to an SMTP/25 port?



Le Fri, 14 Oct 2016 13:49:34 +0200,
Gunnar Haslinger  a écrit :

> Full-Quote of Guillaume's mail see below (mail was sent directly and
> didn't go to the list). 
> 
> My Opinion about this: Yes, you have to use dedicated
> submission-ports, that's how it is defined to work. Misusing port 25
> is a wideseen configuration, but that's not how it was designed in
> the RFC's. You say popular IT-Networks don't allow outgoing
> connections to the dedicated submission-ports but allow outgoing
> connections to port 25? That's weird. My personal experience when
> traveling and using Public/Hotel/Airport/University/Company-WLANs is,
> that port 25 is almost everywhere blocked (to prevent outgoing spam
> from these LANs) but using submission-ports usually works fine. 
> 
> If you really have this problem feel free to configure your personal
> client to use Port 25 or host an additional submission port on 443 to
> go through these firewalls. 
> 
> Am 2016-10-14 13:34, schrieb Guillaume REMBERT:
> 
> > OK. I got it! This is driven by the master.cf config with -o
> > smtpd_tls_security_level=encrypt.
> > 
> > Thanks a lot for your feedbacks and for correcting me.
> > 
> > One last question/remark to fully understand this topic and config.
> > 
> > TLS is under the application layer SMTP. In my original setup,
> > port 25 is used for both reception of Mail (MTA) and submission
> > (MSA). How can be done the differenciation between a reception
> > connexion and a submission connexion? It is not possible as TLS is
> > done before any application exchange. So I need also to open a
> > dedicated port reserved for submission as recommended in the doc -
> > TCP/587?
> > 
> > One problem that I see there is that most IT networks don't allow
> > output traffic to port 587, thus it is not possible to directly send
> > mail in most foreign corporate networks - example here-after of an
> > access provided by a big european organisation:
> > - HTTPTCP / 80
> > - HTTPS   TCP / 443
> > - SMTP*   TCP / 25
> > - POP3TCP / 110
> > - POP3s   TCP / 995
> > - IMAPTCP / 143
> > - IMAPs   TCP / 993
> > - IPSEC   UDP / 500
> > - IPSEC   UDP / 4500
> > - OpenVPN UDP / 1194
> > 
> > In that case I would have to establish a VPN in order to send my
> > mail.
> > 
> > What would be your position related to this strong limitation?

___
Ach mailing list
Ach@lists.cert.at
http://lists.cert.at/cgi-bin/mailman/listinfo/ach

Re: [Ach] BetterCrypto guide - POSTFIX configuration mistake / missing parameter

[Gunnar Haslinger]

Full-Quote of Guillaume's mail see below (mail was sent directly and
didn't go to the list). 

My Opinion about this: Yes, you have to use dedicated submission-ports,
that's how it is defined to work. Misusing port 25 is a wideseen
configuration, but that's not how it was designed in the RFC's. You say
popular IT-Networks don't allow outgoing connections to the dedicated
submission-ports but allow outgoing connections to port 25? That's
weird. My personal experience when traveling and using
Public/Hotel/Airport/University/Company-WLANs is, that port 25 is almost
everywhere blocked (to prevent outgoing spam from these LANs) but using
submission-ports usually works fine. 

If you really have this problem feel free to configure your personal
client to use Port 25 or host an additional submission port on 443 to go
through these firewalls. 

Am 2016-10-14 13:34, schrieb Guillaume REMBERT:

> OK. I got it! This is driven by the master.cf config with -o
> smtpd_tls_security_level=encrypt.
> 
> Thanks a lot for your feedbacks and for correcting me.
> 
> One last question/remark to fully understand this topic and config.
> 
> TLS is under the application layer SMTP. In my original setup,
> port 25 is used for both reception of Mail (MTA) and submission (MSA).
> How can be done the differenciation between a reception connexion and a
> submission connexion? It is not possible as TLS is done before any
> application exchange. So I need also to open a dedicated port reserved
> for submission as recommended in the doc - TCP/587?
> 
> One problem that I see there is that most IT networks don't allow
> output traffic to port 587, thus it is not possible to directly send
> mail in most foreign corporate networks - example here-after of an
> access provided by a big european organisation:
> - HTTPTCP / 80
> - HTTPS   TCP / 443
> - SMTP*   TCP / 25
> - POP3TCP / 110
> - POP3s   TCP / 995
> - IMAPTCP / 143
> - IMAPs   TCP / 993
> - IPSEC   UDP / 500
> - IPSEC   UDP / 4500
> - OpenVPN UDP / 1194
> 
> In that case I would have to establish a VPN in order to send my mail.
> 
> What would be your position related to this strong limitation?___
Ach mailing list
Ach@lists.cert.at
http://lists.cert.at/cgi-bin/mailman/listinfo/ach