[pfx] OpenSSL compile vs. runtime version warning

Hi > warning: run-time library vs. compile-time header version mismatch: > OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0 Is this warning still relevant with OpenSSL's new versioning scheme, where OpenSSL 3.x releases are guaranteed[1] to be ABI compatible ? [1] http

[pfx] Re: OpenSSL compile vs. runtime version warning

On Thu, Oct 24, 2024 at 10:50:18AM +0200, Geert Hendrickx via Postfix-users wrote: > > warning: run-time library vs. compile-time header version mismatch: > > OpenSSL 3.4.0 may not be compatible with OpenSSL 3.3.0 > > Is this warning still relevant with OpenSSL's new ver

[pfx] Re: OpenSSL compile vs. runtime version warning

On Thu, Oct 24, 2024 at 20:00:05 +1100, Viktor Dukhovni via Postfix-users wrote: > And this is the logic used in Postfix >= 3.10-20240612, but while you've > upgraded to a shiny new OpenSSL, you haven't also upgraded to a shiny new > Postfix snapshot. :-) This is usi

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Mon, Sep 23, 2024 at 08:55:14AM -0400, Wietse Venema via Postfix-users wrote: > And thanks for expanding the TLAs (*). No worries, I should perhaps note a terminology nit, KEMs are Key Encapsulation Mechanisms, rather than Key Encapsulation Methods, though IMHO it hardly matters. https://

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

rgot that detail, fair enough. Still not sure this warrants an > entry in the RELEASE_NOTES file, but if it does, it could read: > > [Feature 2024] Support for provider-based OpenSSL 3.x key > encapsulation methods (KEMs, generalisation of key exchange groups). In >

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

but if it does, it could read: [Feature 2024] Support for provider-based OpenSSL 3.x key encapsulation methods (KEMs, generalisation of key exchange groups). In prior Postfix versions it was not possible to use KEMs loaded from an external (not built-in to OpenSSL) "provide

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Mon, Sep 23, 2024 at 18:32:00 +1000, Viktor Dukhovni via Postfix-users wrote: > This is not a release-notes-worthy change, just avoids loss of minor forensic > detail for externally loaded kex "groups" (or, more generally, KEMs). That's only true for the very last change - but the entire chang

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Mon, Sep 23, 2024 at 10:09:12AM +0200, Geert Hendrickx via Postfix-users wrote: > Tested with OpenSSL 3.0 as well now (RHEL 9 version), with oqs-provider added. > > $ openssl version > OpenSSL 3.0.7 1 Nov 2022 (Library: OpenSSL 3.0.7 1 Nov 2022) > > $ ./bin/pos

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Fri, Sep 20, 2024 at 20:06:43 +1000, Viktor Dukhovni via Postfix-users wrote: > If it is possible to test kyber768 with OpenSSL 3.0 or 3.1, please do, > and post your findings to the list. Tested with OpenSSL 3.0 as well now (RHEL 9 version), with oqs-provider added. $ openssl v

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Fri, Sep 20, 2024 at 01:53:10AM +1000, Viktor Dukhovni via Postfix-users wrote: > Let's let the code bake in, and if nothing further needs to change, I'll > drop Wietse a fresh pointer to the git branch. I looked more closely at the available OpenSSL APIs, and found a way f

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 05:04:03PM +0200, Geert Hendrickx via Postfix-users wrote: > On Fri, Sep 20, 2024 at 00:40:35 +1000, Viktor Dukhovni via Postfix-users > wrote: > > > So you should be able to apply the top-most commit at: > > > > https://github.com/vdukhovni/postfix/commits/provide

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Fri, Sep 20, 2024 at 00:40:35 +1000, Viktor Dukhovni via Postfix-users wrote: > So you should be able to apply the top-most commit at: > > https://github.com/vdukhovni/postfix/commits/provider-kex/ > > to a Postfix 3.10-20240917 (or earlier, modulo the expected conflict in > the HISTORY

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

and X25519, the key_share > succeeds from first ClientHello, no HRR (as I'm consciously sending only > one group in these tests). Ah, this is in fact expected, a KEM is not an (EC)DH-like key exchange, the client never receives a server public key, so there's no plausible peer_dh_pubk

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 21:41:44 +1000, Viktor Dukhovni via Postfix-users wrote: > Can you build Postfix after running "makedefs" with "OPT='-g -ggdb3'", > and set a break-point in posttls-finger at line ~1054 of tls_misc.c: > > 1054 if (tls_get_peer_dh_pubkey(ssl, &dh_pkey)) { With a PQ

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

Viktor Dukhovni via Postfix-users: > On Thu, Sep 19, 2024 at 10:01:16AM +0200, Geert Hendrickx via Postfix-users > wrote: > > > > Anonymous TLS connection established from X: TLSv1.3 with cipher > > > TLS_AES_128_GCM_SHA256 > > > (128/128 bits) key-exchange x25519_kyber768 server-signature ECDSA

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 12:36:23PM +0200, Geert Hendrickx via Postfix-users wrote: > It works, and it's even interoperable with gmail's MX. But provider > key exchanges aren't logged for outbound connections by smtp(8) or > posttls-finger: That's unexpected, it is the same code generating the l

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 17:44:36 +1000, Viktor Dukhovni via Postfix-users wrote: > Try the below: Perfect: > Anonymous TLS connection established from X: TLSv1.3 with cipher > TLS_AES_128_GCM_SHA256 > (128/128 bits) key-exchange x25519_kyber768 server-signature ECDSA > (prime256v1) > server-di

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 19:10:05 +1000, Viktor Dukhovni via Postfix-users wrote: > On Thu, Sep 19, 2024 at 10:01:16AM +0200, Geert Hendrickx via Postfix-users > wrote: > > > > Anonymous TLS connection established from X: TLSv1.3 with cipher > > > TLS_AES_128_GCM_SHA256 > > > (128/128 bits) key-e

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

gt; > > Good to know it worked, I did not have an easy way to test this, since > > no such providers are built on my end. Test drive this some more, and > > if all is well, I'll send the combined patch to Wietse (or he can of > > course extract both parts from th

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

from this thread). I take it this change would appear in Postfix 3.10.0? Will this bump the minimum openssl version to 3.x? If so what would be the exact minimum version? For my EL8 and 9 builds I can work with a minimum openssl version <= 3.0.7. Thanks, Peter

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 05:44:36PM +1000, Viktor Dukhovni via Postfix-users wrote: > > (FWIW, nginx logs unknown groups by their group id, in this case "0x6399") > > > > https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L5138 > > Not terribly friendly/useful. To be preci

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 10:01:16AM +0200, Geert Hendrickx via Postfix-users wrote: > > Anonymous TLS connection established from X: TLSv1.3 with cipher > > TLS_AES_128_GCM_SHA256 > > (128/128 bits) key-exchange x25519_kyber768 server-signature ECDSA > > (prime256v1) > > server-digest SHA256 >

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 09:02:39AM +0200, Geert Hendrickx via Postfix-users wrote: > Could the reverse lookup be fixed as well, for Received headers and logging? > > > Anonymous TLS connection established from X: TLSv1.3 with cipher > > TLS_AES_128_GCM_SHA256 > > (128/128 bits) key-exchange UND

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 08:26:53 +0200, Geert Hendrickx via Postfix-users wrote: > I confirm your patch works, I can now use these new key exchanges in Postfix. Could the reverse lookup be fixed as well, for Received headers and logging? > Anonymous TLS connection established from X: TLSv1.3 wi

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 12:54:41 +1000, Viktor Dukhovni via Postfix-users wrote: > Not a problem, the proposed decoration would be part of the element, but > I'm arguing that it is not needed. > > https://github.com/openssl/openssl/issues/21633#issuecomment-2359871975 I agree

[pfx] Re: Patch: Postfix and OpenSSL provider algorithms

f DEF_TLS_FFDHE_AUTO); + VSTRING_RESET(names); +/* + * OpenSSL does not tolerate duplicate groups in the requested list. + * Dedup case-insensitively, just in case OpenSSL some day supports + * case-insensitve group lookup. Users who specify the group name twice + * and get the

[pfx] Re: Postfix and OpenSSL provider algorithms

nce they're available in the OpenSSL runtime. > > Well actually, in this case it achieves the opposite, as the individual > checking prohibits using newer groups from an external provider. Only for a handful of early adopters who want to test-drive bleeding-edge algorithms on

[pfx] Re: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 02:02:50 +1000, Viktor Dukhovni via Postfix-users wrote: > This makes it possible to write "forward-looking" configs that will use > newer groups once they're available in the OpenSSL runtime. Well actually, in this case it achieves the opposi

[pfx] Re: Postfix and OpenSSL provider algorithms

On Wed, Sep 18, 2024 at 05:38:25PM +0200, Geert Hendrickx via Postfix-users wrote: > Oh, I see now. If SSL_CTX_set1_curves_list() is defined, nginx runs > it directly on the whole list (without checking the elements first). > OBJ_sn2id is only used for older openssl. The problem is

[pfx] Re: Postfix and OpenSSL provider algorithms

On Thu, Sep 19, 2024 at 01:01:42 +1000, Viktor Dukhovni via Postfix-users wrote: > The OBJ_sn2nid() function is not extensible, and not affected by loading > of providers. To actually be able to map this algorithm to a "nid", the > base OpenSSL code would have to know abo

[pfx] Re: Postfix and OpenSSL provider algorithms

); > > continue; > > } > > Indeed it already fails at one of the *2nid calls. nginx uses only > OBJ_sn2nid: > > https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L1540 Well, if OBJ_sn2nid(group) had succeeded, the message

[pfx] Re: Postfix and OpenSSL provider algorithms

On Wed, Sep 18, 2024 at 14:02:32 +0200, Geert Hendrickx via Postfix-users wrote: > On Wed, Sep 18, 2024 at 21:29:07 +1000, Viktor Dukhovni via Postfix-users > wrote: > > You should initially test with "posttls-finger", > > `posttls-finger -L ssl-debug` shows succesful TLS negotiation, but without

[pfx] Re: Postfix and OpenSSL provider algorithms

On Wed, Sep 18, 2024 at 21:29:07 +1000, Viktor Dukhovni via Postfix-users wrote: > On Wed, Sep 18, 2024 at 01:04:58PM +0200, Geert Hendrickx wrote: > > > Specifically, this provider implements new Key Encapsulation Methods like > > "x25519_kyber768", which I can use wi

[pfx] Re: Postfix and OpenSSL provider algorithms

On Wed, Sep 18, 2024 at 01:04:58PM +0200, Geert Hendrickx wrote: > Specifically, this provider implements new Key Encapsulation Methods like > "x25519_kyber768", which I can use with `openssl s_server -groups`, or with > nginx as `ssl_ecdh_curve`, but not with Postfix in `tl

[pfx] Postfix and OpenSSL provider algorithms

Hi Viktor I was recently playing around with oqs-provider[1] for PQC support in openssl, but couldn't get it to work with Postfix 3.9.0 for TLSv1.3 key exchange. Specifically, this provider implements new Key Encapsulation Methods like "x25519_kyber768", which I can use with `o

PATCH: build error with OpenSSL 1.0.2

This patch addresses a build error for Postfix-3.4.28 and Postfix-3.5.18 with OpenSSL 1.0.2. Undefined first referenced symbol in file EVP_MD_CTX_new ../../lib/libtls.a(tls_fprint.o) EVP_MD_CTX_free

Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange

e underlying coefficient finite fields for the EC groups > are not based on the same primes as any of the FFDHE groups, and even > if some of the primes were the same, these are still independent code > points. > > I'll post a patch before too long. Attached. -- Viktor.

Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange

need two parameters with > > the below defaults: > > > > tls_eecdh_auto_curves = X25519 X448 prime256v1 secp521r1 secp384r1 > > tls_ffdhe_auto_groups = ffdhe2048 ffdhe3072 > > > > When Postfix is linked with OpenSSL 3.0, the two lists will be merged >

Re: [Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange

e always > from a negotiated list of well-known groups (no ad-hoc key exchange > parameters). > > --- OpenSSL 1.1.1 > > In OpenSSL 1.1.1 the TLS 1.3 implementation supports only EC key exchange > (ECDHE and ECX), the finite-field (FFDHE) groups are available only for TLS > 1

[Devel] OpenSSL 3.0 + TLS 1.3 and FFDHE key exchange

-known groups (no ad-hoc key exchange parameters). --- OpenSSL 1.1.1 In OpenSSL 1.1.1 the TLS 1.3 implementation supports only EC key exchange (ECDHE and ECX), the finite-field (FFDHE) groups are available only for TLS 1.0–1.2. The APIs for configuring FFDHE parameters and ECDHE curves are separate

Re: Patch: workaround: Fatal - Unexpected Message returned with OpenSSL 3.0

On Wed, Jul 06, 2022 at 12:07:51AM -0400, Viktor Dukhovni wrote: > On Mon, Jul 04, 2022 at 04:32:42PM +0200, Spil Oss wrote: > > > Since migrating to OpenSSL 3.0 we are experiencing intermittent issues > > in TLS handshakes. > > [...] > > the client returns a a F

Patch: workaround: Fatal - Unexpected Message returned with OpenSSL 3.0

On Mon, Jul 04, 2022 at 04:32:42PM +0200, Spil Oss wrote: > Since migrating to OpenSSL 3.0 we are experiencing intermittent issues > in TLS handshakes. > [...] > the client returns a a Fatal alert, unexpected_message. > > See also > * https://github.com/openssl/openssl/issu

Re: Fatal - Unexpected Message returned with OpenSSL 3.0

On Mon, Jul 04, 2022 at 04:32:42PM +0200, Spil Oss wrote: > https://github.com/openssl/openssl/issues/18690 It is very unlikely there's anything Postfix-specific here. So for now I am asking you to redirect follow ups to the OpenSSL issue page. > Network trace shows that any t

Fatal - Unexpected Message returned with OpenSSL 3.0

Since migrating to OpenSSL 3.0 we are experiencing intermittent issues in TLS handshakes. Old env: Ubuntu 21.10 / Postfix 3.5.6 / OpenSSL 1.1.1l New env: Ubuntu 22.04 / Postfix 3.6.4 / OpenSSL 3.0.2 (daily updated to latest available patches) Narrowed this down to Java / JavaMail clients

Re: is it possible to change the openssl security level?

Ok, I think I've got a partial workaround. If I'm reading the TLS 1.3 spec (and the output of `openssl ciphers -s -tls1_3`) correctly, it has an effective minimum of 128 bits of security with forward secrecy, not including the security of the public key(s) or PKIX signatures. So as l

Re: is it possible to change the openssl security level?

Op 23-09-2021 om 22:26 schreef Viktor Dukhovni: On Thu, Sep 23, 2021 at 10:02:26PM -0400, David Mandelberg wrote: With the settings below, postfix 3.5.6 and openssl 1.1.1k successfully connected to a server with a 2048-bit RSA key, which should be disallowed by openssl's security le

Re: is it possible to change the openssl security level?

On Thu, Sep 23, 2021 at 10:02:26PM -0400, David Mandelberg wrote: > With the settings below, postfix 3.5.6 and openssl 1.1.1k successfully > connected to a server with a 2048-bit RSA key, which should be > disallowed by openssl's security level 4. Postfix explicitly override

is it possible to change the openssl security level?

Hi, With the settings below, postfix 3.5.6 and openssl 1.1.1k successfully connected to a server with a 2048-bit RSA key, which should be disallowed by openssl's security level 4. tls_high_cipherlist = DEFAULT:!eNULL:!aNULL:@SECLEVEL=4:@STRENGTH smtp_tls_mandatory_ciphers = high When

Re: openssl error [solved]

On Tue, 13 Apr 2021 20:36:45 +1200 Peter wrote: > > Yes, but why 1 minute ok, 1 minute errors, 1 minute ok, etc etc? > > What's the TTL on the dkim TXT DNS record? Got it: the signing server consists of two servers and the keypair for one of the domains was not in sync. I think I created the ke

Re: openssl error

On Tue, 13 Apr 2021 20:36:45 +1200 Peter wrote: > > Yes, but why 1 minute ok, 1 minute errors, 1 minute ok, etc etc? > > What's the TTL on the dkim TXT DNS record? As I said: 3600 sec... -- richard lucassen http://contact.xaq.nl/

Re: openssl error

On 13/04/21 7:40 pm, richard lucassen wrote: On Tue, 13 Apr 2021 00:16:42 -0400 Viktor Dukhovni wrote: On Mon, Apr 12, 2021 at 07:23:50PM +0200, richard lucassen wrote: mail.info: Apr 12 18:01:16 opendkim[13977]: 828FE7F581: s=202103 d=example.com SSL error:0407008A:rsa routines:RSA_padding_

Re: openssl error

On Tue, 13 Apr 2021 00:16:42 -0400 Viktor Dukhovni wrote: > On Mon, Apr 12, 2021 at 07:23:50PM +0200, richard lucassen wrote: > > > mail.info: Apr 12 18:01:16 opendkim[13977]: 828FE7F581: s=202103 > > d=example.com SSL error:0407008A:rsa > > routines:RSA_padding_check_PKCS1_type_1:invalid paddin

Re: openssl error

On Mon, Apr 12, 2021 at 07:23:50PM +0200, richard lucassen wrote: > mail.info: Apr 12 18:01:16 opendkim[13977]: 828FE7F581: s=202103 d=example.com > SSL error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid > padding; > error: 04067072:rsa routines:rsa_ossl_public_decrypt:padding che

openssl error

.com; sleep 1 ; done minute 1: the DKIM is OK minute 2: errors, minute 3: the DKIM is OK minute 4: errors, minute 5: the DKIM is OK minute 6: errors, minute 7: the DKIM is OK minute 8: errors, etc etc I have really no idea where to start searching. It is perhaps a opendkim or an openssl issue.

Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)

14.05.20, 03:32 CEST, Viktor Dukhovni: > Are any other Debian users seeing similar issues? I did grep for "TLS library problem"[1] an 2 Debian 10 servers (low volume, though) and didn't find anything that seemed related. [1] The following came up empty: $ zgrep -i "TLS library problem" /var/log/

Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)

asting my time and the OP's chasing bugs in low-level internals if it could be that simple? Please avoid unproductive speculation that's not consistent with the symptoms. Don't just guess, your hypothesis is ruled out by the packet traces, and the OpenSSL errors on SSL_read() pu

Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)

>Is this the stock OpenSSL for your system, or your own build? There's just one OpenSSL library installed on the system, the stock version supplied by the OS's package manager. $ ldd | grep ssl libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 (0x7f13e45f

Re: (Calling Kurt Roeckx, Postfix + OpenSSL on Debian buster) (was: "SSL_Shutdown:shutdown while in init" while sending and receiving)

sending-and-receiving-td105822.html ] On Wed, May 13, 2020 at 06:03:42PM -0700, Alexander Vasarab wrote: > >Is this the stock OpenSSL for your system, or your own build? > > There's just one OpenSSL library installed on the system, the stock > version supplied by the OS's p

Re: CAfile problem with OpenSSL-1.1.1c

Hi Andreas, > Am 14.08.2019 um 10:01 schrieb A. Schulze : > > > Christian Rößner: > > Hello Christian, > >> By changing *_CAfile parameters to *_CApath, everything started working >> again. > > nothing specific to your OpenSSL version but:

Re: CAfile problem with OpenSSL-1.1.1c

Christian Rößner: Hello Christian, By changing *_CAfile parameters to *_CApath, everything started working again. nothing specific to your OpenSSL version but: do you run postfix chroot? from http://www.postfix.org/postconf.5.html#smtpd_tls_CApath: "To use smtpd_tls_CApath in c

CAfile problem with OpenSSL-1.1.1c

Hi, I recently upgraded my systems to have full openssl-1.1.1c support. After upgrading my mail-server, I realized that I had problems with trusting server certificates. I checked that the server still uses /etc/ssl/certs/ca-certificates.crt, but for some reason Postfix can not work with this

Re: Postfix 3.4.5, openssl 1.1.x, and TLS 1.3?

With Postfix 3.3 and earlier and OpenSSL 1.1.1 the signature algorithm and key exchange algorithm details are not logged when TLS 1.3 is used. This is because TLS 1.3 negotiates the signature algorithm and key exchange separately from the bulk encryption cipher code point. No HOW-TO is required.

Postfix 3.4.5, openssl 1.1.x, and TLS 1.3?

Hello, I'm wanting to ensure my postfix configuration will work with TLS 1.3. Any suggestions/howtos? Thanks. Dave.

Re: Postfix vs. OpenSSL on Debian "buster".

On 24 Jan 2019, at 18:07, Viktor Dukhovni wrote: > This may be especially important with submission, where various > peripheral devices (fax-to-email, printers, ...) may only support > TLSv1. So the "buster" system-wide default of TLSv1.2 and up may > cause problems. The least likely to be patch

Postfix vs. OpenSSL on Debian "buster".

On Thu, Jan 24, 2019 at 05:19:44PM -0500, Scott Kitterman wrote: > I'm the Debian postfix > maintainer and part of why I'm on this list is to help with our distro > specific issues. Speaking of "distro-specific issues", I just today came across a Debian &quo

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

;> $ make -f Makefile.init makefiles CCARGS='-DUSE_TLS -DUSE_SASL_AUTH \ >>> -DDEF_SERVER_SASL_TYPE=\"dovecot\" \ >>> -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \ >>> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \ >>> -DDEF_DAEMON_DIR=\&qu

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

> On Nov 28, 2018, at 5:55 AM, James Brown wrote: > > $ locate opensslv.h > /usr/local/Cellar/openssl/1.0.2p/include/openssl/opensslv.h > /usr/local/Cellar/openssl/1.0.2q/include/openssl/opensslv.h > /usr/local/Cellar/openssl@1.1/1.1.1/include/openssl/opensslv.h > /usr

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

"s:DB_VERSION_MAJOR == 5:DB_VERSION_MAJOR == 6 || &:" -i src/util/dict_db.c My make directives. I have a number of openssls installed … but only use one of course set -- '-DUSE_TLS -I/usr/local/Cellar/openssl@1.1/1.1.1/include' set -- "$@" '-I/usr/local/opt/icu

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

On Wed, Nov 28, 2018 at 11:00:33PM +1100, James Brown wrote: > > On 28 Nov 2018, at 10:38 pm, Herbert J. Skuhra wrote: > > > > On Wed, Nov 28, 2018 at 09:55:02PM +1100, James Brown wrote: > >> I have installed OpenSSL v1.1.1 via Homebrew. I’m trying to install >

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

> On 28 Nov 2018, at 10:38 pm, Herbert J. Skuhra <mailto:herb...@gojira.at>> wrote: > > On Wed, Nov 28, 2018 at 09:55:02PM +1100, James Brown wrote: >> I have installed OpenSSL v1.1.1 via Homebrew. I’m trying to install Postfix >> 3.3.2 but it always ends with:

Re: Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

On Wed, Nov 28, 2018 at 09:55:02PM +1100, James Brown wrote: > I have installed OpenSSL v1.1.1 via Homebrew. I’m trying to install Postfix > 3.3.2 but it always ends with: > > cc -I. -I../../include -DUSE_TLS -DUSE_SASL_AUTH > -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DDEF

Compile error on Mojave (Postfix 3.3.2): 'openssl/opensslv.h' file not found

I have installed OpenSSL v1.1.1 via Homebrew. I’m trying to install Postfix 3.3.2 but it always ends with: cc -I. -I../../include -DUSE_TLS -DUSE_SASL_AUTH -DDEF_SERVER_SASL_TYPE=\"dovecot\" -DDEF_COMMAND_DIR=\"/usr/local/sbin\" -DDEF_CONFIG_DIR=\"/usr/local/etc/po

Re: [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

> On Sep 11, 2018, at 11:20 AM, Viktor Dukhovni > wrote: > > All supported Postfix releases (3.0, 3.1, 3.2, 3.3 and the 3.4 snapshots) > work with OpenSSL 1.1.x at their most recent patch levels. This was done > some time back. Small correction, not all the "bitr

Re: [m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

> On Sep 11, 2018, at 10:17 AM, The Doctor wrote: > > Yes. I would encourage *all* applications still on the 1.0.x API to move > to 1.1.1 asap. By the end of next year there will be no supported > OpenSSL version that has the old API. All supported Postfix releases (3.0, 3.

[m...@openssl.org: Re: [openssl-users] openssl 1.0.2 and TLS 1.3]

- Forwarded message from Matt Caswell - Date: Tue, 11 Sep 2018 15:01:38 +0100 From: Matt Caswell To: openssl-us...@openssl.org Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 On 11

Patch: Postfix 3.2 snapshots 1227 & 1231 (missing TLS_method with OpenSSL < 1.1.0)

On Sun, Jan 01, 2017 at 11:12:19AM -0500, Wietse Venema wrote: > Florian Piekert: > > I am receiving compile errors for the recent snapshots. The 1224 > > compiles and works nicely, 1227 and 1231 do not compile on my > > opensuse 42.2 (nothing changed from 1224). > >

Re: How to forbid using openssl.. starttls to connect port 25?

> On Nov 9, 2016, at 9:54 AM, vod vos wrote: > > master.cf: > smtp inet ... smtpd > ... > -o smtp_relay_restrictions=$mua_relay_restrictions > -o smtp_recipient_restrictions=$mua_recipient_restrictions > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_auth_o

Re: How to forbid using openssl.. starttls to connect port 25?

it seem modify "-o smtpd_sasl_auth_enable=no" below "smtp ... smtpd" work for me. then you could not auth successfully via port 25, and could auth successfully via port 587 using tls. thanks all. On 星期三, 09 十一月 2016 08:35:36 -0800Wietse Venema wrote

Re: How to forbid using openssl.. starttls to connect port 25?

vod vos: > What I want to do is to forbid AUTH PLAIN on port 25, /etc/postfix/main.cf: smtp ... smtpd -o smtpd_tls_auth_only=yes However, you should not enable AUTH on port 25 at all, when your submission clients connect to port 587. The port 25 service is for MTA-to-MTA traffic, and that sh

Re: How to forbid using openssl.. starttls to connect port 25?

What I want to do is to forbid AUTH PLAIN on port 25, and just on port 587. Thanks Wietse. > If smtpd_tls_security_level=may, the port 25 is still could not be forbided. You can't forbid connections made with "starttls s_client...". Where do you get the idea from that that is ev

Re: How to forbid using openssl.. starttls to connect port 25?

vod vos: > master.cf: > > smtp inet ... smtpd > ... > -o smtp_relay_restrictions=$mua_relay_restrictions > -o smtp_recipient_restrictions=$mua_recipient_restrictions > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_auth_only=yes > -o smtpd_sasl_auth_ena

Re: How to forbid using openssl.. starttls to connect port 25?

01:21:15 -0800Viktor Dukhovni <postfix-us...@dukhovni.org> wrote On Wed, Nov 09, 2016 at 12:47:05AM -0800, vod vos wrote: > How to forbid using openssl.. starttls to connect port 25? You can only do that by disabling TLS entirely, but that does not seem to be what yo

Re: How to forbid using openssl.. starttls to connect port 25?

That helps. Thanks. On 星期三, 09 十一月 2016 01:21:15 -0800Viktor Dukhovni <postfix-us...@dukhovni.org> wrote On Wed, Nov 09, 2016 at 12:47:05AM -0800, vod vos wrote: > How to forbid using openssl.. starttls to connect port 25? You can only do that by disabling TLS

Re: How to forbid using openssl.. starttls to connect port 25?

On Wed, Nov 09, 2016 at 12:47:05AM -0800, vod vos wrote: > How to forbid using openssl.. starttls to connect port 25? You can only do that by disabling TLS entirely, but that does not seem to be what you're asking for. On the receiving end, there is no way to distinguish between

How to forbid using openssl.. starttls to connect port 25?

hi, How to forbid using openssl.. starttls to connect port 25? Or how to forbid AUTH PLAIN on port 25, and just using port 587 for submission? Thanks.

Re: OpenSSL CVE-2016-0701

> On Jan 28, 2016, at 8:38 PM, Viktor Dukhovni > wrote: > > On Thu, Jan 28, 2016 at 08:36:02PM -0500, CSS wrote: > >> http://intothesymmetry.blogspot.com/2016/01/openssl-key-recovery-attack-on-dh-small.html >> >> It seems that there are a number of factors (

Re: OpenSSL CVE-2016-0701

On Thu, Jan 28, 2016 at 08:36:02PM -0500, CSS wrote: > http://intothesymmetry.blogspot.com/2016/01/openssl-key-recovery-attack-on-dh-small.html > > It seems that there are a number of factors (that I do not understand) > that determine whether an application is vulnerable. For examp

OpenSSL CVE-2016-0701

http://intothesymmetry.blogspot.com/2016/01/openssl-key-recovery-attack-on-dh-small.html It seems that there are a number of factors (that I do not understand) that determine whether an application is vulnerable. For example, Apache/mod_ssl is not. Is there enough information here to

Re: Cannot Start TLS: handshake failure (openssl command succeed)

On 2015-05-20 11:32, King Cao wrote: Dears, Hi, Currently my postfix need to delivery mails to exchange 2003 and encounter handshake failure issue when setting up the TLS connection. posttls-finger failed but openssl succeeded. The remote exchange only support cipher: "RC4-SHA".

Cannot Start TLS: handshake failure (openssl command succeed)

Dears, Currently my postfix need to delivery mails to exchange 2003 and encounter handshake failure issue when setting up the TLS connection. posttls-finger failed but openssl succeeded. The remote exchange only support cipher: "RC4-SHA". The "RC4-SHA" is 71st place on

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Am 22.03.2015 um 23:33 schrieb Viktor Dukhovni: > Indeed external referefences would have been "U" rather "T". So your > build is different. The machine OP gave me access to had the 5.6 MySQL > client. The builds may well be different. > > The MySQL documentation: > > > https://dev.mysql.

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Am 22.03.2015 um 23:25 schrieb Matthias Andree: > Nothing else relating to zlib or libz. Full poudriere 3.1.1 build log > uploaded to > http://people.freebsd.org/~mandree/mysql55-client-5.5.42.log.xz > > There is some local /etc/make.conf stuff in the build but nothing > obviously related to zlib

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

On Sun, Mar 22, 2015 at 11:25:19PM +0100, Matthias Andree wrote: > > Try, "nm -D". I get: > > > > $ nm /usr/local/lib/mysql/libmysqlclient.so.18 | egrep 'deflate' > > 000ece80 T deflate > > 000ee2c0 T deflateBound > > 000ee510 T deflateCopy > > 000

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Am 22.03.2015 um 22:00 schrieb Viktor Dukhovni: > On Sun, Mar 22, 2015 at 09:34:12PM +0100, Matthias Andree wrote: > >> The strange thing is, on my system the mysqlclient library appears to >> include system zlib (10.1-RELEASE amd64): >> >> $ pkg which /usr/local/lib/mysql/libmysqlclient.so.18 >>

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Matthias Andree: [ Charset windows-1252 converted... ] > Am 22.03.2015 um 20:46 schrieb Wietse Venema: > > > Ignore the patch. The crashes are the result of a name conflict > > with the non-system zlib implementation that is bundled with MySQL. > > The fix is to build mysql with the system zlib im

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

On Sun, Mar 22, 2015 at 09:34:12PM +0100, Matthias Andree wrote: > The strange thing is, on my system the mysqlclient library appears to > include system zlib (10.1-RELEASE amd64): > > $ pkg which /usr/local/lib/mysql/libmysqlclient.so.18 > /usr/local/lib/mysql/libmysqlclient.so.18 was installed

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Am 22.03.2015 um 20:46 schrieb Wietse Venema: > Ignore the patch. The crashes are the result of a name conflict > with the non-system zlib implementation that is bundled with MySQL. > The fix is to build mysql with the system zlib implementation. The strange thing is, on my system the mysqlclient

Re: PATCH: Postfix / OpenSSL signal 11 on delivery from ebay

Wietse Venema: > Summary: the Postfix SMTP server crashes with signal 11 on FreeBSD > 10.1-RELEASE when some library (below, the MySQL client) links zlib > at build time, and OpenSSL from ports tries to load zlib lazily at > runtime (zlib-dynamic is enabled by default). > > To

Re: Postfix / OpenSSL signal 11 on delivery from ebay

Viktor Dukhovni: > On Sun, Mar 22, 2015 at 09:07:22AM -0400, Wietse Venema wrote: > > > BTW mysql does not link in its own libz. Postfix links the > > system libz because MYSQL_README requires it: > > What I was alluding to is that the sources for the mysql-client > (MySQL 5.6) package include zl

Re: Postfix / OpenSSL signal 11 on delivery from ebay

On Sun, Mar 22, 2015 at 09:07:22AM -0400, Wietse Venema wrote: > BTW mysql does not link in its own libz. Postfix links the > system libz because MYSQL_README requires it: What I was alluding to is that the sources for the mysql-client (MySQL 5.6) package include zlib 1.2.3 sources which are comp

  1   2   3   >