Re: password security

[Demi Marie Obenour]

On 4/27/22 14:01, Wietse Venema wrote:
> Michael Stroeder:
>>> Either way a compromised CA or a compromise KDC is bad news...
>>
>> Yes!
>>
>> And one of my biggest concerns are bad operational practices. That's why 
>> admins should not have to manually deal with crypto key files like 
>> service keytabs or TLS server keys.
> 
> To implement strong (network) security, some system will have to
> keep some secret somewhere. Few people can afford operating an HSM
> (hardware security module), what are the remaining options.
> 
>   Wietse

TPM-backed storage might work, but I suspect it is too slow in
practice.  One could use TPM-based disk encryption though.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: password security

[Michael Ströder]

On 4/27/22 21:30, Wietse Venema wrote:

Michael Stroeder:

So even if you cannot afford a HSM you can e.g. use ssh-agent via Unix
domain socket for your SSH-CA to avoid having to grant direct read
access to the SSH-CA's private key to your SSH-CA service. Simple
solutions, which you can isolate a bit more with stuff already available
on many Linux systems (AppArmor or SELinux, systemd sand-boxing, etc.).


You give client-side examples;


No, not only client-side.

An SSH-CA server using ssh-keygen for cert signing can use ssh-agent 
too, either for signing directly with a local key file or by using a 
PKCS#11 module.


Ciao, Michael.

Re: password security

[Wietse Venema]

Michael Stroeder:
> So even if you cannot afford a HSM you can e.g. use ssh-agent via Unix 
> domain socket for your SSH-CA to avoid having to grant direct read 
> access to the SSH-CA's private key to your SSH-CA service. Simple 
> solutions, which you can isolate a bit more with stuff already available 
> on many Linux systems (AppArmor or SELinux, systemd sand-boxing, etc.).

You give client-side examples; at $work, applications use agents
that talk to hardware tokens. But there still needs to be a backend
that is operated securely.

Wietse

Re: Fixed: postscreen signal 11

[Michael Grimm]

Wietse Venema  wrote:
> Wietse Venema:

>> This is a site-specific problem. I ran "openssl s_client" and
>> "posttls-finger -w" against one of the affected servers, and reliably
>> crashed their postscreen daemon. I've been doing similar tests
>> against my own servers without any problems.
> 
> That was with FreeBSD 13.0, as well as Fedora Linux.
> 
> I was able to reproduce the problem with FreeBSD 13.1 RC4 (a release
> candidate) from ftp.freebsd.org, with the command
> 
>openssl s_client 127.0.0.1:25
> 
> This was a Postfix problem that was exposed by a more aggressive
> compiler. See patch below.
> 
> The real fix, already available with the Postfix 3.8 unstable
> release, is to roll back the change from 20211023 that resulted in
> this confusing code, so that the mistake cannot be made again.
> 
> The code confused both me (so that I made the mistake) and the
> compiler (so that it did not report a missing initialization).

Wow! I want to thank you very, very much for your efforts in identifying and 
solving this issue so quickly. Your dedication and help is very much 
appreciated! 

Thanks and regards,
Michael

P.S. Now I do know why recompiling base, kernel, and port with clean ccache 
still throws 'signal 11' ;-) As I am following postfix-current, I will soon run 
a fixed postscreen.

Re: password security

[Michael Ströder]

On 4/27/22 20:01, Wietse Venema wrote:

Michael Stroeder:

Either way a compromised CA or a compromise KDC is bad news...


Yes!

And one of my biggest concerns are bad operational practices. That's why
admins should not have to manually deal with crypto key files like
service keytabs or TLS server keys.


To implement strong (network) security, some system will have to
keep some secret somewhere. Few people can afford operating an HSM
(hardware security module), what are the remaining options.


With bad operational practices I think of the real-world cases of e.g. 
Kerberos service keytab files sent via unencrypted e-mail to an admin 
for installation, and keys never rotated later...


Or the enterprise CA private key accidently exported from MS CA and sent 
to an admin requesting a TLS server certs...


When designing systems I try to follow the principle of separating 
functions as much as possible. Actually, Wietse, already in the 90s I 
was heavily inspired by your work (TCP wrapper, multi-process design of 
postfix) and a book by Cheswick & Bellovin.


So even if you cannot afford a HSM you can e.g. use ssh-agent via Unix 
domain socket for your SSH-CA to avoid having to grant direct read 
access to the SSH-CA's private key to your SSH-CA service. Simple 
solutions, which you can isolate a bit more with stuff already available 
on many Linux systems (AppArmor or SELinux, systemd sand-boxing, etc.).


Or similar the GnuPG key agent.

Or LoadCredential= in systemd.exec(5) also looks interesting.

Unfortunately there's no such ready-to-use component widely available 
for OpenSSL-based systems.


My question on openssl-users:

https://mta.openssl.org/pipermail/openssl-users/2020-April/012344.html

According to Rich's answer here there might be some code in the OpenSSL 
tracker.


https://mta.openssl.org/pipermail/openssl-users/2020-April/012345.html

Some years ago I also tried to use a PKCS#11 proxy. But I couldn't even 
compile its OCaml code. Nowadays there seem to be forked-again 
implementations in C. Not sure whether they work or are maintained.


Ciao, Michael.

Re: password security

[Wietse Venema]

Michael Stroeder:
> > Either way a compromised CA or a compromise KDC is bad news...
> 
> Yes!
> 
> And one of my biggest concerns are bad operational practices. That's why 
> admins should not have to manually deal with crypto key files like 
> service keytabs or TLS server keys.

To implement strong (network) security, some system will have to
keep some secret somewhere. Few people can afford operating an HSM
(hardware security module), what are the remaining options.

Wietse

Re: password security

[Michael Ströder]

On 4/27/22 19:03, Viktor Dukhovni wrote:

On 27 Apr 2022, at 12:45 pm, Michael Ströder  wrote:

But my concern is rather that I would not connect my KDC to the
Internet (for now leaving aside approaches like proxy KCM). >>
In general I'm leaning more towards using asymmetric keys for
authc. On my personal to-do list is to implement a simple X.509-CA
for issuing short-term client certs, with a CLI tool to directly
manipulate Thunderbird and Firefox key/cert DB. >

FWIW, both Heimdal and MIT KDCs support "pkinit",


Yes, all this but...


That said, there is not yet support for "raw public key" AS requests, where the
KDC stores the user's public key, rather than either a symmetric key or a 
trusted
issuer CA.


...the above will probably never happen.

Or put it the other way: Today this is rather covered by JWT/OAuth2 or 
similar which are also more proxy-friendly than e.g. TLS with client 
certs. Not sure about the smooth integration in MUAs though. 
SASL-XOAUTH2 does not seem to be widely implemented (puh, stay a bit 
on-topic.. ;-)



Either way a compromised CA or a compromise KDC is bad news...


Yes!

And one of my biggest concerns are bad operational practices. That's why 
admins should not have to manually deal with crypto key files like 
service keytabs or TLS server keys.


Ciao, Michael.

Re: password security

[Viktor Dukhovni]

> On 27 Apr 2022, at 12:45 pm, Michael Ströder  wrote:
> 
> But my concern is rather that I would not connect my KDC to the Internet (for 
> now leaving aside approaches like proxy KCM).
> 
> In general I'm leaning more towards using asymmetric keys for authc. On my 
> personal to-do list is to implement a simple X.509-CA for issuing short-term 
> client certs, with a CLI tool to directly manipulate Thunderbird and Firefox 
> key/cert DB.

FWIW, both Heimdal and MIT KDCs support "pkinit", and it should be (but may not 
yet)
be possible to disable symmetric-key AS requests (the TGS will still be keyed 
with
a symmetric key, but it is independent of long-term user secrets, and the TGS 
key
can be rotated from time to time).

That said, there is not yet support for "raw public key" AS requests, where the
KDC stores the user's public key, rather than either a symmetric key or a 
trusted
issuer CA.  This has probably been proposed, but I don't know of any current 
RFCs
or implementations along these lines.  Should be a relatively straight-forward
extension.

A KDC is basically an online CA, both store valuable secrets that if leaked 
enable
impersonation.  The main difference is that for a CA that's just one trust 
anchor,
perhaps more readily replaced, but for a KDC there are also many principals 
whose
shared secrets with the KDC need to be refreshed in the event of a compromise.

Either way a compromised CA or a compromise KDC is bad news...

-- 
Viktor.

Re: password security

[Michael Ströder]

On 4/27/22 18:38, Demi Marie Obenour wrote:

On 4/27/22 07:58, Michael Ströder wrote:

Mozilla hunked out all features for PKI client cert enrollment from
Firefox and Thunderbird. So today it's easier to issue client certs to
Outlook users than to Thunderbird users. :-(


Please report a bug on https://bugzilla.mozilla.org as this is a problem
with Thunderbird.


Did you actually read my e-mail? They hunked out  etc. This ship 
has sailed quite a while ago. No point to waste my time to create yet 
another dead ticket in their bugzilla.


Ciao, Michael.

Re: password security

[Antonio Leding]

“Well, if you believe that it's ok for you to use it.”

Not sure if you mean I’m being presumptuous (not intended) or actually 
that I would see value in using it - I think you meant the latter but 
again, not sure…(lol)


Anyway, I would see value in at least checking it out - seems 
interesting…


- - -

On 27 Apr 2022, at 9:52, Michael Ströder wrote:


On 4/27/22 18:39, Demi Marie Obenour wrote:

On 4/27/22 12:27, Michael Ströder wrote:

On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
I’m very interested in what options / solutions (if any) exist 
that allow
you to use a passwordless approach to authenticating your users 
against

imaps/pop3/smtps/submission services (tls encrypted of course)


one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via
public Internet.


Hard disagree; Kerberos is safe for use over the Internet.


Well, if you believe that it's ok for you to use it.

My personal preference is to avoid storing shared secrets in a 
directly accessible network services. And I'm saying this as somebody 
who tried hard to secure OATH-LDAP services (HOTP with Yubikey and 
OpenLDAP).


BTW: My doubts are not about the Kerberos crypto used. My doubts are 
rather about the many unknown security bugs in all the systems 
involved which might allow attackers to get hold of the shared 
secrets.


Ciao, Michael.

Re: password security

[Michael Ströder]

On 4/27/22 18:50, Antonio Leding wrote:

On 27 Apr 2022, at 9:45, Michael Ströder wrote:
> “On my personal to-do list is to implement a simple X.509-CA for issuing 
> short-term client certs, with a CLI tool to directly manipulate 
> Thunderbird and Firefox key/cert DB.”


As in you are planning to build such a suite and put up on GH for all of 
us to use as well???


Yes, just like I publish almost all of my stuff (e.g. EKCA) - when I 
ever find the time ... don't hold your breath waiting for it..


Ciao, Michael.

Re: password security

[Michael Ströder]

On 4/27/22 18:39, Demi Marie Obenour wrote:

On 4/27/22 12:27, Michael Ströder wrote:

On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:

I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of course)


one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via
public Internet.


Hard disagree; Kerberos is safe for use over the Internet.


Well, if you believe that it's ok for you to use it.

My personal preference is to avoid storing shared secrets in a directly 
accessible network services. And I'm saying this as somebody who tried 
hard to secure OATH-LDAP services (HOTP with Yubikey and OpenLDAP).


BTW: My doubts are not about the Kerberos crypto used. My doubts are 
rather about the many unknown security bugs in all the systems involved 
which might allow attackers to get hold of the shared secrets.


Ciao, Michael.

Re: password security

[Antonio Leding]

“On my personal to-do list is to implement a simple X.509-CA for 
issuing short-term client certs, with a CLI tool to directly manipulate 
Thunderbird and Firefox key/cert DB.”


As in you are planning to build such a suite and put up on GH for all of 
us to use as well???


If so, would love to learn of your progress in that realm…

- - -

On 27 Apr 2022, at 9:45, Michael Ströder wrote:


On 4/27/22 18:36, Viktor Dukhovni wrote:
On 27 Apr 2022, at 12:27 pm, Michael Ströder  
wrote:



one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via 
public Internet.


Suitability depends on the user base, ... my personal mail server
indeed supports SASL GSSAPI submission.  There are no users with
weak passwords.


Strictly speaking you would have to say SASL GSSAPI with Kerberos 5 
because...



Note also that in principle GSSAPI can support all sorts of novel
authentication mechanisms,


...you're of course right that GSSAPI is also a generic layer.


The layering of SASL over GSSAPI is somewhat redundant,


Agreed.

But my concern is rather that I would not connect my KDC to the 
Internet (for now leaving aside approaches like proxy KCM).


In general I'm leaning more towards using asymmetric keys for authc. 
On my personal to-do list is to implement a simple X.509-CA for 
issuing short-term client certs, with a CLI tool to directly 
manipulate Thunderbird and Firefox key/cert DB.


Ciao, Michael.

Re: password security

[Michael Ströder]

On 4/27/22 18:36, Viktor Dukhovni wrote:

On 27 Apr 2022, at 12:27 pm, Michael Ströder  wrote:


one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via public 
Internet.


Suitability depends on the user base, ... my personal mail server
indeed supports SASL GSSAPI submission.  There are no users with
weak passwords.


Strictly speaking you would have to say SASL GSSAPI with Kerberos 5 
because...



Note also that in principle GSSAPI can support all sorts of novel
authentication mechanisms,


...you're of course right that GSSAPI is also a generic layer.


The layering of SASL over GSSAPI is somewhat redundant,


Agreed.

But my concern is rather that I would not connect my KDC to the Internet 
(for now leaving aside approaches like proxy KCM).


In general I'm leaning more towards using asymmetric keys for authc. On 
my personal to-do list is to implement a simple X.509-CA for issuing 
short-term client certs, with a CLI tool to directly manipulate 
Thunderbird and Firefox key/cert DB.


Ciao, Michael.

Re: password security

[Demi Marie Obenour]

On 4/27/22 12:27, Michael Ströder wrote:
> On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:
> I’m very interested in what options / solutions (if any) exist that allow
> you to use a passwordless approach to authenticating your users against
> imaps/pop3/smtps/submission services (tls encrypted of course)
>>
>> one way to authenticate may be using Kerberos.
> 
> Not recommended for roaming users accessing submission service via 
> public Internet.
> 
> Ciao, Michael.

Hard disagree; Kerberos is safe for use over the Internet.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: password security

[Demi Marie Obenour]

On 4/27/22 08:37, Jahnke-Zumbusch, Dirk wrote:
> Hi everybody,
> 
 I’m very interested in what options / solutions (if any) exist that allow
 you to use a passwordless approach to authenticating your users against
 imaps/pop3/smtps/submission services (tls encrypted of course)
> 
> one way to authenticate may be using Kerberos. Get your
> K5-Ticket-Granting-Ticket at your Kerberos server,
> yes: using username password, and then use this ticket
> during the next hours to authenticate against properly
> configured servers (Dovecot, Apache, ...). May be this
> is a hint into the direction of what might help you.
> 
> Cheers, Dirk.

Please enable channel binding if you go with this route.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: password security

[Demi Marie Obenour]

On 4/27/22 07:58, Michael Ströder wrote:
> On 4/27/22 12:27, Jaroslaw Rafa wrote:
>> Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:
>>>
>>> I’m very interested in what options / solutions (if any) exist that allow
>>> you to use a passwordless approach to authenticating your users against
>>> imaps/pop3/smtps/submission services (tls encrypted of course)
>>
>> To my knowledge, Thunderbird supports certificate-based authentication both
>> to imaps and smtps/submission. On the server side, you can probably configure
>> certificate-based authentication in most mail server software, in particular
>> in Postfix and Dovecot.
> 
> Configuring it on the server-side is fairly easy.
> 
> The hard part is enrolling client certs for end-users, especially into 
> Thunderbird.
> 
> Mozilla hunked out all features for PKI client cert enrollment from 
> Firefox and Thunderbird. So today it's easier to issue client certs to 
> Outlook users than to Thunderbird users. :-(
> 
> Ciao, Michael.

Please report a bug on https://bugzilla.mozilla.org as this is a problem
with Thunderbird.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: password security

[Michael Ströder]

On 4/27/22 17:28, lists wrote:
The TOTP built into Linux has a 30 second time limit but most 
implementations approve the stale code making it effectively 60 
seconds.

>

Hackers have either implemented [..] a man in the middle attack
intercepted the token.
An implementation taking the "one-time" in "TOTP" serious will lock a 
seen time-step from being reused.


See also:

https://datatracker.ietf.org/doc/html/rfc6238#section-5.2

"Second, the next different OTP must be generated in the next time-step 
window."


I guess many TOTP implementations are sloppy though.

Ciao, Michael.

Re: password security

[Viktor Dukhovni]

> On 27 Apr 2022, at 12:27 pm, Michael Ströder  wrote:
> 
>> one way to authenticate may be using Kerberos.
> 
> Not recommended for roaming users accessing submission service via public 
> Internet.

Suitability depends on the user base, ... my personal mail server
indeed supports SASL GSSAPI submission.  There are no users with
weak passwords.

Note also that in principle GSSAPI can support all sorts of novel
authentication mechanisms, so long as client and server agree on
a suitable mechanism OID.  The layering of SASL over GSSAPI is
somewhat redundant, ... but I digress.

-- 
Viktor.

Re: password security

[Michael Ströder]

On 4/27/22 14:37, Jahnke-Zumbusch, Dirk wrote:

I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of course)


one way to authenticate may be using Kerberos.


Not recommended for roaming users accessing submission service via 
public Internet.


Ciao, Michael.

Re: Exclude non-existing subdomains from checking

[Viktor Dukhovni]

On Wed, Apr 27, 2022 at 08:42:25AM +0200, Varadi Gabor wrote:

> > /\.that-domain\.com$/  OK
> 
> /.*\.that-domain\.com$/ OK
> 
> Tested in https://www.debuggex.com/?flavor=pcre

No. The original form is better.  The leading ".*" is unnecessary and
may be less efficient.

The OP (who failed to post "postconf -nf" output) likely has
"reject_unknown_sender_domain" in more than one restriction
list, perhaps also "smtpd_recipient_restrictions"?

-- 
Viktor.

Re: for what file need to run postmap

[Viktor Dukhovni]

On Wed, Apr 27, 2022 at 06:12:53PM +0800, al...@coakmail.com wrote:

> I guess this kind of file doesn't need to run postmap against it?
> 
>  virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
>  virtual_alias_domains = /etc/postfix/virtual_alias_domains

These are "match lists", the syntax allows a list of literal values, or
a file with one value per line, or a table with keys and ignored values.

Tables types that are "indexed files" (hash, btree, cdb, lmdb, ...)
don't use the source file directly, instead a "database" file is
created from the source file in order to support more efficient
lookup than linear search.

Table syntax always specifies the table type "type:table", and
postmap is needed for the "types" that construct "indexed file"
representations of the data.

> But this file need postmap after the modification?
> 
>  virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

This parameter requires lookup tables, and does not support a list of
literal values.  The values associated with the lookup keys are
meaningful and not ignored.

-- 
Viktor.

Re: for what file need to run postmap

[Wietse Venema]

al...@coakmail.com:
> Hello
> 
> I guess this kind of file doesn't need to run postmap against it?

All tables that are created with the postmap command, as described
in https://www.postfix.org/DATABASE_README.html#types

Wietse

Re: password security

[lists]

The TOTP built into Linux has a 30 second time limit but most implementations 
approve the stale code making it effectively 60 seconds. 

Hackers have either implemented or there was a proof of concept (I forget 
which) where a man in the middle attack intercepted the token. That is more 
likely to occur with a web page Auth where the MITM presents a fake page. 






  Original Message  


From: postfixlists-070...@billmail.scconsult.com
Sent: April 27, 2022 8:04 AM
To: postfix-users@postfix.org
Subject: Re: password security


On 2022-04-27 at 01:47:06 UTC-0400 (Wed, 27 Apr 2022 17:47:06 +1200)
AndrewHardy 
is rumored to have said:

> Hi,
>
> Following this thread has been quite intriguing. Interesting
> conversation indeed.
>
> On a similar topic but probably more focused on addressing root cause
> (which in mind is just passwords = the devil of security) and the
> inherent insecurities with using them.
>
> I’m very interested in what options / solutions (if any) exist that
> allow you to use a passwordless approach to authenticating your users
> against imaps/pop3/smtps/submission services (tls encrypted of course)
> acknowledging that it’s extremely unlikely to address abuse of the
> non-auth enabled smtp listener so won’t rid the server of ‘all
> noise’ or ‘hacking attempts’ nor address lower level
> exploit/attacks (network/protocol level etc).
>
> Do any solutions exist today? I suspect the issue isn’t so much what
> you can do server side as possibilities are near endless but
> constraint is email client support which in my mind is the primary
> issue? Is that a reasonable conclusion?

I think it depends on what you mean by 'primary' but basically: yes. The
reason client support is extremely uneven is that there are not easily
implementable standards for how to avoid passwords with SMTP AUTH. The
most common mechanism is to use OAuth2, which requires client developers
to register their authenticating apps with service providers and get
their blessings to be used with their services. Typically the
out-of-band OAuth2 interaction requires some form of one-time password.
Another approach is to use client X.509 certificates, a mechanism that
is better for automated use (i.e. where there's no one available to
respond to perform the OOB OAuth2 renewal.) Both client certs for
authentication and OTP+OAuth2  are non-trivial to do correctly in a MUA.

The real root cause is deep and insoluble. Passwords are problematic
because they can be guessed or stolen. A certificate can be stolen. A
hardware token (e.g. RSA key) that generates random-ish one-time
passwords (i.e. HOTP) can itself be stolen and has seed and counter
values that can be stolen. A TOTP authenticator app (e.g. Google
Authenticator or MS Authenticator) has a seed value. To fix that
problem, nth-factors typically are time-limited. TOTP codes expire every
minute, typically. HOTP codes are strictly one-use so that a thief needs
the seed, counter AND to prevent legit use. Certificates expire, and the
trend is towards making them expire faster. OAuth2 tokens expire. All of
these create the need for regular human interaction to renew the
authentication, and so feel inconvenient. A 'slick' solution is
impossible because there needs to be a barricade against a thief
automating access with stolen credentials.


> I’m guessing what I’m asking is if there’s an open source
> solution that doesn’t require you to pay Microsoft or others
> extraordinary amounts of money just to get some smart protection?

If you want to do it now with Postfix, client certificates from your own
CA are probably the best way to go. Based on the angst displayed on that
topic here over the years, it is not trivial to get set up correctly,
but it is possible. Dovecot SASL supports OAuth2, so that's also an
option if you're willing to handle the backend yourself.


--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Fixed: postscreen signal 11

[Wietse Venema]

Wietse Venema:
> This is a site-specific problem. I ran "openssl s_client" and
> "posttls-finger -w" against one of the affected servers, and reliably
> crashed their postscreen daemon. I've been doing similar tests
> against my own servers without any problems.

That was with FreeBSD 13.0, as well as Fedora Linux.

I was able to reproduce the problem with FreeBSD 13.1 RC4 (a release
candidate) from ftp.freebsd.org, with the command

openssl s_client 127.0.0.1:25

This was a Postfix problem that was exposed by a more aggressive
compiler. See patch below.

The real fix, already available with the Postfix 3.8 unstable
release, is to roll back the change from 20211023 that resulted in
this confusing code, so that the mistake cannot be made again.

The code confused both me (so that I made the mistake) and the
compiler (so that it did not report a missing initialization).

Wietse

diff -ur /var/tmp/postfix-3.7.1/src/postscreen/postscreen_smtpd.c 
./src/postscreen/postscreen_smtpd.c
--- /var/tmp/postfix-3.7.1/src/postscreen/postscreen_smtpd.c2021-12-19 
08:04:50.0 -0500
+++ ./src/postscreen/postscreen_smtpd.c 2022-04-27 09:57:24.0 -0400
@@ -1149,6 +1149,8 @@
if (cmdp->flags & PSC_SMTPD_CMD_FLAG_DESTROY)
return;
}
+   } else {
+   cmdp = 0;
}
 
/*
@@ -1164,7 +1166,7 @@
 * Hopefully, someone will call us back to process the remainder of
 * the pending input, otherwise we could hang.
 */
-   if (cmdp->flags & PSC_SMTPD_CMD_FLAG_SUSPEND)
+   if (cmdp && cmdp->flags & PSC_SMTPD_CMD_FLAG_SUSPEND)
return;
 
/*

Re: password security

[Bill Cole]

On 2022-04-27 at 01:47:06 UTC-0400 (Wed, 27 Apr 2022 17:47:06 +1200)
AndrewHardy 
is rumored to have said:


Hi,

Following this thread has been quite intriguing. Interesting 
conversation indeed.


On a similar topic but probably more focused on addressing root cause 
(which in mind is just passwords = the devil of security) and the 
inherent insecurities with using them.


I’m very interested in what options / solutions (if any) exist that 
allow you to use a passwordless approach to authenticating your users 
against imaps/pop3/smtps/submission services (tls encrypted of course) 
acknowledging that it’s extremely unlikely to address abuse of the 
non-auth enabled smtp listener so won’t rid the server of ‘all 
noise’ or ‘hacking attempts’ nor address lower level 
exploit/attacks (network/protocol level etc).


Do any solutions exist today? I suspect the issue isn’t so much what 
you can do server side as possibilities are near endless but 
constraint is email client support which in my mind is the primary 
issue? Is that a reasonable conclusion?


I think it depends on what you mean by 'primary' but basically: yes. The 
reason client support is extremely uneven is that there are not easily 
implementable standards for how to avoid passwords with SMTP AUTH. The 
most common mechanism is to use OAuth2, which requires client developers 
to register their authenticating apps with service providers and get 
their blessings to be used with their services. Typically the 
out-of-band OAuth2 interaction requires some form of one-time password. 
Another approach is to use client X.509 certificates, a mechanism that 
is better for automated use (i.e. where there's no one available to 
respond to perform the OOB OAuth2 renewal.) Both client certs for 
authentication and OTP+OAuth2  are non-trivial to do correctly in a MUA.


The real root cause is deep and insoluble. Passwords are problematic 
because they can be guessed or stolen. A certificate can be stolen. A 
hardware token (e.g. RSA key) that generates random-ish one-time 
passwords (i.e. HOTP) can itself be stolen and has seed and counter 
values that can be stolen. A TOTP authenticator app (e.g. Google 
Authenticator or MS Authenticator) has a seed value. To fix that 
problem, nth-factors typically are time-limited. TOTP codes expire every 
minute, typically. HOTP codes are strictly one-use so that a thief needs 
the seed, counter AND to prevent legit use. Certificates expire, and the 
trend is towards making them expire faster. OAuth2 tokens expire. All of 
these create the need for regular human interaction to renew the 
authentication, and so feel inconvenient. A 'slick' solution is 
impossible because there needs to be a barricade against a thief 
automating access with stolen credentials.



I’m guessing what I’m asking is if there’s an open source 
solution that doesn’t require you to pay Microsoft or others 
extraordinary amounts of money just to get some smart protection?


If you want to do it now with Postfix, client certificates from your own 
CA are probably the best way to go. Based on the angst displayed on that 
topic here over the years, it is not trivial to get set up correctly, 
but it is possible. Dovecot SASL supports OAuth2, so that's also an 
option if you're willing to handle the backend yourself.



--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

Re: what's a encrypted email?

[Byung-Hee HWANG]

wilson  writes:

> today everyone claim they are encrypted email provider.
> what's the definition of an encrypted email? messages and headers and
> logs were encrypted in the rest?

I think RFC 8461 is worth considering, thanks!

Sincerely, Linux fan Byung-Hee

-- 
^고맙습니다 _布德天下_ 감사합니다_^))//

Re: password security

[Jahnke-Zumbusch, Dirk]

Hi everybody,

>>> I’m very interested in what options / solutions (if any) exist that allow
>>> you to use a passwordless approach to authenticating your users against
>>> imaps/pop3/smtps/submission services (tls encrypted of course)

one way to authenticate may be using Kerberos. Get your
K5-Ticket-Granting-Ticket at your Kerberos server,
yes: using username password, and then use this ticket
during the next hours to authenticate against properly
configured servers (Dovecot, Apache, ...). May be this
is a hint into the direction of what might help you.

Cheers, Dirk.

Re: password security

[Michael Ströder]

On 4/27/22 12:27, Jaroslaw Rafa wrote:

Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:


I’m very interested in what options / solutions (if any) exist that allow
you to use a passwordless approach to authenticating your users against
imaps/pop3/smtps/submission services (tls encrypted of course)


To my knowledge, Thunderbird supports certificate-based authentication both
to imaps and smtps/submission. On the server side, you can probably configure
certificate-based authentication in most mail server software, in particular
in Postfix and Dovecot.


Configuring it on the server-side is fairly easy.

The hard part is enrolling client certs for end-users, especially into 
Thunderbird.


Mozilla hunked out all features for PKI client cert enrollment from 
Firefox and Thunderbird. So today it's easier to issue client certs to 
Outlook users than to Thunderbird users. :-(


Ciao, Michael.

Re: password security

[Jaroslaw Rafa]

Dnia 26.04.2022 o godz. 18:59:35 lists pisze:
> I see the snowshoe hackers on my web server and I
> assume they are on my email but I don't read the postfix logs as often. I
> haven't seen a hacker hammer my server in a long time. It is all snowshoe
> these days.

I also have a personal server and I can see both. There is a lot of
snowshoe, but there are also IPs that constantly hammer my submission/smtps
ports for long time, trying subsequent login/passwords combinations (usually
for usernames that never existed on my server :), I only rarely see them
trying an actually existing username). What's interesting, I don't see the
latter behavior with ssh attempts - this is actually almost 100% snowshoe -
but with submissions/smtps, yes, the "hammering" happens all the time.

After I see this behavior in the logs, I usually ban those IPs in iptables
permanently.

Of course there was a lot more of this "hammering" when some time ago I had
mistakenly AUTH turned on on port 25, so it looks like the bots that try to
crack email passwords are mostly targeting this port.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: for what file need to run postmap

[Aban Dokht]

Hello Alice,

check out:

http://www.postfix.org/postconf.5.html

For every parameter you'll find the expected values, e.g. for virtual_alias_maps , which 
expects a "lookup table".
If you use hash:*, you must postmap this file.





al...@coakmail.com wrote:

Hello

I guess this kind of file doesn't need to run postmap against it?

  virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
  virtual_alias_domains = /etc/postfix/virtual_alias_domains

But this file need postmap after the modification?

  virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

please give an explanation. thank you



Regards
Aban

--
 Aban Dokht   aban.do...@abando.de
--

Re: password security

[Jaroslaw Rafa]

Dnia 27.04.2022 o godz. 17:47:06 AndrewHardy pisze:
> 
> I’m very interested in what options / solutions (if any) exist that allow
> you to use a passwordless approach to authenticating your users against
> imaps/pop3/smtps/submission services (tls encrypted of course)

To my knowledge, Thunderbird supports certificate-based authentication both
to imaps and smtps/submission. On the server side, you can probably configure
certificate-based authentication in most mail server software, in particular
in Postfix and Dovecot.

Although the above is based only on what I read in the docs, never used it
:)
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

for what file need to run postmap

[alice]

Hello

I guess this kind of file doesn't need to run postmap against it?

 virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
 virtual_alias_domains = /etc/postfix/virtual_alias_domains

But this file need postmap after the modification?

 virtual_alias_maps = hash:/etc/postfix/virtual_alias_maps

please give an explanation. thank you

Re: what's a encrypted email?

[Jaroslaw Rafa]

Dnia 27.04.2022 o godz. 15:46:33 wilson pisze:
> today everyone claim they are encrypted email provider.
> what's the definition of an encrypted email? messages and headers
> and logs were encrypted in the rest?

"Encrypted email" is a very vague term and one can understand it very
differently.

Myself, I understand "encrypted email" usually as end-to-end encryption, ie.
before sending mail to someone, you encrypt it with that person's public
key, eg. using GPG/PGP, and that person decrypts the message using their
private key when they view it in their inbox. Support for this is integrated
in most email clients. With this method, the message stays encrypted all
the time - on your computer, in transit, on server and on recipient's
computer. It is not encrypted only while you are writing it and on
recipent's screen while viewing. Only the body of the message is encrypted,
the headers are not. But this has nothing to do with the provider - it is
purely a client-side thing.

BTW. You can not only encrypt, but also digitally sign email with this
method.

But if someone speaks about "encrypted email" in context of a provider, I
don't think they mean this kind of encryption. I think they rather mean the
simple fact that all communication with the mail server is encrypted with
TLS. So message is fully encrypted in transit (all communication is
encrypted), but it stays unencrypted both on sender's and recipient's
computer, as well as on the server (if you didn't use end-to-end encryption
when sending it). This is pretty much a standard nowadays, so it's strange
to me that anybody is putting any emphasis on this.

Of course both these types of encryption can be used simultaneously, they
don't exclude each other.

There are also "encrypted email providers" that claim that the messages stay
encrypted on their server, so for example admins are not able to access and
view them - and that is what they mean by "encrypted email". This is usually
in addition to the "standard" TLS encryption described above, which is
basically a standard that everyone has.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."

Re: password security

[Shardul Adhikari]

One more important thing is to educate the users  to not click on any
unknown links because many a times spammers get hold of the account by the
way of phishing emails.

Fail2ban works in case there are brute force attempts. but if the password
is valid then the server will authenticate.



On Mon, Apr 25, 2022 at 12:38 PM Laura Smith <
n5d9xq3ti233xiyif...@protonmail.ch> wrote:

>
> --- Original Message ---
> On Monday, April 25th, 2022 at 05:26, ミユナ  wrote:
>
> > do you know how to stop passwords from being brute-forced for a
> > mailserver? do you have any practical guide?
> >
>
> Simple. You've got two options:
>
> a) Use strong passwords (and if you run an automated password changing
> system, enforce strong passwords)
>
> b) Use client-certificate authentication
>
> Stuff like fail2ban is for the lazy. You should be focusing on solving the
> underlying cause of the problem, i.e. using one of the two options above.
>
> The problem with stuff like fail2ban is that you are basically playing
> whack-a-mole.  IP address blocking simply does not work 2022, attackers
> have too many options (i.e. they can hop between cloud providers, they can
> use IPv6 to give them massive ranges to play with etc. etc.).
>

AW: Exclude non-existing subdomains from checking

[Ludi Cree]

Hi,

>> /\.that-domain\.com$/  OK

>/.*\.that-domain\.com$/ OK

>Tested in https://www.debuggex.com/?flavor=pcre

Thanks!

Greets,
Ludi

what's a encrypted email?

[wilson]

today everyone claim they are encrypted email provider.
what's the definition of an encrypted email? messages and headers and 
logs were encrypted in the rest?


Thanks

Re: password security

[Ansgar Wiechers]

On 2022-04-27 lists wrote:
> Steve Gibson spent four years developing a passwordless Auth system.
> Open sourced it. Provided APIs. Nobody bought into it.

Steve Gibson? The same Steve Gibson who claimed that raw sockets in
Windows XP are evil because ... reasons? The same Steve Gibson who
successfully brainwashed half the internet into destroying ICMP because
"stealth?" *That* Steve Gibson?

I *strongly* advise everyone to take *anything* coming from Gibson with
two or three handful of salt. At least. The guy is a charlatan at best.

Regards
Ansgar Wiechers
-- 
"Abstractions save us time working, but they don't save us time learning."
--Joel Spolsky

Re: password security

[lists]

  Steve Gibson spent four years developing a passwordless Auth system. Open sourced it. Provided APIs. Nobody bought into it. https://www.grc.com/sqrl/sqrl.htmPart of what you asked sounds like the equivalent of a web firewall (WAF). I'm not a fan since the one I was using often broke the website I think postfix and dovecot have enough options that you don't need something like a WAF. From: andrewha...@andrewhardy.co.nzSent: April 26, 2022 10:47 PMTo: li...@lazygranch.comCc: postfix-users@postfix.orgSubject: Re: password security  Hi,Following this thread has been quite intriguing. Interesting conversation indeed.On a similar topic but probably more focused on addressing root cause (which in mind is just passwords = the devil of security) and the inherent insecurities with using them.I’m very interested in what options / solutions (if any) exist that allow you to use a passwordless approach to authenticating your users against imaps/pop3/smtps/submission services (tls encrypted of course) acknowledging that it’s extremely unlikely to address abuse of the non-auth enabled smtp listener so won’t rid the server of ‘all noise’ or ‘hacking attempts’ nor address lower level exploit/attacks (network/protocol level etc).Do any solutions exist today? I suspect the issue isn’t so much what you can do server side as possibilities are near endless but constraint is email client support which in my mind is the primary issue? Is that a reasonable conclusion? I’m guessing what I’m asking is if there’s an open source solution that doesn’t require you to pay Microsoft or others extraordinary amounts of money just to get some smart protection? I see security as a right for users so open source way to craft an architecture that provides this as an option for users who opt-in would be pretty cool (eventually becoming the normal longer term)Keen to hear thoughts on this as I suspect if you can architect a solution that allows users to opt for passwordless approach to auth’ing with a long term desire and goal to phase out password use, then it seems like a pretty epic win for I loving the security of the internet as a whole longer term. Large scale providers with perhaps millions of users = ok tough luck that’s gonna be a real challenge, legendary feat if can accomplish it in practice :) May not be the appropriate thread or ask these questions but thought if there were solutions available for such a solution, perhaps that may go a long way to helping answer what can be done to secure the servers from these types of attacks :)I’m much more inclined personally to tackle root cause and remove the issue completely but acknowledge that it may be a panacea and utopian mind set and may not = reality or not readily work in more scenarios than what issues it’s trying to address. Feasibility question(s) really.ThanksAndrewOn 27/04/2022, at 2:00 PM, lists  wrote:   https://www.reddit.com/r/postfix/Well there is a subreddit for postfix. News to me but I just joined it. I do my best to stay out of these "conversations" on the listserv and reserve my posts for when I am really stumped. But since I am posting put me in the firewall geofence crowd. I have done this for a two years now and it vastly reduces the hacking on my server. I block all email ports other than 25 from countries I have no plan on visiting. This is really only practical for a personal email server. I also have a list of data centers that I give the same treatment. I see the snowshoe hackers on my web server and I assume they are on my email but I don't read the postfix logs as often. I haven't seen a hacker hammer my server in a long time. It is all snowshoe these days. I am not a fan of fail2ban or sshguard on my low powered VPS. I find dynamically adding IPs to the firewall is a high CPU usage event. It may be a consequence of having a huge list of IP space to block. My assumption is firewalld has to add the IPs in an efficient to search manner and arranging the table/database is CPU intensive. It would send the VPS to 100%. (My personal data center blocking list is about 40k lines of CIDRs.) I was choking the server adding IPs for what would otherwise be a low impact event. Sometimes I think a VPS is lower CPU power than a R Pi. Firewalld itself is a very low CPU usage program once the table/database is established. It does use a fair amount of RAM which again must be related to the table/database it creates. I have no fear of my passwords being breached. It is a personal server so every password was created by me and all are generated by an algorithm to achieve high entropy. I've been using 20 characters as a standard since that seems to 

Re: Exclude non-existing subdomains from checking

[Varadi Gabor]

2022. 04. 27. 8:16 keltezéssel, Ludi Cree írta:

Hi all,

  


I would like to exclude non-existing subdomains from this rule:

  


"reject_unknown_sender_domain"

  


that I have on the end of my sender-restrictions here:

  


smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated,
reject_non_fqdn_sender, check_sender_access pcre:/etc/postfix/pcre_sender,
reject_unknown_sender_domain

  


So I put in my PCRE check before that:

  


/\.that-domain\.com$/  OK


/.*\.that-domain\.com$/ OK

Tested in https://www.debuggex.com/?flavor=pcre

--
  [Varadi Gabor]

Exclude non-existing subdomains from checking

[Ludi Cree]

Hi all,

 

I would like to exclude non-existing subdomains from this rule:

 

"reject_unknown_sender_domain"

 

that I have on the end of my sender-restrictions here:

 

smtpd_sender_restrictions = check_sender_access
hash:/var/spool/postfix/plesk/blacklists, permit_sasl_authenticated,
reject_non_fqdn_sender, check_sender_access pcre:/etc/postfix/pcre_sender,
reject_unknown_sender_domain

 

So I put in my PCRE check before that:

 

/\.that-domain\.com$/  OK

 

But I still get mail from @station.that-domain.com thrown out with:

 

4.1.8 Sender address rejected: Domain not found;

 

What am I missing here?

 

Greets,

Ludi