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 

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

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

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

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


--- end -

When I requested for some error messages from their end, they were not 
forthcoming.


Here are my configs. Need advice on what changes can be done to allow 
emails from them? Besides turning off the TLS.


-- start -
tls_preempt_cipherlist = yes
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_security_level = may
tls_ssl_options = NO_RENEGOTIATION
smtpd_use_tls = yes
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_dh1024_param_file = /etc/pki/tls/private/postfix.dh.param

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

[Viktor Dukhovni]

> On Dec 5, 2016, at 4:40 AM, Zalezny Niezalezny <zalezny.niezale...@gmail.com> 
> wrote:
> 
> Problem is generated by one of our Ironport systems which is trying to 
> establish TLS connection.
> In Postfix server I already configured it:
> 
> smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
> smtpd_tls_protocols = !SSLv2,!SSLv3
> smtp_tls_protocols = !SSLv2,!SSLv3
> 
> I suspect that TLS client is not properly configured to establish connection. 
> 
> How to properly configure Postfix to enable all type of TLS connections ?

You begin by posting a properly detailed problem description.  The above isn't
even close.

http://postfix.1071664.n5.nabble.com/TLS-issue-td87598.html#a87612
http://www.postfix.org/DEBUG_README.html#mail
http://www.postfix.org/DEBUG_README.html#sniffer

To decode TLS packet dumps:

   $ tshark -r /file/name -V -x

and look for blocks of text starting with "Secure Socket".

The configuration error is probably on the Ironport, so after
ruling out Postfix mistakes a packet dump will be needed to
see what's going wrong during the handshake.

-- 
Viktor.

Re: TLS issue

[Zalezny Niezalezny]

Problem is generated by one of our Ironport systems which is trying to
establish TLS connection.
In Postfix server I already configured it:

smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3

I suspect that TLS client is not properly configured to establish
connection.

How to properly configure Postfix to enable all type of TLS connections ?


With kind regards

Zalezny


On Sat, Dec 3, 2016 at 5:40 PM, @lbutlr  wrote:

> On 12/2/16 12:16 PM, Wietse Venema wrote:
>
> With 'no shared ciphers' happening frequently, do we want to set
>> up a TLS troubleshooting document, or is the decision tree too
>> complex for such a document to be useful?
>>
> Considering how often the question is asked, probably.
>
> However, I think the error message in the logs is partly to blame since it
> will come up in a grep search for 'error'. (yes, people should grep for
> "error:" but they don't.)
>
> Instead of "Protocol error;" I'd suggest maybe "no protocol match;" or
> similar wording that doesn't include 'error'.
>
>
>
>
>

Re: TLS issue

On 12/2/16 12:16 PM, Wietse Venema wrote:


With 'no shared ciphers' happening frequently, do we want to set
up a TLS troubleshooting document, or is the decision tree too
complex for such a document to be useful?

Considering how often the question is asked, probably.

However, I think the error message in the logs is partly to blame since 
it will come up in a grep search for 'error'. (yes, people should grep 
for "error:" but they don't.)


Instead of "Protocol error;" I'd suggest maybe "no protocol match;" or 
similar wording that doesn't include 'error'.

Re: TLS issue

[John Stoffel]

The problem is only going to get worse, so any guidance and probably even some 
more general error messages giving more direct hints would be appreciated.  

The guy who just posted his solution to interoperable with old postfix and the 
Windows patch he could us is a perfect example.

Sent from my Amiga 1000

> On Dec 2, 2016, at 2:16 PM, Wietse Venema  wrote:
> 
> Viktor Dukhovni:
>> 
>>> On Dec 2, 2016, at 4:22 AM, Zalezny Niezalezny 
>>>  wrote:
>>> 
>>> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: SSL_accept error 
>>> from smtptransit.de.net.intra[152.21.2.44]: -1
>>> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS library 
>>> problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared 
>>> cipher:s3_srvr.c:1352:
>> 
>> Your Postfix SMTP server accepting an inbound connection could not
>> complete a TLS handshake with the remote SMTP client, because the
>> remote SMTP client's list of supported TLS ciphers, TLS signature
>> algorithms, supported EC curves, ... did not support any of the
>> corresponding parameter combinations available on your server.
>> 
>> For more detailed help, you should post more detail of your TLS
>> configuration.  (The shell commands below assume a POSIX shell,
>> not csh or similar):
> 
> With 'no shared ciphers' happening frequently, do we want to set
> up a TLS troubleshooting document, or is the decision tree too
> complex for such a document to be useful?
> 
>Wietse

Re: TLS issue

[Postfix User]

On Fri, 2 Dec 2016 14:16:20 -0500 (EST), Wietse Venema stated:

>With 'no shared ciphers' happening frequently, do we want to set
>up a TLS troubleshooting document, or is the decision tree too
>complex for such a document to be useful?

+1 for a "TLS Troubleshooting Document"

-- 
Jerry

Re: TLS issue

[Wietse Venema]

Viktor Dukhovni:
> 
> > On Dec 2, 2016, at 4:22 AM, Zalezny Niezalezny 
> >  wrote:
> > 
> > Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: SSL_accept error 
> > from smtptransit.de.net.intra[152.21.2.44]: -1
> > Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS library 
> > problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared 
> > cipher:s3_srvr.c:1352:
> 
> Your Postfix SMTP server accepting an inbound connection could not
> complete a TLS handshake with the remote SMTP client, because the
> remote SMTP client's list of supported TLS ciphers, TLS signature
> algorithms, supported EC curves, ... did not support any of the
> corresponding parameter combinations available on your server.
> 
> For more detailed help, you should post more detail of your TLS
> configuration.  (The shell commands below assume a POSIX shell,
> not csh or similar):

With 'no shared ciphers' happening frequently, do we want to set
up a TLS troubleshooting document, or is the decision tree too
complex for such a document to be useful?

Wietse

Re: TLS issue

[Viktor Dukhovni]

> On Dec 2, 2016, at 4:22 AM, Zalezny Niezalezny  
> wrote:
> 
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: SSL_accept error from 
> smtptransit.de.net.intra[152.21.2.44]: -1
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS library 
> problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared 
> cipher:s3_srvr.c:1352:

Your Postfix SMTP server accepting an inbound connection could not
complete a TLS handshake with the remote SMTP client, because the
remote SMTP client's list of supported TLS ciphers, TLS signature
algorithms, supported EC curves, ... did not support any of the
corresponding parameter combinations available on your server.

For more detailed help, you should post more detail of your TLS
configuration.  (The shell commands below assume a POSIX shell,
not csh or similar):

   * What version of OpenSSL is your Postfix SMTP server linked with?
 Post the output of:

$ openssl version -v -p
$ ldd $(type -p openssl)
$ ldd $(postconf -xh daemon_directory)/smtpd

   * Post the output of:

$ postconf -n | egrep '^(smtpd_|)tls_'

   * Post the output of (executed as root):

# for cert in $(postconf -xh smtpd_tls_cert_file smtpd_tls_eccert_file 
smtpd_tls_dcert_file)
  do
  echo "$cert:"
  openssl x509 -in $cert -subject -issuer -dates
  done

* If the problem is ongoing capture some TCP traffic from that client:

# client=152.21.2.44
# ifname=eth0; : set ifname to match your external interface
# pcap=/var/tmp/$client.pcap
# (umask 077; tcpdump -c 1000 -i $ifname -s 0 -w $pcap host $client and 
tcp port 25) &

 This may be useful later.  It will capture at most 1000 packets from/to 
that
 client.  That is often enough to capture a few STARTTLS attempts.  If 
you're
 unlucky, it will catch just a portion of a session that is sending a large
 attachment, in that case you'll try again later...

-- 
-- 
Viktor.

Re: TLS issue

[Wietse Venema]

Zalezny Niezalezny:
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS library
> problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared
> cipher:s3_srvr.c:1352:

This is asked onnce a week. Google for 'SSL3_GET_CLIENT_HELLO no shared cipher'.

Wietse

Re: TLS issue

[Paweł Grzesik]

That looks like a problem with your certificates.
You can check/verify them by openssl command.

Thanks,
Pawel

2016-12-02 9:22 GMT+00:00 Zalezny Niezalezny :

> Hi,
>
> we have a problem with TLS on our Postfix server
>
>
> ec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: connect from
> smtptransit.de.net.intra[152.21.2.44]
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: SSL_accept error
> from smtptransit.de.net.intra[152.21.2.44]: -1
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS
> library problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no
> shared cipher:s3_srvr.c:1352:
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: lost connection
> after STARTTLS from smtptransit.de.net.intra[152.21.2.44]
> Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: disconnect from
> smtptransit.de.net.intra[152.21.2.44]
>
>
>
>
> But to be honest I do not understand what is this. Maybe somebody will be
> able to help here and explain.
>
>
> Thanks in advance.
>
> Zalezny
>

TLS issue

[Zalezny Niezalezny]

Hi,

we have a problem with TLS on our Postfix server


ec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: connect from
smtptransit.de.net.intra[152.21.2.44]
Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: SSL_accept error
from smtptransit.de.net.intra[152.21.2.44]: -1
Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: warning: TLS library
problem: 37036:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared
cipher:s3_srvr.c:1352:
Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: lost connection
after STARTTLS from smtptransit.de.net.intra[152.21.2.44]
Dec  2 10:12:03 postfix-server01 postfix/smtpd[37036]: disconnect from
smtptransit.de.net.intra[152.21.2.44]




But to be honest I do not understand what is this. Maybe somebody will be
able to help here and explain.


Thanks in advance.

Zalezny

Re: TLS Issue

[Jan Kowalski]

Dnia , o godz. 
Steffan A. Cline stef...@hldns.com napisał(a):

Hi,

have you resolved this problem yet?

I reproduce it when I connect via either imap or smtp from claws-mail
linked against gnutls 3.3.10-1 to a postfix server with dovecot sasl
enabled.

In my case it is caused by my dovecot configuration, namely:

ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

According to [1]:

 It seems that following poodle many sites incorrectly banned SSL 3.0
 record packet versions. Since gnutls uses an SSL 3.0 record to
 advertise TLS 1.2, they are effectively banning it even if it doesn't
 advertise SSL 3.0.

After removing SSLv3 from ssl_cipher_list the client connected
successfully. I'm not really sure though if it is a proper workaround
or am I opening a possible attack vector; I will be carrying out more
tests next weekend. However, I don't think it's necessary for gnutls to
behave this way, NSS works fine in either configuration.

[1]:
http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html

Re: TLS Issue

[Steffan A. Cline]

Jan,

No, I have not.

Viktor suggested my webapp was at fault. I submitted a bug to the
middleware provider to see if they can isolate it but if there are other
apps with the same issue, it makes me wonder if there's something we can
change server side (postfix) to fix it.

You've renewed my interest. I'll poke a little  more to see if I can
figure it out.



Thanks,
Steffan

---
T E L  6 0 2 . 7 9 3 . 0 0 1 4 | F A X  6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Clinestef...@execuchoice.net
http://www.ExecuChoice.net Phoenix, Arizona USA
  
---






On 12/7/14, 10:02 AM, Jan Kowalski baken...@cock.li wrote:

Dnia , o godz. 
Steffan A. Cline stef...@hldns.com napisał(a):

Hi,

have you resolved this problem yet?

I reproduce it when I connect via either imap or smtp from claws-mail
linked against gnutls 3.3.10-1 to a postfix server with dovecot sasl
enabled.

In my case it is caused by my dovecot configuration, namely:

ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

According to [1]:

 It seems that following poodle many sites incorrectly banned SSL 3.0
 record packet versions. Since gnutls uses an SSL 3.0 record to
 advertise TLS 1.2, they are effectively banning it even if it doesn't
 advertise SSL 3.0.

After removing SSLv3 from ssl_cipher_list the client connected
successfully. I'm not really sure though if it is a proper workaround
or am I opening a possible attack vector; I will be carrying out more
tests next weekend. However, I don't think it's necessary for gnutls to
behave this way, NSS works fine in either configuration.

[1]:
http://lists.gnutls.org/pipermail/gnutls-help/2014-November/003673.html

Re: TLS Issue

[li...@rhsoft.net]

Am 07.12.2014 um 18:02 schrieb Jan Kowalski:

Dnia , o godz.
Steffan A. Cline stef...@hldns.com napisał(a):

have you resolved this problem yet?

I reproduce it when I connect via either imap or smtp from claws-mail
linked against gnutls 3.3.10-1 to a postfix server with dovecot sasl
enabled.

In my case it is caused by my dovecot configuration, namely:

ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

According to [1]:


It seems that following poodle many sites incorrectly banned SSL 3.0
record packet versions. Since gnutls uses an SSL 3.0 record to
advertise TLS 1.2, they are effectively banning it even if it doesn't
advertise SSL 3.0.


After removing SSLv3 from ssl_cipher_list the client connected
successfully. I'm not really sure though if it is a proper workaround
or am I opening a possible attack vector; I will be carrying out more
tests next weekend. However, I don't think it's necessary for gnutls to
behave this way, NSS works fine in either configuration.


remove the !SSLv3 from ssl_cipher_list is the proper configuration
hence both options exists

that's not gnutls specific
Outlook on WinXP beahves the same way

ssl_prefer_server_ciphers  = yes
ssl_options = no_compression
ssl_protocols = !SSLv2 !SSLv3
ssl_cipher_list = 
ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-RSA-DES-CBC3-SHA:DES-CBC3-SHA

Re: TLS Issue

[Viktor Dukhovni]

On Sun, Dec 07, 2014 at 06:02:23PM +0100, Jan Kowalski wrote:

 In my case it is caused by my dovecot configuration, namely:
 
 ssl_protocols = !SSLv2 !SSLv3
 ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

This configuration is incorrect.  The majority of TLSv1.2 cipher
suites were defined as part of SSLv3.  In the cipherlist, the
protocol number is the *lowest* protocol that supports the cipher
suite, but removing all SSLv3 ciphers from TLS leaves only bleeding
edge AEAD and SHA-2 ciphers that many clients don't support.

A better cipherlist for *dovecot* would be:

DEFAULT:!EXPORT:!LOW:!MEDIUM:!MD5

The MD5 ciphers suites are a superset of the SSLv2 cipher suites.
The DEFAULT list is generally a good starting point for non-experts,
to which you apply sensible exclusions.

-- 
Viktor.

Re: TLS Issue

[Steffan A. Cline]

Looking earlier on the thread, Jan suggested that it was dovecot that had
the issue and may be related.

My issue seems to be a connection issue postfix and my webapp. Viktor
suggested it could be an issue with my OpenSSL implementation. The dev
webapp is running on MacOS X 10.10 which should have a very recent
version. OpenSSL 0.9.8za 5 Jun 2014. The server hosting postfix is on
CentOS 6 using OpenSSL 1.0.1e-fips 11 Feb 2013

Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: connect from
x-x-x-x.phnx.qwest.net[x.x.x.x]
Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: warning: TLS library
problem: 4350:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: lost connection after
STARTTLS from x.x.x.x.phnx.qwest.net[x.x.x.x]
Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: disconnect from
x-x-x-x.phnx.qwest.net[x.x.x.x]

Not sure where those configs from dovecot comes into play when it's
postfix showing the error.


Do Viktor's suggested dovecot configs also pertain to postfix?

I'm still checking on the TLS implementation of the middleware for my
webapp that sends the email.


Thanks,
Steffan

---
T E L  6 0 2 . 7 9 3 . 0 0 1 4 | F A X  6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Clinestef...@execuchoice.net
http://www.ExecuChoice.net Phoenix, Arizona USA
  
---






On 12/7/14, 11:36 AM, Viktor Dukhovni postfix-us...@dukhovni.org wrote:

On Sun, Dec 07, 2014 at 06:02:23PM +0100, Jan Kowalski wrote:

 In my case it is caused by my dovecot configuration, namely:
 
 ssl_protocols = !SSLv2 !SSLv3
 ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

This configuration is incorrect.  The majority of TLSv1.2 cipher
suites were defined as part of SSLv3.  In the cipherlist, the
protocol number is the *lowest* protocol that supports the cipher
suite, but removing all SSLv3 ciphers from TLS leaves only bleeding
edge AEAD and SHA-2 ciphers that many clients don't support.

A better cipherlist for *dovecot* would be:

DEFAULT:!EXPORT:!LOW:!MEDIUM:!MD5

The MD5 ciphers suites are a superset of the SSLv2 cipher suites.
The DEFAULT list is generally a good starting point for non-experts,
to which you apply sensible exclusions.

-- 
   Viktor.

Re: TLS Issue

[Viktor Dukhovni]

On Sun, Dec 07, 2014 at 10:56:17PM -0700, Steffan A. Cline wrote:

 Looking earlier on the thread, Jan suggested that it was dovecot that had
 the issue and may be related.
 
 My issue seems to be a connection issue postfix and my webapp. Viktor
 suggested it could be an issue with my OpenSSL implementation. The dev
 webapp is running on MacOS X 10.10 which should have a very recent
 version. OpenSSL 0.9.8za 5 Jun 2014.

That's not recent at all.  This is a recently patched, but by now
ancient OpenSSL.  OpenSSL 0.9.8 does not support TLS 1.2 (or TLS
1.1 IIRC), and so removing SSLv3 ciphers leaves it with none.

 Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: connect from
 x-x-x-x.phnx.qwest.net[x.x.x.x]
 Dec  7 22:07:25 hosting1 postfix/smtpd[4350]: warning: TLS library
 problem: 4350:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
 number:s3_pkt.c:337:

Wireshark!

 Not sure where those configs from dovecot comes into play when it's
 postfix showing the error.

It doesn't.  Someone posted dovecot settings, I pointed out those were
unwise.

 Do Viktor's suggested dovecot configs also pertain to postfix?

No.

-- 
Viktor.

TLS Issue

[Steffan A. Cline]

I've been googling a while to find a resolution to this but am not having
the best of luck.

I have a web app trying to connect to postfix to send mail via TLS. It
fails right after authentication. I find a BUNCH of these in the log:

Nov 30 10:10:32 hosting1 postfix/smtpd[11990]: connect from x[x.x.x.x]
Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: warning: TLS library
problem: 11990:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
number:s3_pkt.c:337:
Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: lost connection after
STARTTLS from x[x.x.x.x]
Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: disconnect from
x[x.x.x.x]

I'm not sure if it's an SSL cert related issue or not. I am using a UCC
cert from GoDaddy and the first name in the list matches the mail server
name.


Suggestions where to go with this?

postconf as follows:

[root@xxx ~]# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
broken_sasl_auth_clients = yes
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
header_checks = regexp:/etc/postfix/header_checks
home_mailbox = Maildir/
html_directory = no
inet_interfaces = all
inet_protocols = ipv4
mail_owner = postfix
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
mailq_path = /usr/bin/mailq.postfix
manpage_directory = /usr/share/man
message_size_limit = 104857600
milter_default_action = accept
milter_protocol = 2
mydestination = $myhostname, localhost.$mydomain, localhost, mail.hldns.com
newaliases_path = /usr/bin/newaliases.postfix
non_smtpd_milters = inet:localhost:8891
queue_directory = /var/spool/postfix
readme_directory = /usr/share/doc/postfix-2.6.6/README_FILES
sample_directory = /usr/share/doc/postfix-2.6.6/samples
sender_bcc_maps = hash:/etc/postfix/sender_bcc
sendmail_path = /usr/sbin/sendmail.postfix
setgid_group = postdrop
smtpd_milters = inet:localhost:8891
smtpd_recipient_restrictions = permit_mynetworks
permit_sasl_authenticated   reject_unauth_destination
check_client_access hash:/etc/postfix/whitelist
check_sender_access hash:/etc/postfix/auto-whtlst
check_client_access cidr:/etc/postfix/blacklist.cidr
reject_unknown_reverse_client_hostnamereject_non_fqdn_sender
  reject_invalid_helo_hostnamereject_non_fqdn_helo_hostname
reject_unknown_helo_hostnamereject_unlisted_recipient
check_client_access pcre:/etc/postfix/fqrdns.pcrereject_rbl_client
zen.spamhaus.orgreject_rhsbl_client dbl.spamhaus.org
reject_rhsbl_sender dbl.spamhaus.orgreject_rhsbl_helo
dbl.spamhaus.orgcheck_policy_service inet:127.0.0.1:6
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_tls_CAfile = /etc/postfix/postfix.ca.pem
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_mandatory_ciphers = high
smtpd_tls_security_level = may
unknown_local_recipient_reject_code = 550
virtual_alias_maps = hash:/etc/postfix/virtual



Thanks,
Steffan

---
T E L  6 0 2 . 7 9 3 . 0 0 1 4 | F A X  6 0 2 . 9 7 1 . 1 6 9 4
Steffan A. Clinestef...@execuchoice.net
http://www.ExecuChoice.net Phoenix, Arizona USA
  
--- 

Re: TLS Issue

[Viktor Dukhovni]

On Sun, Nov 30, 2014 at 09:32:43AM -0700, Steffan A. Cline wrote:

 I have a web app trying to connect to postfix to send mail via TLS. It
 fails right after authentication.

Actually, no, it (what you show from the logs) fails during the
TLS handshake, which should precede authentication.

 I find a BUNCH of these in the log:
 
 Nov 30 10:10:32 hosting1 postfix/smtpd[11990]: connect from x[x.x.x.x]
 Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: warning: TLS library
 problem: 11990:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version
 number:s3_pkt.c:337:
 Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: lost connection after
 STARTTLS from x[x.x.x.x]
 Nov 30 10:10:33 hosting1 postfix/smtpd[11990]: disconnect from
 x[x.x.x.x]

The client software is buggy.  Perhaps it continues to send cleartext
after sending STARTTLS, or sends QUIT\r\n in the clear after
giving up the incomplete TLS handshake.

 I'm not sure if it's an SSL cert related issue or not. I am using a UCC
 cert from GoDaddy and the first name in the list matches the mail server
 name.

There is no mention of certificates anywhere above.  The problem
has nothing to do with certificates.  The Postfix SMTP server
receives a TLS record with a bad version number.

 Suggestions where to go with this?

Tcpdump (without packet truncation) and wireshark.  Extract from
the raw capture a single TCP stream (match on client port) with a
session of interest, and post (the raw PCAP file of) that if you
don't understand what wireshark tells you.

Either your OpenSSL is not adequately patched to resolve all known
interoperability issues, or your web app STARTTLS implementation
is buggy.

-- 
Viktor.

SSL/TLS issue

[IT geek 31]

I have an issue regarding SSL/TLS.

I have configured my certificates and STARTTLS works fine.  Out of
curosity, I wanted to get SSL over tcp/465 working.

I uncommented the following line in master.cf:

  smtps inet  n   -   n   -   -   smtpd

And netsat shows the server is now listening on tcp/465.  However when
I configure my client (Thunderbird) use use SSL, it comes back with
the following error:

  Sending of message failed.  The message could not be sent
because the connection to SMTP server mail timed out.

The following, rather unhelpfully, is listed in maillog:

Jan 18 21:58:48 mail postfix/smtpd[2551]: initializing the server-side
TLS engine
Jan 18 21:58:49 mail postfix/smtpd[2551]: connect from pc[172.x.x.x]
Jan 18 21:59:19 mail postfix/smtpd[2551]: lost connection after
UNKNOWN from pc[172.x.x.x]
Jan 18 21:59:19 mail postfix/smtpd[2551]: disconnect from pc[172.x.x.x]

Does anyone have any thoughts on what I'm missing?



Output from postconf -n:

body_checks = regexp:/usr/pkg/etc/postfix/body_checks
command_directory = /usr/pkg/sbin
config_directory = /usr/pkg/etc/postfix
daemon_directory = /usr/pkg/libexec/postfix
data_directory = /var/db/postfix
debug_peer_level = 2
header_checks = regexp:/usr/pkg/etc/postfix/header_checks
html_directory = no
inet_protocols = ipv4
mail_owner = postfix
mail_spool_directory = /var/mail
mailbox_size_limit = 0
mailq_path = /usr/pkg/bin/mailq
manpage_directory = /usr/pkg/man
message_size_limit = 0
mydestination = localhost, localhost.$mydomain, $myhostname, $mydomain
mydomain = xxx.xx.com
myhostname = mail.xxx.xx.com
mynetworks = x.x.x.x, x.x.x.x, 127.0.0.0/8
mynetworks_style = subnet
myorigin = $mydomain
newaliases_path = /usr/pkg/bin/newaliases
proxy_interfaces = x.x.x.x
queue_directory = /var/spool/postfix
readme_directory = /usr/pkg/share/examples/postfix
sample_directory = /usr/pkg/share/examples/postfix
sendmail_path = /usr/pkg/sbin/sendmail
setgid_group = maildrop
smtp_tls_CAfile = /etc/openssl/certs/DigiCertCA.crt
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
smtp_tls_security_level = may
smtpd_banner = $myhostname ESMTP
smtpd_delay_reject = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = check_helo_access
hash:/usr/pkg/etc/postfix/helo_access, reject_non_fqdn_hostname,
reject_invalid_hostname, reject_unknown_hostname, permit
smtpd_recipient_restrictions = permit_sasl_authenticated,
permit_mynetworks, check_sender_access
hash:/usr/pkg/etc/postfix/sender_access, reject_unauth_pipelining,
reject_non_fqdn_$
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sender_restrictions = permit_sasl_authenticated,
permit_mynetworks, check_sender_access
hash:/usr/pkg/etc/postfix/sender_access, reject_non_fqdn_sender,
reject_unknown_sender$
smtpd_tls_CAfile = /etc/openssl/certs/DigiCertCA.crt
smtpd_tls_auth_only = no
smtpd_tls_cert_file = /etc/openssl/certs/mail.xxx.xxx.xx.crt
smtpd_tls_key_file = /etc/openssl/private/mail.xxx.xxx.xx.key
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_timeout = 3600s
unknown_local_recipient_reject_code = 550

Re: SSL/TLS issue

[Wietse Venema]

IT geek 31:
 I have an issue regarding SSL/TLS.
 
 I have configured my certificates and STARTTLS works fine.  Out of
 curosity, I wanted to get SSL over tcp/465 working.

Port 465 uses a different protocol than port 25.

On port 25, the session starts in plaintext, and the client sends STARTTLS.

On port 465, the session starts in ciphertext.

Wietse

Re: SSL/TLS issue

[IT geek 31]

On 18 January 2011 22:22, Wietse Venema wie...@porcupine.org wrote:
 IT geek 31:
 I have an issue regarding SSL/TLS.

 I have configured my certificates and STARTTLS works fine.  Out of
 curosity, I wanted to get SSL over tcp/465 working.

 Port 465 uses a different protocol than port 25.

 On port 25, the session starts in plaintext, and the client sends STARTTLS.

 On port 465, the session starts in ciphertext.

        Wietse


From that I take it that my config is missing a lot to get SSL
working, and that maybe I should RTFM?

Re: SSL/TLS issue

[Wietse Venema]

IT geek 31:
 On 18 January 2011 22:22, Wietse Venema wie...@porcupine.org wrote:
  IT geek 31:
  I have an issue regarding SSL/TLS.
 
  I have configured my certificates and STARTTLS works fine. ?Out of
  curosity, I wanted to get SSL over tcp/465 working.
 
  Port 465 uses a different protocol than port 25.
 
  On port 25, the session starts in plaintext, and the client sends STARTTLS.
 
  On port 465, the session starts in ciphertext.
 
  ? ? ? ?Wietse
 
 
 From that I take it that my config is missing a lot to get SSL
 working, and that maybe I should RTFM?

Port 465 TLS is described in 
http://www.postfix.org/postconf.5.html#smtpd_tls_wrappermode

Wietse

Re: SSL/TLS issue

[IT geek 31]

On 18 January 2011 22:34, Wietse Venema wie...@porcupine.org wrote:
 IT geek 31:
 On 18 January 2011 22:22, Wietse Venema wie...@porcupine.org wrote:
  IT geek 31:
  I have an issue regarding SSL/TLS.
 
  I have configured my certificates and STARTTLS works fine. ?Out of
  curosity, I wanted to get SSL over tcp/465 working.

  Port 465 uses a different protocol than port 25.
 
  On port 25, the session starts in plaintext, and the client sends STARTTLS.
 
  On port 465, the session starts in ciphertext.
 
  ? ? ? ?Wietse
 

 From that I take it that my config is missing a lot to get SSL
 working, and that maybe I should RTFM?

 Port 465 TLS is described in
 http://www.postfix.org/postconf.5.html#smtpd_tls_wrappermode

        Wietse


Read it, configured it, got it working.

Many thanks,

Re: SSL/TLS issue

[Reindl Harald]

in thunderbird you have two options

SSL/TLS
StARTTLS

on port 465 you have to use SSL/TLS
the same for imaps/pop3s on dedicated ports

if port / enycryption is in the wrong combination it will not
work, happens most time if you changed the ports manually
while doing some tests, after that the dialog will no longer
set the correct combination

normally thunderbir dchanges the port to 25/465 depending on
the encryption-method

this is a problem in the client-configuration and not the server
as long there is no firewall involved

Am 18.01.2011 23:28, schrieb IT geek 31:
 On 18 January 2011 22:22, Wietse Venema wie...@porcupine.org wrote:
 IT geek 31:
 I have an issue regarding SSL/TLS.

 I have configured my certificates and STARTTLS works fine.  Out of
 curosity, I wanted to get SSL over tcp/465 working.
 
 Port 465 uses a different protocol than port 25.

 On port 25, the session starts in plaintext, and the client sends STARTTLS.

 On port 465, the session starts in ciphertext.

Wietse

 
 From that I take it that my config is missing a lot to get SSL
 working, and that maybe I should RTFM?



signature.asc
Description: OpenPGP digital signature

Enforced TLS issue after Postfix upgrade

[Mueller, Martin (Messaging)]

Hello,

After upgrading from 2.5.x to 2.7.1 mail started queuing up to one particular 
domain (TLS security level: verify) with Server certificate not verified. 
Systems still on 2.5.x versions of Postfix transmit messages to that domain via 
enforced TLS just fine. Based on some testing with different version it seems 
that the change in behavior started with 2.6.0.

The ST part of the CN contains an encoded string sequence of \xC3\xBC that  
represents the German u Umlaut. 
We  have tons of domains setup for enforced TLS and this is the only one that 
is causing trouble. Warning messages in the log file
are also tied to asn1 encoding and eventually CN appears with no value in the 
log. Which seems to suggest that the asn 1 encoded
character is what causes the trouble.

Some log information below. 

Regards,

Martin


Nov 29 22:14:23 server postfix/smtp[6740]: initializing the client-side TLS 
engine
Nov 29 22:14:24 server postfix/smtp[6740]: setting up TLS connection to 
mx2.mlp-ag.com[195.170.185.78]:25
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
TLS cipher list ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL
Nov 29 22:14:24 server postfix/smtp[6740]: looking for session 
smtp:195.170.185.78:25:mx2.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL
 in smtp cache
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
certificate verification depth=3 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=Class 3 Public Primary Certification Authority
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
certificate verification depth=2 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use 
only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
certificate verification depth=1 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa 
(c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
certificate verification depth=0 verify=1 
subject=/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/2.5.4.15=V1.0,
 Clause 5.(b)/serialNumber=HRB 
335755/C=DE/2.5.4.17=69168/ST=Baden-W\xC3\xBCrttemberg/L=Wiesloch/2.5.4.9=Alte 
Heerstrasse 40/O=MLP Finanzdienstleistungen Aktiengesellschaft
Nov 29 22:14:24 server postfix/smtp[6740]: SSL_connect:SSLv3 read finished A
Nov 29 22:14:24 server postfix/smtp[6740]: save session 
smtp:195.170.185.78:25:mx2.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL
 to smtp cache
Nov 29 22:14:24 server postfix/smtp[6740]: warning: tls_text_name: 
mx2.mlp-ag.com[195.170.185.78]:25: error decoding peer subject CN of ASN.1 
type=12
Nov 29 22:14:24 server postfix/smtp[6740]: warning: TLS library problem: 
6740:error:0D07A0A0:asn1 encoding routines:ASN1_mbstring_copy:unknown 
format:a_mbstr.c:142:
Nov 29 22:14:24 server postfix/smtp[6740]: mx2.mlp-ag.com[195.170.185.78]:25: 
Trusted subject_CN=, issuer_CN=VeriSign Class 3 Extended Validation SSL SGC CA
Nov 29 22:14:24 server postfix/smtp[6740]: Trusted TLS connection established 
to mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA 
(256/256 bits)
Nov 29 22:14:24 server postfix/smtp[6740]: 193A714002: Server certificate not 
verified
Nov 29 22:14:25 server postfix/smtp[6740]: setting up TLS connection to 
mx1.mlp-ag.com[195.170.185.77]:25
Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: 
TLS cipher list ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL
Nov 29 22:14:25 server postfix/smtp[6740]: looking for session 
smtp:195.170.185.77:25:mx1.mlp-ag.comp=1c=ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL
 in smtp cache
Nov 29 22:14:25 server postfix/smtp[6740]: SSL_connect:before/connect 
initialization
Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: 
certificate verification depth=3 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=Class 3 Public Primary Certification Authority
Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: 
certificate verification depth=2 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use 
only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: 
certificate verification depth=1 verify=1 subject=/C=US/O=VeriSign, 
Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa 
(c)06/CN=VeriSign Class 3 Extended Validation SSL SGC CA
Nov 29 22:14:25 server postfix/smtp[6740]: mx1.mlp-ag.com[195.170.185.77]:25: 
certificate verification depth=0 verify=1 
subject=/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/2.5.4.15=V1.0,
 Clause 5.(b)/serialNumber=HRB 

Re: Enforced TLS issue after Postfix upgrade

[Victor Duchovni]

On Tue, Nov 30, 2010 at 02:44:31AM +, Mueller, Martin (Messaging) wrote:

 After upgrading from 2.5.x to 2.7.1 mail started queuing up to one
 particular domain (TLS security level: verify) with Server certificate
 not verified.

Postfix TLS support has not changed noticeably since 2.5.

 Systems still on 2.5.x versions of Postfix transmit messages to that
 domain via enforced TLS just fine. Based on some testing with different
 version it seems that the change in behavior started with 2.6.0.

What's new in 2.6/2.7 is that finally and with good reason SSLv2 and
its associated ciphers are disabled by default.

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

It is also likely that are you are using a more recent version of OpenSSL,
this can be more significant than any minor changes in Postfix.

 The ST part of the CN contains an encoded string sequence of \xC3\xBC
 that  represents the German u Umlaut.

The ST as you say, is not part of the CN it is part of the
Distinguished Name or DN. Parts of the DN that are not the CN do
not matter for peer verification.

 We  have tons of domains setup for enforced TLS and this is the only one that 
 is causing trouble. Warning messages in the log file
 are also tied to asn1 encoding and eventually CN appears with no value in the 
 log. Which seems to suggest that the asn 1 encoded
 character is what causes the trouble.

This is almost certainly a Red Herring.

 initializing the client-side TLS engine
 setting up TLS connection to mx2.mlp-ag.com[195.170.185.78]:25
 mx2.mlp-ag.com[195.170.185.78]:25: TLS cipher list 
 ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL

Your TLS log level is a bit too verbose.

 Nov 29 22:14:24 server postfix/smtp[6740]: warning: TLS library problem: 
 6740:error:0D07A0A0:asn1 encoding routines:ASN1_mbstring_copy:unknown 
 format:a_mbstr.c:142:

Harmless noise unless you have peername verification turned on. What is
the configured TLS security level?

 Nov 29 22:14:24 server postfix/smtp[6740]: Trusted TLS connection established 
 to mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA 
 (256/256 bits)

The TLS handshake completes.

 Nov 29 22:14:24 server postfix/smtp[6740]: 193A714002: Server certificate not 
 verified

But you appear to have peername verification turned on. What is your
tls security level for this destination?

When testing with Postfix 2.7 compiled against OpenSSL 1.0.0a and also
1.0.0b with two patches from the upcoming 1.0.0c (due any day now)
everything is normal. Your OpenSSL is perhaps less fortuitously selected
than mine.

smtp-finger: Connected to mx2.mlp-ag.com[195.170.185.78]:25
smtp-finger:  220 mx2.mlp-ag.com ESMTP
smtp-finger:  EHLO amnesiac.example.com
smtp-finger:  250-mx2.mlp-ag.com
smtp-finger:  250-8BITMIME
smtp-finger:  250-SIZE 104857600
smtp-finger:  250 STARTTLS
smtp-finger:  STARTTLS
smtp-finger:  220 Go ahead with TLS
smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25 Matched CommonName mx2.mlp-ag.com
smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25: Matched 
subject_CN=mx2.mlp-ag.com, issuer_CN=VeriSign Class 3 Extended Validation SSL 
SGC CA
smtp-finger: mx2.mlp-ag.com[195.170.185.78]:25 sha1 fingerprint 
90:9A:37:16:7B:DB:5E:D4:0D:72:2F:E4:AA:38:4C:5C:9A:12:59:21
smtp-finger: Verified TLS connection established to 
mx2.mlp-ag.com[195.170.185.78]:25: TLSv1 with cipher DHE-RSA-AES256-SHA 
(256/256 bits)
---
Certificate chain
 0 
s:/1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/businessCategory=V1.0,
 Clause 5.(b)/serialNumber=HRB 
335755/C=DE/postalCode=69168/ST=Baden-W\xC3\xBCrttemberg/L=Wiesloch/street=Alte 
Heerstrasse 40
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at 
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended Validation SSL 
SGC CA
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5c:15:d9:5e:08:43:61:e7:6e:40:76:e5:a3:cd:7b:bc
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of 
use at https://www.verisign.com/rpa (c)06, CN=VeriSign Class 3 Extended 
Validation SSL SGC CA
Validity
Not Before: Jul  1 00:00:00 2010 GMT
Not After : Jul  1 23:59:59 2011 GMT
Subject: 
1.3.6.1.4.1.311.60.2.1.3=DE/1.3.6.1.4.1.311.60.2.1.1=Mannheim/businessCategory=V1.0,
 Clause 5.(b)/serialNumber=HRB 335755, C=DE/postalCode=69168, 
ST=Baden-W\xC3\xBCrttemberg, L=Wiesloch/street=Alte Heerstrasse 40, O=MLP 
Finanzdienstleistungen Aktiengesellschaft, OU=e-Services, CN=mx2.mlp-ag.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ba:9e:2d:b9:ea:23:90:d5:a1:28:71:d3:cf:a8:
e5:4b:d0:da:2a:00:c4:21:40:8d:77:43:b8:df:73:
49:f9:d2:e8:ae:85:43:74:e1:aa:e2:53:8c:4b:54:
41:0f:b7:62:85:8b:3d:ad:e6:5c:ca:f7:f8:af:4d:

Re: Enforced TLS issue after Postfix upgrade

[Victor Duchovni]

On Tue, Nov 30, 2010 at 12:56:08AM -0500, Victor Duchovni wrote:

 When testing with Postfix 2.7 compiled against OpenSSL 1.0.0a and also
 1.0.0b with two patches from the upcoming 1.0.0c (due any day now)
 everything is normal. Your OpenSSL is perhaps less fortuitously selected
 than mine.

I get the same (successfully decoded CN) results with 0.9.8p and
Postfix 2.5. I don't have a build of Postfix 2.7 with OpenSSL 0.9.8.
What combination are you using? It sounds like your OpenSSL has a problem
parsing the CN encoding, this happens very far away from Postfix code,
entirely within OpenSSL.

-- 
Viktor.