Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 17/6/2022 12:11 pm, raf wrote:


Something like the following should do it (after making
the renewal config changes that Viktor mentioned (or
including them in the command)):

   certbot renew --force-renewal --cert-name XXX

Also note that there is a very useful forum for help with
letsencrypt and certbot:

   https://community.letsencrypt.org/


Thank you very much for sharing this information.

FYI. The above command works well. This is what I used too.

My bad for not sharing back the command.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[raf]

On Wed, Jun 15, 2022 at 11:09:10PM +0530, P V Anthony 
 wrote:

> Please note, I am still finding how to force renew with the letsencrypt
> certs with the new renewal settings.

Something like the following should do it (after making
the renewal config changes that Viktor mentioned (or
including them in the command)):

  certbot renew --force-renewal --cert-name XXX

Also note that there is a very useful forum for help with
letsencrypt and certbot:

  https://community.letsencrypt.org/

cheers,
raf

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 16/6/2022 8:16 pm, Viktor Dukhovni wrote:


So it is far from clear what you could do to make this client happy.
Perhaps some security middlebox near the client is misbehaving, or its
TLS stack is broken beyond repair.  Your best may be to disable STARTTLS
for connections from this client:

 smtpd_discard_ehlo_keyword_address_maps =
 inline:{ { 216.109.104.12 = starttls } }

If possible, reach out to the postmaster of the remote system or ask the
receiving user for their contacts on the sending side.  They may have some
insight about what it is their software is unhappy about.


Thank you very much for taking the time to look into this issue with so 
much detail. I do appreciate it very very very much.


I will do the smtpd_discard_ehlo_keyword_address_maps to not advertise 
starttls.


I am suspecting it is their java something that has the problem.

When I did communicate with their support, she said this a cloud 
solution and it cannot be their problem. They are big. I think they are 
some SAP company.


Anyway we can conclude that it is not our server. That's a relief.

Once again thank you very much for helping.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 03:09:16PM -0400, Viktor Dukhovni wrote:

> You can share the PCAP file with me off-list.

Thanks for the PCAP file.  An immediate interesting feature is how the
connection is terminated ("tcpdump" output edited to trim excess
detail):

22:32:13.555416 1711 > 25: [S], seq 3405166426, win 65535, length 0
22:32:13.555449 25 > 1711: [S.], seq 1841506549, ack 3405166427, win 28960, 
length 0
22:32:13.742679 1711 > 25: [.], ack 1, win 2058, length 0
22:32:13.994238 25 > 1711: [P.], seq 1:39, ack 1, win 227, length 38: SMTP: 
220 mail.ittech.com.sg ESMTP Postfix
22:32:14.182397 1711 > 25: [.], ack 39, win 2058, length 0
22:32:14.182736 1711 > 25: [P.], seq 1:24, ack 39, win 2058, length 23: 
SMTP: EHLO ansmtp.ariba.com
22:32:14.182767 25 > 1711: [.], ack 24, win 227, length 0
22:32:14.182917 25 > 1711: [P.], seq 39:194, ack 24, win 227, length 155: 
SMTP: 250-mail.ittech.com.sg
22:32:14.370857 1711 > 25: [.], ack 194, win 2056, length 0
22:32:14.371213 1711 > 25: [P.], seq 24:34, ack 194, win 2058, length 10: 
SMTP: STARTTLS
22:32:14.371276 25 > 1711: [P.], seq 194:224, ack 34, win 227, length 30: 
SMTP: 220 2.0.0 Ready to start TLS
22:32:14.559151 1711 > 25: [.], ack 224, win 2058, length 0
22:32:14.559877 1711 > 25: [P.], seq 34:233, ack 224, win 2058, length 199
22:32:14.561871 25 > 1711: [.], seq 224:1672, ack 233, win 235, length 1448
22:32:14.561873 25 > 1711: [.], seq 1672:3120, ack 233, win 235, length 1448
22:32:14.561912 25 > 1711: [P.], seq 3120:3355, ack 233, win 235, length 235
22:32:14.750425 1711 > 25: [R.], seq 233, ack 1672, win 235, length 0

As we'll see below, the the last three TCP segments from the server
contain the TLS Server HELLO, the certificate message, the key exchange
message and server HELLO DONE message.  The client slams the door closed
with "RST + ACK" and a sequence number acking receipt of just the first
of the three frames.  The RST is delayed by ~190ms, which is close to
the RTT delay for earlier messages, so its origin does appear to be
remote.

[ Trimmed "tshark" decodes below signature ]

The first frame contains the TLS Server Hello and only a portion of the
server certificate message.  I am guessing that the remote TLS stack
does not process partial TLS records (waits for each record to arrive in
full).  So whatever the client TLS stack did not like was in the TLS
Server Hello.

The TLS Server Hello message does not look at all remarkable to me:

Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 57
Version: TLS 1.2 (0x0303)
Random: ...
Session ID Length: 0
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Compression Method: null (0)
Extensions Length: 17
Extension: renegotiation_info (len=1)
Type: renegotiation_info (65281)
Length: 1
Renegotiation Info extension
Renegotiation info extension length: 0
Extension: ec_point_formats (len=4)
Type: ec_point_formats (11)
Length: 4
EC point formats Length: 3
Elliptic curves point formats (3)
EC point format: uncompressed (0)
EC point format: ansiX962_compressed_prime (1)
EC point format: ansiX962_compressed_char2 (2)
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)

So it is far from clear what you could do to make this client happy.
Perhaps some security middlebox near the client is misbehaving, or its
TLS stack is broken beyond repair.  Your best may be to disable STARTTLS
for connections from this client:

smtpd_discard_ehlo_keyword_address_maps =
inline:{ { 216.109.104.12 = starttls } }

If possible, reach out to the postmaster of the remote system or ask the
receiving user for their contacts on the sending side.  They may have some
insight about what it is their software is unhappy about.

-- 
Viktor.

Transmission Control Protocol, Src Port: 1711, Dst Port: 25, Seq: 0, Len: 0
Source Port: 1711
Destination Port: 25
[TCP Segment Len: 0]
Sequence Number: 0(relative sequence number)
[Next Sequence Number: 1(relative sequence number)]
Acknowledgment Number: 0
1010  = Header Length: 40 bytes (10)
Flags: 0x002 (SYN)

Transmission Control Protocol, Src Port: 25, Dst Port: 1711, Seq: 0, Ack: 1, 
Len: 0
Source Port: 25
Destination Port: 1711
[TCP Segment Len: 0]
Sequence Number: 0(relative sequence number)
[Next Sequence Number: 1(relative sequence number)]
Acknowledgment Number: 1(relative ack number)
1010  = Header Length: 40 bytes (10)
Flags: 0x012 (SYN, ACK)

Transmission Control Protocol,

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 11:09:10PM +0530, P V Anthony wrote:

> Unfortunately I am not experienced enough to find the problem from the logs.
> 
> Any suggests?
> 
> Please note, I am still finding how to force renew with the letsencrypt 
> certs with the new renewal settings.
> 
>  start 
> Jun 15 21:13:15 mail postfix/smtpd[887899]: connect from 
> ansmtp.ariba.com[216.109.104.12]
> Jun 15 21:13:15 mail postfix/smtpd[887899]: discarding EHLO keywords: 
> CHUNKING
> Jun 15 21:13:15 mail postfix/smtpd[887899]: setting up TLS connection from 
> ansmtp.ariba.com[216.109.104.12]
> Jun 15 21:13:15 mail postfix/smtpd[887899]: ansmtp.ariba.com[216.109.104.12]: 
> TLS cipher list "aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:before SSL 
> initialization
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:before SSL 
> initialization
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS read client 
> hello
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write server 
> hello
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write 
> certificate
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write key 
> exchange
> Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write server 
> done
> Jun 15 21:13:16 mail postfix/smtpd[887899]: SSL_accept:error in SSLv3/TLS 
> write server done
> Jun 15 21:13:16 mail postfix/smtpd[887899]: SSL_accept error from 
> ansmtp.ariba.com[216.109.104.12]: Connection reset by peer

So the client drops the connection (without sending a helpful alert) in
the middle of the server sending TLS HELLO, certificate chain, (EC)DH
key exchange and TLS finished with the last write failing.

So it objected to the HELLO parameters, the certificate chain or (EC)DH
parameters.

Now you need to get a 2048-bit certificate, and change DH parameters to
2048-bit (from 4096).

A PCAP file (tcpdump capture) of traffic from "216.109.104.12" would be
useful, if even after setting less crypto maximalist parameters the
connection still fails.

# tcpdump -s0 -w /tmp/ariba.pcap tcp port 25 and host 216.109.104.12 &

After the next transmission fails, terminate the background job with a
SIGINT.

# kill -INT %1

That'll flush any pending packets from memory to the PCAP file.  You
can share the PCAP file with me off-list.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 3:08 am, Viktor Dukhovni wrote:


Increasing security is primarily about raising the *ceiling*, and rarely
about raising not floor.  When you set the bar too high, instead of
greater security, mail is sent in the clear or not at all.


Got better logs for the ariba.com problem. The logging was set to 2.

Unfortunately I am not experienced enough to find the problem from the logs.

Any suggests?

Please note, I am still finding how to force renew with the letsencrypt 
certs with the new renewal settings.


 start 
Jun 15 21:13:15 mail postfix/smtpd[887899]: connect from 
ansmtp.ariba.com[216.109.104.12]
Jun 15 21:13:15 mail postfix/smtpd[887899]: discarding EHLO keywords: 
CHUNKING
Jun 15 21:13:15 mail postfix/smtpd[887899]: setting up TLS connection 
from ansmtp.ariba.com[216.109.104.12]
Jun 15 21:13:15 mail postfix/smtpd[887899]: 
ansmtp.ariba.com[216.109.104.12]: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH"
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:before SSL 
initialization
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:before SSL 
initialization
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS read 
client hello
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write 
server hello
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write 
certificate
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write 
key exchange
Jun 15 21:13:15 mail postfix/smtpd[887899]: SSL_accept:SSLv3/TLS write 
server done
Jun 15 21:13:16 mail postfix/smtpd[887899]: SSL_accept:error in 
SSLv3/TLS write server done
Jun 15 21:13:16 mail postfix/smtpd[887899]: SSL_accept error from 
ansmtp.ariba.com[216.109.104.12]: Connection reset by peer
Jun 15 21:13:16 mail postfix/smtpd[887899]: lost connection after 
STARTTLS from ansmtp.ariba.com[216.109.104.12]
Jun 15 21:13:16 mail postfix/smtpd[887899]: disconnect from 
ansmtp.ariba.com[216.109.104.12] ehlo=1 starttls=0/1 commands=1/2


-- end 

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 3:08 am, Viktor Dukhovni wrote:


Increasing security is primarily about raising the *ceiling*, and rarely
about raising not floor.  When you set the bar too high, instead of
greater security, mail is sent in the clear or not at all.

 https://datatracker.ietf.org/doc/html/rfc7435

Mostly you should leave crypto policy to OpenSSL and Postfix defaults,
and customise as little as possible.  Most of the "hardening" advice
you'll find is counter-productive to downright harmful.


I like the explaination using ceiling and floor. Very easy for me to 
understand.


Noted on leaving crypto policys on defaults. Lesson learnt.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 12:33:52AM +0200, Steffen Nurpmeso wrote:

> Viktor Dukhovni wrote in
>  :
>  |On Wed, Jun 15, 2022 at 12:07:25AM +0530, P V Anthony wrote:
>  |> On 13/6/2022 4:31 pm, Wietse Venema wrote:
>  ...
>  |Two comments on your server setup:
>  |
>  |* The server certificate is 4096 bit RSA.  This is needlessly turgid.
> 
> The FreeBSD handbook recommendet 4096 RSA keys about twenty years
> ago, stating that likely would be secure until 2030, and most
> FreeBSD developers had such keys by then.
> This was PGP, but the path was set for me.

It may be fashionable, but it is entirely pointless, and sometimes
counterproductive.  Someone who can break 2048-bit RSA can generate
certificates ostensibly issued by a majority of WebPKI CAs, and can also
forge DNSSEC root and e.g. .COM zone signatures.  Stronger certificates
get you nowheere.

>  |subject=C = US, O = Internet Security Research Group, CN = \
>  |ISRG Root X1
>  |issuer=O = Digital Signature Trust Co., CN = DST Root CA X3
>  |
>  |  You may have better luck by configuring "certbot" or similar to
>  |  build a chain that avoids the ISRG -> DST cross cert.
> 
> Interesting; all of OpenBSD, FreeBSD and i have this one in the
> chain, too.

This is only needed to support old Android phones that no longer get
updates.  Few of these are legitimate port 25 mail clients.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[Steffen Nurpmeso]

Viktor Dukhovni wrote in
 :
 |On Wed, Jun 15, 2022 at 12:07:25AM +0530, P V Anthony wrote:
 |> On 13/6/2022 4:31 pm, Wietse Venema wrote:
 ...
 |Two comments on your server setup:
 |
 |* The server certificate is 4096 bit RSA.  This is needlessly turgid.

The FreeBSD handbook recommendet 4096 RSA keys about twenty years
ago, stating that likely would be secure until 2030, and most
FreeBSD developers had such keys by then.
This was PGP, but the path was set for me.

 |  The issuing CA is 2048 bits, there is little to gain from a
 |  stronger EE key.  Some peer libraries may not support keys of this
 |  size.

I also do this :(  The one is mine, the other is theirs.
And they are signed by a 4096 bit thing themselves.

Now that you said that i was looking, the dehydrated ACME client
(letsencrypt.sh by then) has 4096 bits default since 2016.

FreeBSD seems to use RFC 5480 (Elliptic Curve Cryptography Subject
Public Key Information) id-ecPublicKey, curve P-256, prime256v1.
(As a crypto dummy you look "stupid out of the laundry" to 1:1 the
German "Doof aus der Wäsche gucken".)
For their HTTP at least; i would not have dared this.

OpenBSD uses a 4096-bit key onto them, too.

 |* The "Let's Encrypt CA" chain is configured for compatibility with
 |  legacy Android systems that trust the expired "DST" root CA:
 |
 |subject=CN = prometheus.mindmedia.com.sg
 |issuer=C = US, O = Let's Encrypt, CN = R3
 |
 |subject=C = US, O = Let's Encrypt, CN = R3
 |issuer=C = US, O = Internet Security Research Group, CN = ISRG \
 |Root X1
 |
 |subject=C = US, O = Internet Security Research Group, CN = \
 |ISRG Root X1
 |issuer=O = Digital Signature Trust Co., CN = DST Root CA X3
 |
 |  You may have better luck by configuring "certbot" or similar to
 |  build a chain that avoids the ISRG -> DST cross cert.

Interesting; all of OpenBSD, FreeBSD and i have this one in the
chain, too.
(I struggled sending this .. i am too loud.)

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Tue, Jun 14, 2022 at 05:51:17PM -0400, Dan Mahoney wrote:

> Postfix has sane defaults as long as you run a fairly recent version,
> and the developers have clue.  Not all apps have sane defaults (for
> example, I could see the need to configure default SSL configs with
> Sendmail).

Even when Postfix defaults are somewhat dated, and best-practice would
be something different, they are still generally better than many of the
recommended OCD "hardening" recommendations.  You have to go a long way
back in Postfix history, and build with a very old OpenSSL release
(neither supported at this time) to find a combination that actually
would need tweaks to avoid a plausible security issue.

Avoid all cipherlist settings that specify an explicit list specific
ciphers, rather than coarse categories.

Avoid "turning it up to 11", with overly large key sizes, ...

It is by now is generally practical to set:

smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high

smtp_tls_mandatory_ciphers = high
smtp_tls_ciphers = high

and for the SMTP client also:

smtp_tls_exclude_ciphers = SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5
smtpd_tls_exclude_ciphers = SRP, PSK, aDSS, kECDH, kDH, SEED, IDEA, RC2, RC5

though some of these are "for free" with OpenSSL 1.1.1, which typically
no longer supports e.g. IDEA, RC2 or RC5.  The exclusions of "SRP" and
"PSK" are just housekeeping, they can never be used in practice without
supporting application code that is absent in Postfix.

So the only exclusions that make a difference are "aDSS", "kECDH" and
"kDH" (some or all of which may also be gone with OpenSSL 3.0).  Leaving
these enabled is not critical, but disabling these reduces the attack
surface with only negligible impact on interoperability for most users.

I may be tempted to build some of these in as defaults in Postfix 3.8,
though it is also tempting to leave garbage-collection of outdated
ciphers mostly to OpenSSL.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[Dan Mahoney]

> On Jun 14, 2022, at 5:30 PM, P V Anthony  wrote:
> 
> On 15/6/2022 2:43 am, Viktor Dukhovni wrote:
> 
>> The simplest configuration is therefore to just leave the parameter
>> unset, the default value will be sensible.
> 
> I have just commented out smtpd_tls_dh1024_param_file
> 
> I have made so much of mistakes trying to increase security.

It doesn't help when sites like https://cipherlist.eu  
keep giving you settings to randomly drop in to your main.cf and people do it.  
I've certainly been guilty of this as well.

Now, it also doesn't help that apache ships with insanely liberal defaults that 
are vulnerable to lots of downgrade attacks, and people feel the need to apply 
the same "tweak every knob" methodology to their other daemons.

It also doesn't help that there are companies out there running SSL scans on 
everything on your network, and then selling it to the people who would offer 
you insurance, like some kind of credit reports, so people feel the need to 
tweak all the knobs obsessively.  (Dayjob got hit for this, on a hosted system 
that we didn't even control)

Postfix has sane defaults as long as you run a fairly recent version, and the 
developers have clue.  Not all apps have sane defaults (for example, I could 
see the need to configure default SSL configs with Sendmail).

-Dan

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 03:00:58AM +0530, P V Anthony wrote:

> On 15/6/2022 2:43 am, Viktor Dukhovni wrote:
> 
> > The simplest configuration is therefore to just leave the parameter
> > unset, the default value will be sensible.
> 
> I have just commented out smtpd_tls_dh1024_param_file
> 
> I have made so much of mistakes trying to increase security.

Increasing security is primarily about raising the *ceiling*, and rarely
about raising not floor.  When you set the bar too high, instead of
greater security, mail is sent in the clear or not at all.

https://datatracker.ietf.org/doc/html/rfc7435

Mostly you should leave crypto policy to OpenSSL and Postfix defaults,
and customise as little as possible.  Most of the "hardening" advice
you'll find is counter-productive to downright harmful.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 2:43 am, Viktor Dukhovni wrote:


The simplest configuration is therefore to just leave the parameter
unset, the default value will be sensible.


I have just commented out smtpd_tls_dh1024_param_file

I have made so much of mistakes trying to increase security.

Talk about bobo on my part.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 01:45:36AM +0530, P V Anthony wrote:

> smtpd_tls_dh1024_param_file = /etc/pki/tls/private/postfix.dh.param

Also, this appears to be a 4096-bit DH key, again much too turgid.  Use
2048 bits instead:

https://www.postfix.org/postconf.5.html#smtpd_tls_dh1024_param_file

smtpd_tls_dh1024_param_file (default: empty)

File with DH parameters that the Postfix SMTP server should use
with non-export EDH ciphers.

With Postfix ≥ 3.7, built with OpenSSL version is 3.0.0 or
later, if the parameter value is either empty or "auto", then
the DH parameter selection is delegated to the OpenSSL library,
which selects appropriate parameters based on the TLS handshake.
This choice is likely to be the most interoperable with SMTP
clients using various TLS libraries, and custom local parameters
are no longer recommended when using Postfix ≥ 3.7 built against
OpenSSL 3.0.0.

The best-practice choice of parameters uses a 2048-bit prime.
This is fine, despite the historical "1024" in the parameter
name. Do not be tempted to use much larger values, performance
degrades quickly, and you may also cease to interoperate with
some mainstream SMTP clients. As of Postfix 3.1, the compiled-in
default prime is 2048-bits, and it is not strictly necessary,
though perhaps somewhat beneficial to generate custom DH
parameters.

The simplest configuration is therefore to just leave the parameter
unset, the default value will be sensible.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 2:33 am, Viktor Dukhovni wrote:


Actually, don't.  I meant "2".


Ok. I have just changed it to "2".

Thank you for being patient.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 01:46:49AM +0530, P V Anthony wrote:
> On 15/6/2022 1:32 am, Viktor Dukhovni wrote:
> 
> > You may need to temporarily raise the TLS log level to "2".
> > 
> >  smtpd_tls_loglevel = 2
> 
> Just did smtpd_tls_loglevel = 3 just to be sure.

Actually, don't.  I meant "2".

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 2:16 am, Viktor Dukhovni wrote:


Either add the option:

 --preferred-chain "ISRG Root X1"

to your cron job running "certbot renew", or else add the following to 
configuration under
/etc/letsencrypt/renewal/,

 preferred_chain = ISRG Root X1


Wow!!!

Thank you very much for this config. Saved me much time!

Thank you again.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 2:20 am, Viktor Dukhovni wrote:


For this, in the renewal configuration file:

 rsa_key_size = 2048

or on the command-line:

 --rsa-key-size=2048


Thank you very very very much for helping. I really do appreciate it 
very very very much.


This advice has saved me a lot of time.

Thank you again for helping.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 01:56:59AM +0530, P V Anthony wrote:

> On 15/6/2022 1:45 am, Viktor Dukhovni wrote:
> 
> > Two comments on your server setup:
> > 
> >  * The server certificate is 4096 bit RSA.  This is needlessly turgid.
> >The issuing CA is 2048 bits, there is little to gain from a
> >stronger EE key.  Some peer libraries may not support keys of this
> >size.
> 
> I use Let's Encrypt. Need to figure out how to change to 2048 bits. 
> Google search time.

For this, in the renewal configuration file:

rsa_key_size = 2048

or on the command-line:

--rsa-key-size=2048

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 01:56:59AM +0530, P V Anthony wrote:

> > * The "Let's Encrypt CA" chain is configured for compatibility with
> >   legacy Android systems that trust the expired "DST" root CA:
> >
> > subject=CN = prometheus.mindmedia.com.sg
> > issuer=C = US, O = Let's Encrypt, CN = R3
> >
> > subject=C = US, O = Let's Encrypt, CN = R3
> > issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1
> >
> > subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
> > issuer=O = Digital Signature Trust Co., CN = DST Root CA X3
> >
> >   You may have better luck by configuring "certbot" or similar to
> >   build a chain that avoids the ISRG -> DST cross cert.
> 
> More Google searching on how to do this.

Either add the option:

--preferred-chain "ISRG Root X1"

to your cron job running "certbot renew", or else add the following to 
configuration under
/etc/letsencrypt/renewal/,

preferred_chain = ISRG Root X1

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 1:45 am, Viktor Dukhovni wrote:


Two comments on your server setup:

 * The server certificate is 4096 bit RSA.  This is needlessly turgid.
   The issuing CA is 2048 bits, there is little to gain from a
   stronger EE key.  Some peer libraries may not support keys of this
   size.


I use Let's Encrypt. Need to figure out how to change to 2048 bits. 
Google search time.




 * The "Let's Encrypt CA" chain is configured for compatibility with
   legacy Android systems that trust the expired "DST" root CA:

 subject=CN = prometheus.mindmedia.com.sg
 issuer=C = US, O = Let's Encrypt, CN = R3

 subject=C = US, O = Let's Encrypt, CN = R3
 issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

 subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
 issuer=O = Digital Signature Trust Co., CN = DST Root CA X3

   You may have better luck by configuring "certbot" or similar to
   build a chain that avoids the ISRG -> DST cross cert.


More Google searching on how to do this.

Thank you for the advice. I will start searching.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 1:32 am, Viktor Dukhovni wrote:


You may need to temporarily raise the TLS log level to "2".

 smtpd_tls_loglevel = 2


Just did smtpd_tls_loglevel = 3 just to be sure.


This is unfortunately going to apply to all remote clients, not just
"ariba".


Noted.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 15/6/2022 12:38 am, Wietse Venema wrote:


What is the output from:

# postconf -nf | grep tls | grep -v smtp_


smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_dh1024_param_file = /etc/pki/tls/private/postfix.dh.param
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_loglevel = 3 #just did this.
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_use_tls = yes


# postconf -P | grep tls | grep -v smtp_


submission/inet/smtpd_tls_auth_only = yes
submission/inet/smtpd_tls_security_level = encrypt
smtps/inet/smtpd_tls_wrappermode = yes

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 12:07:25AM +0530, P V Anthony wrote:
> On 13/6/2022 4:31 pm, Wietse Venema wrote:
> 
> > Delete the TLS protocol and cipher crap, and see if that solves
> > the problem.
> 
> I am sad to report, even after removing the bad configs, the ariba 
> emails are still not coming in.
> 
> Here are the logs. Is there any other thing I can do?
> 
> -- start ---
> Jun 15 01:39:51 mail postfix/smtpd[605304]: connect from 
> ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:51 mail postfix/smtpd[605304]: discarding EHLO keywords: 
> CHUNKING
> Jun 15 01:39:52 mail postfix/smtpd[605304]: SSL_accept error from 
> ansmtp.ariba.com[216.109.104.12]: Connection reset by peer
> Jun 15 01:39:52 mail postfix/smtpd[605304]: lost connection after 
> STARTTLS from ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:52 mail postfix/smtpd[605304]: disconnect from 
> ansmtp.ariba.com[216.109.104.12] ehlo=1 starttls=0/1 commands=1/2

Two comments on your server setup:

* The server certificate is 4096 bit RSA.  This is needlessly turgid.
  The issuing CA is 2048 bits, there is little to gain from a
  stronger EE key.  Some peer libraries may not support keys of this
  size.

* The "Let's Encrypt CA" chain is configured for compatibility with
  legacy Android systems that trust the expired "DST" root CA:

subject=CN = prometheus.mindmedia.com.sg
issuer=C = US, O = Let's Encrypt, CN = R3

subject=C = US, O = Let's Encrypt, CN = R3
issuer=C = US, O = Internet Security Research Group, CN = ISRG Root X1

subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3

  You may have better luck by configuring "certbot" or similar to
  build a chain that avoids the ISRG -> DST cross cert.

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Wed, Jun 15, 2022 at 12:07:25AM +0530, P V Anthony wrote:

> On 13/6/2022 4:31 pm, Wietse Venema wrote:
> 
> > Delete the TLS protocol and cipher crap, and see if that solves
> > the problem.
> 
> I am sad to report, even after removing the bad configs, the ariba 
> emails are still not coming in.
> 
> Here are the logs. Is there any other thing I can do?
> 
> -- start ---
> Jun 15 01:39:51 mail postfix/smtpd[605304]: connect from 
> ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:51 mail postfix/smtpd[605304]: discarding EHLO keywords: CHUNKING
> Jun 15 01:39:52 mail postfix/smtpd[605304]: SSL_accept error from 
> ansmtp.ariba.com[216.109.104.12]: Connection reset by peer
> Jun 15 01:39:52 mail postfix/smtpd[605304]: lost connection after STARTTLS 
> from ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:52 mail postfix/smtpd[605304]: disconnect from 
> ansmtp.ariba.com[216.109.104.12] ehlo=1 starttls=0/1 commands=1/2

You may need to temporarily raise the TLS log level to "2".

smtpd_tls_loglevel = 2

This is unfortunately going to apply to all remote clients, not just
"ariba".

-- 
VIktor.

Re: TLS issue with purchase order emails from ariba.com system.

[Wietse Venema]

P V Anthony:
> On 13/6/2022 4:31 pm, Wietse Venema wrote:
> 
> > Delete the TLS protocol and cipher crap, and see if that solves
> > the problem.
> 
> I am sad to report, even after removing the bad configs, the ariba 
> emails are still not coming in.
> 
> Here are the logs. Is there any other thing I can do?
> 
> -- start ---
> Jun 15 01:39:51 mail postfix/smtpd[605304]: connect from 
> ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:51 mail postfix/smtpd[605304]: discarding EHLO keywords: 
> CHUNKING
> Jun 15 01:39:52 mail postfix/smtpd[605304]: SSL_accept error from 
> ansmtp.ariba.com[216.109.104.12]: Connection reset by peer
> Jun 15 01:39:52 mail postfix/smtpd[605304]: lost connection after 
> STARTTLS from ansmtp.ariba.com[216.109.104.12]
> Jun 15 01:39:52 mail postfix/smtpd[605304]: disconnect from 
> ansmtp.ariba.com[216.109.104.12] ehlo=1 starttls=0/1 commands=1/2
> 
> --  end 

What is the output from:

# postconf -nf | grep tls | grep -v smtp_
# postconf -P | grep tls | grep -v smtp_

Trust but verify.

Wietse

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 13/6/2022 4:31 pm, Wietse Venema wrote:


Delete the TLS protocol and cipher crap, and see if that solves
the problem.


I am sad to report, even after removing the bad configs, the ariba 
emails are still not coming in.


Here are the logs. Is there any other thing I can do?

-- start ---
Jun 15 01:39:51 mail postfix/smtpd[605304]: connect from 
ansmtp.ariba.com[216.109.104.12]
Jun 15 01:39:51 mail postfix/smtpd[605304]: discarding EHLO keywords: 
CHUNKING
Jun 15 01:39:52 mail postfix/smtpd[605304]: SSL_accept error from 
ansmtp.ariba.com[216.109.104.12]: Connection reset by peer
Jun 15 01:39:52 mail postfix/smtpd[605304]: lost connection after 
STARTTLS from ansmtp.ariba.com[216.109.104.12]
Jun 15 01:39:52 mail postfix/smtpd[605304]: disconnect from 
ansmtp.ariba.com[216.109.104.12] ehlo=1 starttls=0/1 commands=1/2


--  end 

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 13/6/2022 5:04 pm, Viktor Dukhovni wrote:


Well, it is certainly not recommended in the Postfix documentation.
Various OpenSSL cipher recommendations on the Internet are generally
a bad idea.  So sure, "crap".


Thank you very much, Wietse and Viktor, for taking the time to reply and 
helping. I do appreciate it very much.


Will report back on the outcome.

Once again thank you for helping.

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Viktor Dukhovni]

On Mon, Jun 13, 2022 at 04:57:27PM +0530, P V Anthony wrote:

> 
> Haha! Oh no! I must have made such a big mistake for it to be called 
> crap. Haha!

Well, it is certainly not recommended in the Postfix documentation.
Various OpenSSL cipher recommendations on the Internet are generally
a bad idea.  So sure, "crap".

> tls_preempt_cipherlist = yes
> 
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_ciphers   = high

These are backwards.

> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtpd_tls_protocols = !SSLv2,!SSLv3

These are defaults.

> smtpd_tls_exclude_ciphers = RC4, aNULL

These are unnecessary.

> tls_high_cipherlist = 
> !EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+AES256:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:AES128-SHA
> 
> tls_medium_cipherlist = 
> ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA
>  

These are "crap".

-- 
Viktor.

Re: TLS issue with purchase order emails from ariba.com system.

[P V Anthony]

On 13/6/2022 4:31 pm, Wietse Venema wrote:


Delete the TLS protocol and cipher crap, and see if that solves
the problem.


Thank you very much for replying and helping.

Haha! Oh no! I must have made such a big mistake for it to be called 
crap. Haha!


Just to confirm, are these to be deleted?

-- start --
tls_preempt_cipherlist = yes

smtpd_tls_mandatory_ciphers = medium
smtpd_tls_ciphers   = high

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtpd_tls_exclude_ciphers = RC4, aNULL

tls_high_cipherlist = 
!EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+AES256:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:!CAMELLIA256-SHA:AES256-SHA:!CAMELLIA128-SHA:AES128-SHA


tls_medium_cipherlist = 
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA 


--  end ---

P.V.Anthony

Re: TLS issue with purchase order emails from ariba.com system.

[Wietse Venema]

P V Anthony:
> Hi,
> 
> Having problems with purchase order emails from ariba.com systems.
> 
> Has anyone experienced this similar issue with ariba.com?
> 
> Here are the logs from our side.

Delete the TLS protocol and cipher crap, and see if that solves
the problem.

Wietse